Slashdot Mirror
Open Source Code Isn't a Warranty (opensource.com)
An anonymous reader writes: Automotive software issues such as the Jeep hack and Volkswagen cheating on emissions tests have made headlines this year, which means the public is thinking about software in cars like never before. Some experts have argued that mandating that such software be open source is a solution to the problem. In an article on Opensource.com, Ben Cotton writes that although there are definite benefits to public scrutiny of the software, code visibility alone is no guarantee. It's an important thing to bear in mind, because "Open, therefore secure" is an easy straw man to knock down.
I think the better word choice is "guarantee" instead of "warranty" for the headline.
"Never give up, for that is just the time and place when the tide will change." -Harriet Beecher Stowe ^_^
"Open == Secure" Or "Open == More Secure than Closed"?
These are very different claims.
TFS invented the idea, then attacked it.
Somehow they shift the focus from catching cheaters to "security".
And again. There is no such thing as guarantee/warranty in security. And there is no such thing as security in closed source software.
The more insight into code, the less likely companies will do what VW did because its open to public scrutiny. I think we should be focusing on the "Open, therefore open to scrutiny" than the misconception of "Open, therefore secure".
Have any of you ever decompiled machine code and from that tried to figure out how it worked? It's damned difficult, because what functions, variables, registers, and ports are referred to as in the source code, and very much so the programmers' comments, tell you most of what you need to know. Of course I'm not saying that truly talented programmers can't do it, but it's much more difficult. If you've got the source code, fully (hopefully!) commented, a talented hacker (said in the malicious sense of the word, mind you) can find the vulnerabilities relatively quickly, and devise a way to exploit them. I'm not necessarily advocating for closed-source software, but having something as critical as the firmware/software running your vehicle as all open-source could really turn things into a worse race against time between the black hats who want to hijack your vehicle, and the white hats who want to find the vulnerabilities and fix them. In my opinion it's going to be tougher all around if the firmware/software is closed-source, making that race slower. To be fair though, with closed-source, it's easier for manufacturers to just hide the vulnerabilities instead of spending the money required to fix them; you can thank their lawyers and their risk/benefit calculations for that ('It's cheaper to pay off the lawsuits than to fix the actual problem' sort of thinking).
Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
or maybe...
Open, therefore not illegal to review?
A straw man attack consists of refuting an argument which no one is making. It is not a generic term for false arguments. "Open, therefore secure" may be false, but it is not a straw man.
OTOH, since no one is making the case that open source is secure by default, the last line does look like a straw man. (But it's not really.)
Lemon curry???
The Jeep hack is the kind of thing you get in open source projects where there's a 'code of conduct' preventing Linus from telling them that the idea is really fscking stupid because that might cause feelbads.
This software absolutely should be open-source. The OpenSSL issue is an example of why open source is superior, even though it's obviously no guarantee you'll have no problems: when the vulnerability was discovered, it was fixed very quickly.
The problem with proprietary software is that there's no way to actually fix it, unless the vendor wants to. When the OpenSSL problem was found, a fix was made and rolled out, and everyone was able to install it.
When a vulnerability is found on your 5-year-old Jeep and publicized, what do you do when Jeep decides they don't feel like fixing it for you? Guess what, you're screwed! Now hackers can take control of your vehicle and drive you off a cliff, and there's nothing you can do about it because the vendor doesn't care and there's no way to upgrade the software yourself.
This kind of thing shows exactly why Stallman had the right idea about "TiVOization". Not only is it important that you can have access to the source code for your device so that you can modify or fix the code, but it's equally important that you can actually get the fix *onto* the device so you can use it. Otherwise you're at the vendor's mercy.
Luckily cars are so heavily regulated that my Jeep scenario above is unlikely, simply because of government regulation and also lawsuits, but this isn't true of other places where physical safety isn't a factor. With the current "IoT" push to connect every little device to the internet, having the firmware open-source is more important than ever because of the security issues, combined with the **proven** tendency of vendors to abandon support after a few months.
If it is open enough to satisfy users it will be too open to satisfy governments. Governments want to make sure that users aren't modifying the code to do things like cheat on emissions, increase performance beyond safety measures (remove any governors), etc. Hobbyists want to do those things (not all of them, but some). If it is open enough to allow modification, it won't be approved by governments.
...but it admits to the possibilities that a) an enterprising white hat (or black hat) CAN inspect the code for integrity, logical structure, and fitness for purpose, and b) if a black hat can (or could, or does) exploit the code, a white hat can improve the code to close that security breach. Closed Source limits the potential white hats to those the intellectual property owner chooses...and they have little economic incentive to choose well or comprehensively, or ask for expensive comprehensive inspection of the code to find potential flaws, because it will increase their costs.
Another stupid comment by people that do not understand the difference between a "necessary condition" and a "sufficient condition".
Open-sourcing the software/firmware in question is a necessary thing. That means it must be done. It is not a sufficient condition. That means it is not enough. It still must be done, but other things must be done in addition to get the desired outcome.
It is almost as if people do not understand basic logic anymore. No surprise so many things in the IT space get screwed up badly these days.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Okay so this is something I've been wondering since the whole scandal with VW blew up and it was revealed that their software could identify testing conditions. Let's say the car does this through complicated ANN's where the entire set of stimuli and responses are encoded as learned behavior in nothing more than the configuration of a few vectors in memory. The code itself is for a complex machine, to be sure, but the source code only tells half the story. The engineers building the cars then train the machine to act a certain way outside of the law.
Source code analysis would tell us that this stuff is POSSIBLE, and presumably we would then insist on knowing the calibration data. But what good would a hundred million floating point variables do anybody? This is a grey area with far-from-simple solutions.
you're too cheap to even hire an H1B.
Just wait till we have fully autonomous cars
The comments made by people like ESR didn't stopped being valid because somebody says they are publishing the source and putting something else in there. Microsoft does it to governments and its plain bullshit.
What you need to understand is that if what you need is security, not only having the source is enought but having the ability to do deterministic builds from scratch, and install that build you made on your hardware.
The other thing people miss is also to include the firmware for peripherials. Those are easyer to hack than a hole OS and are being ignore by anyone. You just need to program an ESP8266 like an arduino to get that if that is possible in any of the hardware in your box, it doesn't matter the OS or software protection you have on.
Open source vehicle code isn't about preventing vulnerabilities, it's about allowing owners to fix issues that the manufacturer does not fix. In the US an auto manufacturer is only required to perform recalls for 10 years after the initial sale of a vehicle. There are plenty of well maintained vehicles over 10 years old but if a new vulnerability were discovered in the software then the owner would have no way to get it fixed. If the software were open source then it would likely be fixed by someone other than the manufacturer and the owner could take the car to any shop to have the patch installed. Perhaps there needs to be a regulation requiring auto manufacturers to open source all of the code if they have not fixed a vulnerability within a set period of time. This would allow them to fix it and protect their code or force them to let someone else fix it if they don't want to do it.
But it allows you to create guarantee because you can audit it.
Only if you compile it yourself and have the actually ability to audit the software. (and you have a compiler you trust)
For closed source software, you have to trust the supplier and their guarantee.
This is true of most open source software as well with the exceptions mentioned above. If Mozilla provided a warranty for firefox, I have no actual ability to audit their software and even if I did, such an audit would be meaningless unless I compiled the software myself. For any non-trivial piece of open source software, this means that functionally there is little difference between trusting closed or open source software. The only real difference is that with open source I can hope that someone else might figure out that there is a problem but that is just a hope, not a certainty.
Do you trust yourself or your proprietary software vendor more?
Irrelevant since I am not a programmer. And even if I was it is not as if I could realistically audit all the source code for a project the size of the linux kernel. Don't get me wrong I think there are great advantages to open source software but this particular one is hugely overblown.
First of all the Jeep hack and the Volkswagen emissions cheating aren't anywhere near the same. Bugs in code and code that is not written with security in mind creates hacking opportunities and constitutes, at most, negligence that might lead to death. Willfully writing code to circumvent emissions standards so you can sell more cars is out-and-out fraud. The only commonality I see with the two cases is that more objective eyes on the code would have the possibility of detecting the security faux pas as well as the code that messed with engine emissions; granted the emissions code would be more difficult to identify without knowledge of the full system including the emission targets and how they are tested.
Second, there's no guarantee of much of anything in life, that doesn't mean you don't try to do something open if even the potential benefits are minimal.
Finally, that whole post wreaks of troll!
Over a decade ago it was common knowledge in the OSS community that "With Many Eyeballs, All Bugs Are Shallow."
The original source of the meme, or maybe what led to its popularity, is probably The Cathedral and the Bazaar.
People argued that open-source software was more secure because self-interested users would be reviewing code or happen upon bugs and fix them themselves. Or that users were programmers who could write good bug reports. It was always a mistake to be complacent and rest assured that code auditors were working on things because they were open, but memes. I naively believed it in my youth.
This meme was fairly common. If it wasn't for some embarrassing, high-profile FOSS bugs, like in bash and openssl, people might still be defending it.
From the summary:
"It's an important thing to bear in mind, because \"Open, therefore secure\" is an easy straw man to knock down."
So "timothy" has proposed a strawman argument, mentioned it was a strawman argument, and then knocked it down himself. Nice work!
Why are we blaming the company for cheating? When you create a government agency or state agency to review and certify. Its seems to me the problem was in not vetting the software for engine management properly to begin with. Clearly what happened with Volkswagen and possibly others is that Volkswagen knew the process and simply found a way around it. How is it no vehicle emission agency considered this potential end around? Its not that we need a open standard of software for engine management. Its that the agencies put in charge of certifications need to include vetting the software. Apparently something they have not done or done poorly. I suspect they simply took for granted the auto maker was doing right so they never bothered to check. Let's also assume and rightly so that every car engine releases more emissions in real world driving then in a dyno like test in a garage not moving. Maybe what we need to do is change the standard and make emission certification a more real world test. I find it interesting that the Volkswagen issues with diesels gets more negative press then a GM faulty ignition that killed over 100 people.
Only days ago open source Chrome code was exploited to send users malware so it has that downside http://it.slashdot.org/story/1...
When we considered open source in the vehicle 15 years ago, the lawyers clobbered it as they company likes putting the supplier on the hook for recalls.
In any case, the company is responsible for defects in the open source. You cannot wave away the rights of anyone you plow into, regardless of the cleverness of any disclaimers.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
You still have to solve the distribution/update mechanism security and QA problems.
How do you make sure only authorized roms get flashed to your vehicle? How do you guarantee your vehicle is even using that rom, and not some other copy? (open hardware also?)
An entire pk infrastructure or other security ecosystem must exist to get signed/trusted roms, and delivered timely to people. 99% of the population is not going to pay attention and regularly flash their car's rom. Even microsoft, android phones, and apple/iOS can't get people to always update their equipment, let alone not introduce new bugs in the process.
No one wants to wake up on car-patch-tuesday morning to find their car's latest rom that downloaded overnight now won't start and they can't go to work...
it's equally important that you can actually get the fix *onto* the device
Don't even get me started on how I can't flash vanilla Android onto the Samsung Galaxy S4 that I own because they locked down the bootloader. Moved onto a Nexus device and will never give my money to Samsung as long as they continue with that shit.
Its been made clear (usually by people who work for very large close-source companies), that having open source software --that is, software where access to the source code is openly available for 3rd party audit-- is no guarantee of code quality. And that's true. Is the author a kid or a PhD.? You don't know. Although to be completely fair, if you are writing software that does extreme things, it won't work at all unless you have a thorough understanding of how to write software, and how software interacts with hardware. At some point, you must have studied. Now there might be bugs in OSS (in fact its highly likely that you will find one given enough time and skill). So it can be audited and fixed. So how is this different from closed source software? We know there is no guarantee with closed source software. Pundits who will want to argue my last sentence need a wake up call. When (or if they were to ) READ THE PROPRIETARY LICENSE that the software came with, it usually mentions the words "AS IS". As is means what you bought is what you get. Now they will pick nits with my last sentence too. And the truth is that very large (yes, the very very large one you are thinking about, that software company) wrote a web browser. They destroyed the secondary market for web browsers for a while, then did literally nothing for 10 years. Then competition came back, and they had to try and compete again. But they had disbanded the team, people had left the company, and equipment had been re-purposed. There is no guarantee of code quality in closed source software either, 10 year old bugs clearly were not being fixed, new sales of 10 year old software with 0 improvement, --AND NO WAY TO DO A 3RD PARTY AUDIT!. That's the difference. Another analogy: with open source you might not be able to fix the engine in your car, but you do get a hood release and you can take the full manual to someone who knows (any mechanic you like). With closed source software, the hood is welded shut. You go to the people who sold it to you only, they charge whatever they feel like (usually that means bush prices), and they can decide to fix or not at their discretion. You are stick with it. Now you know the difference.
Since when did any software, open or otherwise, come with a warranty or guarantee of any kind?
Software licenses are notorious for claiming practically nothing about the effectiveness of the software they cover. Typically they're full of legalese that goes to great length at how the software is offered with no warranty of any kind, not even an implied warranty or merchantability (whatever that means) or fitness for any particular purpose, blah blah blah.
If it weren't for deadlines, nothing would be late.
But what do you need with a warranty when you made it and it is entirely yours? When you build a shelf for the home, do you expect a warranty? No. Is this a "no shit, sherlock, why the hell would I want one?" moment?
If the code can be modified and changed by you, then if you change it, you have no warranty other than the one you negotiate with yourself.
If the code CAN'T be modified and changed by you, then you can't do anything about changing it, and therefore the one preventing this is actively opposing your safety. It's a positive act, one they took, and actions and responsibilities for those actions, are a warranty.
As long as its closed source, there is simply no way to check.
If it's open source, it may be checked, also there is no guarantee that this will really happen at all.
But as long, as closed source can never achieve that same goal of proofability, closed source is like driving west to go north .. it just never ever will hit the goal. With open source on the other side, you are at least having an angle in the right direction.
Because security failures happen to those you trust, and closed source means you have to trust the vendor. So you get no choice there. Open source, you get to trust yourself, or if you cannot do that, find someone you DO trust.
Nice straw man to a straw man because no one is saying "Open, therefore secure." They are saying having more eye balls on the code helps find problems.
Fucking American idiots. Unbelievable.
Open is not bug free, but you can look for the bugs.
Open is not trojan free, but you can look for the trojans.
Open is not robust, but you can look for weaknesses.
Open is not secure, but you can look for the weaknesses.
Open is not functionally guaranteed, but you can look at the behavior.
Open is open. It is nothing more. Anyone expecting it to be more than open does not understand what open is.
What warranty do the Closed Source companies give to the users of the software?
It's not THE solution all by itself, but open source is an essential part of the solution.
A GPL-v3 style anti-tivoization clause is necessary too, otherwise you can't verify that the published source is actually what is running on the device.
You need the complete set of sources to get a base foundation in designing a secure system. It in and of itself doesn't provide any security. However without it you're guaranteed to be unable to properly secure it because *you don't control it*. All the while the people writing exploits *can still do so* with or without the sources. When you have the code you at least have the opportunity to fix it.
Obviously, a machine code binary is a form of open source, just not a very useful one. The most open state of a software project is when any outside contributor has exactly same access to knowledge as founder/CEO, including personal one on one attention from key developers. This is impractical in practice. The best we can hope for is that all machine-readable materials are equally available to all contributors.
and then we get into the discussion that the source provided might not be the same as what is actually running in your ECU.
who's going to check those things?
On a long enough timeline, the survival rate for everyone drops to zero.
If it's open source and hardware, you can always fix it yourself. That's the kind of guarantee I want.
Fallacy: Open source has more eyes and security
All open source means is that more people "could" look at the code. It doesn't ensure more people "do" look at the code.
Also, "more eyes" are useless for adding security if those eyes have no security knowledge. To make open source more security, you need more security skilled eyes to look at it and find and remove security holes.
Also, there is an argument that secure is a a bool value. You are either secure or your not. If you have 1 remote hole you are just as vulnerable as if you have 10 remote holes. You either have 0 remote holes or you are insecure. However, there is no way to prove 0 remote holes. You can prove a security hole exists, but you can't prove 0 security holes exist because not all possibly security holes are even known.
The media decides what to write about, and therefore what the public will think about. The public doesn't say, "Hey, media, I heard VW did something bad, would you please write about it?"