240261 - (CVE-2008-2809) [1.8 branch] peer-trusted certs can use alt names to spoof

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[John G. Myers]

There appears to be a vulnerability in the way that the peer trust model
interacts with alternative subject names.  The issue is that NSS only has a
single bit which trusts a cert for all of its subject names, not just the name
the user intended to trust the cert for.

An example would come from an https site with a malicious self-signed cert. 
despot.mozilla.org would be a good example of a good launch site--someplace
where users would not find a self-signed cert to be unusual.  The cert would not
only contain its own, legitimate, domain, but would include an alternate name of
a site the attacker wishes to spoof.  The user accepts the cert for purposes of
authenticating the legitimate domain, but PSM has NSS mark the cert as trusted
for domains that were never mentioned to the user.

This affects all peer-trust areas, SSL, S/MIME, and code signing.

Bug 230655 at least gives the user an way to see what the domains are, without
having to decode ASN.1 in their head.  At a minimum, PSM would need to list all
of the alternative names before giving the user the opportunity to mark the cert
as peer-trusted--this is related to bug 238142.

Better would be to have, instead of a peer-trust bit on the cert, a list of
names for which the cert is peer-trusted.  This would require either an
extensive change to NSS or for slightly more extensive changes to PSM to take
over the peer-trust-database functions of NSS.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Sounds like the problem is that PSM asks the user to trust the cert without
giving the user all the relevant info that the user should consider before
making that decision.  

There is no other PKI product in the world (known to me) that allows the user
to trust some of the names in a cert but not others.  

I object to making the trust mode MORE complicated.  The user should either
trust the cert entirely, or not at all.  But the user SHOULD see all the 
relevant info before making that decision.

SO, this seems like a UI problem, not a trust DB problem.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 308244 has been marked as a duplicate of this bug. ***

Comment 4

[Nils Toedtmann]

