234058 - Certificate name matching for non-FQDNs is insecure

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[Tim Dierks]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

We were wondering why we don't get cert warnings when going to a site with a
cert for
'blahblah.internal.company.com' with a URL of the form: http://blahblah/file.html :

A colleague found the code:
> Looks like some shadiness in mozilla/security/nss/lib/certdb/certdb.c,
> specifically in cert_TestHostName (hn is the host, cn is the common
> name in the cert):
>
> ------------------
>     if ((hndomain = PORT_Strchr(hn, '.')) == NULL) {
>         /* No domain in URI host name */
>         char * cndomain;
>         if ((cndomain = PORT_Strchr(cn, '.')) != NULL &&
>             (cndomain - cn) > 0) {
>             /* there is a domain in the cn string, so chop it off */
>             *cndomain = '\0';
>         }
>     }
> ------------------
>
> If the URI in the browser isn't fully qualified, it just checks it
> against the first part of the common name. Seems like this is
> intentional, which is weird.

This is a security vulnerability.

An attacker could get a cert issued by Verisign for www.badguys.com and
impersonate www.internal.company.com , assuming some users at company.com have
internal.company.com set as their default search domain and access their site
using the short name 'www'.

IMHO, the right way to do it would to expand the short name being accessed into
a FQDN and compare them. I don't have any idea how to do this in practice; it
might require a browser setting. Unfortunately, my first idea, resolving the
name from the cert and comparing IP addresses, is also insecure: it would just
require the attacker to modify their own DNS record for www.badguys.com to point
to the same ip address as www.internal.company.com.

This bug makes SSL security dependent on DNS security (which is bad).

However, being able to support the desired behavior is good: it's nice for
people to be able to use unqualified names, and the security infrastructure can
(and should) support them. It would be nice if NSS, rather than trimming the
qualification from the CN, added candidate qualifications to the non-qualified
host name until it got a match or ran out of candidates. The hard part is where
to get the candidate qualifications from.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Tim, thanks for reporting this in bugzilla.

To eliminate the vulnerability, it is necessary to remove from NSS the code
quoted above.  That will immediately have the effect that https URLs featuring
non-FQDNs will all get host name mismatch errors.

To retain the desired functionality (that is, in order for URLs like
https://www/file.html to continue to work) some code must be added to 
NSS or the application that calls NSS's cert name matching function
(which, in mozilla, is PSM) that:

a) has a copy of the DNS search path for the system on which it is running,
   WITHOUT relying on the DNS protocol/servers for that information, and 
   WITHOUT relying on NIS/YP protocol/servers for that info.

and

b) constructs FQDNs from the simple hostname in the URL and the domain names
   in the DNS search path, and tests them with NSS's host name matching 
   function.  

There is, in general, no way for NSS to find this information.  So either

c) we add a new NSS function that allows the application to give NSS a copy
of the domain search list, and require the application to call it, or

d) we simply let the "application-supplied cert-chain validation callback" 
function do what I described in b above.  

Either way, to retain the desired functionality in mozilla, a change to 
PSM is required, and I suspect that will take longer than the NSS change.

The question I have now, is this:
Should we go ahead and remove the vulnerability now, even if we cannot then
restore the desired functionality for some time thereafter?

I'm adding John G Myers, who is presently working on PSM in his spare (?) 
time, to this list.  John, your thoughts on how to add back the relevant 
functionality to PSM are invited. 

Comment 2

[Tim Dierks]

