[144603] in cryptography@c2.net mail archive
Re: XML signature HMAC truncation authentication bypass
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Sun Jul 19 14:33:00 2009
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: cryptography@metzdowd.com, lmeiners@gmail.com
In-Reply-To: <4A60BE7A.2050607@gmail.com>
Date: Sat, 18 Jul 2009 15:39:17 +1200
Leandro Meiners <lmeiners@gmail.com> quotes:
>"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."
This excessive generality is a serious problem in way too many crypto specs,
and implementations of security protocols. For example PKCS #11 allows you to
leak keys out of cryptographic hardware by specifying the use of a 1-bit key
derivation function, allowing you to guess an entire key one bit at a time
(fortunately few, if any, implementations actually support this). In the PKI
world, virtually no spec requires sensible limits on anything (some years ago
I brought a CA to a halt by specifying a huge salt and large iteration count
for the challenge-response protocol they used to authenticate certificate
issues. Then I repeated it to make sure it wasn't just a coincidence the
first time :-). PGP Desktop 9 uses as its default an iteration count of four
million (!!) for its password hashing, which looks like a DoS to anything that
does sanity-checking of input. Netscape (and obviously this test was done
some years ago) will happily accept a certificate with a 1MB MPEG of a cat in
the X.500 DN, but then become what could mildly be described as "unresponsive"
once it's stored it in its cert.database. The SSH oracle attack of a few
months ago was helped by the fact that the length field wasn't constrained to
sensible values. This list goes on and on, it's scary just how vulnerable a
lot of security software is to anything that can drop a slightly unexpected
value into a data field.
Peter.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
