762800 - Denial of service, use a site with a fake cert to prevent people from visiting valid secure sites

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Kai Engert (:KaiE:)]

NSS makes assumptions about the compliancy of web sites.

In particular, NSS assumes that no two certificates will ever use the same combination of {issuer, serial number}. NSS made that pair a private key to distinguish certificates.

In order to avoid mistakes and inconsistencies, the NSS developers decided in the past to throw an error whenever such a conflict is detected.

One consequence of this strategy is bug 435013, where users experience such conflicting certs in real life.

Now I realized this specific property of NSS can be abused for a denial of service attack against secure sites. An attacker that wishes to disturb a specific secure site can generate a certificate that conflicts with the one used by the targeted site. The certificate doesn't need a trusted signature. It's sufficient that the attacker gets the victim to visit a fake site once. If the victim hasn't yet visited the real site in the current session, the victim won't be able to visit the real site prior to restarting the Mozilla software.

Test case:
(1) restart your browser, 
    and make sure you haven't yet visited bugzilla.mozilla.org
(2) go to https://kuix.de:8666
(3) ignore the security warning
(4) go to https://bugzilla.mozilla.org
(5) you'll get an error message about conflicting certificates,
    and you are unable to visit bugzilla.

Additional, worse problem, if the user has decided to add a (permanent) exception in step (3):
Even after restarting the Mozilla software,the user won't be able to visit bugzilla. The only remedy is to go to certificate manager, find the override for bugzilla.mozilla.org and restart.


My motivation for filing this bug is bug 435013.
Fixing bug 435013 is very difficult, because of NSS behaviour to strictly complain about such conflicting certs. It's made worse by Mozilla's delayed cleanup of JS objects, which has the effect of keeping NSS certificate objects around longer than necessary.

However, because of this potential denial of service attack, in my opinion bug 435013 should be solved anyway.

Comment 1

[Daniel Veditz [:dveditz]]

although technically a DoS I'm going to rate this sec-moderate because it would be easy to "turn off" most of the important sites on the web through a drive-by attack. Could also be used to turn off update or blocklist checks for Firefox itself, at least for that session.

Nominating for K9o because disabling updates, the app store, for the "session" would be pretty long-lived in a phone since people don't typically reboot their phones regularly.

Comment 2

[Kai Engert (:KaiE:)]

> NSS made that pair a private key to distinguish certificates.

not "private key", I intended to say "primary key"

Comment 3

[Robert Relyea]

This problem has also been known for a long time.

When part of the reproduction is "ignore the security warning", I consider the issue either 'not a bug' or very low priority. 

Once you create an exception, you are on your own. Exceptions are dangerous, users do so on at their own peril, if you don't know what you are doing, don't create the exception. This is just one more reason why you shouldn't do this.

bug 435013 is invalid as far as I am concerned. This particular bug doesn't change that opinion.

bob

Comment 4

[Kai Engert (:KaiE:)]

The DoS doesn't require an exception.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The DoS doesn't require an exception, but is there a way to cause a persistent DoS without adding an exception?

For the non-persistent case: An attacker could simply block all your connections to the target domain(s) by blocking DNS or blocking the TCP/IP traffic to the target domain; they don't need to use this mechanism for that.

However, given that users are very likely to add certificate exceptions, I don't think we can rate this "low" based on the fact that when you add an exception, you are on your own.

I think we need to stop using (serial, issuer) as a lookup key.

Comment 6

[Robert Relyea]

> The DoS doesn't require an exception, but is there a way to cause a persistent DoS without adding
> an exception?

Not without some CA making a serious error in their infrastructure.

> I think we need to stop using (serial, issuer) as a lookup key.

It not looking up keys, it's identifying certs in the cache. That code isn't just a quick change it is fundamental to NSS.

If the user does DoS himself by adding the exception, the user can undo the damage by removing the exception.

bob

Comment 7

[Josh Aas]

Does this bug really need to be hidden?

Kai, do you want to work on this?

Comment 8

[Kai Engert (:KaiE:)]

(In reply to Josh Aas (Mozilla Corporation) from comment #7)
> Kai, do you want to work on this?

This can't be fixed easily, but might require architectural changes in NSS.
I'm not able to make it a priority at this time.

Comment 9

[Wan-Teh Chang]

Kai, I remember Julien filed a bug about this issue before.
Would be nice to find it and see if this bug can be marked
as a duplicate.

Comment 10

[Kai Engert (:KaiE:)]

(In reply to Wan-Teh Chang from comment #9)
> Kai, I remember Julien filed a bug about this issue before.
> Would be nice to find it and see if this bug can be marked
> as a duplicate.

This is a query for all bugs filed by Julien that contain the word "serial" in any comment.
I don't see anything that seems related.
https://bugzilla.mozilla.org/buglist.cgi?emailreporter1=1;list_id=5491303;emailtype1=exact;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=READY;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;longdesc=serial;email1=julien.pierre%40oracle.com;product=NSS;longdesc_type=allwordssubstr

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

This was fixed by bug 915930.