Hacker News new | past | comments | ask | show | jobs | submit login

While the effects of a bug like this will be mostly short lived on desktop systems where patch management is usually pretty good in linux, the effects on embedded systems can reverberate for years. Look around your house or office and consider how many devices like TVs, dvd players, DVRs, broadband routers, access control devices, industrial control systems and the like run linux and have a usb port. Many of these will have a broad range of usb device drivers built into the kernel (even if they're not used) and often use a network port or wireless chip by design. Very few of these will have reasonable update policies, and even fewer of them will move to a new kernel or backport a vulnerable driver. Many rely on custom drivers that would need to be tested all over again to qualify a new kernel and have busy and relatively inexperienced staff on them.

The ability to use these devices as sniffers, network backdoors and MITM attackers is very much there. Most of the time devices like this are more less invisible, very few consumers will be watching their network traffic. Worse, even when an intrusion is detected on a network and all traditional computing devices are wiped or replaced few people will think to replace their blu-ray.

Just another brick in the pervasive insecurity wall.




Look around your house or office and consider how many devices like TVs, dvd players, DVRs, broadband routers, access control devices, industrial control systems and the like run linux and have a usb port.

I have a few devices that are running a Linux kernel under the hood (TV, maybe DVR, maybe router but it has firmware updates, maybe BluRay but it also has firmware updates) but none of them have a USB port.

Many of these will have a broad range of usb device drivers built into the kernel (even if they're not used)

Are you an embedded developer? Seems strange to include unnecessary drivers on an embedded device.

Also I wonder how common something like ProPolice would be on embedded Linux devices.


Looking around my house, embedded devices with USB: Toshiba DVD, Sony Blu-ray, D-link Boxee box, Sharp TV (labeled service), Sharp Blu-ray, ASUS wireless N router, Cisco PIX firewall (built with BSD afaik), Chumby alarm clock, Samsung Android phone, LG Android phone (Android not running in host mode though, afaik), LG feature phone (probably not linux?), and a TiVo in a box in the attic.

I'm not an embedded developer. I agree these won't be built with the full range of default kernel drivers. Perhaps when I said a "broad range" I should have said something like "quite a few". Never the less, most of these devices will be built with a variety of usb storage drivers since that's the purpose of the usb port. I know for a fact that the Sony Blu-ray contains an impressive number of wireless lan drivers in addition to the storage drivers. The Chumby contains a variety including serial and wired lan. The ASUS router supports many mass storage options as well as parallel and serial printer support. The boxee box is reported to even include mouse and keyboard support as well as mass storage support, and I'd wager they left a lot more than that on.

Which isn't to say that any of these devices have this driver built in, I simply don't know. My point was more to raise the issue of what happens when a bug is discovered that affects one or more of these devices - many of which have a pretty large local attack surface. The answer is generally it stays vulnerable until you replace it, with the less similar it is to a PC the more likely that is to be true.

I wouldn't bet on many of these devices having stack smashing protection turned on. Look at how few linux distros have it turned on by default.


Note that not all buffer overflows are remotely exploitable though. Many of them only happen if you are able to run a program or in this case plug in a malicious device.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: