Flaw Found iIn Ethernet Device Drivers

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.

Comments

Not Exactly

[starX]

The Cert advisory says that MS doesn't ship any drivers with this vulnerability. This is a lot different from saying that MS systems are completely uneffected. We're going to have all double check against the actual driver being used by the system (when this list is complete of course) to find out if we are particularly affected by this.

Not a hard fix for open source

[Arethan]

If this bugs you, just make a change to the link layer drivers. Pad with nuls again, like it is supposed to, rather than garbage data. The downside to this is there will be a speed hit, since you are wasting time fscking with small packets to make sure they are secured. But, given the speed of modern systems vs the speed of ethernet, I highly doubt you'll notice.

Honestly, the big problem here is going to be MS. I doubt they'll introduce a fix at all.

SSH

[mmol_6453]

It could be enough for someone to snag the SSH private keys for a connection.

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.

Re:SSH

[Daniel Phillips]

It could be enough for someone to snag the SSH private keys for a connection.

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. I don't know about you, but for me, but that's too high an asking price for automatic security updates.

Why is this "devastating"?

[Dwonis]

Why is this "devastating"? People can sniff ethernet networks anyway? People don't rely solely on a switch for your network security, right?? (Who am I kidding? Of course someone does. Sigh.)

Re:Or maybe

[ottawanker]

It's pretty bad when people who reply don't read the article, but shouldn't the poster himself at least read it? Excerpt from the article:

"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

[the_mice]

Granted Windows is listed as "Not Vulnerable", but here's the MS statement regarding this issue (from the CERT advisory's vendor listing):

Microsoft does not ship any drivers that contain the vulnerability. However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue. We have made corrections to the samples in our documentation, and will include tests for this issue in our certification process.

So the OS itself isn't vulnerable as it's own networking code doesn't handle Ethernet padding, but the OS vendor has in the past provided Windows NIC vendors (and hence driver developers) with documentation leading directly to this vulnerability... Sounds secure to me...

Good gods, RTFA

[Kourino]

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?

Oh god, lets hype it all up

[Anonymous Coward]

Great. I don't mean to sound like a troll, but @stake is really stretching for publicity here. 46 bytes? Do you realize how small the padding is? Yes, it's enough for a password, but keep in mind, that padding being sent out is transmitted from OLD FRAMES. These items have been transmitted before. Guess what kids? If you observe secure computing practices, such as using a encrypted login method (ssh comes to mind) and you mind your standard p's and q's, this problem should never be a PROBLEM. I am sorry, but as a professional that researches this stuff, I have to rate this vulnerability as a "really really low" and keep plugging on. In a perfect world, we would grab from urandom/random/null but this isn't a perfect world. Lets focus on remote root compromises, remote "system/admin" compromises, and lets also focus on getting IIS away from the industry. These are the REAL problems. Someone wake me up when @stake has a real advisory to give, something excellent that we are used to seeing from them, besides this trivial fluff they are going to over-hype.

Mod me however you want, I'm a coward to /. but this will be the same position I give the Fortune 500 company I work for. /me wonders if my VP will mod me "troll" or "flamebait" =P

Looks pretty harmless

[heikkile]

It is a flaw alright, but I fail to see it as very serious. It is not a remote exploit, nor a local one. It leaks basically random bytes from the memory, without telling where in the memory they come from, and without any way for the attacker to specify where in the memory he wants to read. So, yes, there could be a password in it, but there could as well be a snippet of executable code or binary data, or whatever. It would take a lot of sniffing of these, and a lot of filtering, before anything useful would come out of it.

I am sure someone will rush to correct me if I am wrong about this.

Re:I can read!

[fucksl4shd0t]

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

[Michalson]

While not 100% true I do see truth in that. For anything to get on the front page these days it seems to require at least one of the following:

• Microsoft is bad, we don't know why, but it is
• Another article just like it is already on the frontpage
• The Poster has provided enough FUD about the article to fill a landfill
• Someone got arrested in the vicinity of a tech company. IT MUST BE A THREAT TO OUR RIGHTS!
• Crazy, unsupported rumor. Likely about Apple.

Re:You assume too much

[Kourino]

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 ...

Re:You assume too much

[lynx_user_abroad]

How is MS guilty for crappy code in other people's drivers now?

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??

[hanwen]

Whenever I read "memset", I think aloud "unix".

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

[labratuk]

...I can't imagine every manufacturer of every card is going to fix this....

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

[Antity]

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.

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.

[Drakonian]

Good point. Personally, I think there is something fundamentally broken with the whole system. To have your story submitted, you have to submit it fast (Even though this news is actually 3 days old). To have your post modded up to +5 area it has to be very fast - i.e. too fast to actually read the article. Does this seem broken to anyone else?