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