Friday, October 24, 2014

Do not purchase if tamper-evident seal is damaged

Leviathan Security this week managed to catch, red-handed as it were (the malicious server appears to be in Russia and is even named, puckishly, kulak), a Tor exit node actively patching software and modifying it as it came over the wire. Long hypothesized but now finally demonstrated in the wild, this particular node was looking for uncompressed Portable Executable (Windows) binaries and monkeypatching them on their way back to the requester. In fact, it was so active that it gave itself away by trying to patch nearly anything that looked like a Windows application; a smarter node would only patch specific binaries and pass others unmodified, meaning these stealthier malefactors may never be discovered by security researchers even if they do in fact exist.

This applies to unencrypted downloads, of course; assuming no flaws allowing a man-in-the-middle attack, this sort of screwing around would be immediately obvious on a TLS connection. On Google Code, we had encrypted downloads, but Google Code (meanie) no longer allows uploads (scum); SourceForge's mirror network only supports regular HTTP downloads, which are not encrypted (please upvote this ticket if you have an SF account).

Are we high risk? No. You probably have a higher risk of developing Ebola than getting a tainted TenFourFox. It's hard to patch a compressed binary in flight, so it would almost certainly be a complete substitution, it would have to be done on a machine that can build such binaries and it would need to do something interesting on a Power Mac, and given all those preconditions frankly I'm not aware of someone who hates me that much except possibly the cute shop girl at the AT&T store who won't give me her phone number.

Still, I'd like to guard against that possibility, or of any network-imported code over an insecure channel (network snippets, for example, can be loaded into the start page -- which has chrome privileges -- and this should make you suddenly feel very icky and vulnerable). This ties in nicely with a recurring thought I've had of redoing the new tab and start pages so that we're not getting snippets from Mozilla anymore about browser things that don't really apply to us or aren't otherwise compatible. To that end, I think publishing a verifiable hash for all downloads and redoing the new tab (possibly just using a blank one?) and start page for 38ESR will achieve that. We also need to ensure the following:

  • It should not require any special software to verify the hash. You should be able to do it with the tools that come with 10.4.11.
  • The hash list needs to be secure, or that could be tampered with too.
  • The new tab and start pages should not do network loads.

