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.
