> 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]