Bug 512912 (CVE-2009-2404)

Summary:	CVE-2009-2404 nss regexp heap overflow
Product:	[Other] Security Response	Reporter:	Mark J. Cox <mjc>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	low
Version:	unspecified	CC:	caillon, emaldona, kengert, kreilly, psplicha, rrelyea, security-response-team, stransky
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-03-29 09:14:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	230399, 512918, 514915, 565580, 565581, 565584, 565585, 582839
Bug Blocks:

Description Mark J. Cox 2009-07-21 10:19:14 UTC

A heap overflow flaw was found in a regular expression parser in the NSS library used to match common names in certificates. A malicious site could present a carefully crafted certificate in such a way as to trigger the heap overflow leading to a crash or possibly execute arbitrary code as the user running a browser such as firefox.

The overflow happens when the browser checks if the hostname of the site you are visiting matches the Common Name (CN) field of the presented certificate. This check (cert_TestHostName) only happens automatically if the certificate is one that is signed by a Certificate Authority you have previously trusted. If the attacker presents a malicious self-signed certificate, or one signed by an untrusted CA, the user is presented with a dialog box about the certificate before the vulnerable function is called. If the user chooses to accept the certificate then the vulnerable function is called and the heap overflow happens. So this issue does require slightly more user interaction to be exploited.

Co-incidentally, the handling of regular expressions for NSS versions 3.12.3 and above was changed to use a different and simpler regular expression routine which is not vulnerable to this issue. Therefore where a system has NSS 3.12.3 installed, it is not vulnerable to this issue by default. (Although it is possible to change Firefox back to use the old vulnerable library it is not something that is expected users to have done, and is not an obvious documented ability)

For Red Hat Enterprise Linux 5, Firefox uses the system provided NSS library. This library was updated to a versions greater than 3.12.3 by RHBA-2009:1161 on 20th July 2009. Therefore systems updated to RHBA-2009:1161 are protected by default from this issue.

For Red Hat Enterprise Linux 4, Firefox uses the system provided NSS library. This library is due to be updated to a version greater than 3.12.3 and this will probably happen within the week (so before the embargo lifts).

For Red Hat Enterprise Linux 3 we do not ship Firefox but instead SeaMonkey which provides the NSS library. SeaMonkey will need updating to correct this issue.

Comment 1 Mark J. Cox 2009-07-21 10:22:45 UTC

I've verified the flaw by creating malicious test certificates (both signed by a personal CA and self-signed):

SeaMonkey on RHEL3 crashes with SEGV
Firefox on RHEL5 prior to RHBA-2009:1161 crashes
Firefox on RHEL5 after RHBA-2009:1161 does not call affected routine, no crash

Comment 11 Mark J. Cox 2009-07-27 13:27:45 UTC

Because this issue requires extra user interaction it perhaps does not qualify to be labelled as severity critical (A victim would be presented with a display showing the bad certificate details and would have to accept it before the overflow happens).  However, recent research found that the certificate warnings are often ignored, and you could probably make your malicious certificate in such a way that the overflow isn't obvious when the certificate is displayed:

http://www.goodgearguide.com.au/article/312438/security_certificate_warnings_don_t_work_researchers_say

So therefore we'll keep this as AC:M and impact=critical

Comment 13 Elio Maldonado Batiz 2009-07-28 15:33:40 UTC

In the upstream patch for Firefox, as well in more current versions of NSS shipped with RHEL 4 and 5, the  NSS_USE_SHEXP_IN_CERT_NAME environment variable is checked. If set, the code reverts to the old way of checking for backward compatibility. If not set, which is the default, it then follows the RFC 2818 approach which fixes the problem. On RHEL-3 we can't count on NSS_USE_SHEXP_IN_CERT_NAME so this patch follows the RFC 2818 approach always thus fixing the problem. This patch is only required for RHEL-3.

Comment 18 Mark J. Cox 2009-07-30 21:54:49 UTC

Updating comment #11, Moxie found it was possible to get such a certificate signed by a CA.  Although the CA is likely to no longer issue certificates with nulls (and each attempt of your shellcode would require a new signed certificate), it may well be possible to use this attack without the need for the user to accept a certificate manually.  This is already rated impact=critical, so no change to the rating.

Comment 19 Mark J. Cox 2009-07-30 21:56:08 UTC

This issue was presented by MOXIE last night at Black Hat and is outlined in the public slides:
        http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf

Therefore removing embargo

Comment 20 errata-xmlrpc 2009-07-30 22:10:01 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1184 https://rhn.redhat.com/errata/RHSA-2009-1184.html

Comment 21 errata-xmlrpc 2009-07-30 22:19:21 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2009:1185 https://rhn.redhat.com/errata/RHSA-2009-1185.html

Comment 22 errata-xmlrpc 2009-07-30 22:20:10 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1186 https://rhn.redhat.com/errata/RHSA-2009-1186.html

Comment 24 errata-xmlrpc 2009-07-31 14:31:41 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2009:1190 https://rhn.redhat.com/errata/RHSA-2009-1190.html

Comment 25 errata-xmlrpc 2009-08-12 14:31:20 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.2 Z Stream

Via RHSA-2009:1207 https://rhn.redhat.com/errata/RHSA-2009-1207.html