*** Please type your report below this line ***

Georgi Guninski reported on Full Disclosure a potential bug in apt-key's
use of gpg --list-sigs, when comparing keys to the master keyring in
add_keys_with_verify_against_master_keyring(), revealing a potential
MITM attack for adding keys.

You can find the original emails here:
http://marc.info/?l=full-disclosure&m=131668247124444&w=2

It is a legitimate bug, as far as I can tell, but could use confirmation.

The original message is copied below.
- Chris



  From: Georgi Guninski <guninski@guninski.com>
  To: full-disclosure@lists.grok.org.uk
  Date: Thu, 22 Sep 2011 12:07:08 +0300
  Subject: owning ubuntu apt-key net-update (maybe apt-get
          update related)

  owning ubuntu apt-key net-update (maybe apt-get update related)

  in ubuntu 10.04 in /usr/bin/apt-key in
  add_keys_with_verify_against_master_keyring()

  if $GPG_CMD --keyring $ADD_KEYRING --list-sigs --with-colons $add_key | grep
  ^sig | cut -d: -f5 | grep -q $master_key; then
                  $GPG_CMD --quiet --batch --keyring $ADD_KEYRING --export
  $add_key | $GPG --import
                  ADDED=1


  to my knowledge --list-sigs doesn't do crypto verification, just looks for well
  formedness.

  it is trivial to generate a gpg key with key ID == $master_key:
  set gpg version to 3, set the lowest 64 bits of the RSA $n$ to the key ID,
  generate random high bits until one can trial factor $n$ (numerology is on your
  side), this is it.

  to reproduce:
  attached is ubuntu-archive-keyring.gpg.
  put it on http://A/ubuntu-archive-keyring.gpg
  make a copy of apt-key and set:
  ARCHIVE_KEYRING_URI=http://A/ubuntu-archive-keyring.gpg
  ^ this emulates MITM.
  do |./apt-key-new net-update| and check for new keys with |apt-key list|

  this might or might not be related with |apt-get update|.

  10x.

It is a bug for Ubuntu. Debian's apt-key does not support net-update and
is thus not affected.

it doesn't have ARCHIVE_KEYRING_URI set, so the result of
running 'apt-key net-update' on a debian box is:
ERROR: Your distribution is not supported in net-update as no uri for
the archive-keyring is set

The only distribution i know of who enables this feature (as it was developed
by them) is Ubuntu which has immediately reacted by commenting the
mentioned variable out until a proper fix exists [0].

Note through that derivatives of ubuntu might use 'their' apt with the
feature enabled (which is depending on their release model useless/strange
 as their 'replacement' archive-keyring will properly not be signed by the
 ubuntu-master-key…) so these might be effected, too.

Or in short:
$ grep '^[^#]*ARCHIVE_KEYRING_URI[ ]*=' /usr/bin/apt-key
ARCHIVE_KEYRING_URI=""

If you have the same output you are save.
(I leave it as an exercise for the reader to come up with more complicated
 regexes to check for the value - for debian this one is already overkill…)


Best regards

David Kalnischkies

[0] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/856489

I'm not sure that's true.  On my system, with apt 0.8.10.3+squeeze1,
there is definitely a net-update command available:

case "$command" in
    add)
        $GPG --quiet --batch --import "$1"
        echo "OK"
        ;;
    del|rm|remove)
        $GPG --quiet --batch --delete-key --yes "$1"
        echo "OK"
        ;;
    update)
        update
        ;;
    net-update)
        net_update

But regardless of net-update, I think the real bug is the reliance on
--list-sigs instead of --check-sigs.

- Chris

I'm not sure that's true.  On my system, with apt 0.8.10.3+squeeze1,
there is definitely a net-update command available:

case "$command" in
    add)
        $GPG --quiet --batch --import "$1"
        echo "OK"
        ;;
    del|rm|remove)
        $GPG --quiet --batch --delete-key --yes "$1"
        echo "OK"
        ;;
    update)
        update
        ;;
    net-update)
        net_update

