Revisiting ARP for security and robustness

What is old is new again

In today’s security-focused world, every protocol is a potential attack point, even a protocol as old and localized as ARP.

ARP was originally defined in 1982 as RFC 826. Despite its age, Linux kernel code for ARP is still being actively developed. There have been more than 10 commits (11 as of October 2017) made to the net/ipv4/arp.c source file in 2017 alone. This level of change puts ARP at risk for unexpected behaviors, bugs, regressions, and misconfigurations. The new CDRouter ARP test module provides a nice collection of ARP regression and stress tests to ensure that your ARP implementation is solid and helps minimize this risk.

In some cases, the Linux kernel default behavior for ARP may not be well suited for a router or firewall device. It may be desirable to change the defaults to improve resistance to ARP spoofing attacks. The default Linux kernel allows ARP to respond to any ARP request on any interface regardless of the source address or network. There are also several new filtering devices on the market that specifically depend on ARP spoofing to redirect traffic through a content aware filtering device.

Uncovered Issues

Our testing of the new ARP module has revealed many questionable behaviors in several currently shipping gateway products.

Leaking WAN side address and gateway information on the LAN

We’ve seen several devices that send WAN side ARP requests for the default gateway to both the WAN side and LAN side interfaces. Leaking the WAN side information via ARP puts the gateway at risk especially if guest networking is offered.

Allowing the WAN side gateway to be easily spoofed on the LAN

Gateways that leak WAN side gateway information may also be susceptible to ARP spoofing attacks from the LAN which allow the attacker to modify the WAN side default gateway next-hop MAC with a bad entry. The CDRouter ARP test module contains a test case that attempts this attack and shows that some vendors are vulnerable.

ARP stress tests produce ARP cache errors

CDRouter’s new ARP stress tests expose the DUT to a large number of rapid MAC address changes. The Linux kernel code actually ignores some ARP table updates that happen too quickly. This behavior was intended to limit ARP thrashing when multiple proxy ARP devices may respond.

We found some gateways behave poorly after subjected to ARP stress tests. One particular device would switch target MAC addresses midway through a TCP stream to a previous ARP cache entry. While multiple ARP updates may not be expected in a normal deployment, these are definite attack points. Another device would fail to process additional ARP responses under certain conditions causing WAN forwarding to fail.

Solutions

It’s extremely important that even protocols that are considered mature and robust
be tested on any new product or platform. The issues we discovered when revisiting
ARP are a prime example, and certainly not the last problem with older protocols
we’ll see.