> From: Ralf-Philipp Weinmann
> [...]
> Relevant files to this problem that were patched turned out
> to be security/nss/lib/cryptohi/secvfy.c and
> nss/lib/util/secdig.c. Have a look at the function
> DecryptSigBlock() in secdig.c, lines 92-95
>
> > /* make sure the "parameters" are not too bogus. */
> > if (di->digestAlgorithm.parameters.len > 2) {
> > goto sigloser;
> > }
>
> Quite amused, we also noted the following:
>
> < /* XXX Check that tag is an appropriate algorithm? */
> ---
> > /* Check that tag is an appropriate algorithm */
> > if (tag == SEC_OID_UNKNOWN) {
> > goto sigloser;
> > }
>
> This means, that before the patch was applied, NSS indeed was
> vulnerable to Kaliski's OID attack.
>
While the patch for Firefox obviously fixed the bugs in
security/nss/lib/cryptohi/<whatever>,
There is another pkcs#1-padding check in security/nss/lib/softtoken/rsawrapr.c,
see function
RSA_CheckSign() and RSA_CheckSignRecover(). Does anybody know what these
functions are used for?
I tried to find that out, but did not get very far...
(Hal Finney also noted these functions some days ago).
It seems to be another creative bug:
/*
* check the padding that was used
*/
if (buffer[0] != 0 || buffer[1] != 1)
goto loser;
for (i = 2; i < modulus_len - hash_len - 1; i++) {
if (buffer[i] == 0)
break;
if (buffer[i] != 0xff)
goto loser;
}
/*
* make sure we get the same results
*/
if (PORT_Memcmp(buffer + modulus_len - hash_len, hash, hash_len) != 0)
goto loser;
So it would accept a padding ( 00 || 01 || 00 || garbage || hash ), which is
not exactly what pkcs#1 says :)
The same loop is used in RSA_CheckSignRecover(), but I did not succeed in
finding out what it is exactly used for and if that is a safe application of
the rather wrong code.
Cheers,
Ulrich
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
