Revisiting ARP for security and robustness

Published: Nov 3, 2017
Tags: ARP security

by Joe McEachern & Matt Langlois

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.

You can see the issue in action in this capture:

https://www.cloudshark.org/captures/e987e09866b0?filter=arp

This is a known security issue that has fortunately been outlined by several existing Common Vulnerability and Exposure reports (CVEs):

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.

There’s an example of this problem here on CloudShark:

https://www.cloudshark.org/captures/01778a7c34c2?filter=arp%20or%20icmp

No response to ARP probes defined by RFC 5227

RFC 5227 introduced the concept of an ARP probe for IPv4 address conflict detection. The ARP probe format uses a source address of 0.0.0.0 in the ARP request. Some older ARP implementations ignore this ARP probe request.

The process looks like this when it happens:

https://www.cloudshark.org/captures/f43d5817df0e?filter=arp

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.

Here’s an example:

https://www.cloudshark.org/captures/054d343b10d6?filter=tcp.stream%20eq%20177%20or%20arp

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.

What can be done about it? In our next training installment on ARP, we look at how new tests added in CDRouter 10.5 cover these vulnerabilities.