During our development of GRC's comprehensive DNS nameserver spoofability profiling system, we discovered something quite unexpected: A number of users were losing all Internet connectivity shortly after initiating the nameserver profiling. Upon further examination they discovered that the test was crashing their consumer NAT routers. The following routers are currently known to be susceptible to crashing under this test:

DNS Test “Crashable” NAT Routers • 3Com 3CR858-91 OfficeConnect Ethernet Broadband Router • 3Com 3CRWDR100A-72 OfficeConnect ADSL Wireless 11g Firewall Router • A-Link RR24AP(i+) with latest firmware at time of crash report • Belkin F5D7234-4 v3 (01) Wireless G Router (firmware 3.00.3) • Belkin F5D7234-4 v4 (01) Firmware v4.00.05 • Belkin F5D7630-4A (rebranded as MicraDigital) • Belkin F5D8236-4 v2 Wireless N Router • Belkin F5D8636-4 v2 Wireless N Router • Belkin F7D2301 v1 (01) Wireless N Router • Ozenda AR4505GW • Philips SNA6500 ADSL Wireless Base Station • Siemens Gigaset SX551 WLAN DSL

Okay, that's annoying, but why is it a concern?
What this means is that the Internet data packets entering these routers from the outside are, in some way, something that the router does not currently handle properly — so the router crashes. The development of virtually all successful remote Internet exploits begins when someone notices that something unexpectedly crashes a system. This is typically evidence of a previously unknown “buffer overrun” or “unchecked buffer” vulnerability in the affected device. Armed with the knowledge of the existence of such a possible vulnerability, skilled hackers — and make no mistake about it, these people are highly skilled — are often able to refine the characteristics of the “crashing packet” to cause the affected system to execute code they provide in a some sophisticated version of that packet.

And, with that, the minor annoyance that once crashed a router when running
GRC's DNS test evolves into a full blown exploit that allows a remote hacker to
take control of the network that was previously protected by that router.

PLEASE CAREFULLY NOTE what we are and are not explicitly stating about this potential for a remotely exploitable vulnerability:

• We are NOT stating that any of the routers which our test causes to crash have any discoverable remotely exploitable vulnerability.
• We ARE stating that no one's router should ever crash simply by having it pass a valid, resolved domain name from the Internet to a machine on its internal network — which is all our test does.
• We ARE stating that remote execution exploits almost always begin life as unexpected (and certainly unwanted) crashes.
• We ARE stating that any newly discovered crash, exactly like this, provides the sort of window of opportunity that talented hackers live for.
• We WILL NOT be surprised to learn that this revelation results in the creation and exploitation of any of the routers listed above.

Mitigating Circumstances:
It might very well be that the inherent behavior of NAT routers, whereby they simply ignore and drop unsolicited packets coming in from the Internet, would completely mitigate any danger from the fact that expected and solicited packets — such as those occurring during our test — are able to crash the router. In other words, your router is crashable and potentially vulnerable only because and only while it is in the process of running this test which was initiated by you “on the inside” from behind your router's inherent protection.

Having said that, however, it might also be that any exposed ports in a router, such as those created by explicit port forwarding or the use of a router's “DMZ” forwarding capability, would once again expose the router to DNS packets it appears to be unable to safely digest.

• Complain loudly to your router's manufacturer:
  One advantage of this publicly available router crashability test is that any router manufacturer can easily use it to reproduce and fix their defective router firmware. (And yes, we realize that the downside is that the bad guys can also use it to figure out what's happening and possibly design a potent exploit. This is the common tradeoff when publicly and openly dealing with Internet troubles.)
• Don't panic:
  Yes, there's significant potential for trouble here, but please remember that it's only potential at this time, even if it is significant. That's still very different from confirmed trouble. Please don't confuse the two. At the moment, there's every reason to believe that only solicited packets arriving during GRC's DNS test can cause a router to crash. Unexpected (unsolicited) incoming packets will simply be dropped, no matter what payload they carry. It seems quite likely that it is the act of the router actively dealing with and digesting the incoming DNS packet that's causing trouble. Without knowing the exact nature of the trouble for each router, it's impossible to say for sure. With the exception of “evil web sites” such as we outlined in the box above, this is not panic-worthy at this time.
• If your router crashes and it is NOT already on this list:
  Given that so many defective routers were discovered by a relatively small testing group, we fully expect to discover that many more routers are crashable. Therefore, if you discover a crashable router that is not listed above, please notify us immediately using our feedback page with this link or the link below. Our best option is to bring this problem to the attention of the broader Internet community so that users can notify their router manufacturers, and those manufacturers can repeat the behavior, observe the trouble, and fix their defective firmware promptly. The more pressure that's brought to bear by their customers, the faster the manufacturers are likely to respond. So please help us to list any additional routers you discover. This will also help to protect anyone else who may be using the same router.
• If your router IS on the list and DOES NOT crash:
  We need to know that too, so that we can maintain an accurate list of currently crashable routers. Once manufacturers have repaired their firmware, we'll want to make note of that fact so that users of still-defective firmware — and then needlessly crashable routers — can update their router's firmware then use this test to verify that their router is repaired.
• If a router YOU DO NOT OWN crashes:
  As we detailed in the box above, we recognize that this trouble may be widespread enough that routers on “borrowed networks” — such as at wireless hotspots, in hotels, or other communal settings — could unfortunately and inadvertently be brought down by the use of this inherently benign DNS-based test. That is a risk created by a public test such as this, benign though it is. However, this trouble was first discovered publicly through public tests on GRC's newsgroups, so those horses have left the barn and are roaming freely. The best course of action now is to get all crashable routers repaired — especially if this trouble does extend beyond simple crashability. So please also let us know if you discover crashability on such borrowed networks. We probably won't share the information, except very generally. But it could be important to know that it is happening.

---

So now you know as much as we do about this intriguing issue.
But you may not know whether you have a crashable router.
Simply push the button below to find out...

---