vendor:
Firefox
by:
Jesse Ruderman
9.3
CVSS
HIGH
Buffer Overflow
119
CWE
Product Name: Firefox
Affected Version From: 3.0.13
Affected Version To: 3.0.13
Patch Exists: YES
Related CWE: CVE-2009-2411
CPE: a:mozilla:firefox
Metasploit:
https://www.rapid7.com/db/vulnerabilities/freebsd-vid-bce1f76d-82d0-11de-88ea-001a4d49522b/, https://www.rapid7.com/db/vulnerabilities/apple-osx-subversion-cve-2009-2411/, https://www.rapid7.com/db/vulnerabilities/linuxrpm-RHSA-2009-1203/, https://www.rapid7.com/db/vulnerabilities/centos_linux-cve-2009-2411/, https://www.rapid7.com/db/vulnerabilities/gentoo-linux-cve-2009-2411/, https://www.rapid7.com/db/vulnerabilities/suse-cve-2009-2411/
Other Scripts:
N/A
Tags: N/A
CVSS Metrics: N/A
Nuclei References:
N/A
Nuclei Metadata: N/A
Platforms Tested: Windows, Linux, Mac
2009
Firefox addmodule() Vulnerability
Firefox up through 3.0.13 had an obscure little function under window.pkcs11: long addmodule(in DOMString moduleName, in DOMString libraryFullPath, in long cryptoMechanismFlags, in long cipherFlags). Attacker doesn't get zero click install -- there's a dialog -- but: 1) Attacker does get to customize the dialog via moduleName 2) The dialog is modal, so the user doesn't get access to Firefox again until they hit OK (can't even close Firefox) 3) On Windows, he can put a UNC path in for the Library path. There's probably similar on OSX and some Linux distros. Even without, there's usually a way to get a file in a known location -- see John Heasman's Java work. LoadLibrary of Attacker library on OK.
Mitigation:
Upgrade to Firefox 3.0.14 or later