Bug 5775 - update signing key is not cross-signed
update signing key is not cross-signed
Status: RESOLVED FIXED
Product: Spamassassin
Classification: Unclassified
Component: sa-update
SVN Trunk (Latest Devel Version)
Other other
: P5 normal
: 3.2.5
Assigned To: SpamAssassin Developer Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-01-09 02:13 UTC by Justin Mason
Modified: 2008-05-01 04:13 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2008-01-09 02:13:05 UTC
from an "sa-update --debug" run with trunk:

[5142] dbg: gpg: calling gpg
[5142] dbg: gpg: gpg: Signature made Tue Jan 8 02:50:47 2008 CST using RSA key
ID 24F434CE
[5142] dbg: gpg: gpg: WARNING: signing subkey 24F434CE is not cross-certified
[5142] dbg: gpg: gpg: please see
http://www.gnupg.org/faq/subkey-cross-certify.html for more information
[5142] dbg: gpg: [GNUPG:] SIG_ID 3yStwCUIl80BUlPErS2/cOLxQgw 2008-01-08 1199782247
[5142] dbg: gpg: [GNUPG:] GOODSIG 6C55397824F434CE updates.spamassassin.org
Signing Key <release@spamassassin.org>
[5142] dbg: gpg: gpg: Good signature from "updates.spamassassin.org Signing Key
<release@spamassassin.org>"
[5142] dbg: gpg: [GNUPG:] VALIDSIG 0C2B1D7175B852C64B3CDC716C55397824F434CE
2008-01-08 1199782247 0 3 0 1 2 00 5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
[5142] dbg: gpg: [GNUPG:] TRUST_UNDEFINED
[5142] dbg: gpg: gpg: WARNING: This key is not certified with a trusted signature!
[5142] dbg: gpg: gpg: There is no indication that the signature belongs to the
owner.
[5142] dbg: gpg: Primary key fingerprint: 5E54 1DC9 59CB 8BAC 7C78 DFDC 4056
A61A 5244 EC45
[5142] dbg: gpg: Subkey fingerprint: 0C2B 1D71 75B8 52C6 4B3C DC71 6C55 3978
24F4 34CE
[5142] dbg: gpg: found signature made by key
0C2B1D7175B852C64B3CDC716C55397824F434CE
[5142] dbg: gpg: key id 0C2B1D7175B852C64B3CDC716C55397824F434CE is release trusted

http://www.gnupg.org/faq/subkey-cross-certify.html says:

There is a subtle weakness in the OpenPGP design for signing subkeys. Recall
that subkeys are signed by the primary key to show they belong to the primary
key. However, the signing subkey does not sign the primary to show that it is
owned by the primary. This allows an attacker to take a signing subkey and
attach it to their own key.

as it notes, we're using a signing subkey to do our signing:

bash-3.00$ gpg --homedir /home/updatesd/key --list-keys -v
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: using PGP trust model
/home/updatesd/key/pubring.gpg
------------------------------
pub   4096R/5244EC45 2005-12-20
uid                  updates.spamassassin.org Signing Key <release@spamassassin.org>
sub   4096R/24F434CE 2005-12-20


the FAQ notes:

GnuPG has code for adding this cross-certification to signing subkeys that were
issued before this change to the OpenPGP design. Just run "gpg --edit-key
(yourkey)" and then enter "cross-certify". You'll need to type your passphrase,
and GnuPG will add the cross-certification.

however the zone has gpg 1.4.2 and this is new in 1.4.3, so it'll reuqire
an upgrade.

the command, btw, will be something like this:

  sudo -H -u updatesd gpg --homedir /home/updatesd/key --edit-key 5244EC45
  cross-certify
  quit
Comment 1 Graham Murray 2008-01-09 14:32:09 UTC
I am seeing the same error with sa-update on 3.2.4 using gpg 2.0.8, and the
update fails with code 4.
Comment 2 Theo Van Dinter 2008-01-09 15:09:13 UTC
Maybe I'm missing something here (it does say this is a subtle issue), but ...  sa-update doesn't care 
about signed keys, just that the key which signed the file is in the list of "trusted keys" as given to it.  
so cross-signing doesn't change anything for us.  Also:

