No modern browser allows javascript URLs in CSS. None. Completely non-standard and dangerous. Old IE and Netscape? Yeah, they were dumb back then, but that was over a decade ago.
That misses the point of this vuln entirely which requires NO JavaScript whatsoever on the user's part. The site is written to use JavaScript and set up a JSONP service. This trick fools the JSONP service into returning a "callback name" that just so happens to be valid.swf data. The attacker then uses the URL that triggers that response in a context that expects flash (e.g. an or tag). As far as Flash is concerned the.swf came from that site so it's allowed to make any further requests to that site it wants.
[I, too, am sad the UI for disabling JS is gone, but honestly for myself I've always used the Web Developer Toolbar when I wanted to disable JS because it's faster to get to that option.]
Why was ping a "Mozilla" fiasco? It was a WHATWG specification, never shipped enabled in a Firefox final release, but is currently supported by Chrome.
As the Firefox Security Manager I completely and vehemently disagree. I employ a team that spends 100% of their time "going on bug-hunts" looking for security bugs in Firefox, and I know my counter-part at Google is doing the same for Chrome. Our Bug Bounty programs (VRP? ugh, so very corporate) are an incentive for people who stumble on neat stuff to pass it on, not a substitute for doing the work ourselves.
Mozilla isn't too keen on that, either: we're quite serious about wanting this to be a distributed system. Announcing Yahoo as an Identity Provider is an important step toward that. Another important step will be native navigator.id support in the browser so sites don't need to load the polyfill from persona.org.
No browser would accept a *.* certificate. According to the spec '*' can only appear in the leftmost label and can match only within that label. Long ago Netscape originally supported an expressive regexp syntax; modern browsers follow the RFC.
Mozilla is working on a short-term patch to TLS that will prevent the attack in the browser (see the bug), and in the longer term will implement TLS 1.2 (but if you don't prevent TLS downgrades you haven't fixed anything, and if you do you break all the version-intolerant servers out there).
No browser fix can prevent this attack from using a vulnerable plugin such as Java since Java is making these network requests on its own. Either the plugin vendor issues a fix, or you fix it by disabling the plugin.
If there were "better" ways that didn't require a plugin they would have demoed that. Maybe there are such ways, but not through simple <script> or <img> tags. In some ways I wish that is what they used: we could have fixed that ourselves rather than being at the mercy of plugin vendors.
We're also investigating a different approach of double-keying cookies with the primary and 3rd-party domains, which has the advantage of preventing advertisers from correlating your visits across sites within a session. This breaks even more legitimate things (as Opera also found when they experimented with this) so we're still brainstorming.
Actually, the reason Google knows that bit more about sites people visit, is that Firefox, Chrome and Safari all send each and every domain you visit to Google's Safebrowsing servers before they connect to it.
That is not how SafeBrowsing works. Firefox downloads a large database of hash prefixes. If the hashes of the domain and url are not in the list you go to the site and nothing is sent to Google. If the first bit of the hash matches an entry in the list Firefox asks Google for the list of complete hashes that start with that prefix. If the site's hash matches then you're blocked, if it doesn't you're not, but nothing more is sent.
To further obfuscate things, when Firefox finds a prefix match it doesn't just ask for the hashes matching that prefix, it also asks for the hashes matching a couple other random prefixes from the list.
Google may still know all the sites you visit through cookies on google-analytics or AdSense, but they're not getting that information from SafeBrowsing.
Firefox was an early adopter of the <a ping> HTML 5 feature to solve exactly this redirect-for-tracking issue, added in early 2006: https://bugzilla.mozilla.org/show_bug.cgi?id=319368 There was huge controversy that the feature helped sites track users (never mind that you're being tracked as it is, and that the feature let you turn it off) and it was disabled before it ever shipped. We thus continue trudging through redirect hell when the browser could have been doing that for us in parallel while giving us the content we wanted.
The feature would have sold better if it was framed as <a shortcut> or <a dest>. That is, keep the historical href behavior jumping through redirects in old browsers, while new browsers could just load the final content directly from the shortcut (or dest) attribute and treat href as the ping. I'm sure that suggestion gives HTML purist fits on semantic grounds. At least it's backward compatible unlike ping which requires a site to choose between serving different content to old and new browsers, forgoing link tracking on old browsers (the majority? fat chance), or not supporting the feature at all (we have a winner!).
URL-shorteners are a different use-case altogether and not served by <a ping>
We don't advertise it because anyone competent to check SHA1 hashes should be able to check PGP signatures, and the mirror network scales unlike hosting everything ourselves. Obviously the SSL server is not mirrored because giving out the cert would make it pointless.
It will enable all your officially incompatible addons just like the pref, and you can help by reporting your add-ons as working fine or not compatible (reporting is completely optional).
The issue at hand is the CEO of a for-profit organization backed by a non-profit organization, and hence pays no taxes whatsoever on the $66 million some of which goes into obscene CEO profits.
The Mozilla Corporation pays taxes on everything it earns just like every other taxable corporation. It is not allowed to share money back with the Foundation or risk costing the Foundation its non-profit status.
It _does_ work unless you hit some bug (and there have been some that affect some people). If you were an early adopter in particular there were some database corruption issues. If that's the case deleting the places database is often the best fix (especially if there's nothing in there you care about -- you're clearing private data, right?). Instructions at http://support.mozilla.com/ for this and other common problems.
The other issue is that the url bar shows both history and bookmarks. Obviously people don't want to clear their bookmarks so some data still shows up even after clearing history. This issue has been addressed in Firefox 3.5 with an option to not show bookmarks in the URL bar (on the Privacy tab in Options).
The reason something like this scares me is that it lulls users into a higher level of trust... and doesn't protect them from hacked sites, or sites that choose not to implement this.
This mechanism isn't intended for users -- this is a tool for site authors, to cooperate with them in enforcing their policies. The site still has to make a best effort at implementing those policies themselves to protect all their visitors using browsers that don't support CSP (which includes every officially released version of Firefox to date). This is an extra layer of protection for users of CSP-compliant browsers, and a benefit to the site through the reporting function.
Please do continue running NoScript if you like. CSP is a mechanism for site authors to declare their policy, add-ons like NoScript and AdBlock are tools for users to declare their policies.
Even if this was never implemented in any other browser sites still benefit through early detection of active attacks. If your site implements a security policy with a report URI then every Firefox visitor will be conducting a passive security scan on every page they visit, at least for the types of security problems CSP targets (primarily XSS).
If you really don't want any upgrades just go into the options and toggle the "Check for updates" box. The default auto-upgrade is appropriate for 99% of internet users, but if you're one of the 1% please use the preference we put in just for you. No need to get all hostile about it.
Note that this work, also being implemented by Opera, is in the process of being standardized in the W3C HTML working group, with Apple, Opera and Mozilla as members and co-chaired by Chris Wilson of Microsoft. This is the polar opposite of "embrace and extend". Of course Mozilla and Opera run the risk that the final standard will differ slightly from what they initially implement and that they (and early adopters) will have to do some rework. It happens, but in the long run no one cares. Same thing happened in the 802.11 wireless standards, but we did eventually all get equipment that interoperates.
It's especially hard on vendors who sell browser-based applications which run locally. The customer wants SSL, even on their local network, and even for non-sensitive data... But then they go to their local machine and get a big warning from Firefox or IE that their connection is insecure... But they don't want to pay for a certificate.
No, that should be even easier, just set up a local root certificate rather than use self-signed certs. Each user installs that root (or has it preinstalled by IT) and everyone can connect securely to all your internal site with no warnings.
Slashdot Mirror
A few hours ago Mozilla released Firefox 36.0.3 for Windows, OS X, Linux, and Android to patch the exploits revealed at the Pwn2Own contest.
No modern browser allows javascript URLs in CSS. None. Completely non-standard and dangerous. Old IE and Netscape? Yeah, they were dumb back then, but that was over a decade ago.
That misses the point of this vuln entirely which requires NO JavaScript whatsoever on the user's part. The site is written to use JavaScript and set up a JSONP service. This trick fools the JSONP service into returning a "callback name" that just so happens to be valid .swf data. The attacker then uses the URL that triggers that response in a context that expects flash (e.g. an or tag). As far as Flash is concerned the .swf came from that site so it's allowed to make any further requests to that site it wants.
[I, too, am sad the UI for disabling JS is gone, but honestly for myself I've always used the Web Developer Toolbar when I wanted to disable JS because it's faster to get to that option.]
Why was ping a "Mozilla" fiasco? It was a WHATWG specification, never shipped enabled in a Firefox final release, but is currently supported by Chrome.
As the Firefox Security Manager I completely and vehemently disagree. I employ a team that spends 100% of their time "going on bug-hunts" looking for security bugs in Firefox, and I know my counter-part at Google is doing the same for Chrome. Our Bug Bounty programs (VRP? ugh, so very corporate) are an incentive for people who stumble on neat stuff to pass it on, not a substitute for doing the work ourselves.
Mozilla isn't too keen on that, either: we're quite serious about wanting this to be a distributed system. Announcing Yahoo as an Identity Provider is an important step toward that. Another important step will be native navigator.id support in the browser so sites don't need to load the polyfill from persona.org.
"According to Mozilla, the B2G platform can run acceptably well in an environment with as little as 256MB of RAM." from http://arstechnica.com/gadgets/2012/07/mozillas-b2g-to-be-called-firefox-os-will-ship-in-2013/
No browser would accept a *.* certificate. According to the spec '*' can only appear in the leftmost label and can match only within that label. Long ago Netscape originally supported an expressive regexp syntax; modern browsers follow the RFC.
Mozilla is working on a short-term patch to TLS that will prevent the attack in the browser (see the bug), and in the longer term will implement TLS 1.2 (but if you don't prevent TLS downgrades you haven't fixed anything, and if you do you break all the version-intolerant servers out there).
No browser fix can prevent this attack from using a vulnerable plugin such as Java since Java is making these network requests on its own. Either the plugin vendor issues a fix, or you fix it by disabling the plugin.
If there were "better" ways that didn't require a plugin they would have demoed that. Maybe there are such ways, but not through simple <script> or <img> tags. In some ways I wish that is what they used: we could have fixed that ourselves rather than being at the mercy of plugin vendors.
The "pressure from advertisers" came after the feature was turned off because it didn't work right: https://bugzilla.mozilla.org/show_bug.cgi?id=570630#c15
We're also investigating a different approach of double-keying cookies with the primary and 3rd-party domains, which has the advantage of preventing advertisers from correlating your visits across sites within a session. This breaks even more legitimate things (as Opera also found when they experimented with this) so we're still brainstorming.
Actually, the reason Google knows that bit more about sites people visit, is that Firefox, Chrome and Safari all send each and every domain you visit to Google's Safebrowsing servers before they connect to it.
That is not how SafeBrowsing works. Firefox downloads a large database of hash prefixes. If the hashes of the domain and url are not in the list you go to the site and nothing is sent to Google. If the first bit of the hash matches an entry in the list Firefox asks Google for the list of complete hashes that start with that prefix. If the site's hash matches then you're blocked, if it doesn't you're not, but nothing more is sent.
To further obfuscate things, when Firefox finds a prefix match it doesn't just ask for the hashes matching that prefix, it also asks for the hashes matching a couple other random prefixes from the list.
Google may still know all the sites you visit through cookies on google-analytics or AdSense, but they're not getting that information from SafeBrowsing.
Firefox was an early adopter of the <a ping> HTML 5 feature to solve exactly this redirect-for-tracking issue, added in early 2006: https://bugzilla.mozilla.org/show_bug.cgi?id=319368 There was huge controversy that the feature helped sites track users (never mind that you're being tracked as it is, and that the feature let you turn it off) and it was disabled before it ever shipped. We thus continue trudging through redirect hell when the browser could have been doing that for us in parallel while giving us the content we wanted.
The feature would have sold better if it was framed as <a shortcut> or <a dest>. That is, keep the historical href behavior jumping through redirects in old browsers, while new browsers could just load the final content directly from the shortcut (or dest) attribute and treat href as the ping. I'm sure that suggestion gives HTML purist fits on semantic grounds. At least it's backward compatible unlike ping which requires a site to choose between serving different content to old and new browsers, forgoing link tracking on old browsers (the majority? fat chance), or not supporting the feature at all (we have a winner!).
URL-shorteners are a different use-case altogether and not served by <a ping>
A public benefit corporation wholly owned by a non-profit foundation. If you don't think this approach furthers the mission please let us know.
SSLed checksums for the binaries... oh, wait, Mozilla doesn't bother publishing those, for some reason.
Really? So what are these, then? https://archive.mozilla.org/pub/mozilla.org/firefox/releases/3.6/SHA1SUMS
We don't advertise it because anyone competent to check SHA1 hashes should be able to check PGP signatures, and the mirror network scales unlike hosting everything ourselves. Obviously the SSL server is not mirrored because giving out the cert would make it pointless.
Much better to use the Add-on Compatibility Reporter https://addons.mozilla.org/en-US/firefox/addon/15003
It will enable all your officially incompatible addons just like the pref, and you can help by reporting your add-ons as working fine or not compatible (reporting is completely optional).
The issue at hand is the CEO of a for-profit organization backed by a non-profit organization, and hence pays no taxes whatsoever on the $66 million some of which goes into obscene CEO profits.
The Mozilla Corporation pays taxes on everything it earns just like every other taxable corporation. It is not allowed to share money back with the Foundation or risk costing the Foundation its non-profit status.
It _does_ work unless you hit some bug (and there have been some that affect some people). If you were an early adopter in particular there were some database corruption issues. If that's the case deleting the places database is often the best fix (especially if there's nothing in there you care about -- you're clearing private data, right?). Instructions at http://support.mozilla.com/ for this and other common problems.
The other issue is that the url bar shows both history and bookmarks. Obviously people don't want to clear their bookmarks so some data still shows up even after clearing history. This issue has been addressed in Firefox 3.5 with an option to not show bookmarks in the URL bar (on the Privacy tab in Options).
Firefox 3.5 is _not_ vulnerable to this attack.
Mozilla Firefox has supported pre-fetching for years. It has not always been received well.
This mechanism isn't intended for users -- this is a tool for site authors, to cooperate with them in enforcing their policies. The site still has to make a best effort at implementing those policies themselves to protect all their visitors using browsers that don't support CSP (which includes every officially released version of Firefox to date). This is an extra layer of protection for users of CSP-compliant browsers, and a benefit to the site through the reporting function.
Please do continue running NoScript if you like. CSP is a mechanism for site authors to declare their policy, add-ons like NoScript and AdBlock are tools for users to declare their policies.
Even if this was never implemented in any other browser sites still benefit through early detection of active attacks. If your site implements a security policy with a report URI then every Firefox visitor will be conducting a passive security scan on every page they visit, at least for the types of security problems CSP targets (primarily XSS).
If you really don't want any upgrades just go into the options and toggle the "Check for updates" box. The default auto-upgrade is appropriate for 99% of internet users, but if you're one of the 1% please use the preference we put in just for you. No need to get all hostile about it.
Note that this work, also being implemented by Opera, is in the process of being standardized in the W3C HTML working group, with Apple, Opera and Mozilla as members and co-chaired by Chris Wilson of Microsoft. This is the polar opposite of "embrace and extend". Of course Mozilla and Opera run the risk that the final standard will differ slightly from what they initially implement and that they (and early adopters) will have to do some rework. It happens, but in the long run no one cares. Same thing happened in the 802.11 wireless standards, but we did eventually all get equipment that interoperates.
No, that should be even easier, just set up a local root certificate rather than use self-signed certs. Each user installs that root (or has it preinstalled by IT) and everyone can connect securely to all your internal site with no warnings.