Exponent 3 damage spreads...

[Simon Josefsson]

"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.

> OSS efforts regularly share code, and code to pick apart data fields
> is hardly kind of thing that is going to inspire someone to go out
> and "do it better" - just share.

I think you want to read up on free software license compatibilities,
and in particular OpenSSL vs GPL.  But this is a very different topic,
that we shouldn't pursue here...

> The second - embedded parameter fields - is a much deeper issue.
> That's a protocol and cryptographic error.  The implementations
> appear to be correctly implementing the semantics implied by the
> spec - ignore parameters you don't care about.

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).

> This is common practice, and a fine idea in *most* situations, since
> it allows for extensions without breaking existing implementations.

I believe the principle of "Be conservative in what you do; be liberal
in which you accept from others" is generally a bad advice.

The principle hides problems that should be fixed.  Hiding a problem
instead of fixing it typically enables bad things to happen.  We've
seen that lead to security problems for many years, this is just one
example.

/Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com