Security experts are urging Microsoft and Juniper to patch a year old IPv6 vulnerability so dangerous it can freeze any Windows machine on a LAN in a matter of minutes.
Microsoft has downplayed the risk because the hole requires a physical connection to the wired LAN. Juniper says it has delayed a patch because the hole only affects a small number of its products, and it wants the IETF to fix the protocol instead.
The vulnerability was initially discovered in July 2010 by Marc Heuse, an IT security consultant in Berlin. He found that products from several vendors were vulnerable, including all recent versions of Windows, Cisco routers, Linux and Juniper’s Netscreen. Cisco issued a patch in October 2010, and the Linux kernel has since been fixed as well. Microsoft and Juniper have acknowledged the vulnerability, but neither have committed to patches.
The hole is in a technology known as router advertisements, where routers broadcast their IPv6 addresses to help clients find and connect to an IPv6 subnet. The DoS attack involves flooding the network segment with random RAs, which eats up CPU resources in Windows until the CPU is overloaded and a hard reboot is required. “For Windows, a personal firewall or similar security product does not protect against this attack, as the default filter rules allow these packets through,” explains Heuse.
Heuse became so frustrated with Microsoft’s refusal to fix the hole that he published his findings to the Full Disclosure mailing list on April 15. He notes that Microsoft has not even issued a security advisory warning users of the problem. Other Windows networking and security experts have also urged Microsoft to fix the problem, and sources have said that there are even employees inside Microsoft who have been trying to nudge the company to action.
Microsoft has little to say on the subject. “Microsoft is aware of discussions in the security community concerning a technique by which a Windows server or workstation on a target network may experience unprompted high resource utilisation caused by an attacker broadcasting malicious IPv6 router advertisements. The attack method described would require that a would-be attacker have link-local access to the targeted network, a situation that does not provide a security boundary,” a Microsoft spokesperson said.
However, experts aren’t buying it. The hole is “very easy to fix,” Heuse says, and Microsoft has a long history of addressing DoS holes on the local LAN that have far less of an impact. He points to Microsoft fixing a similar issue in 2008 of its implementation of IPv4. Meanwhile, Microsoft has also committed to fixing another issue he recently reported to the company which he describes as “a very minor vulnerability of detecting if a host is sniffing. It, too, is only possible on the local LAN.” His conclusion is that there is a political issue inside Microsoft where the “responsible team does not want to fix these kinds of issues anymore.”
Some Windows networking consultants are so concerned about the hole and Microsoft’s lack of interest in fixing it, that they have been warning users directly. “There is a serious Windows vulnerability for RA flooding as a denial-of-service attack on wired LANs. It only takes between 5 to 20 packets to CPU-bound every Windows 7 or Server 2008 machine on that subnet,” said Microsoft MVP Ed Horley, Principal Solutions Architect at Groupware Technology to attendees of the Rocky Mountain IPv6 Summit. “I have heard rumour it can also lock out Playstation 2 and Xbox consoles. With enough packets it requires a hard reboot to recover.”
Although several workarounds exist, each has a significant drawback. One is to turn off IPv6, which also disables new Microsoft technologies that rely on it, such as DirectAccess, a service that allows Windows 7 machines to have an always-on remote access connection to Windows Server 2008 R2 servers. Remote Access is touted as a money-saving option as it replaces the need for a separate VPN in Windows environments.
Experts also advise using a router that has implemented a Cisco technology called RA Guard, and while Cisco routers support RA Guard, not all routers do. RA Guard was submitted as an informational document to the IETF, RFC 6105, but it is not on track to become a standard.
Juniper, for instance, has no intention of implementing it and is instead waiting for IETF RFC 6164. “RFC 6105 IPv6 Router Advertisement Guard, published about nine weeks ago, is an informational RFC, as opposed to an IETF Standard, that documents Cisco's proprietary RA-Guard technology. Cisco asserts that at least one of their patent applications (US PPA 20080307516) covers this technology. While Cisco has stated that should RFC 6105 become a standard then they will make a royalty-free license available, since this is not yet a standard there is no such option. We can however achieve much the same functionality simply by applying access control lists,” said Juniper’s Peter Lunk, director of product marketing for high-end security systems.
Lunk added: “Conversely, RFC 6164, released last month, is a ‘standards track’ RFC (which is to say on the way to being, but not yet, a standard) supported by Juniper, Google and IBM and others that addresses many of the same issues in a much more open manner. We expect this to be ratified as a full standard at the next IETF meeting in July.”
Heuse has also called Juniper out on the carpet for dragging its feet to fix the hole. Juniper’s Lunk argues that the RA advertisement problem stems from a flaw in the ICMPv6 protocol and should be fixed by the IETF.
“The flaw in the ICMPv6 protocol has only been identified in a small subset of older Juniper products, and only when configured as a host rather than a router,” he said. “According to the protocol, devices configured as hosts must accept and process all advertised routes. This is an inherently dangerous thing to do. If our customers must use auto-configure mode on the IPV6 host on an open LAN, then we strongly recommend whitelisting sources of acceptable routes which will protect them from bogus advertisements.”
He adds: “While individual vendors may put in patches to cover up the fundamental problem, the fact is that conforming implementations of the spec are inevitably vulnerable to route contamination even if they hide the resource exhaustion problem. Until the IETF fix the protocol the best course of action is to only accept routes from routers that you trust by whitelisting legitimate route sources.”
If RA Guard is not available, another workaround within a Windows environments is to turn off Router Discovery, says Sam Browne, a computer networking instructor who has also been pressuring Microsoft to fix the hole. Bowne has produced a video that shows how easy the exploit is to do. Turning off Router Discovery “is a simple solution, requiring only one command, but it will prevent you from using Stateless Autoconfiguration. It's probably appropriate for servers, but not as good for client machines,” Bowne says.
Bowne says another possibility is to set your firewall to block rogue Router Advertisements, while whitelisting them from authorised gateways. But both Bowne and Heuse say that this method is easily defeated. Heuse is even planning on demonstrating an attack that bypasses this fix later this month.
Horley also says that the attack isn’t limited to those connected to a wired LAN, either. “It does affect Windows 7 and Server 2008 machines on wireless networks too,” he said. “There is no fix for wireless networks as RA Guard is not a feasible option on wireless.”
On the other hand, Horley also admits that on the wireless side, “the greatest risk of being affected is when joining an open network. Assuming the machine is on a trusted, secure wireless network, unless it is ‘owned’ there is no reason someone would run this exploit unless they were being malicious.” He also notes: “There are likely far better exploits out there then a simple DOS attack if you have managed to connect to the secure wireless network.”
Meanwhile Bowne is continuing to push Microsoft to take three actions: issue a security warning telling people to disable router discovery on servers and adjust their firewall to block rogue Router Advertisements on clients, shut Router Discovery off by default in future products and patch the network software so that it limits the amount of CPU that can be consumed by the Router Discovery and Stateless Autoconfiguration processes.