Forgot your password?
typodupeerror

Comment: Re:And yet, mozilla won't let you disable javascri (Score 1) 68

by dveditz (#47416295) Attached to: 'Rosetta Flash' Attack Leverages JSONP Callbacks To Steal Credentials
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.]

Comment: Re:Incentives (Score 1) 95

by dveditz (#44245531) Attached to: Study Finds Bug Bounty Programs Extremely Cost-Effective

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.

Comment: Re:Persona vs Browserid (Score 1) 81

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.

Comment: Re:Say what! (Score 2) 309

by dveditz (#37561648) Attached to: To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework

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.

Comment: Re:Umm... Flash? (Score 2) 309

by dveditz (#37561558) Attached to: To Stop BEAST, Mozilla Developer Proposes Blocking Java Framework

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.

Encryption

SSL/TLS Vulnerability Widely Unpatched 103

Posted by Soulskill
from the never-put-off-until-tomorrow-what-you-can-forget-entirely dept.
kaiengert writes "In November 2009 a Man-In-the-Middle vulnerability for SSL/TLS/https was made public (CVE-2009-3555), and shortly afterwards demonstrated to be exploitable. In February 2010 researchers published RFC 5746, which described how servers and clients can be made immune. Software that implements the TLS protocol enhancements became available shortly afterwards. Most modern web browsers are patched, but the solution requires that both browser developers and website operators take action. Unfortunately, 16 months later, many major websites, including several ones that deal with real world transactions of goods and money, still haven't upgraded their systems. Even worse, for a big portion of those sites it can be shown that their operators failed to apply the essential configuration hotfix. Here is an exemplary list of patched and unpatched sites, along with more background information. The patched sites demonstrate that patching is indeed possible."
Security

LulzSec Teams With Anonymous, In Operation AntiSec 419

Posted by CmdrTaco
from the summon-dennis-leary dept.
c0lo writes "After a brief spat where the notorious Anonymous hacking collective sniped at Lulzsec, the 'upstart' hacking collective, for crowing about low-rent Denial of Service attacks on the CIA and 4chan websites, the two groups have apparently teamed up in operation Anti-Sec. The operation's 'top priority is to steal and leak any classified government information, including email spools and documentation. Prime targets are banks and other high-ranking establishments. If they try to censor our progress, we will obliterate the censor with cannonfire anointed with lizard blood.' We can only predict that the following will be unpredictable: store canned food and flash batteries, change your eBanking password daily."
Data Storage

Military Bans Removable Media After WikiLeaks Disclosures 346

Posted by timothy
from the no-using-your-photographic-memory dept.
cgriffin21 writes "The Pentagon is taking matters into its own hands to prevent the occurrence of another WikiLeaks breach with removable media ban, preventing soldiers from using USB sticks, CDs or DVDs on any systems or servers. The directive prohibiting removable media followed the recent publication of more than 250,000 diplomatic cables, which were leaked to whistleblower Web site WikiLeaks at the end of last month by a military insider."

Comment: Re:Serious Problem With Mozilla (Score 1) 179

by dveditz (#34495688) Attached to: Microsoft Adds 'Do Not Track' Option For IE9

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.

Comment: Re:A money grab (Score 2, Informative) 164

by dveditz (#34228852) Attached to: The Ascendancy of<nobr> <wbr></nobr>.co

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.

Comment: ping (Re:HTML 5?) (Score 1) 321

by dveditz (#33683588) Attached to: Is the Web Heading Toward Redirect Hell?

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>

Counting in octal is just like counting in decimal--if you don't use your thumbs. -- Tom Lehrer

Working...