oss-security - Re: Fixing the XML signature HMAC truncation authentication bypass

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Wed, 15 Jul 2009 02:41:16 +0200
From: Robert Buchholz <rbu@...too.org>
To: oss-security@...ts.openwall.com
Cc: Florian Weimer <fw@...eb.enyo.de>
Subject: Re: Fixing the XML signature HMAC truncation authentication bypass

On Tuesday 14 July 2009, Florian Weimer wrote:
> Quoting from <http://www.kb.cert.org/vuls/id/466161>:
> | XML Signature Syntax and Processing (XMLDsig) is a W3C
> | recommendation for providing integrity, message authentication,
> | and/or signer authentication services for data. XMLDsig is commonly
> | used by web services such as SOAP. The XMLDsig recommendation
> | includes support for HMAC truncation, as specified in RFC2014. When
> | HMAC truncation is under the control of an attacker, however, this
> | can result in an effective authentication bypass. For example, by
> | specifying an HMACOutputLength of 1, only one bit of the signature
> | is verified. This can allow an attacker to forge an XML signature
> | that will be accepted as valid.
>
> What shall we do about this?  Shall we just cap the value at 80 or 96
> bits in our implementations?

I believe this to be the best approach. RFC 2104 specifically states 80 
or half of the digest length as the lower boundary for truncation, and 
it would be compatible API-wise.

As far as Gentoo is concerned, the following upstreams have confirmed 
the issue (to CERT):
1) Apache XML Security
2) aleksey.com xmlsec library
3) Mono
4) Sun JDK/JRE 1.6

1) Apache
Bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47526
Patch:
http://svn.apache.org/viewvc?view=rev&revision=794013

It seems they disallow HMAC truncation completely.
* In my personal opinion the best move (since we're dealing with XML,
  who cares about an additional <16 bytes?)


2) xmlsec:

These are the patches that went into 1.2.12:
http://git.gnome.org/cgit/xmlsec/commit/?id=34b349675af9f72eb822837a8772cc1ead7115c7
http://git.gnome.org/cgit/xmlsec/commit/?id=d4ac1a621f88a923b17394530e333a3086ebe206

The value of 40 seems like a really bad default.


3) Mono

Patches:
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137886 (trunk)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137887 (2.4)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137888 (2.0)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137889 (1.9)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137890 (1.2.5)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137891 (1.2.2)
http://anonsvn.mono-project.com/viewvc/?view=rev&revision=137892 (1.1.7)

They impelement min = max(80, full length/2). Good!



Florian Streibelt's analysis of the GnuTLS code indicated that is also 
vulnerable. On our list of unreviewed suspects is still:
* gSOAP (SOAP C++ Web Services)
* zsi (Zolera Soap Infrastructure)
* OpenSAML


Robert

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.