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.
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
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
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.
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.
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
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
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
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
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
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