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

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [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

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.