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.

Or maybe

[Anonymous Coward]

the flaws are in linux drivers too. Who knows, you might even want to read the article.

You assume too much

[GroovBird]

From the article (in case you haven't read it):

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

Read the f*cking article.

[Alranor]

Since they don't specify the OS

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

OK, it's slashdot, so we expect people to post comments without reading the article, but it's a little ridiculous that the submitter didn't even bother.

CERT link

[Jan-Pascal]

You can find the CERT's take on this here:
http://www.kb.cert.org/vuls/id/412115 [cert.org].

Re:You assume too much

[GroovBird]

In addition (I post too fast), the CERT has made available a list of vulnerable systems [cert.org] that they know of.
Interesting fact: Microsoft Windows is mentioned as "not vulnerable".

common fault

[oliverthered]

Lots of applications have the same fault, e.g. Microsoft Access doesn't appear to memset so you get what ever happens to be kicking around in memory written to emptyness in the database.
Also Access doesn't clean out deleted data.

Links to actual article

[tomlouie]

Here's a link to the original article:

http://www.atstake.com/research/advisories/2003/ at stake_etherleak_report.pdf

Here's a link to the CERT notice:

http://www.kb.cert.org/vuls/id/412115

Both articles have more info than the article that was posted for this story. Silly rabbit.

Enjoy.

Tom

Re:Or maybe

[packeteer]

Exploitable drivers have been found for Windows, Linux, NetBSD, and a few other proprietary OS's which i would assume could mean something like Mac or Novell or OS/2... who knows really.

Re:Wow..

[NuMessiah]

Well, we are speaking about the ethernet packets here. As soon as the packet hits the router or bridge only the IP (or ICMP ...) protocol partition is transferred. So this bug actualy can't be globaly exploited, only within the switched eternet networks.

bb4now,
PMC

Details from @stake

[Unfallen]

@stake's advisory release:
http://www.atstake.com/research/advisories/2003/a0 10603-1.txt [atstake.com]

And their etherleak report PDF:
http://www.atstake.com/research/advisories/2003/at stake_etherleak_report.pdf [atstake.com]

deja vu.....

[taviso]

here [google.com] is a bugtraq thread from a year ago, describing a similar sounding problem...

Re:Details from @stake

[1010011010]

So, @Stake is just figuring this out [google.com], eh?

It is possible to read parts of a remote machines memory. To be specific, it would have to be memory recently freed/swapped to disk. Consider this for example:

int main(int argc, char **argv[], char **envp[])
{
char *ptr=0; /* We take a rather large chunk of memory and fill it with A's */
int val, i;

while(1) {
sleep(1);
val = 30000000; // ~ 30 M
ptr = (char *)malloc(val);

memset(ptr, 0x41, val-1);
free(ptr);
}
}

And then we modify nmap(1) (Around line 687) so it only transmits the first fragment out of a fragmented scan. This will illict a ICMP TTL Exceeded message. Due to Linux including a lot more of the packet than most other OS's, we have around 20 bytes to read. From memory, Solaris includes a little bit extra on ICMP messages.

Let's look at a sniffer trace from snort(2): (Ignore the time stamps, as the machine this was originally done had a date in 1994...)

12/11-00:34:34.290903 127.0.0.1 -> 127.0.0.1
ICMP TTL:255 TOS:0xC0 ID:29812
TTL EXCEEDED
00 00 00 00 45 00 00 24 A2 15 20 00 3E 06 BC BC ....E..$.. .>...
7F 00 00 01 7F 00 00 01 E1 C1 01 91 FB 73 6B E2 .............sk.
00 00 00 00 50 02 08 00 41 41 41 41 41 41 41 41 ....P...AAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA

12/11-01:02:30.170720 127.0.0.1 -> 127.0.0.1
CMP TTL:255 TOS:0xC0 ID:31185
TTL EXCEEDED
00 00 00 00 45 00 00 24 32 25 20 00 3B 06 2F AD ....E..$2% .;./.
7F 00 00 01 7F 00 00 01 AA 1E 01 11 50 FE C6 45 ............P..E
00 00 00 00 50 02 08 00 41 41 41 41 41 41 41 41 ....P...AAAAAAAA
41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA

Also - to prove this is not Snort's fault I included a tcpdump(3) log.

01:06:02.640246 lo < 127.0.0.1 > 127.0.0.1: icmp: ip reassembly time exceeded [tos 0xc0]
45c0 0054 7b85 0000 ff01 4161 7f00 0001
7f00 0001 0b01 77a3 0000 0000 4500 0024
d3e5 2000 3306 95ec 7f00 0001 7f00 0001
c027 055a 5fa5 73a5 0000 0000 5002 0800
4141 4141 4141 4141 4141 4141 4141 4141

AFFECTED:
I assume it would be any OS that includes more than the ip addresses/ports.

USAGES:
The ramifications from this could be great. You may get fragments of the shadow file, various plaintext passwords (greatly depends...), pieces of code, urls, random memory.

One specific use is for this could be identifying the endianness of a remote machine because of the addresses are in memory. (Reading from Linux Magazine November 2001, page 50, you have 0xef* for the stack on a big endian system as opposed to the 0xbf* on little endian. (linux-wise)).

FIX:
hrmm.... well.

• Locking memory for important stuff (passwords etc.). I've forgotten the call to do that but it is possible. This will prevent swapping to disk which might make it better.
• Modifying the kernel so in its idle loop (or whatever) it wipes some (unused!) memory. Could lead to a race though...
• A small program to continues malloc() / zero / free() stuff. A little like the program above, but zeroing it instead. (You could always take the offensive stand by filling it with decoy data... that's left to the reader to implement. ;)
• Make the network code zero out the packet before sending it. This would slow it down though, and make it even more obvious that you are running linux.
• Filter out various icmp error messages, but as usual that breaks everything.

... from January, 2002.

Re:SSH

[42forty-two42]

It can't sniff SSH keys from that; SSH is secure even if you sniff *all* packets.

Re:Wow..

[Large Green Mallard]

Close. Hits a router, or something routing (ie a PC) and the ethernet frame becomes just another TCP/IP packet.

A bridge doesn't route, it only segments ethernet segments and reduces the amount of traffic going to the section it is in front of.

Re:I can read!

[Raphael]

The pad of older data in a 46 byte header can't contain a lot of data.

In addition, you also have to be able to get this data. As mentioned by mmol_6453, you can only get the Ethernet frames if you are on the same LAN or if the victim is tunneling the Ethernet frames through a VPN. If there is an IP router between you and the victim, you will probably not be able to get the leaked bytes (and I am glad to see that several routers listed in the CERT advisory [cert.org] are not vulnerable).

The advisory says: "the leaked information may originate from dynamic kernel memory, from static system memory allocated to the device driver, or from a hardware buffer located on the network interface card.". If you are using a broadcast Ethernet medium, then the leaked information collected from the static memory of the device driver or from the hardware buffer on the NIC will probably be much less than what could be collected by running a packet sniffer on the same Ethernet segment, because the leaked bytes will come from previous packets. However, this is different if you are running a switched Ethernet network (not broadcast) because the packet sniffers are less useful in this case.

As I see it, the only real potential for information leakage comes from the device drivers that are leaking bytes from the dynamically allocated kernel memory. Then you could get almost anything from that machine, not only something that is supposed to be sent over the network. On the other hand, it is probably very hard to predict what will be leaked.

It would be interesting if the advisory could give a list of operating systems that are leaking random information from the kernel versus those that are leaking information from the previous packets (in the driver or in the NIC). I would be more worried about the former than the latter.

Re:Not a hard fix for open source

[Richard_at_work]

Read the CERT advisory:

Microsoft Corporation Not Vulnerable 3-Jan-2003

So are they such the big problem you thought they were going to be?

Re:Or maybe

[Ashran]

A link [cert.org] from the article has a list of vulnerable vendors.
#
Quote

Microsoft Corporation Not Vulnerable 3-Jan-2003

Re:Slow newsday for eweek then.

[sboyko]

You can't use ping, because ping's job is to echo back what you sent. It should fill the packet.

http://www.ietf.org/rfc/rfc0792.txt?number=0792

Re:Read the f*cking article.

[fulgan]

This is even MORE stupid since the REAL advisory this article is based on specifically states that windows doesn't ship with any vulnerable drivers.

The only point of interrogation is that SAMPLES that when compiled without changes, will have the reported problem (http://www.kb.cert.org/vuls/id/JPLA-5BGP7V)

The drivers comply with the RFC

[dcs]

RFC1042 says "When necessary, the data field should be padded (with octets of zero)to meet the IEEE 802 minimum frame size requirements."

RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."

Re:A call

[k98sven]

f any of the linux kernel hackers are reading this, don't just sit there, fix those network modules.

According to this post [iu.edu] by Alan Cox on the kernel mailing list,
patches for the problem are currently in testing already.

Cisco isn't vulnerable:

[Ayanami Rei]

Cisco's Status/Statement [cert.org]
and
Full CERT Advisory [cert.org]

Re:SSH

[Anonymous Coward]

It can't sniff SSH keys from that; SSH is secure even if you sniff *all* packets.

Unless of course you are using SSH version 1 which is easily cracked. Check out ettercap [sourceforge.net] for an SSH version 1 sniffer.

Re:Not a hard fix for open source

[AvidLinuxUser]

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. From Cert Site...

Re:SSH

[thing12]

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

No, the SSH private keys are never in an ethernet packet to begin with. You can only get information from the target system that it a) has already sent somewhere else; b) got from a pool of free memory and then sent you packet with fewer than 46 bytes of data in it (i.e. ICMP). I find it hard to believe that this is remotely useful since you only get up to 46 bytes - so your ssh key would have to be in a block of memory that had been deallocated back to the kernel memory pool - and the ethernet driver has to be lucky enough to then allocate that memory when it needed more buffer. But why would it need to allocate more buffer when all you're asking from it is a packet that contains less than 46 bytes?

The idea that it's a useful exploit from that standpoint that you can read a remote systems memory is a bit preposterous. It all seems like it requires a coincidence on the order of planetary alignment for any valuable information to be extracted from this bug. Yes, you can grab parts of previously sent packets - but in a world where all sensitive information is encrypted prior to transmission this flaw is just moot. Fix it, move on, nothing to see here.

This flaw is a non-issue

[rmckeethen]

Consider the length of time this so-called vulnerability has lurked in the device driver code for all those operating systems, than ask why no one discovered the problem sooner. Could it be that there's nothing to be worried about?

I'm guessing this problem has gone undetected so long because uber-short frames don't naturally occur on most Ethernet installations. Networks typically send real data, not empty frames, that's why we build them in the first place. You have to intentionally generate super-small frames if you want to see them. All the examples @Stake provides are based on ICMP Echo/Echo Replies, where you can specify the packet length at the command line. Show me some real network traffic that exhibits this problem, than I'll start to worry.

Still not convinced? Well, consider that you can't exploit the issue beyond even a single router, and that the vulnerability in most cases is just rehashed data, stuff that's already gone out on the wire. How big a security issue is that? Seems like the least of my problems. I'd worry more about one un-patched system on the network or one stupid marketroid opening a TELNET secession to the web server than I'd worry about this.

I'm going to go out on a limb here and declare this a non-issue. I'm sure the guys over at @Stake are happy to have something to show their bosses (and the media) so soon after the holidays, but it just doesn't look very serious from where I'm sitting.

Re:Someone please mod down wrong.

[schon]

this is uninformed spouting of the mouth.

you mean his post, or yours?

Block IMCP if you don't need it

Ahem; if you run TCP/IP, you always need it.

ICMP is used for control messages between systems - it's used for control messages (the 'C' and 'M' in ICMP) for TCP and UDP packets.

Without ICMP, your connections can take longer, or (in some cases) not work at all. All modern OSes support path MTU discovery - and PMTU discovery relies on ICMP messages. If you block these messages, your clients will be unable to reach sites if part of your path to them has a smaller MTU than the MTU of your local interface.

You may know a lot about SSH, but you don't know squat about TCP/IP. ICMP is used for more than just 'ping'.

Re:SSH

[Tom]

Wrong topic. This isn't about sniffing the SSH traffic, it's about sniffing the memory of the machine, which can well contain the key.
Your hit-chance is pretty bad, though.

Re:Slow newsday for eweek then.

[gclef]

Read the advisory. The problem they're highlighting involves breaking the standard a bit.

What you do is send an ethernet frame that is too small by the standard's requirements. The reply will come back padded to meet the minimum size requirement. Where the padding comes from is apparently the problem...apparently it's just malloc'd, not cleared in any way.

This means, for one thing, that you have to be on the local LAN with your target, since any routing of the packet will re-write the ethernet header, blowing away your sneakiness. It also means that standard ping won't do. You have to be able to break the rules for ethernet to see the effect.

Re:well

[Ivan Raikov]

lets hope this isn't globally exploitable, as I can't imagine every manufacturer of every card is going to fix this....

One wonders whether it would be possible to build a fix into the operating system, or would that be too great an abstraction?

Well, all you need to do is set your firewall to drop all ICMP packets. Theoretically, someone could exploit this over TCP, but because TCP allows piggybacking, and because it generally has more overhead than simple ICMP packets, it's unlikely that you can easily trick a remote system to respond with a TCP packet that's less than 48 bytes.

And by the way, if you use Mandrake Linux and the firewall software that ships with it, Shorewall (basically a collection of iptables rules), ICMP packets are already being dropped when they reach your system.

Re:well

[Ivan Raikov]

What I wrote was wrong. ICMP is a necessary part of the IP protocol, so you can't really block all ICMP message. My firewall only drops ICMP Echo and Echo Reply packets, which are used by ping.

Re:You assume too much

[Anonymous Coward]

You failed to return a value at the end if main() even though it is declared to return an int.

Re:SSH

[Anonymous Coward]

up to 46 bytes of memory, which would usually be statically allocated, and reused for each packet, meaning that only the first packet would have random data, the rest would have data that was already transferred by the same card (or at least same driver = same brand of card).

Re: Read the f*cking CERT note

[Drestin]

If you read the actual CERT Vulnerability note [cert.org] and seen that Windows is not vulnerable.

Fixed in 2.4

[noselasd]

http://linux.bkbits.com:8080/linux-2.4/ChangeSet@- 3d?nav=index.html You'll see Marcelo just commited fixes for heaps of network drivers from Alan Cox to the 2.4 tree.

Re:deja vu.....

[Russ Nelson]

a year ago?? You're kidding. This problem has been well-known for at least fifteen years. But given that passwords have been floating around in the clear (telnet, pop3, imap), why bother securing random contents of memory? Remember, you've got to be on the same Ethernet to exploit this.
-russ

Re:Stupid

[photon317]

Oh and I might add that this won't work over an IP connection only (e.g. across the net). You need to be on the same ethernet segment as the target. This greatly limits the usefulness again. While we're at it, if you were on their segment, and it's not switched, you likely already are seeing every packet the target machine transmits anyways. Oh and by the way, there's exploits out there already to make most switches give up this data as well, so in all likelyhood this gained you nothing.

Re:well

[Corgha]

It's also wrong because this bug is in ethernet frame padding, not in IP padding. Your firewall shouldn't be leaking that layer 2 stuff anyway -- this is only exploitable on the local network. Now, if your firewall also has this bug, it could leak data to machines on the network segment of its external interface, but that's another matter, and an attacker a few hops away isn't likely to get anything useful.

From the initial @stake advisory:

It is important to note that the attacker must be on the same ethernet network as the vulnerable machine to receive the ethernet frames.

Re:SSH

[ehiris]

It reads the static memory allocated to the driver or other dynamic kernel memory. It is highly unlikely for the full SSH private key to be there but there is a small chance since the threads are being run in a pretty close time frame apart. Actually it also depends how large your key is and how much data is in the ICMP package. It is 8* more likely to retrieve a 128 bit SSL private key then there is to retrieve an 1024 bit SSH private key.
I'd be more worried about secure credit card transactions on web servers that don't get patched soon and don't renew their private keys.

exploiting

[Phrack]

Windows CAN be vulnerable. Found several locally. Hardware companies using too much Microsoft example code, I imagine.

Simple to exploit.
Mac OS X/Linux:ping -c 1 -s 0 10.10.10.10
Solaris: ping 10.10.10.10 0 1
Windows: ping -n 1 -l 0 10.10.10.10
(where 10.10.10.10 is, of course, target host). Solaris doesn't seem to even want to *send* the echo request with 0 payload. Then again, I didn't investigate that too hard. IOS will definately not let you specify datagram size small enough to exploit (for that matter, it pads the echo request properly, unlike my test Win2k box with Xircom card.

Collect in favorite packet sniffer and observe. In Ethereal, it's added as Trailer under the Ethernet frame. Don't expect it to make sense.

Routers may or may not impede it. Checking about half a dozen local private class C's, I found 20 machines returning frame data. One linux, a few Windows, and a few VoIP devices. Those were crossing a Cisco L3 switch. It sorta routes, it sorta switches. However, as expected, crossing a 7204 easily screws the pooch.

So, for someone on the outside to make use of this, they'll have to break into a machine elsewhere on your network and setup some automatic exploit. To allow that to happen, you've got big troubles already besides already transmitted frame data.

And anyway, 18 bytes of previously transmitted frame data are not much to worry about. If you're not already deploying the basic security that would foil this.. just get out of the game.

Re:Looks pretty harmless

[pclminion]

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.

No! It would most likely be data from some other packet that was sent or received previously. The OS doesn't allocate network buffers willy-nilly, it tries to reuse the buffers if possible. This means the memory used to send a short packet is most likely going to be reused from a previous network buffer. Meaning the data out on the wire is probably going to be someone else's network traffic that you shouldn't have seen.

I agree that the problem would be much less severe if you really were getting bytes from random spots in memory, but that isn't what happens. Operating systems tend to allocate a big chunk of memory for buffers, then reuse it over and over.

Re:common fault

[jeremyp]

The Word problem is far worse than that. The "fast save" facility just tacks amendments onto the end of the original document. you can often find earlier drafts of documents (or even completely different documents) by doing strings on them.

Nowadays I send all docs out in pdf format.

This is silly.

[Dagmar d'Surreal]

When I first saw this, I thought to myself, "Surely Steve Gibson's name is on the report somewhere" because this is the sort of lunacy one usually finds his name on.

Much to my suprise, @Stake's name was on it. Looking further, I see that Eweek has genuinely made a mountain out of a molehill. Seventeen bytes of randomly chosen data can be snatched from a remote machine, provided it's literally in the same building as the attacker, and provided it's got a cheap-o network card. Pardon me while I quake in fear for the safety of the little children.

Why do we have to be in the same building? Because if the packet in question goes through most routers, they're quite likely to crumple the bits up and throw them away because of it's past use as a means for covert communication. ...and while it's good that the memory leakage is of contiguous bytes (otherwise they'd be entirely useless) seventeen bytes is a _really_ small window for any meaningful data to come through. If you were lucky, you might be able to get part of a (presumeably encrypted) password, or two and a half words from a typical email. It's also possible that fancy arp-foolery would get you *all* the victim's network traffic, making it the long and obnoxious way to go about doing something as simple as sniffing packets.

Their statement about it being "trivial to exploit" should have stopped at just saying it was "trivial". It was good of @Stake to bring this to the attention of programmers, although quite possibly publishing in PDF format made it look a little more important than it really is. ...What Eweek published about it was downright silly.

Clue.

[twitter]

Read the article, what a great idea! I'd never have thought that's what Slashdot was good for. Solid advice worthy of a +5 troll rating. So what do we find?
Thanks to some vagueness in the standards defining IP datagram transmission on Ethernet networks, it's not entirely clear exactly how the padding should be done. Some implementations do it on the NIC, while others handle it in the software device driver

Ding! This means that all NICs that have the problem have that problem under any OS unless the card can be overcome by software. Additionally, "software drivers" under any OS can have the same problem.

Is the problem more likely under, M$ junk? Of course it is. The free software world will move to fix any driver problems, and there are only a few dozen drivers in the world to work the thousands of different brand name cards. The closed source world has thousands of drivers to fix by companies that may not even exist anymore, and because it's closed and the user won't know any better, why would anyone bother?

Of course this completely ignores whole models that are available in the free software world to prevent such problems of untrusted networks in the first place. I don't really care if my NIC pads packets with chunks of the last SSH packet. Encryped noise is just that and you can have as many packets as you like of it. If you played it over a speaker it would sound like this "Shushshhshhhshhhhhshhhhsh!" and I sugest you do shush.