3 min read
by Joe McEachern & Matt Langlois
As network protocols age, so do their implementations
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. CDRouter’s 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 filtering devices (e.g., for parental control) on the market that specifically depend on ARP spoofing to redirect traffic through a content aware filtering device.
When exercising CDRouter’s ARP module, we have, more than once, observed questionable behaviors in several home gateways we use in our test bed.
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):
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
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
CDRouter’s 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
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? Explore this article on CDRouter’s ARP test module that covers these vulnerabilities.
