On Friday we read about the Firefox security issue, CAN-2005-2871. This issue looked like it could well be a 'critical' issue potentially allowing a malicious web page to control a heap buffer overflow. We know that various technologies in Red Hat Enterprise Linux and Fedora Core are likely to reduce the chances of this being actually exploitable by an attacker -- checks foil the most usual way of exploiting heap overflows by messing with malloc control structures, and on x86 at least heap randomization makes an exploit harder. But this issue was already public and so we didn't have the luxury of time to be able to test the mitigation. So we initiated our emergency response process to get the packages through development and QA and got Firefox and Mozilla packages out via Red Hat Network within 20 hours of this issue being public (due to the awesome work from engineering folks, QA folks, and the security response team who worked late into Friday night to get this done).
Most laptops have the ability to set a hard drive password that gets asked for on boot -- take the hard drive out of the laptop and put it into another machine and you'll find you still need the password, the drive is locked by its firmware. This feature doesn't provide amazingly high security, it's known that some data recovery firms can bypass the password on some drives, some of the time, but it's probably good enough to thwart a thief who is after your machine and not your data. Anyway, most 3.5" drives found in desktop machines also have this feature, but it's mostly unsupported by motherboards (at least the sample of machines I could find). However Arne Fitzenreiter has come up with a novel solution, writing code for a BIOS that can unlock or lock desktop drives at boot. Incredibly useful also if your laptop has died, you had a password set, and you want to use the laptop drive in a desktop for a bit... guess who this applied to ;-)
In theory you should be able to program an EPROM or EEPROM, and just pop it into any old network card you have laying around that has a boot PROM socket. There is even a utility for the 3c905b/c that lets you program a EEPROM from Linux, and you can pick up a 3c905b card on ebay for under $5 including postage, so cheaper than a dedicated programmer. However the 3c905b isn't a great card to try to use the EEPROM in after it's programmed: a flaw in that card stops all the ROM contents being mapped properly.
Armed with a 3c905b for programming, an Atmel AT29C010A from Farnell Electronics, and a old 3c900 I'm glad I didn't throw away for the destination, a spare Windows PC, a couple of spare hours got it all working. Here are the final steps to make it all work for me:
- Boot Linux with the 3c900 card to find it's vendor and product id (for my card it was 0x10b7, 0x9004)
- Use the ATASX program in DOS to create an image for that product id
- The ROM image produces won't work as it is on a 3c900, you need to fill it out to 65536 bytes just appending 0xff characters (a line of perl will sort this out)
- Using the AT29C010A in the 3c905b card, use the bromutil utility (in contrib directory of etherboot) to erase the eeprom and burn the image
- With the ROM and 3c900 boot to MSDOS and use the 3c90xcfg.exe program to make sure that the ROM is enabled
- Reboot. Watch nothing happen (you got the vendor/product id wrong or the ROM isn't enabled) or a checksum error (the ROM image was bad, try again or use the disrom.pl script to look at the image file) or you see the ATASX program come to life.