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.
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".
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???
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.
...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.
Nobody finds vulnerabilities by reading source or machine code.
You fuzzy it until it crashes, then you analyze the core dump - no source code needed.
You don't care what it does, or where it crashes, you care what input makes it crash, where the input ends up in memory, and what you can do placing shellcode there.
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.
After the Cherokee hacking debacle, a few people at Jeep/Chrysler *need* to feel bad.
You have misunderstood the implication. It is "closed source" => "insecure". It is not "open source" => "secure". These are two different things. You can never (in practice and under usual economic border conditions) make closed source secure. On the other hand, while you must make it open in order for it to be possibly secure, you must do other things in addition.
Really, get a grip on basic logic and stop claiming bullshit.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Just wait till we have fully autonomous cars
Have any of you ever decompiled machine code and from that tried to figure out how it worked?
Yes.
It's damned difficult
Full reverse engineering is difficult. But a hacker doesn't need to do that. He is just looking for potential stack overflows, buffer overruns, weak user authentication code, etc. If they exist, those are easy to find, using a disassembler and a VM.
In my opinion it's going to be tougher all around if the firmware/software is closed-source
Security through obscurity doesn't work. Open source is no guarantee of perfect security, but it has a better track record than closed source.
Not only does releasing the source code open you up to hacks, but it also makes it trivially easy for someone to modify the code, adding backdoors, exploits, etc and recompile it. A simple replacement of the original code with the 'improved' codes means you have been completely pwned.
In other words, replacing the legitimate module with a trojan one.
With certain exceptions, it's very hard even allowing for the lax attention to security that is so prevalent today for an outside agent to swap out an arbitrary app in someone's shop for a trojan. And if you're getting pre-built open-source binaries from a reputable repository, that repository typically carries checksums that are intended to ensure that the module you download is the one that they built. Also, the people who built the repository don't accept arbitrary source changes from just anyone.
On the other hand, disassembling and hacking closed-source binaries isn't nearly as hard as it's made out to be. I speak from experience, both on my own part and on the part of other people I know. Although if that's not good enough, I'll simply point you to the innumerable exploits made on Windows, Flash, and other critical system resources despite the fact that few, if any of the corrupted modules had publicly-visible source code.
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.
Vulnerabilities are easier to find in open code, but they are also easier to fix.
In open code, both blackhat and whitehat hackers will be looking at the code, with closed source code whitehats cannot look but blackhats often have illegal access to closed source code.
And yes, closed source vendors will often just try to hide vulnerabilities - but that simply doesn't work, they will be found anyway. Just look at the number of security advisories and exploits in closed source software.
Not to mention unsupported closed source, where there's no way to fix the vulnerabilities - leaving users with a useless product.
And of course, most security centric products out there (e.g. firewalls) are based on open source code, either bsd or linux.
I'd pick open over closed any day...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It has a better track record than closed source.... hmm, not sure I believe that. Certainly some of the more recent high profile issues were in open source software.
I think the real problem is not closed source == insecure, open source == maybe secure. In theory, either can be made secure through audits (probably not in practice), however the only people who can fully audit closed source software is the owner of the code.
The issue is actually one of trust. Microsoft can audit their software to death and they can, at least theoretically, make it secure. The problem is that, when they say they have audited their software and it is fine, you can't be certain they are telling the truth.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
And who cares? /sarcasm Because no-one ever clones physical hardware
Whether a product is open or closed is irrelevant. It won't stop people from cloning it.
--
Only an self-entitled idiot wants to rob Paul to pay Peter
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.
Full reverse engineering is difficult. But a hacker doesn't need to do that. He is just looking for potential stack overflows, buffer overruns, weak user authentication code, etc. If they exist, those are easy to find, using a disassembler and a VM.
Some of what you say is true. Stack buffer overflows are trivial to spot in both source and binary if they're local. If they're non-local, then you need to do some interprocedural analysis, but it's slightly easier to spot the root cause (someone passes a pointer to something that's on the stack) in source analysis. Heap buffer overflows are really hard to automatically detect with anything short of symbolic execution, though some heuristics can find likely places to look (are you doing pointer arithmetic without a bounds check?) and these are relatively easy in both compiled and binary, though going back and understanding what the invariants about the size are, which can elide the need for bounds checks is usually easier in source form.
Higher-level vulnerabilities in use of crypto, failure to correctly handle errors, and so on are all much easier to find in source form.
I am TheRaven on Soylent News
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.
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.
**Anything** can be used, or mis-used. Film at 11.
What you're describing isn't new.
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.
You can never (in practice and under usual economic border conditions) make closed source secure. On the other hand, while you must make it open in order for it to be possibly secure, you must do other things in addition.
Really, get a grip on basic logic and stop claiming bullshit.
Sorry, but I've spent WAY too much time over the last year or two dealing with huge vulnerabilities in open source to believe any of the stuff you are spouting. OpenSSL alone (Heartbleed and several other critical flaws) has cost me a huge amount of time, and that's one of those open source security related products that theoretically will attract the most auditing attention and should be "secure due to the number of eyeballs theoretically always auditing it". Yet despite being open, it has not become secure, or even close to secure.
On my web hosting team (which hosts thousands of websites and uses both Linux and Windows), we have spent far less time over the last couple of years patching or dealing with closed source critical Windows vulnerabilities than we have spent on various open source critical vulnerabilities. Things always go in cycles, and probably we'll have a year here soon where Windows racks up the most major headaches again, but the point is, there's no way you can claim you can "never make closed source secure" but that "making it open could make it possibly secure if you take some additional steps". That's all nonsense. Neither model is any better than the other when it comes to security, and neither can ever be made totally secure, especially as complexity continues to rise.
Open source has its benefits, but security has never been one of them, as recent history demonstrates. It just seemed that way for a while when it had less of an install base. Now that everyone, even commercial products, are embedding open source packages like OpenSSL into them, the target base is easily big enough to invite the black hat attention, and we see that things are basically the same as they are for closed source packages with a large install base.
PS - The Linux foundation is working with researchers to make a huge push to audit OpenSSL to look for issues. This, again, proves things are the same between open and closed source. Windows gets repeatedly, badly owned, and Bill Gates writes his secure computing memo directing a huge amount of resources at security training and auditing, and things do actually improve (though they are never perfect). Now, OpenSSL gets owned, someone directs huge resources at it, and it will probably improve, in the same way and for the same reasons as closed source. Put the resources behind it, you can improve security, but without a dedicated, directed push, things slide in both models because programmers, whether in closed or open shops, are in general are fairly lazy and like new shiny things, and don't really enjoy doing mundane boring tasks like auditing old code.
Beware of bugs in the above code; I have only proved it correct, not tried it.
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.
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?"