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

Tue Apr 7 19:00:30 CEST 2015

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

On Sun, Apr 05, 2015 at 04:13:52AM +0000, Patrick Schleizer wrote:
> Marek Marczykowski-Górecki:
> > 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?
> 
> Similar to the Valid-Until field in Debian apt release files [and other
> package managers that use similar fields]:
> http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html
> 
> Well, that would be ideal, but that would also be something that the one
> who provides the file and signature would have to do, i.e. upstream. So
> if you wanted to do this, you could only do this for your own signatures
> and could only try to convince upstream of doing it as well. Worthwhile,
> sure, but unlikely to happen for every upstream.

Ok, I'll work on this, at least for our repos. But that would require
some rework of repos management scripts, so will take a while.

> > This is also not ideal because of manual work
> > required for that.
> 
> Yes.
> 
> > But maybe worth the effort?
> 
> Definitively.
> 
> > Maybe it is enough to add
> > another section in our warrant canaries (list of most recent tags on
> > source code)?
> 
> Dunno. Any place works as long as it's checked during build.
> 
> > I guess 3-month isn't frequent enough...
> 
> Yes.
> 
> >>>> 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.
> 
> Not sure. I specifically asked about this on gnupg-users mailing list.
> 'Are there cases where gpg --verify will exit 0, even if verification
> failed?'
> https://lists.gnupg.org/pipermail/gnupg-users/2015-January/052232.html
> 
> While I was not told any specific example as a great deterrence, my
> conclusion is, that gpg exit codes are totally not to be relied on.
> 
> > But indeed it would be good idea to
> > switch to either --status-fd, or gpgv (or both).
> 
> Yes.
> 
> Other options to consider (just consider, not arguing they are great,
> better, whatsoever):
> - gpg2
> - gppv2
> 
> Another subtlety to consider, checksec.sh on Debian wheezy reports, that
> gpg[v] has Partial RELRO and NO PIE vs gpg[v]2 that has FULL RELRO and PIE.
> 
> ***
> 
> A related point I would like to raise is another common misconception or
> unpopular fact about OpenPGP signatures. You might be aware of it, but I
> would invite you to specifically think it through wtr to the Qubes file
> [not git] verification code.
> 
> OpenPGP signatures do sign files. Not file names.

This isn't a problem for source tarballs, as the version is stored
inside archive (as a directory name). So if someone would provide
linux-3.12.11.tar.xz as linux-3.12.39.tar.xz, the build will fail
because there would be no linux-3.12.39 directory.

- -- 
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

iQEcBAEBAgAGBQJVJA0uAAoJENuP0xzK19cs4OAH/1HJEMts6G6vtG5dtlXKr9NM
86PmfBU10aIt01Oas9VoBsXfggu3D3XDlc+nEp04fAItnST7EdDdHWdh5t7zhzmv
kR0B7/8sbNTJpALD+U+itfttd7hH45IufG55s+GxbDP3cgPCcP3n0MjkVuyw4qHX
/230UfeF214J2anbuYVyckhTsChESOcYL7eFEvevPxwtYdnPcp0o6OJ6TbFW52Se
ieptjROQuEONKVTl5eorN9NqMgPNVZQQxtgqtBLcOSyGMEhZyXBY4MMaTQVbALD7
ktXNd3BNbQbW6RNgUG7OsKG3oLKWXqwWqxOhj5DAWNiuYYBd0waL6fsFDc2xGVw=
=JN75
-----END PGP SIGNATURE-----