FWIW, IE doesn't have similar code in it and warns on accessing such a site.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I'm removing the security sensitive flag, since the text of this bug
has been posted to netscape.public.mozilla.security.  :(

Comment 4

[John G. Myers]

Mozilla does DNS lookups through NSPR, so for NSS to get this information NSPR
would have to add a new function for returning the domain search list.  After
that is done, PSM could then call into NSPR to get the information to give to
NSS, or NSS could assume its calling applications have the same search list as
NSPR and directly call into NSPR to get the information.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

John,  

Do most, or any, systems have a standard or common API by which an 
application can fetch the local system's DNS search path?

Is there an API that works on windows 9x, Win2K and WinXP?

And, what about systems that use NIS/YP in host->IP address resolution ?  
How can we simulate the behavior of that in the construction of FQDNs?

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: proposed patch v1

This patch also removes another non-standard name matching behavior.
The old code treated a simple host name in the cert, e.g. CN=foo.bar.com
as if is also matched [^.]*.foo.bar.com

Comment 7

[Wan-Teh Chang]

Comment on attachment 141379 [details] [diff] [review]
proposed patch v1

r=wtc.

Nelson, I verified that this patch removes the two
non-standard name matching behaviors.  But I'd like to
know whether you plan to implement the safe versions
of the two non-standard name matching behaviors.  If
not, we break backward compatibility.  I just wanted
to make sure that's what you want to do.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

In answer to comment 7: 
Yes, I think our first obligation is to remove the vulnerability.
If we are able to reinstate the desired behavior in a non-vulnerable way at
some point, then that is fine, but I am not convinced there is such a way
in general, especially in the presence of NIS.  
I would not delay ther removal of the vulnerability while we look for a 
non-vulnerable way to reinstate the desired behavior.

Comment 9

[Wan-Teh Chang]

Thanks, Nelson.

Just curious: what is the second non-standard name matching
behavior (the one you described in comment 6) useful for?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

It allowed a company to get one cert that matched all servers in their 
outermost domain, e.g. one cert that said (e.g.) CN=netscape.com 
could be used on www.netscape.com, imaps.netscape.com, 
secnews.netscape.com, etc.

Comment 11

[John G. Myers]

...which was made necessary because CAs historically charged extortionate rates
for wildcard CAs.  The "subdomains not allowed" restriction generally benefits
CAs, not server operators or end users.  The restriction requires domaines to
buy more certs from the CA.  I don't know if competition in CAs has changed this
much.

There could conceivably be a domain where the top-level web server has lower
security requirements than some subdomain, but this is a stretch.

Comment 12

[John G. Myers]

"for wildcard CAs" should be "for wildcard certs"

Comment 13

[Wan-Teh Chang]

Is the second non-standard name matching behavior
a security vulnerability, too?  It seems that its
security risk is the same as that of wildcard certs.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

This behavior turns ANY single-named-server cert into a subdomain server cert.  
E.g. if you have a cert that names, e.g. CN=www.domain.TLD, then it may be used
with *.www.domain.TLD.  

The security risk is certainly very similar as that of wildcard certs.
Any additional risk comes about because the wildcard is invisible,
and thus unlikly to be spotted by the vigilant user or admin.

John, do you think we should preserve this behavior?  (I don't).

Comment 15

[John G. Myers]

I consider the second nonstandard name matching behavior to be an acceptable
risk/benefit tradeoff.  I may well be overestimating the benefit, though.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

These two features go back to at least the Netscape Navigator 3.x sources.
They may have made sense way back then. 

I think today this second feature has no real benefit.  Today mozilla and
browsers derived from it are "alternative" products, and no enterprise will
setup its business infrastucture to depend on features that are not found 
in IE.  I am told that neither of these features is in IE, so I think it's
time to drop 'em.  I surely don't want to be asked to defend them ever again.

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Patch checked in.  

/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.65; previous revision: 1.64

fix will be in NSS 3.10.

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Attachment: supplemental patch for ssl.sh QA test script

The ssl.sh qa test script and the ecc SSL test script (ecssl.sh) were both
dependent on the old behavior.	This patch changes them to always use FQDNs.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

test scripts checked in.  

/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.2; previous revision: 1.1

/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.56; previous revision: 1.55

Comment 20

[Wan-Teh Chang]

As our backward compatibility tests correctly shown,
this fix broke backward compatibility.  Since this bug
is a security vulnerability we can break backward
compatibility to fix it but we need to remember to
document this in the NSS 3.10 release notes.

We should update the ssl.sh QA test script used in
our backward compatibility tests so that they pass.
Bishakha, could you take care of this?

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

I'm beginning to think that our QA script named "all.sh" should be renamed 
to "lessthanall.sh".  I continue to desire that the checked-in QA scripts
used by developers be ALL-inclusive, so that they accurately predict the
outcome of nightly QA testing.  

Comment 22

[Wan-Teh Chang]

Comment on attachment 145667 [details] [diff] [review]
supplemental patch for ssl.sh QA test script

To backport this patch to older NSS branches (to
which this patch cannot be applied cleanly), you
just need to edit ssl.sh (and ecssl.sh, if it exists)
and make sure that the argument to the -h option of
all tstclnt commands (including those in the echo
commands) is ${HOSTADDR} instead of ${HOST}.

Comment 23

[chris hofmann]

wtc,  do you know if the mozilla 1.7 branch has this fix/NSS 3.10?

Comment 24

[Daniel Veditz [:dveditz]]

I talked to Nelson earlier, it is not fixed in the 3.9.1 that the mozilla 1.7
branch is using.

Comment 25

[Wan-Teh Chang]

Chris, the Mozilla 1.7 branch doesn't have this fix.
I'll be happy to check it in if you invite me to join
the gmail beta club.

Julien, I'll need to check this fix in on the NSS 3.9
branch as well.  This fix breaks backward compatibility,
so you need to tell your NSS 3.9.2 customers to watch
out for this.

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

This bug fix requires that https URLs always contain FQDNs.  

That's not going to be a problem for public Internet use (e.g. banks, merchants),
but could be a BIG problem for "intranet" (corporate) users who often tend 
to be sloppy and use simple hostnames in their web page links.  

Previously, it was decided not to impose this change, with its potential
incompatibility, on moz users at the very last minute before moz 1.7 RTM.

mozilla.org is free to change its mind about that, but should do so with its
eyes wide open to the potential consequences.

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

doesn't comment 16 indicate that such links would not work in IE, anyway?

Comment 28

[Julien Pierre]

Wan-Teh, we already recommended to our customers to use wildcard certs or
multiple hostnames in the cert. I don't think we ever documented the behavior
that is being corrected here. So it shouldn't be a problem hopefully. Since we
are doing a 3.9.2 beta drop to our internal customers in the next couple days,
it would be good if this got checked in before so we are certain it didn't break
anything before the 3.9.2 rtm later this month.

Comment 29

[Wan-Teh Chang]

I checked in the two patches on the NSS_3_9_BRANCH
(NSS 3.9.2).

mozilla.org drivers: please set the approval1.7+
flags on the two patches if you'd like me to check
them in on the MOZILLA_1_7_BRANCH.

Checking in lib/certdb/certdb.c;
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.61.2.3; previous revision: 1.61.2.2
done
Checking in tests/ssl/ecssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.1.18.1; previous revision: 1.1
done
Checking in tests/ssl/ssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.55.16.1; previous revision: 1.55
done

Comment 30

[Daniel Veditz [:dveditz]]

Comment on attachment 141379 [details] [diff] [review]
proposed patch v1

a=dveditz for 1.7

Comment 31

[Daniel Veditz [:dveditz]]

Comment on attachment 145667 [details] [diff] [review]
supplemental patch for ssl.sh QA test script

a=dveditz for 1.7

Comment 32

[Daniel Veditz [:dveditz]]

And we'll want it on the AVIARY_1_0_20040515_BRANCH.

Comment 33

[Wan-Teh Chang]

I checked in the patches on the MOZILLA_1_7_BRANCH
for Mozilla 1.7.

Checking in lib/certdb/certdb.c;
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.61.4.1; previous revision: 1.61
done
Checking in tests/ssl/ecssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.1.20.1; previous revision: 1.1
done
Checking in tests/ssl/ssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.55.18.1; previous revision: 1.55
done

Comment 34

[Daniel Veditz [:dveditz]]

Adding Jon Granrose to CC list to help round up QA resources for verification

Comment 35

[Jon Granrose]

adding dave to verify on 1.7

Comment 36

[David Epstein]

I need a test case with steps to verify against the 1.7 branch. Does the fix
prevent some spoofing scenarios?

Comment 37

[Wan-Teh Chang]

I verified this fix using Mozilla 1.7 on Windows.

My test case is aka.mcom.com, an internal server
at AOL's Mountain View network.  I can no longer
get there using the URL https://aka/ without
triggering the "Security Error: Domain Name Mismatch"
dialog.

Comment 38

[David Epstein]

ok thanks. Verified on 1.7 branch. 

Comment 39

[Christopher Aillon (sabbatical, not receiving bugmail)]

Applied both patches on the 1.4.3 branch

Comment 40

[Mark Cox]

Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0765 to this issue.