Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

kfz-versicherung writes "During the CanSecWest international conference in Vancouver, members of ANSSI described how an attacker could be able to exploit a flaw to run arbitrary code inside some network controllers (full presentation; PDF). The attack uses routable packets delivered to the victim's NIC. Consequently, multiple attacks can be conducted including man-in-the-middle attacks on network connections, access to cryptographic keys on the host platform, or malware injection on the victim's computer host platform."

"However, the attack presented only applies to a specific network card model (Broadcom NetXtreme) whenever a remote administration functionality (called ASF for Alert Standard Format 2.0) is turned on (it is off by default) and configured. According to vendors, this functionality is far from being widely used. As a consequence, this vulnerability is really likely to have a very limited impact in practice."

Okay but will the UDP packets which cause the problem be well formed enough to be routed into your network from outside? In most cases if you have access to the local network all systems are vulnerable anyway.

In most cases if you have access to the local network all systems are vulnerable anyway.

True: "if you have physical access then all systems are vulnerable" -- definitely. Just remove the hard drive, plug-in a keyboard sniffer, etc.Maybe true: "if you can login to the box then all systems are vulnerable" -- yeah, most OSs probably have some local root exploit.Stretch: "if you have access to the local network all systems are vulnerable" -- most desktop boxes don't even have any server ports open. Hacking them from the LAN is unlikely.

Okay but will the UDP packets which cause the problem be well formed enough to be routed into your network from outside?

Yes, they will.The packets in question cause problems because they cause a buffer overflow in a parameter sent in the data.

The NIC accepts normal UDP packets for port 664 and then analyses the packets to see whether they use a certain protocol. If that's correct, the NIC responds to the packet itself and the OS never sees it.

Yes. A proof of concept attack has been demoed during the CanSecWest conference. It showed how an attacker can remotely shutdown or wake up his victim’s machine, and fully compromise a COTS operating system machine (Linux for the demo, but all operating systems are vulnerable).

A lot of IPMI and ASF code is an open door into at least some portion of the overall system. As NICs become more and more "intelligent," there's going to be more opportunities to exploit the NIC architecture and any subtle flaws because of the communication path into the system itself. Couple that with a rush to get stuff out the door faster and cheaper...and more of these issues will crop up.

Intelligent LAN cards are nothing new. Back when 80386 processors were being used in servers, several manufacturers produced NICs with their own processor. The LAN protocol stack would be run partially on the NIC itself to reduce the load on main server. We had a Xenix server at work that used such a NIC.

As a matter-of-fact I've still got a similar designed serial card in my cupboard of spares. This used an 80186 to control 6 serial lines, leaving the main processor free to get on with other things.

It seems that the presentation focuses heavily on the NetXtreme framework, which is specific to Broadcom. Doesn't Intel, the other major NIC vendor/manufacturer, use their own proprietary security and administrative protocols on their devices?

I wonder how secure Realtek's stuff is; their drivers/software leave me to think that their hardware code is ripe for discovery...

Realtek's stuff is pretty much little more than reference implementation. They represent the "value end" of the marketplace, which works fine for cheaper Linux-based computers since drivers are ubiquitous for low-end (ahem: value priced) hardware.

Intel uses IPMI, which tends to not have quite as many management hooks into higher level functions as ASF. There are still plenty of things that can go horribly, horribly wrong with a bad IPMI implementation...but they're more likely to be exploitable because of something on the system side than something on the NIC side.

Love that comment! Too bad it was done anonymously, you deserve credit for the genius of its simplicity and clarity. "device vulnerabilities" have been around a long time. I used to make people on IRC lose their connections by sending specially crafted PING packets which would contain "+++ATH0" resulting in an immediate disconnection. I had one poor schmuck who patched and recompiled his Linux kernel like 6 or 7 times as he thought I was hacking his "computer" rather than exploiting his modem. His logs showed an ICMP coming from me followed by an interruption of his network link. He could have done one of two things: disable ping responses or changed a setting in his modem. It was hilariously funny watching the guy struggle though. Finally, I told him what I was doing..."Denwaugh"? Are you out there? Muhahaha! That comment brings back some memories...

