Slashdot Mirror
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.
One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Just tested this with Ethereal on W2K.
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?
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
---"What did I say that sounded like 'Tell me about your day?'"---
Interesting fact: Microsoft Windows is mentioned as "not vulnerable".
You mean Microsoft said they aren't vulnerable. 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.
Have you got your LWN subscription yet?
I was browsing around a Delphi executable file, and found a hod load of HTML that I had been working on earlier that day. The thing that pissed me off most was that all that junk that could have been zeros made the file less compressable than if it were, and we were distributing software over 19.2kbps serial connections at the time.
The firm I was workign for at the time noticed this 6 years ago on AIX.
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?
>> Since they don't specify the OS, I'm assuming these are drivers for Windows.
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.
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
I've found another similar vulnerability in Windows IP stack. I'm sure that I am not the first to discover this but, it has existed for a long time and has never been fixed. I have verified the vulnerability on all Windows platforms except XP, which I simply haven't bothered to look at.
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.
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.
If she floats, she's a witch.
Access cleans out the database when you compact it.
Not "packing" (which is the term when a filebased database doesn't immediately physically remove deleted records) is a very common occurance among filebased and ISAM databases. This isn't a flaw. If you want it removed, compact.