Slashdot Mirror
Study: Firmware Plagued By Poor Encryption and Backdoors
itwbennett writes: The first large-scale analysis of firmware has revealed poor security practices that could present opportunities for hackers probing the Internet of Things. Researchers with Eurecom, a technology-focused graduate school in France, developed a web crawler that plucked more than 30,000 firmware images from the websites of manufacturers including Siemens, Xerox, Bosch, Philips, D-Link, Samsung, LG and Belkin. In one instance, the researchers found a Linux kernel that was 10 years out of date bundled in a recently released firmware image. They also uncovered 41 digital certificates in firmware that were self-signed and contained a private RSA encryption key and 326 instances of terms that could indicate the presence of a backdoor.
But really, who's going to hack your fridge?
It will be like the internet of humans was. Everyone will be in a gold fever. Everyone will want to join the train and everyone just HAS to get with the latest fad and have a sock drawer that has some kind of internet connection. Every petty, crappy, useless gadget will need to have some sort of internet access.
And of course the manufacturers will deliver it. Everything and their dog collar will be online.
Then the first people, I'd predict some geeks with a rather odd sense of humor, will start to piss people off by "talking" to their fridge and telling it to put some milk bones and condoms on the next shopping list, just to make your friends wonder about your ... private life should they get their hand on it.
And given time, someone will come up with a way to abuse the whole shit not just for fun but also for profit. And only THEN we'll stand there and ask why oh why security has not been a core topic right from the start because that should have been obvious... and it probably was.
It was just way cheaper to ignore it. And as long as people buy it (who will react just like the very first person in this thread, i.e. "who's going to hack your fridge?"), why bother with security? Security costs money and it's no selling point. So... to the crapper with it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The point is, who really need a connected fridge?
I can't ever see secure firmware becoming the norm given the economics of consumer goods, so I think we're going to need much better firewalls than what we see in SOHO routers currently.
Port/address level control is spectacularly insufficient when everything runs on port 80, and nobody is going to spend time mapping out specific source/destination pairs for everything (The washer can talk to the dryer. The washer can talk to my smartphone. The dryer can talk to my smartphone...)
I'd like to see something like a home-PKCS standard where:
1. Any IOT device requires a client certificate supplied by the router
2. The router drops any traffic not signed by a recognized client certificate
3. The router's signing key must be kept on a seperate USB drive, and the WAN port is locked out if the USB drive is inserted.
To set up a new device on your home network you would:
1. Insert USB key into the router (WAN port shuts down)
2. Generate a new client certificate for the new device (push button "a")
3. Install the certificate on the new device (push button "b" on router and also on device within 60 seconds, enter PIN, something automated like that)
4. Remove USB key from router (WAN port comes back up)
The router will now pass signed traffic to/from your new device. Traffic not signed? No talking to IOT devices for you.
Yeah, key management sucks, but I bet it could be fairly easily automated for home use. It would take more thought and detail than I've outlined above, but should be doable. Unfortunately, that would require that everyone agree to follow the same standard for home-PKCS, and I can't see that happening either.
Plus cheap devices would have the crypto implemented badly, plus you wouldn't be able to turn on the microwave from your office, so on and so forth.
Never mind, I give up.
If it works on the hardware in question, what's wrong with that? Sometimes being newer isn't better, it's just newer.
I don't see this as a huge problem for embedded systems.... Unless it's something like a firewall or a router that lives on the internet, then it *might* be worth looking at. If it's something like a media player or printer on your private network, who cares? (unless you are member of the tin foil hat society).
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
That's how language works. Deal with it.
Dealing with such toxic bullshit only ensures it will spread around more, even if only slightly. I'd rather point out why it's garbage.
Yes, but the entire article is low-brow drivel. I have no idea why this was the source they chose to link to (though it might go a long way toward explaining the tone and content of Slashdot's discussions these days...). I mean, check out this para:
The murky world of firmware sometimes makes it hard to figure out which products might be affected. Manufacturers often rely on tools and development kits that are widely used across industries, so the flawed firmware can end up in product sold under lots of different brands.
It's hard to know whether this 'writer' even teh English. But worse, the content is almost anti-information. What the fuck is a 'murky world'? People use generic toolkits? Sold to more than one company?! Who is this Adam Smith and where do I get his pamphlets?!?
Worse, the author[*] is implying that this is somehow an inherent flaw that might prove to be a fundamental difficulty. In truth, it's an aspect of software development that has been there since the very first computers existed. And what's more, we know how to fucking deal with it. Instead of massaging the conscience of halfwit managers, maybe he could have offered a bit of illumination concerning the decades of precedent for dealing with software quality, and explaining how these principles can (or cannot) be applied to firmware.
The thing that drives me toward despair is that the article - the whole publication - is clearly aimed at corporate decision-makers.
---------------
[*] With apologies to all real authors everywhere.
Crumb's Corollary: Never bring a knife to a bun fight.
Exactly. Consider how stupid "Movie" sounds. It started out a lot dumber sounding than "Internet of Things".
Getting a signed certificate for an embedded device may cost more than manufacturing the device... per year.
It's actually worse than that, because you don't even have a fixed target to price up. You have to consider how long a certificate needs to be valid for, the longer the more expensive but if it's not enough for the working lifetime of the device people are going to get upset. There's also the risk that a link in the certification chain could disappear, which is presumably more likely the longer the certificate lasts. For serious equipment running on corporate networks you might also have to consider letting them install their own certs backed by their own in-house CA, which introduces overheads of its own for your technical implementation. And none of this matters for devices that aren't going to be available from a machine with Internet access, because then there's no way to verify certs signed by the major public CAs anyway.
But the AC's basic point is sound. There are genuine concerns being raised here, but there's also a degree of FUD. If you see "10 year old Linux kernel" and assume "security flaw", you're the guy embedded software developers hate. That's not because they don't like criticism, it's because what really happens is they get a report back from some suit in the sales team saying a customer ran a "vulnerability scanner" and it flagged something based on a simple version check or other heuristic and that "vulnerability" must be fixed before you can get the sale. When they point out that patches have been applied for all known vulnerabilities that are relevant to their system and ask the sales guy what actual vulnerability the customer is concerned about, all they get back is crickets.
Then you get someone from management being told by the sales guy who just lost his commission that the engineering team is incompetent, and wanting to know how much it would cost to upgrade the entire system to the latest Linux kernel. Manage gets told by engineering leadership about the cost, the time required to do the work, the time required for a complete regression test, and the risk of some regressions slipping through anyway because you're giving up tried and tested code and maybe being forced to change fundamental things like what kind of filesystem you're using on your internal flash storage. Somewhere around the point where the half dozen guys who normally work on the firmware for that product now need six more guys whose only job is to watch for every relevant update to any software component in the system, integrate it, regression test the results, issue the firmware update, and brief sales and marketing because reading a changelog is too difficult, the manager usually loses interest. It's a huge amount of wasted time and effort all around, for something that in many cases was never actually a real problem in the first place.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Better idea: Give up on this stupid everything-as-to-be-on-the-Internet bullshit.
That's a good idea, but it doesn't solve the problem for devices that actually do have good reasons to be connected: streaming media players, IP-based phones/faxes, consoles with multiplayer games, and so on. Many of these devices are connected to household networks these days, both to access the Internet and to communicate for legitimate reasons with other devices also on that home network. The devices themselves or other devices on the home network may store sensitive data. They may also have sensors, and while cameras and microphones are the most obvious risks, less obvious things like accelerometers in mobile devices and GPS can also create huge security/privacy holes.
Sooner or later, we're going to have to confront the implications of connecting all of this stuff together, and we're going to need a more sophisticated strategy than "just don't do it", because a lot of the time doing it is very useful but also dangerous without proper limitations.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Unfortunately, I'm sort of being put into this area now. But this term covers so much stuff, a lot of which has existed before the term existed. The stuff that's eye rolling are bluetooth enabled devices that talk to phones, that's not really the internet of things. But something like a stoplight could be internet of things, if it reports back when a bulb has burned out; it's a thing, it is on some private network, and it is something not traditionally networked in the past. Similarly, smart meters, traffic monitors, and so forth.
The reason embedded device kernels never get updated is because the source code for them is on some SOC vendor's way out there fork of some ancient kernel that nobody with a clue actively develops for anymore.
And the vendor (say, TI) had hired a bunch of clueless interns to write the "BSP"s (old acronym from the binary blob obsessed asshats at vxworks et al) for their SOCs and the cluster of shoddily designed peripherals crowbarred into the SOC.
And those interns wrote code so toxic and broken that no sane kernel developer would ever have accept any of their garbage into any mainline kernel tree.
So there are all these embedded devices out there with kernels from the 90s, and it would take time (and expertise) that none of the vendors have (including the SOC suppliers, like TI) to merge the changes into something even remotely contemporary.
All of this because the requirements for these embedded projects (dictated by clueless PHBs) is only "linux support" not "mainline kernel support", so SOC vendors (like TI) just don't have the incentive to develop SOC peripheral driver code suitable for mainline inclusion.
Mr. Potato Head. Mr. Potato Head! Back doors are not secrets!
https://www.youtube.com/watch?...
SD Cards can be several devices, including wifi cards, so those are just as (un)safe as USB devices if the device they are connected to would be susceptible to hot plugged hardware and have the drivers available for those.
SSL/TLS is plagued with bugs due to the backward compatibility issue. Heartbleed anyone?
Self Signed shouldn't be a problem, providing the device has the pubkey for the CA that was used to self sign present.
Doing a wget on an image requires at least a minimal install like busybox on top of a linux kernel. This is currently one of the most used ways to upgrade firmwares and often there are older version of busybox, the kernel and many other applications on the device. Those are one of the big sources of devices being hacked.
As you see, it's not as simple as it seems. Apart from standard apps being outdated and not validating certificates, a lot of the custom parts of firmware aren't written with any security in mind. Things like old fashioned buffer overflows, SQL/XML injections, XSS and whatnot in user interfaces are much more common than in directly web facing websites these days. With IPv6 around the corner and the end of NAT in sight, plenty of these devices will be connected directly to the internet and we will see a large increase in "things" getting hacked once we get to that point.
I was promised a flying car. Where is my flying car?