The real point here is that devices are more than bits of hardware -- they are little computers themselves with their own vulnerabilities. Our trust of devices is a problem that is rarely considered.

He could have done one of two things: disable ping responses or changed a setting in his modem.

Disabling ping is merely a poor workaround. You can exploit it in at least one other way, CTCP also has a ping response. If the victim is running an SMTP server that you can connect to you can get the SMTP server to repeat +++ATH0 via several different tricks. I'm sure there's other services that behave in a similar manner. The only REAL fix is to disable the sequence in the modem.

Or to buy a modem from a manufacturer that implemented it properly. The escape sequence is not just "+++" - there has to be an interval before and after those characters in which no other bytes are sent to the modem. This can only happen if you're typing directly from a terminal, since there are always extra headers present if you're sending TCP/IP traffic.

If your modem was vulnerable to this then the manufacturer was either incompetent or intentionally screwing it up to avoid paying patent royalties.

Unfortunately, that method was patented (did th patent run out yet?) and famously, modems based on the Rockwell chipset was vulnerable to this problem. I think USRobotics had the patent, I dun't know any more. But I know it was because of a patent on the pause following +++

That method was patented by Hayes. Some modem manufacturers licensed the patent, while others did not. My Rockwell-chipset Supra modems handled +++ properly back in the day, but most of the no-name modems made after the September that never ended [catb.org] lacked this detail.

If I recall, there was also a way to do this using IRC directly, by issuing a command which would cause the remote client to respond (in part) with +++ATH0.

My personal favorite was just pinging folks to death. Their connection would simply deg

Even low end state taskforces can buy in p2p tracking software to find your 'unique' MAC.

Given that the MAC address isn't transmitted outside whatever subnet the device is on, how can "tracking software" (P2P or otherwise) determine your MAC address unless it is either on the same subnet or uses software that's somehow been installed on the target PC?

As devices become more and more complex, device functions that were once embedded within a chip are now being implemented by embedded computer systems which are tiny processors, ROM and RAM. And these devices interface with our computers through Direct Memory Access in some form or another and they get access to our computer's memory. If you think it is getting harder to find a virus in a running Windows installation, try finding one in your network cards or other devices.