Here's how we'll accomplish that:

  • The most secure hash algorithm that comes with Tiger's built-in OpenSSL appears to be RIPEMD-160; it doesn't support SHA-2, or I'd use that. RIPEMD-160 is a less common hash function but to date cryptanalysis has not demonstrated collisions so far with known attack methods (here's some light bathroom reading on that topic). You can verify that the .zip file downloaded properly by simply going into Terminal and typing (this is the actual hash):

    % openssl dgst -ripemd160
    RIPEMD160( e6637dff473f68d2b4a4b6b920c70183d8658dea

  • While we can't upload to Google Code any more, we can certainly post things. The Google Code project page is secured by SSL -- -- and the hashes will either be listed there or on one of the wiki pages. You can grab the hashes securely before you update, download the file from SourceForge, and check that the hash matches. If it does, you have excellent assurance it has not been tampered with in transit. Hashes will be posted for the changesets too.

  • We'll be taking the network and dynamic code out, which as a side benefit will reduce their overhead, and possibly some other minimizing changes. I'll probably still allow the old pages by an about:config switch, though I haven't really plotted how the infrastructure will look either. Just expect this for the next ESR.

Assuming no one finds any glaring holes in this idea, I'll probably implement the hashes for 31.2.0 and the 34 changesets this weekend in my copious spare time. It's just a little bit of extra insurance for our users who may be in more difficult circumstances.

Thursday, October 23, 2014

34 up

I'm typing this in 34 beta, finally, after a large merge where Mozilla destroyed almost all of the old Nitro macroassembler framework that was used for JaegerMonkey and YARR way back when. I restored the pieces we still use, hacked them to be independent and modified PPCBC to point to those. That works as well as 33 did, at least, and it still passes tests. The remainder of the build was relatively uninteresting except for some moved files and a crash introduced with printing that I backed out (it's a Windows-specific change in cross-platform code we don't actually need for our old printing API), though I haven't tried to make an opt build.

Mozilla has two big, though probably survivable, changes for 35 and 36. For 35, Mozilla is updating libvpx, a change that historically tended to upset our custom AltiVec VP8 decoding and will undoubtedly need tweaking to reassemble the fragments. For 36, though, Mozilla is merging DOM and content together, a major seismic shift to unify two core portions of Gecko that have been separate components in the source code even going back to the antediluvian Netscape days. Ironically, this second larger change is the least likely to be problematic for us because it's almost all cross-platform code which we don't have many patches in, but it may invalidate some sections of code indirectly.

Either way, I think I'd like to start the process early on these in order to have extra time for the expected additional merge work, so 34 is going to be changesets-only too; I'll do a little more fiddling with it and then upload them this weekend. I may release 35 as an aurora since that will necessarily require opt builds to be done, though I want to start on the port of MIPS-IonMonkey as soon as I'm done with 35 or 36.

Tuesday, October 21, 2014

Well, it was a good idea at the time

The MP3 idea is shelved for the moment mostly due to bugs in how 31ESR manages media streams (these bugs are also in the regular Firefox, so they're a Mozilla problem). While the MP3 decoder is mostly written and working except for arbitrary seeking which is still problematic and has been disabled for the moment, there are various glitches in streaming music services that make it not ready for 31 (especially on Amazon Music, which is what it was originally written for). These nuisances don't make it unplayable, but they do make it annoying, such as streams failing to time out and requiring full buffering, audio glitches with seeking when tracks switch, and some tracks that fail to play at all. Regular ESR 31.2.0 shows all these problems too, so it's not us, but I can't find a specific fix for these and the proper reworking was probably spread along multiple fixes around Fx33 or Fx34.

Because it mostly works but fails in subtle ways, I will leave it in 31.3 but disabled. To avoid a situation with plugins (this is why we can't have nice things) where people post instructions but don't link back to posts explaining limitations in support, you'll have to find the setting yourself. Seeking doesn't work (except for replaying from the beginning) and there are other bugs which I won't fix in the 31 timeframe, so don't even bother reporting them. No further work will be done on it until we get to 38, assuming we do. If you give these instructions out and you don't remind people of this, I will cut out your intestines with a rusty spoon.

The 34 port hopefully will be done by this weekend and then I need to figure out what to do with it.

Tuesday, October 14, 2014

Poodles are fine dogs. SSLv3 is not a fine protocol.

For the hat trick, the security researchers who brought you BEAST and CRIME now introduce POODLE, the "Padding Oracle On Downgraded Legacy Encryption" attack. The attack allows an SSLv3 connection to be gradually broken down using a dramatically faster method that coughs up a byte of the session cookie on average one out of 256 tries. Ironically, because the demonstrated attack vector is JavaScript, our JIT makes us more vulnerable to this because we run JavaScript faster.

There is no fixing SSLv3 against this -- it's a fundamental flaw in the protocol that can't be worked around, and while previous weaknesses were mitigated somewhat with cipher changes there's no easy way out this time. Most browser vendors, including Mozilla, are taking this as the last straw and ending support for SSLv3, especially since TLS v1 and its successors have been around so long. Even Classilla supports TLS v1.

What will happen is that starting in Firefox 34, all connections must use TLS v1 or higher, giving servers a six-week cycle to do any necessary upgrades. We will follow suit: if Mozilla does not do this first, we will also set TenFourFox on the corresponding ESR release (31.3) to do the same. If you want to do this early, go into about:config and set security.tls.version.min to 1; if this causes problems with HTTPS sites you visit, switch back and tell them to get with it. Classilla users are advised to disable SSLv2 and SSLv3 in the Preferences window, under Security (leave TLS checked). The next version of Classilla, if and when I get those SSL changes done, will have them defaulted off as well.

34 is about 80% done (slogging through JavaScript), and the MP3-enhanced 31 is now playing substantially more audio files without problems. There is still a critical issue with parsing MP3 metadata and it's still quite crashy, but it's developing pleasingly quickly.

Monday, October 13, 2014

31.2.0 available, and music to your ears

31.2.0 is now official.

Also, now I can make that announcement: tonight, TenFourFox played its first MP3 audio file properly with its own internal decoder in-browser (using a modified version of minimp3, a heavily distilled-down version of ffmpeg's MP3 decoder component). Although Firefox can play MP3s using OS X AudioToolbox, the AudioToolbox in 10.4 does not support MP3, so we had to roll our own implementation. Although the codec is still under patent, it's old and we're non-profit and the code has been part of Linux distros for a long time, so we might be able to sneak by without anyone caring. (I hope I won't regret this.)

This code is not ready for primetime: it can't seek within a stream yet, it asserts all over the place with some MP3 files -- I suspect another lurking endian problem in Mozilla's built-in MP3 frame parser since I've already had to fix one of them to even get this far -- and it crashes if you try to queue up two files, though this is a memory allocator issue with its decoder tables and I have an idea how to fix it. It's also kind of slow, though this is partially because I'm on a debug build, partially because the code is not very optimized, and partially because Mozilla disables bigger buffering with audio-only streams, all of which are solveable.

However, the payoff is now music streaming sites like Amazon Cloud Player will "just work." (Amazon Music complains it needs Flash, but it really doesn't. Disable Flash on an Intel Mac running Firefox and you'll see.) And actually that's what I wrote it for, because now OmniWeb crashes trying to run Amazon Music, which is what I used to use on the G5 in the background. I write code to scratch my itches and the priorities for TenFourFox are decided accordingly. If there is a particular feature you want, I strongly urge you to sit down and write it and submit it. Ahem.

Please note that this doesn't really improve MP4 support; the codec glue is quite different and will have to be hacked in separately. I don't have a timeframe for MPEG-4 support and it is not currently a priority for me because the QTE meets my use cases currently. You, of course, can contribute. Ahem, I say.

The target is 31.4.0, though it will ship disabled in that version, so you'll have to turn it on. If it works well, we'll loosen it for 31.5. However, I still need to get 34 working first, and I still want to complete our IonMonkey implementation. I'm determined to get to 38 before concluding parity.

Friday, October 10, 2014

31.2.0 available

31.2.0 is now available (downloads, release notes). It has no changes other than security updates and stability fixes. However, I made a breakthrough on a long requested feature and it may be possible to introduce this into 31.3 or 31.4 -- we'll see, more later. As usual, it will become live Monday night.

Meanwhile, the patches are down for 34 and I'm about 60% through getting a debug build up, but this weekend I'm taking some time off to enter a pinball tournament. Don't wait up.

Thursday, October 9, 2014

And the bash is probably done: 4.3.30

I'm not quite sure if the glitches fixed are exploitable with all the other armour, but 4.3.30 is now available, and should conclude the Shellshock chapter at least this time around. The previous post has been updated, since everyone's still linking to it.