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.

Tuesday, October 7, 2014

And now for something completely different: bad blocks, bad trip

You've already met thule, my recently resurrected Macintosh IIci running NetBSD. The peril of running something old is that things fail. After I got a new recapped motherboard in it, now the hard disk started throwing a couple bad sectors.

Bad sectors happen; magnetic media occasionally gets glitchy. (I do have a backup, but I like running things until they die, so I'm going to keep this drive running until it don't run no more.) Modern drives can often recruit from a pool of sectors and transparently redirect a write to a bad sector to a good sector, but no hard drive can do this on read if the media is bad, and on a drive this geriatric (a 2GB Quantum Fireball from oh-my-gawd-it's-old) even the former is not a given. We want some way to tell the operating system to never use those sectors again.

Some vintage operating systems do this more or less overtly. For example, my Alpha Micro Eagle 300 has an actual bad block file that tells the operating system hands off these sectors (one wonders what would happen if a bad block occurred in the sectors that actually contain the bad block file). Classic Mac OS doesn't really support this, though tools like Norton Disk Doctor can quietly allocate them out of reach. However, Norton Disk Doctor doesn't understand a NetBSD FFS volume. NetBSD does have a tool called badsect(8) that can take a list of sectors and create bogus file descriptors that fsck_ffs will turn into invalid files soaking up those sectors; similar tools exist on other BSDs and even some Linux distributions. This is a little scary and there's not much documentation on this because there aren't many freaks like me running NetBSD on something this old. So here goes.

The console will tell you the bad sector (either on screen or through dmesg). Here's the actual output thule was spitting out:

Check Condition on CDB: 0x28 00 00 32 3d 61 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292513
     ASC/ASCQ:  Unrecovered Read Error

Check Condition on CDB: 0x28 00 00 32 3d 62 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292514
     ASC/ASCQ:  Unrecovered Read Error

Check Condition on CDB: 0x28 00 00 32 3d 63 00 00 01 00
    SENSE KEY:  Media Error
   INFO FIELD:  3292515
     ASC/ASCQ:  Unrecovered Read Error

What this means is that relative sectors 3292513-5 inclusive are kaput. I noticed this because the periodic full system backup had started failing on certain files, so I knew which files were bad, and I could restore them from the previous backup. But before I could do that, I wanted to make sure the OS didn't try to reuse the bogus sectors.

First, I rebooted it in single user mode. This is very important; you are tinkering with a live filesystem and run not only the risk of kernel panic but serious data loss if other things are writing to the disk while you are. (Yes, I've panicked systems at least once by cheating on this. Learn from my mistakes.) Next, I ran fsck on the disk and allowed it to remove the wrecked files, generating more media errors in the process. It did so, and instructed me to reboot. But we don't want to do that yet; we still have those sectors to account for.

Now we use badsect. We create a directory /BAD and tell badsect to create the placeholder files for those crashed sectors:

badsect /BAD 3292513 3292514 3292515

BE VERY CAREFUL. There is no going back. If you type the sector wrong, you may only waste a perfectly good unallocated sector, or you may destroy a file mid-stream. Check your typing twice, and then check it again. If you did this right, the sectors will be marked and badsect will tell you do run fsck again. Do so.

This time, fsck will notice the bogus files and ask HOLD BAD BLOCK? The answer is yes. It should ask you each time for each sector. If you correctly reserved all the bad sectors, there should be no more media errors on the console. If the bad sectors were part of the file system, you may have some DUPs to resolve, which you should answer yes as well if it asks.

Now the part that threw me initially: when fsck proceeds to the second phase and checks pathnames, it will (correctly) notice that the files in /BAD point to bad blocks ... and offer to delete them! Do not let it!

DUP/BAD I=277769 OWNER=root MODE=100600
SIZE=1024 MTIME=Oct 7 19:58 2014


The answer this time, and for anything in /BAD, is NO -- or you'll remove the linkage to the bad sector, and you'll have to create it all over again. This will be true when you fsck this volume again, and you will, because bad sectors will eventually occur somewhere else.

By the end, after you've allowed fsck to complete all the remaining salvage, you shouldn't see any more media errors on the console. Now reboot and restore the files that were lost, if they were important, and tell your backup script to exclude anything in /BAD.

I'm toying with resurrecting thule a second time, but this time running A/UX. That might be fun.

Thursday, October 2, 2014

Blog roll

Nothing new to report on TenFourFox right now -- still working on the patches for 34 -- but two blog posts from the retro-Mac community I wanted to highlight:

Riccardo Mori's rebuttal on doing practical work on classic Macs. If you're reading this blog, you're probably already sympathetic to his view, and since Riccardo is very complimentary to TenFourFox and Classilla my linking to his post is totally, unapologetically and shamelessly self-serving, but I think he hits the main points very well (original article for comparison).

Martin Kukač prepares his G5 for another decade, which is his retrofit of an older G5 useful to those of you trying to maintain your air-cooled DP systems. Fortunately, my quad is already ready to go another nine innings.

Wednesday, October 1, 2014

And the bash goes on again: 4.3.28

bash 4.3.28 is now available, fixing CVE-2014-7186 and CVE-2014-7187, and this should repair all the known outstanding problems. Since everyone is linking to the original post, I have updated it with the new self-tests and instructions.