While the "article" (it's a frikken PDF) says that this has been tested by invading a network card through a normally disabled management interface, what about other means of infection?

What I am saying is this: Once malware gets into the computer, all other devices are increasingly at risk of being a target for being compromised to enable secondary infections even after the hard drive is wiped out... even after the hard drive is replaced. Get some malware stuck inside your system board's controllers and you are either trying to figure out how to reflash every chip on that board, or you're buying a new board.

While everything you say is true, there is some measure of security in the fact that at the device level, you are working with the equivalent of multiple operating systems.

A virus writer infecting both your primary OS and a device on your system must have intimate knowledge of both the primary OS and the device's firmware. The first is not hard, 95% of people use the same brand with only a handful of widely used platforms. The second though, varies wildly, and it would be extremely unlikely that a virus fo

1. common malware happens2. common malware gets system level access3. common malware does an inventory of your system's hardware4. common malware downloads prepared exploits for any common devices in its library hosted on any of the command/control servers or any servers C&C tells it5. common malware then injects prepared exploit packages into device controller firmware

You are thinking about individual focused attacks where a person is driving each step of the game. T

If a particular brand of a common device were ever to absolutely dominate the market I could see it becoming a major concern.

My guess is that about 70% of all laptops and netbooks produced in the last two to three years run one out of maybe five or six different Intel NICs. On desktops targeting the four most widely used Realtek chips should give at least 30% coverage. On servers it boils down to a handful of widely used professional chips.

I do see it being an issue already. Not one of end-of-the-world-like seriousness, but for certain critical applications I would take it into consideration, CYA wise.

Do you have ANY idea how many crappy low end Dells and HPs come with that particular chipset? Think about it this way, what if the malware writers came out with one for Realtek sound chips? While those Broadcom chips aren't quite as hugely popular as the Realtek chips they are getting pretty damned close. I know in just about every laptop that crosses my desk I see Broadcom wireless, and nearly everyone based on the chips in TFA.

With the hardware, especially in the low end, offloading more and more from the

Since none of our clients use ASF, I have manually disabled it on every build I've done. Contrary to the article, many have it enabled by default. Why did I bother? I am a minimalist. I figured having an unused feature enabled could only potentially introduce problems.

Any computer using Broadcom NetXtreme chips with ASF activated and configured is vulnerable. Users of such computers should apply the official patches (see 6). Other vendor cards and other cards models are not impacted by this vulnerability. Machines using Broadcom NetXtreme chips when ASF has never been configured (Requires to launch the Broadcom ASF configuration tool) are not vulnerable but patching is highly recommended.

5. How can I protect my computers from such an attack?

If your computer is vulnerable to this attack you can either (in order of preference):

1. apply the vendor patch (see 6) ;

2. deactivate ASF. This should be done using the Broadcom ASF Configuration tool and not by turning off ASF in the BIOS of the machine;

3. configure all your network packet-filters to filter UDP ports used by ASF (623 and 664).

Please note that some operating systems actually deactivate ASF at boot time. Some operating systems or hypervisors might also take advantage of hardware technologies such as Intel Vt-d and AMD I/OMMUs that would limit the impact of the attack.

The important part about this is not that the attack is very specific (only Broadcom running ASF) but that attacks through a NIC are possible at all. This could be the beginning of more serious and widespread attacks as network components become exploitable through their increasing technology. There's a relationship between amount of code a device runs and the amount of bugs present in that code, and bugs can often be exploited for bad purposes.

Actually, this isn't that important. We've known about hardware vulnerabilities for decades. They're more difficult to exploit, typically, but they've been known about for at least 30 years, now. We used to just exploit the processor embedded microcode. Nothing new here, just moving to a different processor on a different PCB (unless it's built on the motherboard)

"However, the attack presented only applies to a specific network card model (Broadcom NetXtreme) whenever a remote administration functionality (called ASF for Alert Standard Format 2.0) is turned on (it is off by default) and configured. According to vendors, this functionality is far from being widely used. As a consequence, this vulnerability is really likely to have a very limited impact in practice."

One network card by one manufacturer has a vulnerability when an obscure feature is tu

There are Linux utilities for IPMI. [sourceforge.net] It's definitely worthwhile running "ipmiutil discover" on any LAN you control, to find out if anything out there speaks IPMI. It's also worthwhile monitoring your data center's networks for anything happening on UDP ports 663 and 664. If you're not using IPMI, make sure no one else is.

A big problem with IPMI is that the shipped hardware defaults really matter. If someone ships you a NIC card with IPMI enabled and the password known, you are 0wned at a very low level. IPMI boards offer various levels of authentication, some of which offer good cryptographic security. But one of the options is "no authentication".

A deeper problem is the possibility that NIC chips might have a default backdoor password built in. Many NIC chips now are designed in China.

Understand how much you can do via IPMI. You can turn the machine on and off remotely. You can force a reboot. You can change the boot settings. You can change the MAC address. You can override the front panel power and reset switches.(!) You can lock out the keyboard, blank the screen, set up a connection which the computer sees as a hard-wired keyboard, and boot from the LAN. The operating system isn't involved in any of this; it's taking place at a level below that of the main CPU.

If you try to do it right, turning on all the crypto and using unique random keys for each chassis, someone has to manually type in the encryption key in hex on each new server. Then you need a remote management program which securely holds all the keys. How many shops really do that?