Earlier this year, the Internet’s humble timekeeper hit the headlines as the major contributor to a series of devastating denial of service attacks, which were among the largest we’d ever seen. The amplification attacks were due to a flaw in the way the Network Time Protocol works, but recently an even more pernicious set of problems were discovered with NTP, which have the potential to allow an attacker to remotely execute code with the permissions of the NTP binary.
Needless to say, a remote code exploit in NTP is a serious problem. The service is ubiquitous: it’s found in everything from routers to ISP’s servers.
The vulnerabilities we’re concerned about have nothing to do with the NTP protocol itself, rather they are old-fashioned buffer overflow vulnerabilities in the NTP binary. What’s worse, they’re not at all difficult to exploit. A moderately technically educated person would have no trouble exploiting the vulnerability, and there are already tools available that make the process straightforward enough that anyone with malicious intent can have a crack at servers running NTP.
The vulnerabilities were discovered by security researchers Neel Mehta and Steven Roettger, and announced by the Industrial Control Control Systems Cyber Emergency Response Team (ICS-CERT), who said:
As NTP is widely used within operational Industrial Control Systems deployments, NCCIC/ICS-CERT is providing this information for US Critical Infrastructure asset owners and operators for awareness and to identify mitigations for affected devices
Exploiting the vulnerabilities involves a single carefully crafted packet, which can cause one of several buffer overflows, allowing for the execution of arbitrary remote code.
All versions of NTP prior to version 4.2.8 are vulnerable. The six most serious vulnerabilities were fixed in version 4.2.8, which should be available from operating system software repositories as I write. Mitigation of this risk is straightforward, after appropriate testing, upgrade to the most recent version of NTP immediately.
2014 has been a year of serious vulnerabilities in open source projects, the most prominent of which were Heartbleed, ShellShock, and POODLE, all of which were caused by implementation errors in particular services or libraries. In theory, the open source process is supposed to stop things like this from happening: bugs are supposed to be found because anyone can look at the code. In practice, hardly anyone apart from the original developer does look at the code, a situation which largely results from a lack of funding and resources for projects that have become a critical part of our industrial infrastructure.
There are measures afoot to ensure that the community does better in the future, particularly the Core Infrastructure Initiative, which exists to funnel funding to the developers of tools that are essential to our online infrastructure.