Slashdot Mirror
Intel-Powered Broadband Modems Highly Vulnerable To DoS Attack (dslreports.com)
"It's being reported by users from the DSLReports forum that the Puma 6 Intel cable modem variants are highly susceptible to a very low-bandwidth denial-of-service attack," writes Slashdot reader Idisagree. The Register reports:
Effectively, if there's someone you don't like, and they are one of thousands upon thousands of people using a Puma 6-powered home gateway, and you know their public IP address, you can kick them off the internet, we're told... According to one engineer...the flaw would be "trivial" to exploit in the wild, and would effectively render a targeted box useless for the duration of the attack... "It can be exploited remotely, and there is no way to mitigate the issue."
This is particularly frustrating for Puma 6 modem owners because the boxes are pitched as gigabit broadband gateways: the devices can be potentially choked and knocked out simply by receiving traffic that's a fraction of the bandwidth their owners are paying for... The Puma 6 chipset is used in a number of ISP-branded cable modems, including some Xfinity boxes supplied by Comcast in the US and the latest Virgin Media hubs in the UK.
The original submission also notes there's already a class action lawsuit over the performance of cable modems with Intel's Puma 6 chipset, and adds "It would appear the Atom chip was never going to live up to the task it was designed for."
This is particularly frustrating for Puma 6 modem owners because the boxes are pitched as gigabit broadband gateways: the devices can be potentially choked and knocked out simply by receiving traffic that's a fraction of the bandwidth their owners are paying for... The Puma 6 chipset is used in a number of ISP-branded cable modems, including some Xfinity boxes supplied by Comcast in the US and the latest Virgin Media hubs in the UK.
The original submission also notes there's already a class action lawsuit over the performance of cable modems with Intel's Puma 6 chipset, and adds "It would appear the Atom chip was never going to live up to the task it was designed for."
It's not the Atom cores, it's the bolted on NAT accelerator with 2048 max entries + 30s timeout for UDP "connections" + firmware too stupid to fall back to software NAT when the hardware table is full.
Puma 6 chipset has been used in modems/gateways since 2012. Here is a partial list of potentially impacted products:
Arris SB6190
Arris TG1672G
Arris TM1602
Super Hub 3 (Arris TG2492LG) (commonly - virgin media)
Hitron CGN3 / CDA / CGNV series modems:
Hitron CDA-32372
Hitron CDE-32372
Hitron CDA3-35
Hitron CGNV4
Hitron CGNM-3552 (commonly - Rogers)
Hitron CGN3 (eg CGN3-ACSMR) 2013 link
Hitron CGNM-2250 (commonly - Shaw)
Linksys CM3024
Linksys CM3016
TP-Link CR7000
Netgear AC1750 C6300 AC1900
Netgear CM700
Telstra Gateway Max (Netgear AC1900 / C6300) (Australia) 2014 link.
Cisco DPC3848V (eg High latency/ping to Shaw router? )
Cisco DPC3941B / DPC3941T (commonly - Comcast Xfinity XB3)
Cisco DPC3939
Compal CH7465-LG / Arris TG2492LG (commonly - Virgin Media Hub 3)
Samsung "Home Media Server"
There is apparently a packet spray pattern that causes the CableModem (CM) portion of the Puma 6 to reboot. (likely segfault) The CM on a puma 6 is run by an ARM Cpu (not the x86 atom), the problem is with broken hardware optimization -- specifically the overflow handling on a fairly small table (2032 entry) likely built of CAM (content addressable memory) intended to accelerate external/internal mappings. That table has entries inserted when any packet arrives with a new address. Spew enough packets from enough different addresses and the table overflows -- that overflow requires (slow) processing to handle.
Disabling the accelerator caps bandwidth to ~60Mbps, and the DoS attack is mitigated.
But the fact that there is a pattern of (external) packets that *crashes* the CM indicates a potential vulnerability in the CM firmware that would allow a complete takeover of the CM OS.
That would be a global disaster.
One proposed mitigation is to use software mapping for packets from external sources and only add mappings to that small table for packets from the LAN side (not the WAN). This would probably have minimal impact for most -- capping speeds to 60Mbps on connections until a packet originating from the LAN side of things has gone through the device.
But a hostile (and clever enough) hacker may still be able to trick the device into crashing and exposing it to takeover if they can run software on both sides of the device (LAN and WAN) attacking it from both simultaneously.
The Puma 6 is a bit of a debacle -- it may very well have to be recalled.
Ian Ameline