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.
well (Score:5, Interesting)
One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?
I can read! (Score:5, Interesting)
Slow newsday for eweek then. (Score:3, Interesting)
The command 'ping -n 10 -l 1472 ' sends a packet that's padded with 'abcd...uvwabcd...uvwabcd'.
The echo reply is padded with the same characters, apparently just pulled from the request and stuck in the reply. So far I've tried pinging W2K, HPUX, a Cisco router, and a Debian box. All return the contents of the initial request as padding.
Is there more to replicating this than they let on? Or are they just full of poop?
Slashdotted your credibility-and everyone sees it (Score:5, Interesting)
Funny, I am careful about checking my facts, and I am assuming that only 5 people will read my post. I would hope I would put a LITTLE more effort into my fact checking tho if I thought it was going to get 1,000,000 hits.
Since the poster and the editors don't check their facts, I am assuming they don't.
Slashdot is the first site I hit for tech info. And typically, while exagerrated, the attacks on MS have basis at least.
But an ASSUMPTION like above about "Well, there's a problem, it must be Windows!" just makes my ears perk up immediately and want to check the facts. Why doesn't it for the Slashdot editors?
WHY would you assume that? Just from the blurb the poster included it immediately seems the kind of oversight that would have the POTENTIAL at least to affect multiple systems.
And yes, I realize that Windows drivers written by third-parties have been targetted, I find it amazingly amusing the native Windows drivers have been determined not to have this issue
Re:well (Score:1, Interesting)
Re:You assume too much (Score:3, Interesting)
You mean Microsoft said they aren't vulnerable. [cert.org] But look at these weasel words: "However, we have found samples in our documentation that, when compiled without alteration, could yield a driver that could contain this issue." Draw your own conclusions.
Re:common fault (Score:4, Interesting)
noticed this 6 years ago (Score:5, Interesting)
We informed CERT/IBM - nothing happened.
NOW it it makes all the headlines.
what impact does it have - none, unless the stuff in the PADing area contains the unencrypted data that was originally send encryped. Or am I missing something like I normally do?
memset on windows?? (Score:2, Interesting)
Whenever I read "memset", I think aloud "unix".
Windows programmers talk about ZeroMemory and FillMemory, not memset. In drivers, that would be RtlZeroMemory and RtlFillMemory.
memset exists for compatibility, but it's just a wrapper around FillMemory.
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.
Normally, if the app passes it less than 46 bytes of data, the driver would have to copy it to its own buffer space at the lowest execution level to avoid hitting addresses that aren't mapped to physical memory later (would cause a BSOD if it happened above dispatch level).
If that buffer is allocated dynamically it would be empty, if it's static it would contain some part of the previous packet - not so much risk of finding sensitive data there, since it's just repeating something that has already been on the network.
BTW, the CERT advisory contains a long list of checked systems. There are only six names where it says "Not Vulnerable", and one of those six is Microsoft, so heck yeah, please keep feeling safe because *n*x is so damn secure by defi^H^H^H^H religion.
Re:Wow.. (Score:4, Interesting)
Actually, the data could potentially be from a random buffer in memory, depending on the driver and network stack implementation. So, it could even contain portions of decrypted private keys, for example. But, that's highly unlikely, and it would be hard to find that information in the sea of other random info you'd get from these packets.
Yes, it's hard to exploit, but it's also a very serious bug.
Re:Problem I had with net coding (Score:2, Interesting)
This problem is similar in that it is memory releated, but it has nothing to do with server software, and everything to do with device drivers. Your problem was memory on the server side of things, specifically, the buffer you used needed to be cleared out before you used that buffer again, otherwise the old data would be still be in the buffer, until new data came along that was as long (or longer). Basically, you would need to sniff the packets in order to get the overflow of memory, otherwise it was just poor coding on your part. Here's an example:
main()
// . . . some init stuff here // assume we used this
// . . . socket stuff here // send "wookie"
{
char *buffer = "wookie";
send(wookie);
*buffer = "wokie";
}
--LordKaT
3Com/USR?... (Score:3, Interesting)
Re:I can read! (Score:5, Interesting)
The 2924xl and 2950 allow you to block any mac address except broadcast addresses. So if you you flood the network with packets with one broadcast address and one real mac address you overflow its table it goes into a nice bridge mode. With a decent box it takes nearly two whole minutes to crack a single vendors mac codes.
As long as US compaines keep selling out to the short term stock price and sending critical stuff off 1/2 way around the world to be designed by people with no clue about real security, their products are going to be crap and full of holes. At one point I could trust Cisco and Sun but now they are almost at the level of most beige box builders but with them I know who I can go visit to get my money back.
All the new gear I've been buying is Kiwi designed stuff made by ATI. After a decade of dealing with cisco, I can't recomend any of their newer gear. the Current cisco mac address overflow was fixed by real engineers back in 1993. I'm not sure what kind of idiots they get to write their current code since bug history means nothing to them.
Why don't I put this on bugtraq and get it fixed? Its simple, The idiots that put the bug together have good jobs and the good people that know this stuff don't because of cost cutting.
Re:memset on windows?? (Score:3, Interesting)
memset exists for compatibility, but it's just a wrapper around FillMemory.
memset is a standard C library function. Here's a hint: the standard C library exists under Windows, too. I have never called ZeroMemory or FillMemory, period.
Here's another vulnerability. (Score:3, Interesting)
The "vulnerability" is very similar in behavior to the one described in the article but, is at the IP level rather than the link layer. The vulnerability has to do with padding of IP packets on Windows systems. Windows uses the contents of one of its buffers (sorry I can't say which one) to pad IP packets.
This is very easily reproducable when sniffing ping packets. The data portion of the packets are padded with the contents of the buffer. There are other utilities that demonstrate this behavior as well, but it is most easily reproduced with a simple ping and the bigger the ping packet the more data you'll see.
If you have been using IE and then sniff ping packets, you will see the data from your previous browsing. If you just logged in, you can sometimes find your password padding the ping packets.
As I said I have verified this on all WIndows platforms except XP. I have also looked for it on numerous Linux platforms and have NOT found Linux to suffer the same vulnerability. That is, Linux does NOT appear vulnerable.
MS is okay? (Score:2, Interesting)
Date Notified 06/25/2002
Date Modified 01/09/2003 10:55:58 AM
Status Summary: Not Vulnerable
Vendor Statement
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.
Re:common fault (Score:1, Interesting)
Re:common fault (Score:1, Interesting)