Network card rootkit offers extra stealth Security researchers have demonstrated how it might be possible to place backdoor rootkit software on a network card. Guillaume Delugré, a reverse engineer at French security firm Sogeti ESEC, was able to develop proof-of-concept code after studying the firmware from Broadcom Ethernet NetExtreme PCI Ethernet cards. He used …
Sounds similar to the vulnerability in connecting firewire devices as they have DMA as well therefore have free reign over the address space. IIRC some deep diagnostics tools are firewire based for this reason.
Running your own code in a co-processor is rather more sophisticated of course though. Wonder when the same will happen on graphics cards?
Firewire can function pretty well without that requirement, it's just that the interface spec contains that particular stupidity. Fix that and it suddenly is no longer a problem. In the meantime it does make for a useful kernel debugging interface.
AFAIK the code isn't run on the network card, it just lives there. There's an interface that lets you hook in there for pheripheral cards like network cards, and that's how PXE boot starts. But it's also how SCSI and RAID cards and so on initialise and give you a way to run their setup programs. That hook has been there since the days of the original ibm pc. The contents of the EEPROM is also what makes a "mac" card or a "pc" card. The mac cards contain openboot code, the pc cards contain x86 code. Otherwise it's the same pci card.
There should be passwords on firmware upgrades... but this is not thought of enough.
I used to work for a company producing network devices. The firmware upgrade procedure was far too simple without any form of password protection. We often discussed how easy it would be to produce modified firmware and add a packet sniffer to the product which could then email out its logs.
This was especially worrying as we knew our products were inside many secure locations like Banks, Military and Government.
The part we produced was used by many "trusted" big name manufacturers.
The thing is, if you don't know what's in the firmware then anything might be in it. Even if it comes from the manufacturer AND the manufacturer signs it digitally AND in blood AND swears up and down it's guarding against evil with regular excorcisms and copious holy water. Even a "gold master" of the firmware might get infected. How would you know? You just open the box and install the card in your machine, not so?
We already have to trust the manufacturers, and passwords don't change anything there. If you'd rather not trust firmware --But then, why trust the hardware? Or the drivers?-- you can put in your own bootprom and even build it yourself from source. Of course you thoroughly reviewed that source first, haven't you?
If you're afraid of rogue updates, well, malware might infect your computer and brute-force the password behind your back. You wouldn't even notice. A physical jumper preventing rewriting flash memory is a much better proposition. But oh no, now you need to open the case to change the jumper for a firmware update. Which is why motherboards ship with that jumper in the "allow reflashing" position.
Point is, physical access almost always guarantees that you can "own" the box. That was true back when just as much as with this latest illustration. This is not necessarily a bad thing. But it is something that you have to realise. That is all.
I thought that the OS and the system hardware are supposed to fence the addresses range that DMA devices are allowed to access. This would not work for unsolicited input I admit, but allowing a DMA device unrestricted access to the whole address space seems to me to be a security hole waiting to happen.
I've noticed that some Ethernet devices actually have an ARM core embedded in the chip. That means that it would be pretty easy to write some complex code for this. If this has access to the system memory, this opens worrying possibilities.
You haven't really realised just how early in the boot process this happens, have you? Watch a peecee boot up and if there's a network or raid card in the system, watch for "press <some key> to run [raid|network] setup" messages. *That* is when this exploit does its thing.
It happens well before the OS is even loaded. The exploit is loaded in a completely normal way that has been with us since the very beginning of the platform. Also, DMA and address range fences haven't been set up at that point, the OS does that, and anyway that code might sit in a network card's EEPROM, it runs on your x86 cpu, not on the network card. So yes, that code simply has access to everything the OS would have. That is pretty much game over at that point.
This is NOT a root-kit that runs on the local x86 CPU. It is NOT being "loaded in a completely normal way".
The NIC contains a "MIPS-2 instruction set" "RISC core", used for running custom packet filters. It has its own EPROM, and this hack targets that processors. It's the kind of thing the Security Services will be soon be using to monitor us - nip in and flash the network card while we're out.
There is and has been for a while code available /en plain public/, including source, to put custom boot things in your network EEPROM. He could equally well have done it using a custom BIOS, there's also code available /en plain public/ for that. So the wording here is maybe a bit too much credit.
Actually doing it, and in network card firmware, just highlights again how we trust our hardware, firmware, and software. It's also a great show of "ph34r m`/ m4d 5k1llz" that people are so fond of in the security industry. Because it gets lots of free publicity.
What's happened here is that someone built an impressively large stack of things leveraging each other to "load" an exploit. Loading a bit of "crack" code right before an application isn't new by any means. The point is, of course, apart from the show, that if you have the physical box you can subvert it seven ways from sunday.
But this isn't as big and certainly not as new as you might think. Compare and contrast the paper _Reflections on trusting trust_* where a system's compiler had a bit of code added to add a backdoor to a system's login program, and code to add this subversion back in if it was removed from the compiler. Compile, remove the evidence from the compiler source, recompile, and done. Don't forget to look up the date on that paper.
Yes, it's very real. Yes, it has been done, and not just once. Yes, we're all in grave danger. And what do we do about it? Well, what *have* we been doing about it the last score-or-so years? And why? Answer me that and then tell me if you'd rather run this risk or live in a straitjacket where everything is locked up, down, and seven ways from sunday sideways.
I for me rather live in a world where specifications, hardware, firmware, and software are open. It leaves more options to choose how and who to trust.
* http://cm.bell-labs.com/who/ken/trust.html
Sounds like the interesting part is that if there's any kind of exploit or buffer overflow in the code, you might be able to use that to flash the firmware remotely, at least enough to add a rootkit. However, it becomes very NIC-specific, with a half-dozen different routines all targeting different versions of different cards.
And yes, event digital certs verified with TPM won't matter if hardware has the ability to fake out every piece of the puzzle.
This post has been deleted by its author
Variable speed controlled computer fans?
If you can do it to these devices.........
http://arstechnica.com/tech-policy/news/2010/11/clues-suggest-stuxnet-virus-was-built-for-subtle-nuclear-sabotage.ars
Don't be alarmist but be aware of how powerful automatic switches (computers) are & therefore computer coding is.
If humans can design these devices they can also destroy or sabotage them. :(
Network cards have the ability to hold ROMs, Flash, all sorts depending on make and model. I can imagine any of those could be abused. Hell, on another (non-x86) system, I've used the spare capacity of the NIC flash to hold some drivers specific to my homebrew hardware, and these get pulled in at system boot before the harddisc has even initialised itself.
All this excitement for something which was presented back in March 2010 at CanSecWest: the author cites the previous work from 2008 but misses the 2010 additions, not surprising really...
http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-CANSEC10-Project-Maux-III.pdf
Obviously the Sogeti PR machine is much better than an independent consultant.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
