[Whonix-devel] [qubes-devel] qubes-builder gpg verification security, check for rollback (downgrade) or indefinite freeze attacks

Sat Apr 4 01:58:18 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 03, 2015 at 04:06:48PM +0000, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
> > On Thu, Apr 02, 2015 at 12:11:03PM +0000, Patrick Schleizer wrote:
> >> function:
> >> verify_tag
> > 
> >> link:
> >> https://github.com/QubesOS/qubes-builder/blob/7d21e6b7b0a5ab3a68e8acdbc3f540f2221b47c0/scripts/verify-git-tag#L38
> > 
> >> code:
> >> gpg --verify --status-fd=1 $temp_name/content.asc 2>/dev/null|grep -q
> >> '^\[GNUPG:\] TRUST_\(FULLY\|ULTIMATE\)$'
> > 
> >> It does not check freshness? So any older tag/signature would be
> >> accepted, a rollback attack would succeed?
> > 
> > Yes, older tag/signature would be accepted in this function. But when
> > verified, it is *merged* into local sources, not *reseted*. So if you have
> > newer sources (in terms of git history) already downloaded it will not
> > downgrade it. Personally I use combo make prepare-merge + do-merge,
> > which additionally show me color coded info if the merge is
> > fast-forward or not (in addition to all the new commits to be merged).
> > Perhaps we should even introduce an option to fail on non-fast-forward
> > updates.
> > 
> > It doesn't protect you in any way against such type of attacks during
> > first time source download. But you can easily list version tags
> > (including release tags) - make show-vtags - and check if the versions
> > are what you've expected.
> 
> Git merge rather than reset is useful indeed. Prevents people who
> already got the sources from being targetd for rollback (downgrade)
> attacks. Wouldn't prevent indefinite freeze attacks, though.
> 
> Also users who get the source for the very first time are more at risk?
> At that point, nothing protects them from rollback (downgrade) attacks?
> 
> That's my main target audience here. People who prefer to build from
> source code to make sure they don't get backdoored by eventual backdoors
> in the binary builds injected by the build machine during build. [Not
> claiming any backdoor by the Qubes team. But build machines seem
> worthwhile targets to me for powerful adversaries.] Building from source
> code is a cheap way to prevent those. But if they buy that advantage of
> cost of eventual targeted rollback (downgrade) attacks, that's non-ideal.

AFAIK preventing this problem would require refreshing some signature
periodically, right? This is also not ideal because of manual work
required for that. But maybe worth the effort? Maybe it is enough to add
another section in our warrant canaries (list of most recent tags on
source code)? I guess 3-month isn't frequent enough...

> >> Having said that, do you have any other gpg verification code in other
> >> files that I could look into?
> > 
> > Some components downloads additional sources - like kernel, KDE, etc. There
> > is also code to verify that downloads - just a simple gpg -v with
> > isolated keyring (one key in most cases).  That keyring isolation is
> > provided by qubes-builder (scripts/get-sources).  When upstream do not
> > provide signatures, we have file hashes committed into the git repo.
> > This code is in Makefiles in those repositories:
> >  - linux-kernel
> >  - desktop-linux-kde
> >  - desktop-linux-xfce
> >  - vmm-xen
> >  - core-libvirt
> 
> I see. Checked linux-kernel. Code:
> 
> @xzcat $(SRC_FILE) | gpg -q --verify $(SIGN_FILE) - 2>/dev/null
> 
> I don't think this is safe.
> 
> Quote Werner Koch (gnupg lead developer):
> http://lists.gnupg.org/pipermail/gnupg-devel/2005-December/022559.html
> 
> "there is no clear distinction between the codes and for proper error
> reporting you are advised to use the --status-fd messages."

AFAIR this applies mostly to verifying key validity/trust. In our case
it shouldn't be a problem because of dedicated keyring with just the
key(s) to verify given component. But indeed it would be good idea to
switch to either --status-fd, or gpgv (or both).

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVHykaAAoJENuP0xzK19cs7lUH/2SBrkBdT4L3YoIwDpZOBfe7
cOENGYsb/U0rTK/cZil9vANdkwYbAY+mZSLJ8F3caUrsH8iWiak0JT4e7vKjsoYu
bxxJX45Z1OzFhLpV5Q3xVglw4QFWlhYpvWVbmN5CkeGOKRLxATo7/njNUVp2T23c
3hkxkdEj9e0w/GavIdGwhQ361eTDfrBrTRrZB6GhfXZIAjBZye1WQDyFuJM8cC8J
Gm9IJOGcLP1MrCjTG5phEB/9u/n6rn+6UClameq2IkzZ4JyPHFG0s7azU8w1Ayaa
Q6AmxWL+OmCfvIrgib7qb6udtPafMQpThbaF4Ycwn6wZLNDx4LODW0gnEfms4QA=
=FFf6
-----END PGP SIGNATURE-----