Show us the code! You should be able to peek inside the gadgets you buy – FTC commish FTC Commissioner Terrell McSweeny supports the idea of giving people access to the source code to stuff to ensure better security and privacy in the era of the internet of things. The idea is that obvious bad bugs and poor security mechanisms can be quickly spotted and either fixed or the item stays on the store shelf. …
It is possible to look at the source when it's under the appropriate licence. Of course, very often it's only the supporting code that's under GPL or similar, but it's a start. Not that there are many people capable of making use of the availability of source, and who's to say that they're not going to use it to find the holes and exploit them.
Peer review is good, but it is not the golden solution that one might think.
No code base is perfect but I wonder if effectively open sourcing many proprietary products would not force the vendors to do real quality control and testing. Knowing your sorry code base will be mocked might do wonders for security or go out of business - deservedly.
Or it might do wonders for source code spyware obfuscation techniques.
That would be a clear flag to everyone that the company practices do not stand the light of day!
Or they could take the simple route and cheat...including bribing the enforcers...
There is a way here: Mandate that it must be possible to extract the firmware with widely available tools. Then anyone with sufficient technical competence can test if the published source can be compiled into the same firmware (which naturally implies the compilers and their versions, and any build files like Makefiles and scripts must also be published).
I believe such regulations would do wonders to embedded code quality even if very few people actually inspected the code: it would force companies to stick to proper configuration management process. Any short-cuts (such as shipping code with patches that only exist on some developers laptop) would make impossible for others to replicate the build.
"That would be a clear flag to everyone that the company practices do not stand the light of day!"
Not if it's "hidden in plain sight" using a gestalt of very subtle adjustments that are legitimate in and of themselves but when put together just so create the exploit. Remember, we're talking some of the highest stakes there are. Nothing is taboo.
"I believe such regulations would do wonders to embedded code quality even if very few people actually inspected the code: it would force companies to stick to proper configuration management process. Any short-cuts (such as shipping code with patches that only exist on some developers laptop) would make impossible for others to replicate the build."
Unless you use techniques like evil compilers or just go beyond the firmware and use state-level tricks like subverting more basic hardware chips. Eventually, you hit stuff that CAN'T be opened up due to copyrights, trade secrets, or even patents, which means you're going to have to trust SOMEONE. Only problem is, with these kinds of stakes, ANYONE can be bought (or pushed out of the way and replaced with someone pliable).
"No code base is perfect but I wonder if effectively open sourcing many proprietary products would not force the vendors to do real quality control and testing."
The source code does not have to be open-sourced to make it available for inspection; in the same way that publishing a book for people to read does not remove the author's copyright.
So propitiatory code would still be proprietary, and it would be wrong to copy and paste it into your own products (as if programmers would ever do that!).
However, arguments about open source versus proprietary aside, I can't see that making this material available would improve the quality of consumer device software much as the problem is really down to who is going to test it.
With physical products, like cars and electrical equipment, there is a testing process required by law (which is regional of course) and carried out by qualified organisations like TUV.
If the law requires similar testing for software on consumer devices, then it will cost money which will inevitably increase the price of the device; if it isn't enforced by law then consumers will buy the cheapest device and not be concerned about security until after their bank account has been emptied by hackerz.
"The problem is, the average customer is going to understand about as much of the OpenSSL library code as they do the EULA they just click through. They won't be able to work out what it does, let alone whether it has bugs or back doors in it."
And this is where guys like the readership of these esteemed pages come into it. Amongst plenty of others.
The average consumer doesn't understand how his car works either. Yet today he is able to buy a reasonable safe one.
http://boingboing.net/2016/01/25/watch-a-modern-car-utterly-cru.html.
> And this is where guys like the readership of these esteemed pages come into it. Amongst plenty of others.
In theory.
In practice, what you get is a whole lot of people shouting about how the code they run is safe because it's reviewed by millions whereas actually, none of them have reviewed it and odds are pretty high that nobody else has either.
"The average consumer doesn't understand how his car works either. Yet today he is able to buy a reasonable safe one."
To a large extent that's because of regulation. A big step forward would be a requirement for security testing for devices to get UL, CE etc. certification. Having devices calling home is another problem and it's unlikely that "home" will get tested. If, however, all models of popular freezer were to defrost or lights fail to turn on because a server had gone down or the maker had gone bust the public might come to realise that this too is something to avoid.
>The average consumer doesn't understand how his car works either. Yet today he is able to buy a reasonable safe one.
But that's because makers of unsafe cars had their arses kicked by journalists in print and lawyers in court, not because hobby car engineers said "This design is a bit unsafe, and you shouldn't do it."
The code in a lot of routers and such is under GPL already - mostly because the code in a lot of routers and such is a cobbled-together Frankenstein monster of Strange Things Found on GitHub that Mostly Work, Kind Of.
The best way to improve IoT security is to name, shame, and fine offenders. Source code is nice, but it's irrelevant without strong consumer protection.
"The best way to improve IoT security is to name, shame, and fine offenders. Source code is nice, but it's irrelevant without strong consumer protection."
What's to stop unscrupulous dealers then from seeing this coming, vanishing, and reappearing under some new cover in a game of Whack-A-Mole?
Like a Volkswagen you mean?
Actually the problematic VW models are as safe for the consumer as other cars, it is "just" the environment that suffered (more than allowed by regulations).
But note the deceitful code is the one item you cannot inspect by opening the bonnet, or by taking the car apart. Actually pretty good evidence that the possibility of 3. party examination is the only thing that keeps manufacturers honest.
Well, in the particular case of VW, some slightly more intelligent and varied testing methods would have easily uncovered any special case algorithms, and given more relevant data for comparing manufacturers. But that takes a modicum of intelligence on the testers' part.
>And this is where guys like the readership of these esteemed pages come into it. Amongst plenty of others.
There! The new coal-face. You know, for the kids. And they work cheap! What's not to like?
The only down-side I can see at the moment... smart kids are the ones who learn to lie first... Hmmmm.
That's the code under scrutiny, next is open hardware.
Especially for IoT, what is happening when we toggle a bit in an IO port? We need full chip and circuit disclosure. Full hardware disclosure has always been a problem for developers of Linux drivers. They often have to reverse engineer to discover how components work.
The source code calls up routines from libraries, libraries have to be scrutinised as well.
Does anyone get to look inside an integrated development environment?
So... all the companies who invest a ton of money building embedded device firmware are going to open up their source code, making them easy to rip off?
Errr.... no. There's a reason microcontrollers have code-protection fuses... I'm not saying they're 100% effective but (as an embedded systems guy myself) I'm certain there's absolutely zero frickin' chance of this ever happening.
Libre software provides a huge selection of wheels available for free. There is no excuse for re-inventing them. Imagine a couple of logos available for IoT makers:
Logo1 means the device may contain security flaws and spyware which are a real pain for anyone but the manufacturer to correct. Updates might be available from the manufacture until he decides it is time for you to buy a new device.
Logo2 means the device may contain security flaws and spyware which can be corrected by any competent programmer. Updates might be available from any of competent programmers paranoid enough to check the source code.
A couple of decades ago, hunting for a device that deserved Logo2 was hard work, and at best gave you a very limited choice. A decade ago, you could buy routers with openwrt. These days you can buy drones with ArduPilot and children are making their own toys out of raspberry π's. There is still life in Logo1, but a decade from now I think it will be sold to only to governments because no-one else would be that dumb.
As an example, there seem to be a bunch of manufacturers who do rather well selling routers which run open source software, such as DD-WRT. I would have thought that in areas such as home and environmental control a similar approach would also pay off.
It takes a certain confidence to be up-front and open. While this is not of itself a guarantee of quality, it goes some way towards it.
Seems to me that most MCU code isn't valuable IP at all, just some simple control logic and perhaps some libraries for USB, wifi, etc. When that's the case, why waste time locking down the code?
Ok, you might be reliant on 3rd-party proprietary libs, or worried about patent trolls scanning your code for reasons to sue you, or covering up something dishonest (like VW), or bound by [moronic] regulations to prevent users from modifying safety/regulatory controls, or following the time-honored tradition of milking customers with exorbitant fees for simple repairs and modifications.
But I think embedded will be flooded with new developers who don't give a damn about any of that, who see a competitive advantage in transparency, moddability, geeky loyal customers with IT $$$ to burn, and leveraging [often crappy, yes] open-source libs to reduce development costs... FWIW.
I had another comment to the Commissioner. But about 20 minutes of going around in circles, I appears the agency only allows mere citizens to comment on a specific list of current business. So if they are not already working on something, you can't suggest anything. Filed under Open Government.
I did finally find a staff list hidden in an obscure corner. I have provided the online information for Commissioner Mc Sweeny below. It would appear that the FTC is not aware of email or its position in modern business. Like she would take my call. Of if a call would be a suitable mechanism for explaining a moderately complicated point.
McSweeny, Terrell .......................... (202) 326-2606 ................ H-528A ............. 0105 ......... H-526
I did, of course, think about ringing up Obama to ask him to have them provide better public contact information. Nah. At least he has an email address.
"Both agreed there needed to be more dialogue to find a solution that worked for everyone. "
Given that some WANT to data mine and others want to block said mining, that puts them in direct, exclusive competition. It's opponents such as these that bring up the phrase, "You can't please everyone."
... but I know if it is found to suffer from a serious safety design flaw I am, to a greater or lesser extent, protected (viz. large numbers of recalls we have seen).
The problem with a closed source device such as a router, with a massive security hole in it, is that it seems to to fall between two stools: there's very little the user can do check that it is safe, or keep it so, and I'm not aware of anyone who has tried to enforce supplier or manufacturer liability. Not even in the UK, where I'm guessing the Sale of Goods Act should allow you to at least return the device to the retailer.
Perhaps the information required to manage such a device oneself (firmware unlock keys, source code, etc.) should be placed in escrow with consumer organisations so that it can be released if the manufacturer goes under (or just stops supplying updates). But I still think that the detection of certain malfeatures, such as a hardcoded backdoor, should be a matter of manufacturer liability.
Can we see the source code to the voting/counting machines yet? Some of them *still* cannot be audited, and others send their vote count to central counters by networks. How can we trust the vote for a box that cannot be audited.
To ensure the vote is secure, we need proper auditing of those machines and their code, and proper encryption for the connections. Look at Juniper Routers, look at the backdoor that was placed in that code, consider all the effort that was put into that backdoor, now imagine the same in the voting machines and counting machines! How do we know they don't contain and AMX-switchboard style backdoor SSH port?
It's tempting to think that everyone is law abiding, and nobody would rig elections in which $2 billion is spent trying to win, in the US alone. Tempting but stupid, $2 billion is a lot of motive.
Imagine a backdoor in the communications of US votes from voting machines, that could be exploited by foreign hackers to rig elections? Would they do it? Of course they would!
Imagine an out of control domestic bad actor, a rogue civil servant, a Putin figure, a man who thinks Parliament is there to serve him, not him to serve Parliament? Would they rig an election? Of course they would.
Encryption does *far* more than protect privacy. It protects basic data security, commercial, financial, business secrets, designs, and even votes. It protects them from domestic and foreign bad actors.
The problem is that a resourceful adversary can go beyond the code, to the chips where you eventually run afoul of trade secrets and patent protection. They can subvert hardware and hide it within the physical structure of the voting machines, and they can act outside the encryption envelope, defeating even a custom compile and making it exceedingly difficult to detect, even with an X-ray. At some point, you're going to have to trust SOMEONE, and when a state with a big purse (and probably backed up by big boots) comes in, it's hard to say if ANYONE is safe.
Just remind me was Open SSL proprietary code or was it open?
The average guy on the street doesn't give a crap about how well written the code is, how many security flaws it has or how much private information it leaks... If its shiny he will buy it.
If apple announced tommorow that it's next phone would track your every bowel movement and had an open api so that any one could query that data it would STILL sell millions.
The problem isn't just shit code its that the user base don't care.
You also need the ability to replace the compiled code that comes on your device with code that you have inspected and compiled. The point is that how can you be sure that the code running in the device corresponds to the source code that you have been given ? - Especially if the likes of NSA/GCHQ are around with laws that can compel vendors to silently subvert their own products.
The ability to extract the installed code and check that you can build something bit wise identical would also be good.
OK: it will not be for everyone (recompiling) but being able to reinstall firmware should not be too hard.
Also: knowing that someone has verified the manufacturer's binaries will reassure the many for who reinstalling is too hard/much-effort.
If this were to ever happen, then NSA/GCHQ will set up organisations to do the recompiling/checking but lie about the results and so give a false sense of security; so it is not as easy as you might imagine.
Start making companies liable for the crap they produce and you will quickly find the insurance companies that cover them demanding a "UL" for their code. No UL approval, no coverage.
UL was a boon for consumer safety, and something similar is needed again.
Nothing can really test for resistance to sabotage for the simple reason there's always an ultimate saboteur that no system can defeat: the one who PUT IN the anti-sabotage system in the first place. Even if you attempt to use multiple layers, you can just replace the single saboteur with a team: each member having put up one of the layers. And given the stakes involved in governmental elections, you can't count out such a scenario.
Am I the only one in the world to have reached these glaringly obvious conclusions:
That devices in my home, the so-called "internet of things" (and how I loathe the term), have no business whatever being connected directly to the public Internet?
That the only network to which they need be connected leads to my own computer at home?
That if they communicate with the outside world at all it is to be directly from that computer, through VPN, directly to my handset's computer, and nowhere else?
Seriously, I can't be the only one of seven billion people who is thinking, "This is like listening to public debate over mounting a control panel and monitors for one's home on a light pole on the nearest street corner. What sane individual would do this, and why?"
I can understand wanting these devices to be reliable and safe, yet all of the debate seems to revolve around making them reliable, and safe *to connect to the public network*.
Reject that patently stupid idea and the rest of the problem is vastly simplified.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
