Travers Buda wrote: > * Matthew R. Dempsky <[EMAIL PROTECTED]> [2007-01-29 15:16:15]: > >> On Mon, Jan 29, 2007 at 01:30:01PM -0600, Travers Buda wrote: >>> Well I think both are equally dangerous (binary firmware and >>> binary drivers.) They're basically the same thing.
Not at all, see below... >> My understanding has always been that a bad binary driver can >> corrupt main memory, but a bad binary firmware is limited to >> making the device useless. Is this not the case? >> >> > > Well there is that proof-of-concept that debuted at BlackHat where > those researchers compromised the OS of a macintosh. I was under > the impression that they compromised it via the firmware, but it is > equally possible it was achieved via the driver. Details seem to be > sketchy... hrm. At the very least you could do some nefarious > things to the firmware to say, retransmit hardware wep'ed traffic > without wep. > No, that problem was due to the fact that since the Mac is now Intel based, they can use the Windows drivers with a "shim" to attach it to the local OS (such as OS-X, Linux, FreeBSD, etc.). An attack that compromises the drivers has an "in" to the OS itself. Bad. Since Apple accepts binary Windows drivers for OS-X, that should pretty much silence the MacIdiots who run around saying that Mac users don't have to worry about viruses ('course, if reminding them where small system viruses really became epidemic first doesn't shut 'em up, another dose of reality isn't likely to change it, either). Binary drivers means ONLY the vendor can fix the problem. They also mean that the device will ONLY work on certain platforms...and only on the OSs that the manufacturer supports. Binary driver and firmware are not at all comparable. Look at your (amd64/i386) computer for a moment. There's a boot ROM that handles the power-on of the machine. There's possibly a VGA BIOS that handles the video card. There's possibly a boot ROM that handles a RAID card adapter. Maybe a network boot ROM. LOTS of ROM there. Let's look at the RAID card a bit closer. In addition to the boot ROM, there's probably one or more processor-like things on it, those would ALSO have firmware controlling them. That ROM is probably not directly accessible from the OS or the applications at all. No one is up in arms over the fact that we don't have source code for those ROMs. They are there to do a job, they do that job, and we thank them for it. Now...what if instead of a ROM on that RAID card handling the embedded processor, you have a chunk of RAM. In order for the card to become functional, the OS has to stuff some data into that RAM, and start the embedded processor (ok, I've just invented a non-bootable RAID card. Yay me!). That code that is stuffed into the RAM is machine independent, the card doesn't care if it is sitting in a Sun, a MacPPC, a AMD64, an HPPA or or or... It doesn't care if it is running on OpenBSD, Linux, Windows, MacOS9, HP-UX... It just makes the little embedded processor on the card do its job. This is not actually a new idea -- many, many years ago, there were companies selling internal modems with RAM rather than ROM for the onboard signal processor...the OS (MSDOS) would run a small program at boot which would populate the modem's RAM, and then the modem would become a functional device for any application to use. Of course, these modems were not of great use if you weren't running MSDOS or other supported OS, but in theory, you could have that same binary blob stuffed into the modem by ANY OS. Before that, Artisoft used to build non-Ethernet NICs which were basically just a Z80 CPU, an SIO chip, line drivers and a chunk of RAM. The MSDOS driver would stuff a Z80 program into the RAM shared with the main processor, reset the processor, and ta-da, a NIC is born. The binary firmwares we are talking about are the same basic beasts. If the manufacturer were a little less cheap, or willing to spend a little more time trying to make their product work right before shipping, they'd have put an old-fashioned ROM on the thing, and no one would care about the firmware. The firmware is NOT something running on your computer's CPU, but rather the little processor on the (in this case) wireless card (or modem or NIC or ...). Few people "demand" source code to their SCSI or RAID card's BIOS or processor ROM. On the other hand, no one makes you "click through" or sign license agreements to use your SCSI or RAID card. It's really the same stuff, just everyone is getting all hysterical about the fact that it is distributed on a CD or floppy rather than embedded in the device itself. The driver runs in the OS, the firmware runs on the device. If the OS changes, you need a new driver. If you run the device on a different platform, you need a different driver. If only a binary driver is available, you can use the device ONLY on the platforms and the OSs supported. If the company doesn't support the OS or platform you wish to run it on, you are out of luck. If the company goes out of business or loses interest in maintaining the product, the device becomes useless. ON THE OTHER HAND...binary firmwares are quite different. If the OS changes...doesn't matter, it doesn't run on the OS. If you wish to run the device on a different platform, doesn't matter, the firmware doesn't run on the main processor. If the company goes out of business, it really doesn't matter, as the card isn't going to change (as long as distribution rights exist!). Again...if they had just used a ROM instead of uploadable firmware, no one would care in the slightest... Would it be NICE to have full documentation of the card so you could write your own firmware? Sure. But if it were hard ROM instead of firmware, the issue would never be brought up, so expecting it with the uploaded firmware is rather unfair. We just need the ability to distribute the firmware so these products can work as easily as all the other devices OpenBSD supports. Could there be exploits in firmware? Sadly, it might be possible. But then, the same kind of exploits could exist in the ROM-based devices; after all, they (usually) have RAM as well to store data, so a buffer overflow could allow code to be put into the RAM and run. The firmware vs. ROM really doesn't change anything there. Nick.