Red Hat Linux, together with its stablemates Fedora and CentOS, just patched a serious security bug.
This bug doesn’t need a fancy nickname, because it ended up (entirely by chance, of course) with a very memorable bug number: CVE-2018-1111.
Bug OneOneOneOne affects DHCP, short for dynamic host configuration protocol, a network-based system that helps you automate the process of getting computers to play nicely together online.
DHCP solves the problem of how to use the network itself to get a network number (in popular parlance, an IP address) in order to start using the network.
Without DHCP, you’d need to configure the IP address of each laptop, desktop or server on your network by hand.
You’d have to make sure that you didn’t accidentally give two different computers the same IP number, and in the event of an IP address collision you’d have to track down the culprits yourself and resolve the clash.
DHCP automates all this.
An unconfigured computer, called a DHCP client, pumps out a specially formatted network broadcast to say, “Tell me how to set myself up for the network”, and, if there’s a DHCP server on the network, it sends back a reply with everything the client needs to get connected.
The DHCP server typically dishes out your IP number, carefully avoiding collisions; tells you where to send your DNS queries; specifies the router to use to get onto the internet; and much more besides.
There are literally hundreds of different configuration options that a DHCP server can send back to a client, including where to find the official email gateway, what hostname to use, and which server to use as a web proxy.
When a DHCP client receives a reply, it needs to extract a bunch of data from the various options, such as “hostname = HAL” or “http_proxy = 192.0.2.245”, and then to hand this data over to a bunch of configuration programs.
On a Linux system, configuring network settings usually requires sysadmin privileges, so any scripts that deal with DHCP replies need to run as root.
Those configuration scripts had better be jolly careful with the data from the DHCP reply!
You can probably see where this is going.
Red Hat-based Linux distros include a dhclient script as part of their NetworkManager package – until the latest NetworkManager security patch, this script could be tricked into running text provided in a DHCP reply as if it were a system command of its own.
For example, under the guise of telling a Red Hat computer “your web proxy can be found at 192.0.2.245”, you could instead tell it, “your web proxy is at…ahh, heck, forget that, open up a remote shell for me instead so I can login secretly and unofficially later on”.
Technically, this sort of bug is known as a command injection vulnerability, because it allows you to sneak in a command where you are supposed to supply data.
It’s also a root RCE, short for remote code execution, because you don’t need to login first, and because you get to run the remotely supplied code as a system administrator.
What to do?
- Patch early, patch often! This vulnerability was found, reported and fixed before it was publicised, so a prompt patch will keep you ahead of the crooks.
- Validate input! If you’re a programmer, always check and sanitise data sent in from outside before you use it. Be doubly careful of any data you send off to a system command, where certain characters (e.g. quote marks, semicolons, backslashes and ampersands) have special meanings.
- Don’t panic! An attacker needs to be able to send rogue DHCP replies in order to exploit this bug. By default, network routers don’t allow DHCP requests or replies through, as a safety and security precaution. The attacker therefore needs to be on your network already.
Of course, an attacker with a rogue DHCP server on your network is already in a powerful position, even after you’ve patched against this hole – with control over DHCP, they could hijack DNS, kick critical servers off your LAN, allow unauthorised clients to sneak on, divert your internet traffic, and much more.
Some network switches help you to protect against rogue DHCP servers in general, for example by swallowing DHCP replies that don’t come from a specific port. (Speak to your switch vendor and consider using those features if they’re available.)
On wireless networks, look for an option that keeps client computers firewalled off from one another to protect against DHCP spoofing and lots of other roguery.
Sophos Wi-Fi products call this client isolation – it’s especially relevant for guest or hotspot networks, because it stops ill-behaved or badly-configured visitors from spoiling things for everyone else.