506407 - NULs in cert SAN email addresses are not properly escaped

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Nelson Bolyard (seldom reads bugmail)]

I don't know if this is exploitable or not, but I'm marking this security 
sensitive just to be on the safe side.

For bug 480509, I changed a common function used by all the CERT_GetXXXName 
functions, so that it would always escape embedded NUL characters.  That took 
care of nearly all cases.  All the code paths that call CERT_GetNameElement 
are safe now.  But it missed (at least) one code path that does not use 
CERT_GetNameElement.  

The code that gets email addresses out of the SAN extension fails to do 
any escaping of embedded NULs.  Function cert_GetCertificateEmailAddresses
calls static function appendItemToBuf to convert the email address to a 
string.  

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/alg1485.c&rev=1.37&mark=1432-1434#1414

The string passed to appendItemToBuf does not come from CERT_GetNameElement in that case, and appendItemToBuf does no escaping.  

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/alg1485.c&rev=1.37&mark=1368-1370#1361

Sigh.  The patch will be a pretty simple change to appendItemToBuf.

The question in my mind is: Given that email addresses never use wildcards,
How might one get a CA to issue a cert for an email address like
        [e-mail]\[e-mail] 

How might a CA be fooled into thinking that's a legitimage address in the
badguys.org domain?  If the answer is: no way, then this bug is not 
high priority, IMO.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Patch v1 - now tested, for review

I will request review when I have completed testing.

Comment 2

[Julien Pierre]

Re: comment 0, as far as fooling a CA, that's likely to be very specific to each CA's enrollment process, including sub-CAs that we have no knowledge of or direct control over. So, I think we should enforce valid email address syntax.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Attachment: test cert

This is a test cert with lots of email addresses with NULs in them.
Having tested with it, I now request review for the patch above.

Comment 4

[Honza Bambas (:mayhemer)]

Ups, I've seen this before, but didn't pay much attention to it. PSM displays the SAN like this (in Shiretoko):

E-Mail Address: mail3[0000]@foo.com
E-Mail Address: mail4[0000]@foo.com

the [0000] is in place of the special character indicating a zero character. So, for PSM UI it's IMHO not urgent.

The email SAN will probably more effect thunderbird and email programs, right? I have to establish some test environment for this.

Comment 5

[Robert Relyea]

Comment on attachment 390615 [details] [diff] [review]
Patch v1 - now tested, for review

r+ rrelyea

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Checking in certdb/alg1485.c; new revision: 1.38; previous revision: 1.37

Thanks, Bob

Comment 7

[Alexei Volkov]

Comment on attachment 390615 [details] [diff] [review]
Patch v1 - now tested, for review

The only negative difference with the original code that I've notice was that the size of the escaped string grows quite fast(num_esc_chars*2). Even if you have a buffer as long as cert der itself, you still can overrun it and not add the address or  make the buffer to be significantly small, so other, following addresses would not fit there.

Still, it seems to be insignificant.
r+

Comment 8

[Honza Bambas (:mayhemer)]

Just checked that PSM email address checking is vulnerable w/o this fix and not w/ this fix. 

Actually, TB or SM based on NSS earlier then 3.12.4 are vulnerable to spoof of this type. 

This bug's fix makes TB (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3pre) Gecko/20090805 Shredder/3.0b3pre) correctly recognize that SAN is wrong and the message has '?' over the signature sign saying that the signature is correct but the sender is wrong.

However, PSM cert details of SAN remains intact by the fix. There is a full name including the zero-byte (and following attacker's name) but not in form of \00 but in form of [0000] indication character.