Mozilla Auto-Update Vulnerability
Friday, September 15, 2006
Mozilla's auto-update system is a feature recently added to Firefox and Thunderbird that promises to bring prompt security updates to users without manual interaction. Unfortunately, this feature contains a vulnerability allowing attackers to hijack the update process and deliver malicious updates, resulting in the victim's host being compromised.
Methodology
To check for updates, Firefox contacts aus2.mozilla.org over HTTPS and requests the following XML file:
/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml
This URL template is stored in the app.update.url preference. An example URL with the placeholders replaced with real values:
/update/1/Firefox/1.5.0.3/2006042618/Linux_x86-gcc3/en-US/release/update.xml
The XML file contains the locations of the patch to download along with its size and SHA-1 hash. More on the update.xml format can be found on Mozilla's Wiki.
Patch Format
The actual update package is delivered as a Mozilla ARchive (MAR), a custom format developed by Mozilla for the auto-update system. The MAR contains the full payload of the update along with a special file, update.manifest, that specifies which files to add, delete, or modify. Existing files marked for modification are updated using a variation of the bsdiff format.
MAR manipulation tools and libmar can be found here.
Security Vulnerability
Man-in-the-middle attacks on this update process are thwarted by the use of HTTPS and any invalid certificates will cause the update process to abort. While the actual update is downloaded over HTTP, the SHA-1 hash verification provides integrity guarantees for the received update. However, Firefox makes a significant misstep in its certificate verification process, resulting in a vulnerability that can lead to host compromise.
Certificate Cache
When Firefox encounters a SSL certificate from an unknown authority (self-signed, spoofed, etc), it will display a warning to the user. The user will be prompted with three options: accept the certificate permanently, accept the certificate temporarily for the current session, or reject the certificate.
Unfortunately, many users will opt to accept to certificate in order to reach their destination, opening themselves to SSL MITM attacks. In fact, even I accept self-signed certificates for non-critical sites during my average surfing activities. When a certificate is accepted, either permanently or temporarily, it is stored in Firefox's certificate cache to suppress warnings on subsequent visits to that HTTPS site.
The Attack
The auto-update system will abort if it encounters an invalid certificate, however, it will NOT abort if it is presented with a certificate that already exists in the certificate cache. Therefore, if an attacker can get his certificate accepted by a victim, the attacker gains free reign to hijack the auto-update session and execute arbitrary code on the victim's host by delivering a malicious update.
Assuming an attacker has control of the victim's DNS resolution (eg. arpspoofing on a local network), it is trivial to intercept all HTTPS requests to arbitrary websites and trick the user into accepting the forged certificate for the aus2.mozilla.org update server. Once the forged certificate is in the victim's cache, the attacker can simply wait until the next auto-update is triggered either manually by the user or automatically by Firefox's internal timers. When the auto-update occurs, the attacker will intercept the request to aus2.mozilla.org, return a malicious update.xml, and deliver the malicious MAR payload to the victim.
While accepting invalid certificates is generally a bad idea, a user voluntarily surrendering their network security for whatever reason by accepting an invalid cert should never unknowingly be surrendering their host security as well. As Daniel Veditz states in bug 340198:
But the user, being naive, thinks they're saying "thanks for warning me this may be a dodgy site, but I'd like to connect anyway. I'll be careful." They have no concept that this temporary choice would have any bearing on the security of any non-browsing feature (or, for that matter, that it applies to browsing any other site--but that is bug 308244 as you point out). In particular they have no clue that we rely on the integrity of these certs to secure the update feature.
Proof of Concept
I created a proof of concept demonstrating this vulnerability, which is available download, firefox-poc.tar.bz2. It will start its own SSL webserver, spoof ARP and DNS, hijack update requests, and delivers a sample MAR file that contains a "Hello World" bash script. See the included README for detailed instructions.
