Researchers from @stake have discovered a vulnerability that has been slowly bleeding sensitive data across networks for more than a decade.

The report from @stake, “EtherLeak: Ethernet frame padding information leakage,” indicates that the threat derives from the fact that some Ethernet device drivers have been padding small Ethernet packets with previously transmitted and other sensitive data rather than the nulls called for in the Ethernet standard.

Ethernet packets can be from 46 to 1,500 bytes in size. But some high-level protocols call for shorter packets, and the IEEE 802.3 (Ethernet) standard says these should be padded with nulls to meet the minimum size requirements.

The recent discovery by @stake researchers is that some network interface card device drivers don’t generate nulls; instead, they use old pieces of data as filler without any regard to what information is contained in them. In various installations, the “fill” information can come from dynamic kernel memory, from static system memory dedicated to the device driver, or from RAM on the network interface card itself. The source of the data determines what sort of risk is posed.

The researchers suggest that the easiest way to exploit this vulnerability is to send ICMP echo commands to a machine running a vulnerable driver, which will then return bits of kernel memory data to pad the reply. These, in turn, can be searched for valuable information using a packet sniffer.

This may seem like a pretty small vulnerability, since it might add a maximum of only about 30 bits of data to a frame. But some drivers, specifically one Linux driver (Linux 2.4 axnet_cs.c used for PCMCIA Ethernet cards), allow the pad data to be as large as what happens to be in a buffer—not just enough to reach the minimum 46-byte size—and reuse previous frame data.

This appears to apply to a large number of device drivers, according to early reports from @stake. CERT Vulnerability Note # 412115 offers specific details. At the time this was written, most of the vendors still hadn’t determined whether their products were vulnerable to this new threat.

CERT warned, “This vulnerability may also affect link layer networking protocols other than Ethernet,” but it didn’t list any examples in the Vulnerability Note.

Risk level—unknown
The risk level from this threat is probably dramatically increased due to the publicity given the vulnerability, and that’s a primary reason I’ve included this item in Locksmith. How many people have been looking at the null fields of IP datagrams for sensitive data, especially when the controlling protocol RFCs specify that they be nulls?

It’s unlikely that this has been a major cause of security breaches in the past, but it’s equally certain that attackers will now look at this as a potential source of sensitive data. As a result, the risk level is probably going to increase dramatically.

Before anyone complains about @stake disclosing this information prematurely, take note: CERT said that despite having notified vendors more than six months earlier, nearly 40 have yet to even tell CERT whether they have tested their products to determine whether they are vulnerable.

Besides potentially exposing sensitive data, CERT warned that, “In some network environments, this vulnerability can also be used to circumvent technologies that divide networks into separate domains, such as VLANs and routers.”

Mitigating factors
The most significant mitigating factor is that the attacker or snooper must be on the same Ethernet network as the target, so it’s generally going to be internal attackers that can exploit this flaw. Another mitigating factor—at least in terms of the damage that may have occurred thus far—is that it’s doubtful that many hackers have known about this flaw and therefore haven’t exploited it until now.

Of course, it’s sad to say, but another major mitigating factor may be that most networks have much bigger and easier-to-exploit vulnerabilities for hackers to target.

CERT recommends encrypting all network traffic but warns that this still won’t help in situations where kernel memory is used to pad out the packets.

Some vendors have determined that their products aren’t affected by this threat, including IBM, Microsoft, and Cisco, but you should check the CERT bulletin for the latest information on which products are safe. If a product isn’t listed, contact the vendor to see if it has an update available.

Who’s to blame?
This situation demonstrates that even the most innocuous and seemingly benign protocols that have been around for years—Ethernet was developed at PARC in the early 70s and was commercialized in 1980—may have holes in them. The fault isn’t actually due to a flaw with the Ethernet standard developed by IEEE; rather, it is due to a loophole. The creators of the standard tried to keep things as simple as possible, so they just specified that the empty spaces in a packet be filled out with nulls. However, something fell between the cracks of the two relevant RFCs, 894 and 1042, controlling IP datagram transmission, and it was not made clear just who was responsible for padding the packets or where it would be done.

Final word
This is the sort of problem that can go on for years without being discovered (obviously). But once disclosed, it propels hackers to start trolling for the goldmine of sensitive data they hope is there.

A few top-level hackers may have known about this and been quietly exploiting the vulnerability for various purposes, but now it’s public knowledge.

When I first read about this vulnerability on CERT, I thought this was a minor problem because, after all, it is mostly a Layer 2 event. But after looking into it a bit further, I believe this is a serious vulnerability, mostly because it is probably widespread and there is simply no way to know what data is being exposed to unauthorized individuals.

Also, many of us, including myself, are prone to forget that study after study shows that the biggest security threats to networks come from insiders, and this is the kind of threat that insiders can exploit easily.