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

Marek Marczykowski-Górecki marmarek at invisiblethingslab.com
Fri Apr 3 01:10:52 CEST 2015

Hash: SHA1

On Thu, Apr 02, 2015 at 12:11:03PM +0000, Patrick Schleizer wrote:
> Hi!
> Does qubes-builder check for rollback (downgrade) or indefinite freeze
> attacks [1]?
> Threat model:
> - a user who builds from source code
> - building user successfully verified Qubes' source code
> - user doesn't manually ensure after build, that version numbers match,
> doesn't read the build log [unless it stops and shows errors], and
> relies that the verification chain is intact
> - git hosting compromised [2]
> - eventually targeting specific builders
> 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
> 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

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.

> I am very much into file verification, gpg, wrote gpg-bash-lib [6] where
> I'd appreciate feedback and sometimes report gpg usage security issues
> in other projects. [non-exhaustive list [7]]

In short we use git history to mitigate downgrades, but it can't be
easily used for file verification. Maybe you can setup git repo with a
file hash, then use signed tags there. But it's an overkill IMHO.

> 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

> Cheers,
> Patrick
> [1] "rollback (downgrade) or indefinite freeze attack"
> Defined as per TUF: Attacks and Weaknesses:
> - https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md
> - http://www.webcitation.org/6F7Io2ncN
> [2]
> * In case github gets hacked [3] again.
> * Or in cases similar to:
>  * SSL CA's such as DigiNotar was hacked or [4]
>  * comodo resellers that got hacked. [5]
> [3]
> http://www.extremetech.com/computing/120981-github-hacked-millions-of-projects-at-risk-of-being-modified-or-deleted
> [4] https://en.wikipedia.org/wiki/DigiNotar
> [5]
> http://www.scmagazine.com/two-more-comodo-resellers-owned-in-ssl-hack/article/199620/
> [6] https://github.com/Whonix/gpg-bash-lib
> [7] https://phabricator.whonix.org/T245

- -- 
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?
Version: GnuPG v1


More information about the Whonix-devel mailing list