"This does not mean that an attacker can issue signatures pretending to be someone else: the attacker 
cannot issue any signatures from that subkey, as all they have is the public half. The only thing this 
allows an attacker to do is to take an existing signature issued by a signing subkey, and claim that it 
was issued by the attacker's own key. The end result is that the signature can be verified by both the 
actual signer's key and the attacker's key."

So if an attacker can't fake the signature, then who cares?
Comment 3 Sidney Markowitz 2008-01-09 15:31:36 UTC
> So if an attacker can't fake the signature, then who cares?

Maybe the threat is something like this, given that "The end result is that the
signature can be verified by both the actual signer's key and the attacker's
key": Alice signs her release of MalAssassin, which is going to be downloaded
and verified by Bob. Eve uses this vulnerability to cause Alice's signatures of
MalAssassin to verify against Eve's key, then convinces Bob that her key is a
new one to be used for MalAssassin downloads. Bob uses Eve's key, has no problem
verifying legitimate downloads of MalAssassin, and thus is fooled into using
Eve's key to verify a malware download of MalAssassin that Eve has signed.

And here is a stronger reason to cross-sign our key: Otherwise newer versions of
GPG will produce the scary warning message quoted in this bug's Description when
sa-update is run.

Comment 4 Theo Van Dinter 2008-01-09 16:37:51 UTC
(In reply to comment #3)
> > So if an attacker can't fake the signature, then who cares?
> 
> Maybe the threat is something like this, given that "The end result is that the
> signature can be verified by both the actual signer's key and the attacker's
> key": Alice signs her release of MalAssassin, which is going to be downloaded
> and verified by Bob. Eve uses this vulnerability to cause Alice's signatures of
> MalAssassin to verify against Eve's key, then convinces Bob that her key is a
> new one to be used for MalAssassin downloads. Bob uses Eve's key, has no problem
> verifying legitimate downloads of MalAssassin, and thus is fooled into using
> Eve's key to verify a malware download of MalAssassin that Eve has signed.

If Eve convinces Bob to trust a different key, then it doesn't matter what we do.

In our situation, Bob still trusts Alice's key for signing, and Eve can't sign malware using the key, so Bob 
can still trust that what he downloads is signed by Alice.  The fact that the key is associated w/ Eve's 
other keys/identifying information instead of Alice's doesn't matter to us.

> And here is a stronger reason to cross-sign our key: Otherwise newer versions of
> GPG will produce the scary warning message quoted in this bug's Description when
> sa-update is run.

Aha.  While the initial comment implies that validation still works, and there's just a warning ...  It 
appears that (which is what comment 1 also says) apparently the newer GPGs won't validate the 
signature at all...  I just tried a 3.1 update w/ my newly installed gpg 1.4.8:

[26406] dbg: gpg: calling gpg
[26406] dbg: gpg: gpg: Signature made Thu 18 Oct 2007 02:54:04 AM EDT using RSA key ID 24F434CE
[26406] dbg: gpg: gpg: WARNING: signing subkey 24F434CE is not cross-certified
[26406] dbg: gpg: gpg: please see http://www.gnupg.org/faq/subkey-cross-certify.html for more 
information
[26406] dbg: gpg: [GNUPG:] ERRSIG 6C55397824F434CE 1 2 00 1192690444 1
[26406] dbg: gpg: gpg: Can't check signature: general error
error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification
failed.
channel: GPG validation failed, channel failed
[26406] dbg: generic: cleaning up temporary directory/files
[26406] dbg: diag: updates complete, exiting with code 4


So yes, I'm +1 to cross-signing, and we need to do this asap since the channels are potentially broken 
right now...  <sigh>

There should be a way to do this w/out upgrading gpg, I'll take a look in a minute.
Comment 5 Theo Van Dinter 2008-01-09 17:13:59 UTC
Hrm.

I scp'ed the files to my own machine, and tried the cross-certify:

gpg: RSA/SHA1 signature from: "24F434CE updates.spamassassin.org Signing Key 
<release@spamassassin.org>"
gpg: secret key parts are not available
gpg: update_keysig_packet failed: general error

Same error w/ an export/import.  Digging around, I found https://bugs.g10code.com/gnupg/issue673 
which seems to say this is a bug but it's "easy to fix" manually.  However, my gpg-fu is apparently not 
strong enough.

Anyone else want to take a stab at it?
Comment 6 Theo Van Dinter 2008-01-09 17:27:17 UTC
Just for my own curiosity, I compiled gpg 1.4.8 on the zone machine and tried the cross-certify w/ the 
same results.
Comment 7 Sidney Markowitz 2008-01-09 19:17:15 UTC
(in reply to comment #4)
> If Eve convinces Bob to trust a different key, then it doesn't matter what we do.

Security people are supposed to be paranoid about unlikely threats because
attackers are good about finding ways to make the unlikely possible.

The idea here is that Eve uses the fact that her key verifies the good signature
on the good copy of MalAssassin to trick Bob into accepting that her key is a
new one for the software releases. She can't do that if the keys are
cross-certified.

(in reply to comment #5)
> Anyone else want to take a stab at it?

I will, but I have to be reminded what is the hostname for the zone machine and
if I have to do anything special to get ssh and sudo access to it.

Comment 8 Theo Van Dinter 2008-01-09 20:45:32 UTC
(In reply to comment #7)
> > Anyone else want to take a stab at it?
> 
> I will, but I have to be reminded what is the hostname for the zone machine and
> if I have to do anything special to get ssh and sudo access to it.

spamassassin.zones.apache.org.  looking at the passwd file, you already have an entry there, and you 
have sudo access as well.  :)

The 1.4.8 gpg is in /tmp (gnupg-1.4.8/g10/gpg, iirc).
Comment 9 Sidney Markowitz 2008-01-09 20:57:46 UTC
And how do I get the key?
Comment 10 Theo Van Dinter 2008-01-09 21:02:34 UTC
(In reply to comment #9)
> And how do I get the key?

The initial comment has the path to the key.  You'll want to be the updatesd user.  I'd do any attempts in a 
different location, just to be safe.
Comment 11 Theo Van Dinter 2008-01-09 23:13:53 UTC
Ok, I think I figured it out.  It appears the key files that we're actively using doesn't have the full set of 
secret keys associated with it.  Specifically, it appears that it's a stub secret key.   I found a backup copy 
of the key files w/ the full set of secret keys under the BACKUP dir and was able to cross-certify. :)

The new public key was imported into the normal key directory, and I uploaded the key to pgp.mit.edu.  
I'll update the included pubkey in 3.1, 3.2, and trunk in a minute.

However ...  We need to document somewhere that if people can't do an update, and they see the error 
in the debug output, they'll need to get the new pubkey imported.  Ala:

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import /usr/share/spamassassin/sa-
update-pubkey.txt

or

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver pgp.mit.edu --recv-key 5244EC45

Comment 12 Theo Van Dinter 2008-01-09 23:21:47 UTC
Ok, it's committed.  It's seemed like a text/documentation file, so I went CTR on it.  If people disagree, I 
can put up the patch.

Sending        spamassassin-3.1/rules/sa-update-pubkey.txt
Sending        spamassassin-3.2/rules/sa-update-pubkey.txt
Sending        spamassassin-head/rules/sa-update-pubkey.txt
Transmitting file data ...
Committed revision 610699.

Comment 13 Justin Mason 2008-01-10 02:23:21 UTC
(In reply to comment #11)
> Ok, I think I figured it out.  It appears the key files that we're actively
using doesn't have the full set of 
> secret keys associated with it.  Specifically, it appears that it's a stub
secret key.   I found a backup copy 
> of the key files w/ the full set of secret keys under the BACKUP dir and was
able to cross-certify. :)

too much paranoia!  I shouldn't have done that.
can you put the full set of secret keys into the "key" directory in case we
need to do something similar again?

> The new public key was imported into the normal key directory, and I uploaded
the key to pgp.mit.edu.  
> I'll update the included pubkey in 3.1, 3.2, and trunk in a minute.
> 
> However ...  We need to document somewhere that if people can't do an update,
and they see the error 
> in the debug output, they'll need to get the new pubkey imported.  Ala:
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import
/usr/share/spamassassin/sa-
> update-pubkey.txt
> 
> or
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver
pgp.mit.edu --recv-key 5244EC45

damn, that's annoying. stupid gpg!  still, we probably have a while
before the distros start packaging 1.4.8.

it's lucky I spotted the message; I wouldn't have seen it otherwise, since it
only appears with sa-update --debug in gpg 1.4.7.
Comment 14 Justin Mason 2008-01-10 03:20:47 UTC
a poster on the users list has just noted a problem that could be this bug.

'Even though I have followed the intructions in the error message twice now, I 
still have the same error when sa-update is run:

# /usr/bin/sa-update --allowplugins --gpgkey 
D1C035168C1EBC08464946DA258CDB3ABDE9DC10 --channel saupdates.openprotect.com
error: GPG validation failed!
The update downloaded successfully, but it was not signed with a trusted GPG
key.  Instead, it was signed with the following keys:

    BDE9DC10

Perhaps you need to import the channel's GPG key?  For example:

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update --import GPG.KEY

channel: GPG validation failed, channel failed

New secret process guys?  But I note the signature key is the last 8 digits of 
the GPG.KEY my cron job was using.'
Comment 15 Justin Mason 2008-01-10 04:25:21 UTC
actually, looks like this needs to be reverted.  A couple of users have reported
failures to validate sa-updates today, and one notes their gpg version as
gpgme-1.1.5-4.fc8....
Comment 16 Theo Van Dinter 2008-01-10 09:28:09 UTC
(In reply to comment #15)
> actually, looks like this needs to be reverted.  A couple of users have reported
> failures to validate sa-updates today, and one notes their gpg version as
> gpgme-1.1.5-4.fc8....

The one I saw on the users@ list was having a problem with the saupdates.openprotect.com channel, not 
ours.  I responded to that thread already.
Comment 17 Theo Van Dinter 2008-01-29 06:49:47 UTC
it's been reported, btw, that the key being served from pgp.mit.edu is the old
one, not the cross-certified one.  I've sent the key there a few times now, I
don't know if an earlier update just got lost, or if the keyserver doesn't see a
difference from the cross certification.  but if I delete the key locally, then
recv-key, I do in fact get the old one.  so that kind of sucks.


I actually would expect the key to include the subkey signature in "--list-sig"
output, but it doesn't...  The difference is:

pub   4096R/5244EC45 2005-12-20
uid                  updates.spamassassin.org Signing Key <release@spamassassin.org>
sig 3        5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sub   4096R/24F434CE 2005-12-20
sig          5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>

becomes

pub   4096R/5244EC45 2005-12-20
uid                  updates.spamassassin.org Signing Key <release@spamassassin.org>
sig 3        5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sub   4096R/24F434CE 2005-12-20
sig          5244EC45 2005-12-20  updates.spamassassin.org Signing Key
<release@spamassassin.org>
sig          5244EC45 2008-01-10  updates.spamassassin.org Signing Key
<release@spamassassin.org>

that's how you can tell which one you have.
Comment 18 Mark Martinec 2008-02-06 16:51:06 UTC
Daryl, has your key been cross-signed too?
  http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
  http://daryl.dostech.ca/sa-update/sare/GPG.KEY
I can't find a fresher one, and newer gpg complains with this one.
Comment 19 Daryl C. W. O'Shea 2008-02-06 18:26:35 UTC
What's the complaint it's giving?  I don't use a sub key to generate the channel
file signatures.
Comment 20 Mark Martinec 2008-02-07 03:34:35 UTC
> What's the complaint it's giving?  I don't use a sub key to generate
> the channel file signatures.

gpg (GnuPG) 1.4.8

[5135] dbg: http: GET request,
 http://daryl.dostech.ca/sa-update/zmi/70_zmi_german.cf/200705271208.tar.gz.asc
[5135] dbg: sha1: verification wanted: 5991893117da2b7bda8566b719823ba93dbc44b6
[5135] dbg: sha1: verification result: 5991893117da2b7bda8566b719823ba93dbc44b6
[5135] dbg: channel: populating temp content file
[5135] dbg: gpg: populating temp signature file
[5135] dbg: gpg: calling gpg
[5135] dbg: gpg: gpg: Signature made Sun May 27 12:24:08 2007 CEST
  using DSA key ID 856AA88A
[5135] dbg: gpg: [GNUPG:] SIG_ID xx47/E6NVGUIqF6ZqotZXrkEX/Y
  2007-05-27 1180261448
[5135] dbg: gpg: [GNUPG:] GOODSIG 3C5C05EB856AA88A Daryl C. W.
  O'Shea <spamassassin@dostech.ca>
[5135] dbg: gpg: gpg: Good signature from "Daryl C. W. O'Shea
  <spamassassin@dostech.ca>"
[5135] dbg: gpg: [GNUPG:] VALIDSIG ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
  2007-05-27 1180261448 0 3 0 17 2 00 ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
[5135] dbg: gpg: [GNUPG:] TRUST_UNDEFINED
[5135] dbg: gpg: gpg: WARNING: This key is not certified with a 
  trusted signature!
[5135] dbg: gpg: gpg: There is no indication that the signature belongs
  to the owner.
[5135] dbg: gpg: Primary key fingerprint: ABE0 C874 3B87 262E 5FB0 4F2B
  3C5C 05EB 856A A88A
[5135] dbg: gpg: found signature made by key
  ABE0C8743B87262E5FB04F2B3C5C05EB856AA88A
[5135] dbg: gpg: key id 856AA88A is not release trusted
  error: GPG validation failed!
The update downloaded successfully, but the GPG signature verification
  failed.
channel: GPG validation failed, channel failed
Comment 21 Daryl C. W. O'Shea 2008-02-07 09:08:43 UTC
> [5135] dbg: gpg: key id 856AA88A is not release trusted
>   error: GPG validation failed!

Looks like you forgot to add --gpgkey 856AA88A to your command line.

Comment 22 Mark Martinec 2008-02-07 10:51:25 UTC
> Looks like you forgot to add --gpgkey 856AA88A to your command line.

Right. Sorry for the noise.

I mistook a success on the other host for a difference in gpg versions,
whereas that host was already up-to-date with SARE rules and didn't
download any files, so didn't complain despite a missing --gpgkey.
Comment 23 Justin Mason 2008-02-11 13:08:17 UTC
> However ...  We need to document somewhere that if people can't do an update,
and they see the error 
> in the debug output, they'll need to get the new pubkey imported.  Ala:
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --import
/usr/share/spamassassin/sa-
> update-pubkey.txt
> 
> or
> 
> sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys --keyserver
pgp.mit.edu --recv-key 5244EC45

we still need to do this bit.
Comment 24 Justin Mason 2008-02-12 13:14:50 UTC
how does http://wiki.apache.org/spamassassin/SaUpdateKeyNotCrossCertified
look?  feel free to hack it about.

instead of the complex

sudo gpg --homedir /etc/mail/spamassassin/sa-update-keys \
   --keyserver pgp.mit.edu --recv-key 5244EC45

I changed it to just use 

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update --import GPG.KEY

which seems a lot simpler, and appears to work in my testing
(at least the --list-sig change is visible).
Comment 25 Andreas K. Huettel 2008-05-01 03:26:32 UTC
Just for your information, this is hitting people now with a stable, fully updated Gentoo installation. See http://bugs.gentoo.org/show_bug.cgi?id=218239
Comment 26 Justin Mason 2008-05-01 04:13:02 UTC
we should probably push out a 3.2.5 just to get this into a release.