[47392] in cryptography@c2.net mail archive
Re: Exponent 3 damage spreads...
daemon@ATHENA.MIT.EDU (Ralf-Philipp Weinmann)
Thu Sep 28 09:30:13 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <87mz8owdqw.fsf@latte.josefsson.org>
Cc: "Leichter, Jerry" <leichter_jerrold@emc.com>,
Peter Gutmann <pgut001@cs.auckland.ac.nz>, cryptography@metzdowd.com,
Ulrich Kuehn <Ulrich.Kuehn@telekom.de>,
Erik Tews <e_tews@cdc.informatik.tu-darmstadt.de>
From: Ralf-Philipp Weinmann <weinmann@cdc.informatik.tu-darmstadt.de>
Date: Wed, 27 Sep 2006 09:39:23 +0200
To: Simon Josefsson <jas@extundo.com>
On Sep 25, 2006, at 10:29 AM, Simon Josefsson wrote:
> "Leichter, Jerry" <leichter_jerrold@emc.com> 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 majordomo@metzdowd.com