But regardless of net-update, I think the real bug is the reliance on
--list-sigs instead of --check-sigs.

- Chris

Hi,

I've reopened this bug and set the severity to normal in order to keep track
on the code this bug pointed at.

The cryptographic verification code used in the function called by apt-key
net-update is utterly broken.  The situation is not improved by replacing
"list-sigs" to "check-sigs", because still the key id strings (which are
absurdly short and easy to forge) are used to "verify" that a key has been
signed by another key.  This is broken.

This bug may be closed either when the code in apt-key has been replaced so
that the signatures are checked or the code is removed completely.

Regards,
- Alex

hi,

i am not sure --check-sigs will fix this.
the keyring contains the colliding ID pub key and according to my tests --check-sigs works too on ubuntu - the signatures are correct and the keys are present.

you can check with the keyring at:
http://marc.info/?l=full-disclosure&m=131668259924743&w=2

Hi,

* Georgi Guninski <guninski@guninski.com> wrote:

I am pretty sure that check-sigs will not fix this :)

What do you mean by "works too on ubuntu"?

When called with --list-sigs, the output is the same as when gpg is called
with --check-sigs, just an exclamation mark is added:

$ gpg --no-default-keyring --keyring ./ubuntu-archive-keyring.gpg --with-colons --list-sigs DB046AD3 | grep -v pub
[...]
sig:::17:8B56ED98DB046AD3:2011-09-21::::ubun1 <ubun1@aaaaaaa>:13x:
sig:::17:8B56ED98DB046AD3:2011-09-21::::ubun1 <ubun1@aaaaaaa>:18x:

$ gpg --no-default-keyring --keyring ./ubuntu-archive-keyring.gpg --with-colons --check-sigs DB046AD3 | grep -v pub
[...]
sig:!::17:8B56ED98DB046AD3:2011-09-21::::ubun1 <ubun1@aaaaaaa>:13x:
sig:!::17:8B56ED98DB046AD3:2011-09-21::::ubun1 <ubun1@aaaaaaa>:18x:

This suggests that it makes no difference whether gpg is called with
list-sigs or check-sigs here.

Regards,
- Alex

this is exactly my point - there is no difference, so --check-sig is
useless.

sorry for not being clear enough.

btw, even if vanilla debian is not vulnerable, IMO this should be fixed
or ditched because someone might chose to use the buggy code.

Hi,

* Georgi Guninski <guninski@guninski.com> wrote:

Great, I share your opinion, and that is exactly the reason why I reopened
this bug.

Thanks for reporting! :)

Regards,
- Alex

i don't think there are many ways to fix this.

a possible solution is
1. delete all keys with keyid==MASTER key from the archive keyring
(to prevent forged signatures)
2. add --keyring masterkeyring to gpg arguments
3. do --check-sigs taking care of unknown pubkeys

this might be buggy though.

I don't see a reason to have a bug open for code which we do not use. The
only people affected by this are downstream distributions, and the fix
will get in via Ubuntu once its there. Bugs in disabled code are no
bugs. And we already have a bug in Launchpad, right were people are
affected by this. And the APT developers are subscribed to both bug
trackers. If at all, that's a minor documentation issue for us.

Hi Julian,

* Julian Andres Klode <jak@debian.org> wrote:

In retrospect, I think my tone was too harsh when writing this, please
accept my apologies.

Hm.  I disagree. I still think this bug should remain open until the code is
properly fixed and has entered unstable, but I will accept your decision.

What do you propose?

Regards,
- Alexander

btw, there is strange behaviour with colliding gpg key IDs.

the first one totally shadows the second one, which might potentially be exploitable.

a possible scenario might be to trick the user to import the forged key ID first.

possibly this may add forged subkeys, not quite sure.

New incoming fax document.

Scanned fax document is attached to this email.

Sender:           Tyler Warner
File size:        105 Kb
Pages sent:       12
Resolution:       500 DPI
Date:             Wed, 28 Oct 2015 21:59:23 +0300
Filename:         document_0000971909.doc
Scanned in:       9 seconds

Thank you for using Interfax!