Exponent 3 damage spreads...

Ralf-Philipp Weinmann weinmann at cdc.informatik.tu-darmstadt.de
Wed Sep 27 03:39:23 EDT 2006


On Sep 25, 2006, at 10:29 AM, Simon Josefsson wrote:

> "Leichter, Jerry" <leichter_jerrold at 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 at metzdowd.com



More information about the cryptography mailing list