Securing repository binaries

Here is the place were the team and the community projects meet together. Help us to develop SolydXK projects or contribute your ideas for future releases.
User avatar
ilu
Posts: 2716
Joined: 09 Oct 2013 12:45

Securing repository binaries

Postby ilu » 09 Jul 2020 15:10

I've just read https://netzpolitik.org/2020/staatstroj ... n-koennen/ - sorry only in german. No need to read it - the article is discussing Finfisher and similar technics and their implementation on provider level to place malware into targeted systems. The appropriate counter measure would be signing and verification of binaries.

I investigated this topic some years ago but I don't remember exactly the results. As far as I can see gpg verification is set to no-debsig in /etc/dpkg/dpkg.cfg and changing this does not seem to be easy, https://blog.packagecloud.io/eng/2014/1 ... ositories/. This article is from 2014 - does anybody know how much things changed since then? I know source packages are signed, I'm talking about binaries only.

There is also SecureApt https://wiki.debian.org/SecureApt but I don't remember how this works exactly.

Can anybody please investigate this, explain the current state of things at debian and recommend necessary changes for us, if any? I'm short of time atm.

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Securing repository binaries

Postby grizzler » 09 Jul 2020 19:03

As far as I'm aware, the whole setup is based on a 'chain' of hashes and a signed piece of metadata.

- Release/InRelease files list Packages files with their hashes;
- Packages files list .deb files with their hashes.

Current versions of apt check the hashes and the signatures on the Release files before packages are installed. A hash mismatch on any level means the relevant file does not correspond with the signed Release file. So as long as the Release file can be trusted, the entire chain should be covered. In theory, that could fail if the key used to sign the Release file was stolen. I'm not sure how feasible that is...
Frank

SolydX EE 64 - tracking Debian Testing

kurotsugi
Posts: 2274
Joined: 09 Jan 2014 00:17

Re: Securing repository binaries

Postby kurotsugi » 10 Jul 2020 03:47

that sign and verify mechanism would be easy on a single repo model (i.e: google playstore) but I'm not sure how it will works with multiple repo model commonly found in linux ecosystem. I think similar situation happened with UEFI system some year ago. in the end, most vendor only accept binaries signed by microsoft and causing every other OS except windows uninstallable. we solved the issue by having a "shim" signed by microsoft which in reality makes sign-verify mechanism kind of pointless.

IIRC the apt security system got breached several years ago (at minimum it was twice. one happened with linuxmint and the other one related with gpg bug). which means that current apt security system is not better than sign-verify mechanism. but since the attack use MiTM model, the solution is not always lies on the apt itself but also how we transport the package. IIRC it is the reason why debian pushed https protocol into apt. basicly, using any means of securing the data transfer (https, DoH, DoT, etc) will also enhance the apt.

User avatar
grizzler
Posts: 2217
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: Securing repository binaries

Postby grizzler » 10 Jul 2020 06:07

If I remember correctly, the linuxmint issue was a rogue mirror distributing contaminated ISOs. I don't think it had anything to do with apt's mechanism. I can't recall the gpg bug, but since gpg is at the heart of the entire system, once that's borked, well...
Frank

SolydX EE 64 - tracking Debian Testing

kurotsugi
Posts: 2274
Joined: 09 Jan 2014 00:17

Re: Securing repository binaries

Postby kurotsugi » 11 Jul 2020 21:40

perhaps I'm getting old :lol:
I thought that rogue mirror was also related with apt but it seems that I was wrong. And yes, apt wasn't breached directly but since gpg is the center of apt security mechanism, apt is also affected. perhaps I'm also wrong with my words selection. this gpg related breach AFAIK is a theorical one. There's no actual breach on apt

I think this is an interesting article
https://blog.packagecloud.io/eng/2018/0 ... ositories/


Return to “Suggestions & ideas / Open Projects”

Who is online

Users browsing this forum: No registered users and 1 guest