Closed Bug 508577 Opened 17 years ago Closed 17 years ago

mostly universal wildcard certificate in |port_RegExpMatch| when NSS_USE_SHEXP_IN_CERT_NAME is set

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 504456

People

(Reporter: guninski, Unassigned)

Details

(Whiteboard: [sg:dupe 504456])

universal wildcard certificate in |port_RegExpMatch| when NSS_USE_SHEXP_IN_CERT_NAME is set http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/util/portreg.c#275 exp[x] = '\0'; this null terminates the regexp totally changing its content allowing universal wildcard certificate. gdb log: Breakpoint 2, port_RegExpMatch (str=0x7f06c94267a0 "localhost", xp=0x7f06c9444940 "***~guninski.com", case_insensitive=1) at portreg.c:270 270 if(!exp) Current language: auto; currently c (gdb) p exp $1 = 0x7f06c9444900 "***~guninski.com" (gdb) cont Continuing. Breakpoint 1, port_RegExpMatch (str=0x7f06c94267a0 "localhost", xp=0x7f06c9444940 "***~guninski.com", case_insensitive=1) at portreg.c:276 276 if(_shexp_match(str,&exp[++x], case_insensitive) == MATCH) (gdb) p exp $2 = 0x7f06c9444900 "***" (gdb) next 278 break; (gdb) next 281 if(_shexp_match(str,exp, case_insensitive) == MATCH) { (gdb) next 282 PORT_Free(exp); (gdb) next 283 return 0; (gdb) next 289 }
Component: General → Libraries
Product: Firefox → NSS
Version: Trunk → trunk
QA Contact: general → libraries
Whiteboard: [sg:investigate]
Only "mostly" universal: it wouldn't work for any site with "guninski.com" in it. Of course you could use "example.invalid" and be sure you're not excluding anything worthwhile. Given any CA that allows a null probably allows a tilde, yeah, this would be bad. We fixed this when we fixed bug 159483, disallowing these old-style regexps. The code is still present for server shops who require backward compatibility for internal reasons, but should be turned off in clients.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
> Only "mostly" universal: it wouldn't work for any site with "guninski.com" this is pedantically right and i will add "almost universal" to the subject unless i manage to include multiple CN / altsubjectname to make it truely universal. > Of course you could use "example.invalid" fighting pedantism with pedantism, getting cert for "example.invalid" is not trivial without some other kind of other attack. playing with CAs suggest the CA must *suspect* one have control over "example.invalid" and i don't see a way to make it suspect this without some other attack. of course s/example.invalid/onetimedomain${RAND}.com/ would work.
Summary: universal wildcard certificate in |port_RegExpMatch| when NSS_USE_SHEXP_IN_CERT_NAME is set → mostly universal wildcard certificate in |port_RegExpMatch| when NSS_USE_SHEXP_IN_CERT_NAME is set
> You're looking at obsolete source. Look at the gdb breakpoints are authentic.
Georgi, you're looking at old source code, not the current NSS sources. You're looking at code that doesn't have the current fixes. Reporting bugs in code that has already been fixed isn't a good use of anyone's time.
Why doesn't mozilla-central (trunk) have these fixes yet then?
Because someone in MoCo doesn't want to take NSS 3.12.4
(In reply to comment #8) > Because someone in MoCo doesn't want to take NSS 3.12.4 Stop making stuff up, Nelson. Bug 504080 supposedly took mozilla-central to NSS_3_12_4_FIPS4. Does that tag not include the fixes that are already on NSS trunk? If not, what do we need to do to get mozilla-central to a tag of 3.12.4 that has these fixes?
Reed, let's not waste any more time on this. FF 3.5.1 is not vulnerable UNLESS the user sets an environment variable named NSS_USE_SHEXP_IN_CERT_NAME, and I estimate the total number of users in the world who've done that to be 2 (both reading this bug, BTW).
So, if only 2 people in the world use NSS_USE_SHEXP_IN_CERT_NAME, can we just remove that code completely so there's no possible way users could be vulnerable to this problem?
Firefox is not the only code that uses NSS.
(In reply to comment #12) > Firefox is not the only code that uses NSS. What consumers of NSS actually use that environmental variable?
Server products running in intranet environments, acting as clients.
> UNLESS the user sets an environment variable named NSS_USE_SHEXP_IN_CERT_NAME i wrote this in the subject of the bug. nelson: are you saying that the new uberleet code is safe in this scenario even if it is used by less than 2 followers?
Georgi, I don't know what you mean by "followers", but I suggest you try the new code yourself. The files with the fixes are public and may be seen at http://mxr.mozilla.org/security/find?text=&kind=text&string=portreg
looking at the new code, i suspect it is still vulnerable if the env. var is set. is this true?
You suspect? If you can find a test case that fails, please report the failing test case in a comment in this bug, or in bug 509175. If you only suspect there is a problem, but cannot give a test case that fails, that doesn't help us.
the bug is in firefox. to reproduce: export NSS_USE_SHEXP_IN_CERT_NAME=WHO_FIPS_CERTIFIED_THIS\? visit a site presenting a certificate with CN=***~bolyard.meme signed by a fips certified ca i suggest this bug be opened since it is resolved and nelson still pretends to not get it
fyi information i didn't see the memory corruption bug when deleting silently installed in mofo advisories - nelson downplayed it too ;)
... deleting silently installed *user certificates*...
The test case suggested in comment 19 causes absolutely no problem with the portreg code in NSS at the URL given in comment 16. Georgi, the shexp code is not crypto code. It's not part of any FIPS certified library. CA's aren't FIPS certified either.
Whiteboard: [sg:investigate] → [sg:dupe 504456]
Group: core-security
You need to log in before you can comment on or make changes to this bug.