Establishing Digital Trust: Don't Sacrifice Security for Convenience
If you're a Firefox user, don't be surprised to get an update notice when you open your browser this morning.
Yet again, Mozilla developers have pushed out an update for Firefox that aims to fix nagging security issues. Firefox 126.96.36.199 takes a kick at dealing with a particularly nasty Cross-Site Scripting (XSS) flaw that had been publicly reported months ago.
Mozilla's security advisory describes the XSS flaw as being related to the "jar: URI" scheme, which is a mechanism to support digitally signed Web pages and allows those pages to load ZIP archives.https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=iIn February, Mozilla staffer Jesse Rudderman publicly reported in Bugzilla entry 369814 that "any site that allows image uploads (e.g. avatar images) without binary content sniffing is likely to be vulnerable to XSS ... as a result. An attacker would only have to upload a malicious [ZIP] file to the site and get users to follow a 'jar:' link."
Earlier this month, however, Mozilla developers reconsidered the flaw's severity and its ability to be exploited when noted security research Michal Zalewski revealed that the problem could affect a large part of the Web.
"Please note that the vulnerability is more severe and more difficult to mitigate than initially indicated; it does not require the attacked site to host a malicious JAR file, as the security context is not properly updated on 302 redirects," Zalewski wrote in a Bugzilla entry.
Mozilla's advisory today also notes that a published proof-of-concept shows the flaw could have been used to steal the Gmail contacts of logged-in Gmail users.
Firefox 188.8.131.52 also fixes a vulnerability that could have enabled Cross-Site Request Forgery (CSRF) attacks. The flaw is related to how Firefox handles referrer headers, which could potentially be spoofed by an attacker.
"When navigation occurs due to setting window.location, the Referrer header is supposed to reflect the address of the content which initiated the script," Mozilla explained in its advisory. "Instead, the referrer was set to the address of the window (or frame) in which the script was running, and this vulnerability arises from that tiny difference."