Flaw Found iIn Ethernet Device Drivers 429
Licensed2Hack writes "Security researchers have discovered a serious vulnerability that may be present in many Ethernet device drivers that is causing the devices to broadcast sensitive information over networks.
Seems the device driver writers couldn't be bothered with a memset() call. Eweek has their typical (puffy, low on tech details) take on it here.
Since they don't specify the OS, I'm assuming these are drivers for Windows." It's actually Linux, *BSD, and Windows.
Not Exactly (Score:5, Insightful)
Dont assume (Score:1, Insightful)
Not a hard fix for open source (Score:3, Insightful)
Honestly, the big problem here is going to be MS. I doubt they'll introduce a fix at all.
SSH (Score:3, Insightful)
Of course, since you have to read ethernet packets, they'd either be listening to traffic on a VPN, or they'd be on their target's LAN.
More reasons to be afraid of your company's BOFH.
Why is this "devastating"? (Score:3, Insightful)
Re:Or maybe (Score:2, Insightful)
"The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."
Re:You assume too much (Score:5, Insightful)
Good gods, RTFA (Score:2, Insightful)
The article submitters now can't be bothered to read the articles? You know, the bit in the article where it says "The Linux, NetBSD and Microsoft Windows operating systems are known to have vulnerable link layer implementations, and it is extremely likely that other operating systems are also affected."!?
Back to more important issues, like the actual content of the article ... I'm reading linux/net right now, anyone have any definite answers, and could point me to (say) source for where we do do this?
Re:Wow.. (Score:2, Insightful)
A lame bug, but at least not a very exploitably-useful one.
Oh god, lets hype it all up (Score:5, Insightful)
Mod me however you want, I'm a coward to
Re:Wow.. (Score:2, Insightful)
So, even if we are on the ethernet switched network the window-of-oportunity to actualy sniff some data is 46 - 28 = 18 bytes (46 for the minimum ethernet packet and 28 for the minimum ICMP echo reply data within it). So we can intercept 18 bytes of random data from ethernet stack. What are the chances that there is some interesting data (passwords, keys
Furthermore the traffic can be encrypted in case of VLANs, Tuneling or ssh-ed connections.
Anyway, why should we inspect mere 18 bytes of provoked packet (yes, we have to provoke the ICMP echo reply packet so it can be transfered to our NIC directly) data when we are directly on the ethernet segment? In this case it is enough to bump the NIC to promiscous mode and to read all the data we can get from the segment
Well IMHO there is a lot more interesting data in (TCP|UDP)/IP packets then in some 18 byte buffer crap at the end of ICPM echo reply ethernet packet.
bb4now,
PMC
Looks pretty harmless (Score:5, Insightful)
I am sure someone will rush to correct me if I am wrong about this.
Re:I can read! (Score:5, Insightful)
On top of this, and everybody seems to be ignoring this basic fact, but after you get up to 18 bytes of information out of an ethernet packet, you *still* have to chain enough of these together to be a useful chunk of data. The problem drops significantly when you add more machines to the network, because it gets steadily harder and harder to put them together in order from the same machine. (Yeah, I know, you can use the mac or IP address to chain them together, but ethernet allows out-of-order packet delivery)
Re:Or maybe Slashdot wont post news unless its ant (Score:5, Insightful)
Re:SSH (Score:4, Insightful)
The chance of fishing a usable key out of 256 Meg of memory soup, given a random look at a handful of leaking bytes in each packet, is slim indeed. The attacker has no way to control which bytes leak and doesn't know where in memory they came from. This is nothing remotely as serious as a buffer overflow, where the attacker gets to choose which bytes overflow into executable memory, and thus can exercise a great deal of control. Still, by sitting and watching long enough, maybe, just maybe the attacker will be able to piece together something useful.
Now, this is where Linux, BSD et al really show show their strength: this driver leak either has already been patched (sorry, I'm too lazy to check the change logs just now) or will be by the end of the day, and the patched kernel will be immediately available for download. Or I can get the patch and apply it myself if I'm in a panic (which I'm not for the above reasons).
Microsoft on the other hand has to round up dozens of vendors and get them all to apply fixes, and there will be stragglers. Then there is the question of how to get the patches onto customer's machines. It's a safe bet that the majority of home users will never patch this vulnerability, so if attackers need plenty of time to exploit the leak on Windows, they've got it.
Of course, Microsoft's favored solution to the latter problem is to take the liberty of patching your system for you, having required you to agree to this when you installed. You must then trust Microsof not to go further and install additional, unasked-for code, for example, something to send back all your web search terms to Microsoft HQ. [theregister.co.uk] I don't know about you, but for me, but that's too high an asking price for automatic security updates.
Re:You assume too much (Score:2, Insightful)
So here M$ gets look innocent and say, "It's nothing to do with us", while actually being guilty as sin for having an OS that uses loads of vulnerable drivers.
How is MS guilty for crappy code in other people's drivers now? They're not responsible for writing drivers for every single piece of hardware someone wants to run under Microsoft Windows. That would be the responsibility of the hardware vendors. ... and like it or not (and there are bits of the Win32 API I really do dislike), not all code that comes from Microsoft is utter crap with no redeeming qualities.
Oh, I really wish I could find a link to the Penny Arcade about "M$" right now too. :) Although I just realized I'm responding to an AC ...
This is much ado about nothing.. (Score:5, Insightful)
Ever print the results to the screen??
If you have, you know that garbage comes out, and is pretty much undecipherable. The reason it is not readable is that the the program is interpreting each byte as a character, and the data is most likely not ASCII.
This is an analog to what is happening with these "bad" drivers. The driver is simply reading more memory than contains actual data, and sending it along with the good data, since the receiving station will strip off the padding (bad data) it shouldn't matter. What the author of the article is implying is that someone might spend the time to try to decipher the padding and find sensitive data from your system. Good luck to any person who wishes to decipher almost randomly sampled data from a memory map. They will have the same problem as the C program mentioned above: they will have no clue how to interpret the data, and will have to trial and error "known" data types. Even then, they only get 45 bytes of data to use as context. So even if they got ASCII characters, how are they to know if it is a password or part of a Gnumeric spreadsheet??
tips (Score:3, Insightful)
Wow. This is pretty hardcore, especially for networking devices. My biggest fear related to this has to do with the increasing use of VLANs to bound logical security zones. Let's say port 1 and 8 are on different VLANs - 1 is in the private network, 8 is in the DMZ. They use the same ASIC, so padding data is effectively shared between both. You've already owned a DMZ host, so you can use it to listen to ethernet padding data that might contain traffic once transacted on port 1. Listen long enough, and you might get some juicy passwords otherwise invisible to the DMZ.
No guarantees, but until we get updated drivers, put in a snort rule for undersized packets flying around in your public networks, and make sure your VLAN boundaries occur on port group boundaries (Most Nortel switches, for example, have different ASICs for ports grouped physically on the front of the switch.)
Re:You assume too much (Score:3, Insightful)
Microsoft became responsible for other people's code the moment they got into the business of signing other people's code.
If Microsoft wants me to believe that drivers which have been approved and signed by Microsoft are any more trustworthy than drivers which haven't been signed and approved by Microsoft, then Microsoft need to accept responsibility for ensuring that is the case.
You can't say "don't use that code, I haven't approved it. Use this one instead..." and then say "well it's not my fault if the code I demand you use is broken, I didn't write it!"
Re:memset on windows?? (Score:3, Insightful)
Secondly, for security reasons, Windows ensures that no app will ever find remnants of another app's data in its memory space (all allocated memory is erased before is't given to the requester), which significantly reduces the risk that sensitive data would be transmitted.
please keep feeling safe because *n*x is so damn secure by defi^H^H^H^H religion.
Here is a clue for you.
This is about drivers, leaking kernel memory, not drivers leaking application memory.
Drivers are not applications, since drivers run in kernel space. Since memory is generally allocated in Linux by mmapping files, applications can not get "garbage data" from the operating system.
memset is part of the ISO/IEC 9899 standard for the C programming language. If your Windows library doesn't have it, complain to your vendor. This has nothing to do with Unix vs. Windows.
Re:well (Score:3, Insightful)
And hence one of the greatnesses of open source. We don't have to wait for them to do it. Someone can go in and clear up the issue in all the Ethernet drivers just like that. No muss, no fuss. Fixed drivers.
Microsoft Certified Drivers (Score:3, Insightful)
Don't forget that after the vendors fixed it, the new drivers have to be re-certified and signed by Microsoft or their Great OSes[tm] will bark on everyone installing them - which wouldn't shine a bright light on the vendor.
Last thing I remember was that having a new driver certified by Microsoft takes several weeks to months.
An interesting question aside: If so many drivers (if you believe in the article's wording) are affected, why did they pass the Microsoft quality/security "certification" in the first place?
Seems to me that their certification tests aren't worth the bits they're written on - probably they just check that the drivers don't crash the system and so on. (well, and sometimes, not even this.)
Re:Read the f*cking article. (Score:3, Insightful)