OK, let me summarize:
* This is a sec issue, and not a minor one
* It is known since 04/2004 (at least)
* It is marked "Security-Sensitive", thus not public.
* Once a year somebody (like me) rediscovers it, doesn't find it in bugzilla, reports it, gets a "oh we know that, it' a dupe"
* It is WONTFIX for mozilla-1.8/firefox-2 (bug #402347)

OMG.

PS: Someone opened the last dupe, so you can open this one, too. Then it won't get rediscovered and duped over and over again the next three years.

Comment 5

[Nils Toedtmann]

M. Zalewski explained better than i ever could why this should get fixed in 1.8.x, too: <http://www.securityfocus.com/archive/1/483942/30/0/threaded>

Comment 6

[Nils Toedtmann]

I'd like to access bug #406655 this one depends on, is it possible to put me on its CC list?

Comment 7

[Daniel Veditz [:dveditz]]

We're clearly not going to get a patch for this before we want to ship 1.8.1.12, but I don't think waiting for FF3 is all that great an approach. Try for next branch release.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

It appears to me that this bug is a duplicate of bug 238142, which is open
(not security sensitive).  

Bug 238142 has been marked as a duplicate of bug 398718 (although it isn't
obvious to me that they *are* duplicates), and 

Bug 398718 is now resolved fixed, even though this situation with subject 
alt names persists (AFAICT) on branch and trunk.  I don't see how this bug, 
or the others named above, can be resolved (especially fixed) while this 
problem persists.

It seems the REAL work of solving the subject alt name bug has taken place
or will take place in bug 400917 & Bug 411246.  So, I'm marking this bug as
depending on 411246.

Comment 9

[Kai Engert (:KaiE:)]

(In reply to comment #8)
>
> It seems the REAL work of solving the subject alt name bug has taken place
> or will take place in bug 400917 & Bug 411246.

No.

The "subject alt name bug" is already fixed in FF 3, because in FF 3:
- on error pages we list all valid DNS names
- we bind each override strictly to a single hostname and pair

The single purpose of bug 411246 is to fix a small difference between display code and engine verification code.

This bug is asking for a solution for FF 2.x, and I'm not yet aware of one.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

I would hope that when a host name mismatch error occurs in FF3, it displays
diagnostic info that includes the name it was looking for and the names it 
found.  Is that not true for FF3?

Comment 11

[Kai Engert (:KaiE:)]

(In reply to comment #10)
> I would hope that when a host name mismatch error occurs in FF3, it displays
> diagnostic info that includes the name it was looking for and the names it 
> found.  Is that not true for FF3?

Nelson, I don't understand why you ask this question, given my comment 9.
Maybe my comment 9 is confusing?

When I use FF 3 beta to connect to a mismatch host (paypal.com) I get an error page with this text:

Secure Connection Failed
paypal.com uses an invalid security certificate.
The certificate is only valid for www.paypal.com.
(Error code: ssl_error_bad_cert_domain)

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 11,
The error page text shown above does not state the DNS name that the browser
was trying to find inside the certificate.  Sometimes users are confused
about the name of the host in the url, e.g. for URLs like this one:
   https://[e-mail]/ 
I think the dialog should explain not only what names it found in the cert,
but also the name it was trying to find there (but did not).

Comment 13

[Kai Engert (:KaiE:)]

(In reply to comment #12)
> The error page text shown above does not state the DNS name that the browser
> was trying to find


Wrong, I think it does!!!

The error message says
  paypal.com uses an invalid security certificate.

This shows the hostname that we were looking for in the certificate.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Hmmm.  Perhaps you're right.  Perhaps it needs to state more clearly that
the name it expected to find was (in this example) paypal.com.  But I 
agree that the string is there, if one knows how to interpret it.

Comment 15

[Daniel Veditz [:dveditz]]

Why are you guys arguing about FF3, isn't this a branch-only bug now? I thought the trunk mechanism tied the cert to the single host that we got the cert from so this is no longer an issue.

On branch (ff2 and nss 3.11.x) we still have a spoofing problem. Would a "fix" be as easy as listing the alt names in the approval dialog? I know we're not going to be taking NSS 3.12 and all the improved support it has on branch any time soon.

Comment 16

[Daniel Veditz [:dveditz]]

ditto comment 7, moving out yet another release :-(

Comment 17

[Daniel Veditz [:dveditz]]

Is there any realistic way to fix this on the Mozilla1.8 branch? It seems like our choices are to back-port enough of the trunk mechanism that makes the cert-site binding, or easier-but-worse list all the alt names in the initial dialog ("you are also agreeing that this cert is valid for the following sites"). The latter is a localization change, of course, so that doesn't really fly either.

I'm guessing this is a WONTFIX on the branch. :-(

Comment 18

[Kai Engert (:KaiE:)]

Ok, here is an idea that does not require string changes.

The current error message always displays the cert's common name, like:
  "... the security certificate presented belongs to ### ..."

Instead of always displaying a single domain name, we could extract all names from the cert (using code we added on trunk) and display it like this:

  "... the security certificate presented belongs to (site1, site2, site3) ..."

I'm trying to produce a patch.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Kai, I like that suggestion (displaying all the names for which it is 
thought to be valid).  Since those "names" include IP addresses (both
IPv4 and IPv6), let me suggest that you also plan to include any and 
all of those in that list of "names" in that error message.

Comment 20

[Kai Engert (:KaiE:)]

(In reply to comment #19)
> Kai, I like that suggestion (displaying all the names for which it is 
> thought to be valid).  Since those "names" include IP addresses (both
> IPv4 and IPv6), let me suggest that you also plan to include any and 
> all of those in that list of "names" in that error message.

The code we implemented, and which is checked in on trunk, handles both IP addresses and DNS names.

I plan to use an exact copy of that code, so you request is addressed.

Comment 21

[Kai Engert (:KaiE:)]

Attachment: Patch v1 [for 1.8 branch]

This patch works for me.

Comment 22

[Kai Engert (:KaiE:)]

Attachment: screen shot

This screen shot illustrates the new UI.
You get it when you attempt to connect to https://208.109.132.201/

Comment 23

[Kai Engert (:KaiE:)]

Attachment: screen shot 2

one more example: https://72.19.170.120

Comment 24

[Kai Engert (:KaiE:)]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

Note that function GetSubjectAltNames is an exact copy of what we have on trunk, and is therefore reviewed already.

http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#892

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

Nice! Does this also fix the "You have attempted to connect to www.foo.com, however the certificate belongs to www.foo.com" bugs? That's a nice side-effect.

>+// names => a single name or a list of names
>+// multipleNames => whether multiple names were delivered

comment nit: this is "nameCount" now rather than a boolean.

The .idl needed the comment more than here, I think (if you're only going to pick one place).

Looks great, thanks for the patch!
r=dveditz

Comment 26

[Kai Engert (:KaiE:)]

(In reply to comment #25)
> Nice! Does this also fix the "You have attempted to connect to www.foo.com,
> however the certificate belongs to www.foo.com" bugs? That's a nice
> side-effect.

Yes, it does :-)

Comment 27

[Samuel Sidler (old account; do not CC)]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

Approved for 1.8.1.15. a=ss for release-drivers.

Leaving nomination for 1.8.0.15 to the 1.8.0 drivers.

Comment 28

[Kai Engert (:KaiE:)]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

Note that approval for this patch does not make sense for 1.8.0 branch, because the patch does not apply. At least the patch will have to get merged, not sure if more work is required.

Comment 29

[Kai Engert (:KaiE:)]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

I think it would be good if Bob could r+ this bug.

I have already talked to him shortly, he agrees with the plan.

Since function GetSubjectAltNames in this patch is being copied from the trunk, you can skip reading it.

Comment 30

[Robert Relyea]

Comment on attachment 317786 [details] [diff] [review]
Patch v1   [for 1.8 branch]

did not review the details of the 'GetSubjectAltNames' function except to verify semantic assumptions fo the code that called it.

Comment 31

[Kai Engert (:KaiE:)]

checked in to 1.8 branch for Firefox 1.8.1.15

Comment 32

[Kai Engert (:KaiE:)]

Attachment: Patch v1 + bustage fix, merged to 1.8.0 branch

If you want to fix 1.8.0 branch for Firefox 1.5.0.x, too, this patch makes it work for me.

Comment 33

[Alexander Sack]

Comment on attachment 319665 [details] [diff] [review]
Patch v1 + bustage fix, merged to 1.8.0 branch

a=asac for 1.8.0 branch

Please commit.

Comment 34

[Kai Engert (:KaiE:)]

checked in to 1.8.0 branch

marking fixed

Comment 35

[juan becerra [:juanb]]

Kai, I'm looking at the UI on Fx20014 and Fx20015pre while visiting https://72.19.170.120/ and it looks the same. Should it be so?

When I visit https://208.109.132.201/ I can see the difference. 

Comment 36

[Kai Engert (:KaiE:)]

Juan, I get the expected UI on both sites.

Please describe more what exactly you are getting and why you think it's wrong (or a screenshot).

Comment 37

[juan becerra [:juanb]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.15pre) Gecko/2008061004 BonEcho/2.0.0.15pre

Never mind. I needed to OK to accept the certificate before I could see the difference when visiting https://72.19.170.120/

I was expecting the first modal dialog to show me the difference. Trunk doesn't use the modal dialog and you see it right away.

Changing the keyword to verified1.8.1.15