Etherleak

Last updated: 2003-03-12 The vulnerability was analyzed by:

Threat and Vulnerability

This vulnerability exploits flaw in multiple operating systems ethernet network interface drivers. Many drivers incorrectly handle frame padding using old buffers without clearing the old data first. This allows attacker to view parts of previosly sent packets or kernel memory.

This vulnerability is trivial and straight forward to exploit with readily available tools (ping and tcpdump), but results are limited to getting information from small portions of previous packets. Still, this attack might be used to get plain text passwords from hosts without being detected.

Preconditions for the attack

One precondition for this attack is a system using poorly coded Ethernet driver. Operating systems like FreeBSD, OpenBSD, Linux and Windows (all versions) can be vulnerable.

Systems running on i386-based hardware are usually more easily exploited due to multiplicity of different ethernet devices and therefore they have many different drivers.

The other precondition for the attacker is that he must be in the same ethernet network as the machine to be listened. This attack can be done in the switched network or from a completely different network, as long as the transport media is ethernet and nothing in between changes the ethernet frames.

Analysis of the attack

This vulnerability occurs in the device driver, when padding ethernet frames to minimum size with dirty buffers. RFCs require padding to be done with zeros, so this vulnerability could be described as poor implementation of the ethernet protocol.

Here's an example of how a poorly implemented ethernet driver could work. 

1: void xmit_frame(char *frame_buf, int frame_len) { 
2:        int length; 
3:        if (frame_len < MIN_FRAME_SZ)
4:                length = MIN_FRAME_SZ;
5:        else
6:                length = frame_len;
7:        copy_to_tx_buf(frame_buf, length);
8:        return;
9: }

As can be seen on lines 3, 4 and 7, if frame length is smaller than minimum frame size, the size is set to the minimun frame size and MIN_FRAME_SIZE - frame_len additional arbitrary data from (memory is copied to output buffer. This data could contain bytes from kernel memory, as well as data from previously sent or received packets.

Easiest way to deploy this attack is to send ICMP Echo requests to remote host with a payload of 1. After IP and ICMP headers the packet has a total of 29 bytes. Since the minimum packet size in ethernet is 46 bytes, this leaves 17 additional bytes to be padded to the packet. The remote host constructs its Echo reply packet (also 29+17 bytes) same way, and if using malfunctioning ethernet driver it will leak out information from its memory.

The attacker needs only to listen incoming ICMP echo reply -messages and check the 17-byte packet trailer for sensitive data.

Naturally, any method that can make the host to send smaller than 46 byte packets to the attacker can be used.

Detection and tracing

Massive ICMP_ECHO_REQUEST traffic could be sign of exploiting this attack. Tracing should be done at link level (ie using hardware addresses), for it is easy to spoof IP-addresses.

Protection against the Attack

The best protection for this kind of an attack is to upgrade network drivers and/or operating system to the version where ethernet frames are padded correctly. This however might not always be possible, since drivers for more obscure devices are not up to date anyway.

As with protection against any kind of sniffing, also here the sniffing is made useless when using proper encryption. Also filtering out ICMP messages can be used to lower the chances for this attack, since attacker must use some other way to make the host generate packets with small payload.

Test results

First tests were done in TML laboratary class. None of the machines there proved to be vulnerable.

The attacker used command

"ping -s 1 -f attacked_host"

and the results where seen by using tcpdump.

"tpcdump -X -n 'icmp[0] == 0'"

Only zeroes where found in the packet trailer.

Second test were done in private switched linux network. From host yyyyy were sent icmp echo requests to host xxxxx, which was doing continuous http-requests to host www.google.com. Below can be seen some output of tcpdump command in host yyyyy. 


17:13:03.128535 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5940 0000 4001 9e39 c0a8 0109        E...Y@..@..9....
0x0010   c0a8 010d 0000 1ed0 ac2f 3500 00ef 0100        ........./5.....
0x0020   0001 0000 0000 0000 0377 7777 0667             .........www.g
17:13:04.128552 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5941 0000 4001 9e38 c0a8 0109        E...YA..@..8....
0x0010   c0a8 010d 0000 1dd0 ac2f 3600 00ee e839        ........./6....9
0x0020   5010 2058 cb2f 0000 0204 05b4 0402             P..X./........
17:13:05.128538 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5942 0000 4001 9e37 c0a8 0109        E...YB..@..7....
0x0010   c0a8 010d 0000 1cd0 ac2f 3700 0093 0100        ........./7.....
0x0020   0001 0000 0000 0000 0377 7777 0667             .........www.g
17:13:06.128539 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5943 0000 4001 9e36 c0a8 0109        E...YC..@..6....
0x0010   c0a8 010d 0000 1bd0 ac2f 3800 000f 38b8        ........./8...8.
0x0020   5010 25bc 93f0 0000 0377 7777 0667             P.%......www.g
17:13:07.128538 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5944 0000 4001 9e35 c0a8 0109        E...YD..@..5....
0x0010   c0a8 010d 0000 1ad0 ac2f 3900 006e 0100        ........./9..n..
0x0020   0001 0000 0000 0000 0377 7777 0667             .........www.g
17:13:08.128517 xxxxx > yyyyy: icmp: echo reply
0x0000   4500 001d 5945 0000 4001 9e34 c0a8 0109        E...YE..@..4....
0x0010   c0a8 010d 0000 19d0 ac2f 3a00 0072 0100        ........./:..r..
0x0020   0001 0000 0000 0000 0377 7777 0667             .........www.g
The output does not tell much, but the "www.g" part (and the different ethernet trailer in any case) tells that at least some information is leaking out from host xxxxx's ethernet driver. This could be serious if transmitting unencrypted passwords.