In-Depth

New Vulnerability Could Reveal Sensitive Information

A widespread flaw in Ethernet card device drivers affects a “staggering” number of systems

• By Stephen Swoyer
• 01/15/2003

In a security advisory issued last week, @Stake revealed that there are flaws in the design of device drivers for some multiple platform network interface cards (NICs). The problem occurs because of incorrect implementations of RFC requirements, or as a result of poor programming practices, and could result in the disclosure of sensitive or otherwise proprietary information.

Some device drivers responsible for Ethernet frame generation incorrectly handle the padding of small, non-standard data packets, @Stake indicated. The Ethernet standard describes a minimum packet size of 46 bytes, but when a higher-level protocol requires less than this amount, the RFCs specify that the difference should be padded with null data.

Because these device drivers instead pad the difference with data lifted from previously transmitted Ethernet frames, potentially sensitive data could be transmitted across the wire. An unscrupulous attacker could then use a packet sniffer to recover this data. @Stake says that the easiest way to exploit this flaw is to send ICMP echo messages to a machine with a vulnerable Ethernet driver. In this scenario, portions of kernel memory will be returned to the attacker in the padding of the reply messages.

During testing, @Stake found that the padded data typically consists of snippets of whatever network traffic the vulnerable machine was handling. In a vulnerability report posted to the company’s Web site, @Stake analysts Ofir Arkin and Josh Anderson say that this could allow an attacker to see portions of the traffic that a router or firewall is handling on the network segments to which it has direct access. The analysts stress that the attacker must be on the same Ethernet network as the vulnerable machine to receive the Ethernet frames. (You can find the report at http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf.)

The problem is exacerbated by “[a]mbiguities within the RFCs [that] leave it unclear as to who is responsible for padding the Ethernet frames,” the @Stake analysts write. Padding can take place on the NIC hardware itself, in the software device driver, or even in a separate Layer 2 stack.

The result, say both researchers, is a potentially disastrous situation. “The number of affected systems is staggering, and the number of vulnerable systems used as critical network infrastructure terrifying. The security of proprietary network devices is particularly questionable.”

Carnegie Mellon’s CERT Coordination Center posted a list (http://www.kb.cert.org/vuls/id/412115) of vendors whose products could be affected by this vulnerability. Most haven’t disclosed whether or not their products are vulnerable, but some—including Cisco Systems Inc., F5 Networks, IBM Corp. and Microsoft—have confirmed that their products are not vulnerable.