On Sep 25, 2006, at 10:29 AM, Simon Josefsson wrote:
"Leichter, Jerry" <[EMAIL PROTECTED]> writes:
I agree that there are two issues, and they need to be treated
properly. The first - including data after the ASN.1 blob in the
signature computation but then ignoring it in determining the
semantics - is, I'll argue, an implementation error. You list only
OpenSSL as definitely vulnerable, NSS as "?", so it sounds like
only one definitive example.
Yes. I'm only familiar with NSS as a user, not as a developer. For
some reason, the Mozilla bug tracker hides information about this
problem from us, so it is difficult to track the code down.
I believe I identified the patch that solved the problem in NSS,
search for "350640" in:
http://bonsai.mozilla.org/cvsquery.cgi?branch=HEAD&file=mozilla/
security/nss/&date=month
The bug discussion is not public:
https://bugzilla.mozilla.org/show_bug.cgi?id=350640
Possibly also bug reports 351079 and 351848 are related to the same
problem, but these bugs are also hidden.
The actual patch for 350640 is:
http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&subdir=mozilla/security/nss/
lib/
util&command=DIFF_FRAMESET&file=secdig.c&rev1=1.6&rev2=1.7&root=/
cvsroot
If some NSS developer could chime in, that would help.
Even if NSS has the same problem, one has to look at code
provenance.
Sure.
Hi Simon,
I'm not a NSS developer, but we did have a look at the code here to
figure out what EXACTLY those guys patched. The relevant portion can
quite easily be found by diff'ing the tags FIREFOX_1_5_0_6_RELEASE
vs. FIREFOX_1_5_0_7_RELEASE on their CVS tree for example. Insofar I
don't think that leaving the bug reports private after actually
shoving out the release does not really help things in this
situation; quite the opposite.
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.
At least some versions of PKCS#1 does NOT say that, e.g., RFC 3447.
RFC 3447 essentially says to generate a new token and use memcmp().
Such implementations would not be vulnerable to any of the current
attacks, except the Kaliski ASN.1 OID attack (an attack that doesn't
work on existing implementations).
See above.
Cheers,
Ralf
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
