Open Source Code Isn't a Warranty (opensource.com) 214
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.
Guarantee (Score:4, Insightful)
I think the better word choice is "guarantee" instead of "warranty" for the headline.
Re:Guarantee (Score:5, Insightful)
I think the better word choice is "guarantee" instead of "warranty" for the headline.
Also, "visible source" would be better than "open source". Unless they actually mean that anyone should be able to copy, modify, fork, and redistribute.
Re: (Score:2)
Re: (Score:2)
You know what's in your post?
More than meets the eye.
Re: (Score:3, Interesting)
But it allows you to create guarantee because you can audit it.
For closed source software, you have to trust the supplier and their guarantee.
Do you trust yourself or your proprietary software vendor more? It can be a hard choice in some situations.
Re:Guarantee (Score:4, Insightful)
Do you trust yourself or your proprietary software vendor more? It can be a hard choice in some situations.
It's a Hobson's choice for me, as I don't have the time or resources to verify the software of my car, let alone those that I rent.
Re:Guarantee (Score:4, Insightful)
I don't have the time or resources to verify the software of my car
I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.
Re:Guarantee (Score:5, Insightful)
I don't have the time or resources to verify the software of my car
I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.
Many of the things you use are welded shut - integrated circuits, for example.
Re: (Score:2)
I don't have the time or resources to replace a bad head gasket in my car. But I am not going to buy a car with the hood welded shut.
What's the difference? If you don't have the time or resources to replace it then it's not going to get replaced. Generally most people don't have the time, but do have the resources to get engine parts replaced.
Re: (Score:2)
There's probably someone with either enough time on their hands or the predilection towards such things that they would do an audit and more than likely you'd get a small handful of peop
Re: (Score:2)
None of this matters unless it is actually happening to a significant extent. I could be persuaded by statistical evidence, but not by wishful thinking, no matter how often it is repeated.
Re: (Score:2)
Re: (Score:2)
A study, not that long ago, said something like 98% of all open source projects get abandoned in ____ amount of time. I forget how long. I'm not sure that you can say that a "big percentage" has someone else hacking it. It's quite a stretch to do so. This may be true for popular software but that's actually not the majority of open source software.
And no, I'm a Linux user. A registered Linux user actually. I'm just not a zealot and am inclined to try to be honest. It's the internet, you can do that here.
Re: (Score:2)
Actually, I kind of have a theory that every single one of those abandoned projects is still running somewhere - probably on a headless device, in the closet, in the back of a server room, and was installed by a guy who quit ten years ago. I think they're spectral. I'm only partially kidding.
Re: (Score:2)
The fact that bugs are found and fixed in open-source code does not allow you to conclude that open-sourcing will improve bug discovery to any significant extent. That is the issue where wishful thinking is being substituted for evidence.
Re: (Score:2)
Re: (Score:2)
You missed out the bit about significance. Without that, your observation is irrelevant.
Re: (Score:2)
"significant extent."
Define "significant". If someone makes a patch which I apply to MY CAR, that is significant, to me.
And, because I applied the patch, my car DOES NOT accelerate uncontrollably, or veer off the road, or catch fire and blow up, or turn into a Decepticon in your children's school zone, it's pretty significant to you as well.
Re: (Score:2)
yes but, as long as some number of people are willing and interested enough, which for something as widely used as a car, you can expect will be the case (even if it wasn't open, people would be hacking on it), then it works anyway.
Though, in no way are you really protected, its not like "bugs" can't be engineered and well obfuscated.
Oh gee look, some odd data corruption when this register overflows and.....oh quite odd there.
Re: (Score:2)
There seem to be a great many people here who are confident that someone else is going to do this for them.
Did you compile it yourself? (Score:2)
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 t
Re: (Score:2)
That's proof by lack of will, or imagination.
Open source means that you, or an army of people like you, can get it audited, somehow.
For example, you can set up a kickstarter for it and pay someone you trust.
You might also have the competition look at cheats.
Your government can also audit the source, if it's important enough.
People do have power, it takes a lot of getting together with others and stuff, but a lot more is possible than what you can do personally.
Re: (Score:2)
Your government can do that regardless of whether or not the software is open or not.
Re: (Score:2)
My government can't.
My government _could_ do it or pay someone to do it, if the code was open.
Re: (Score:2)
What you say doesn't deny what I said.
You say that some open source code went unaudited, even though it should have been audited.
Open source enables people to do stuff, it doesn't magically make them do it.
Just because openssl could be audited, it didn't magically get audited. But still, it _could_ be audited. That's the first step.
In the case of cars, it's easy, you can just have governments pay for auditing. But you need the code for that to be manageable.
Re: (Score:2)
Head over the XDA Developers, where people mod phone firmware for fun. Note the number of wannabe coders who rant about how stupid Google is and how Android is complete crap without their mods and "fixes". Have a look at some of the scripts and apps they have written.
Very, very few people are qualified to write embedded software for cars, and fewer still to audit it and understand what is safe and why things are done the way they are done. We really, really don't want random people screwing with their car's
Re: (Score:2)
What guarantee do you have that your cars runs the code you were allowed to see?
Re: (Score:2)
What guarantee do you have that your cars runs the code you were allowed to see?
All the consumer safety lawyers willing to make themselves rich by suing car companies.
After a serious accident, if the car company cannot reproduce the binary from the published code, they are going to be forking over a lot of money.
Re: (Score:2)
Can the car makers require that their custom compiler tool-chain is used?
Re: (Score:3)
For the VW incident. having the code open probably wouldn't do much, as it is just the settings/input file which would cause the damage.
Your code could be perfect and still used for evil.
Re: (Score:3)
That file would be considered source code as well.
Re: (Score:2)
A generic .config is usually in the source but that often gets edited and is not included in the source. Why would it be included in this source?
Re: (Score:2)
A generic config file is something that is supposed to be tailored to the individual end-user. In the case you describe it would be a static file that would be identical for each installation of the code. How is that any different from a very specialized domain-specific programming language?
Re: (Score:2)
They don't use the code across multiple vehicles with different configurations and settings?
Re: (Score:2)
They sure can. But the settings files for the individual vehicles will be identical accross all cars of the same model.
It's kinda like translations; you're only using one set of them, but they're still considered part of the code.
Otherwise, please explain why programming language IS source code and some more specialized and limited language (what these files are) ISN'T source code.
Re: (Score:2)
I would probably draw the line on if the config file contains something the equivalent of an IF statement.
Where using the config file will define the order and decision making based on previous inputs.
That would include #ifdef style commands.
However if it is just a table...
Default = 50
60 kph = 40
While it may perform critical roll in the decision process it isn't changing the logic just the thresholds.
Re: (Score:2)
Why? Oh, just 'cause they'd use it to hide it still. But it doesn't seem *likely* that the settings file (the .config) will be identical across vehicles. Sometimes you even get a generic config that you'd change yourself to suit the environment variables. They could easily say, "Well, there's the source code." They'd be accurate, I guess. I'm kind of thinking along the lines of, say, a PHP script with manual installation.
Guarantee, Warranty, Whatever (Score:2)
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.
However.. (Score:4, Interesting)
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".
"Open, therefore secure" (Score:5, Interesting)
or maybe...
Open, therefore not illegal to review?
Not a straw man! (Score:2)
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.)
-1 Stupid (Score:2, Insightful)
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 an
Re: (Score:2)
Jeep releases vehicle with buggy software.
Buggy software comprises 10 million lines of code (the estimate of the size of the offending VW code).
Years down the road, after extensive analysis, white hat posts new and improved software to Git.
????
At issue here is how does a third party hack get distributed to end users?
Further, car makers really don't like it when you chip your car. Last year, I got a warranty notice for my A3 TDI saying my car needed new software to fix part of the emissions control system (h
Onto the device is the important bit (Score:2)
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.
Re: (Score:2)
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.
I think the OpenSSL issue is an example of exactly the opposite. It was a text book example of an open source project that had convoluted and complicated code that actively disincentives anyone to look at the code and thus allow code to go without review and bugs unseen. The idea was that all bugs are shallow yet Heartbleed and Shellshock have both shown some bugs that have stayed with the system despite repeated modifications to the source code and presumably people reading and working with it for many yea
Re: (Score:2)
Open source is superior only in that it provides an ability to do a code review. Clearly that has failed spectacularly in some of our most common and most depended upon open source components.
Huh? I never said OS was perfect; far from it in fact. It's also no guarantee that people are actually going to audit it. I don't understand why people keep thinking this. But if you think proprietary software is of higher quality on average, you're deluded. There's crap code in both camps.
Re: (Score:2)
Only a complete moron would think that proprietary software is immune to problems and that proprietary vendors are proactive about finding and fixing security vulnerabilities.
Re: (Score:2)
I don't see how it'd be any different for proprietary vs. open-source here. They're both going to have vulnerabilities; that's unavoidable with software of any kind. There's always going to be some time between when the bug is found and when it's fixed, during which it can be exploited (worse if black-hats find it first and sell it or use it). The difference between the two is how fast you get a fix, and if you get one at all. With proprietary, you're entirely at the vendor's mercy; if they're really go
Re: (Score:2)
It IS different. If the project's unmaintained, you still have the source code available and can fix it yourself.
You can't do that with a proprietary product. If the proprietary vendor doesn't feel like fixing it, you can't force them to, and you can't do it yourself because you don't have the source code.
If you don't see what the difference is here, I can't help you.
Open Source is no guarantee... (Score:2)
...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 inspectio
Re: (Score:2)
And blackhats frequently do have illegal access to closed source code, putting whitehats (and every other user) at a significant disadvantage.
Duh... (Score:5, Insightful)
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.
Re: (Score:2)
Open-sourcing the software/firmware in question is a necessary thing. That means it must be done. It is not a sufficient condition.
I love open source, and I think the default approach for much software should be open, but it's neither necessary nor sufficient. The insufficiency is clear, at least in the short term. With regard to necessity, there are lots of other options. Here are a few:
1. The vendor could be held liable for any and all security breaches and reliability problems due to their software. That is, they could be required to provide warranties/guarantees, and to be bonded to ensure that they can't skip out of payment by f
Re: (Score:2)
While these approaches all sound nice in theory, they are unworkable or mostly worthless in practice for the type of software under discussion here.
I have done such audits. You get 5 days to review 1000 lines of badly structured and undocumented code. In the end you conclude "no obvious backdoors or vulnerabilities", the vendor is off the hook and the code still sucks. And point 4? Until people doing the code are actually paid wages that attract those that can do it, forget it. Methodologies are vastly over
Re: (Score:2)
I have done such audits. You get 5 days to review 1000 lines of badly structured and undocumented code.
Then you haven't done the audits I'm talking about. I have, and I've had my code audited. It takes many weeks, includes the active participation of the developers and is very thorough.
Re: (Score:2)
I have. But that type is not within the financial means of most projects, hence the meaningless ElCheapo version.
Nothing can prevent vulnerabilities (Score:2)
Right (Score:2)
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.
Closed Source Code isn't a Warranty (Score:2)
only part of the solution (Score:2)
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.
Open source, documentation, tools, training... (Score:2)
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.
source vs binary (Score:2)
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?
Re:"Open == Secure"? (Score:4, Insightful)
They're both wrong.
Open == You can audit it if you want. It's absolutely no guarantee that anyone ever has.
Re: (Score:2)
They're both wrong.
Open == You can audit it if you want. It's absolutely no guarantee that anyone ever has.
There may not be a guarantee but there is a good change it is statistically true. There exists a group of people who may want to audit a car software and they can do it only when it is open. Therefore open source software should have a higher chance of being audited.
Re: (Score:2)
Closed source, commercial software is written by people who are paid to do it. Software that people are paid to written more often includes the boring, not-fun parts like testing, documentation, and auditing. Therefore closed source software has a higher chance of being audited.
We're both just constructing arguments that may or may not be true. My point is that those arguments are irrelevant. A given piece of software either has or has not been audited. It doesn't matter if it's closed or open, it matt
Re: (Score:2)
Software that people are paid to written more often includes the boring, not-fun parts like testing, documentation, and auditing.
I have worked on plenty of both open source and closed source projects over the last 30 years, and this is nonsense. If someone is being paid to do it, then a PHB is setting the priorities, and the programmer is working for pay rather than passion.
I have worked on projects that converted from closed to open source. It was a months long process to clean up all the vomit code, before the company wasn't too embarrassed to make it public. When Netscape went open source, the open source community looked at th
Re: (Score:2)
Of course it's hogwash. You missed my point that it, like vyvepe's argument, is arbitrary speculation and not based in actual fact.
Closed source doesn't make software secure. Open source doesn't make software secure. Securing software makes it secure. Assuming that someone else always bothered to do that for any given piece of open source software is foolish.
Re: (Score:2)
Closed source, commercial software is written by people who are paid to do it. Software that people are paid to written more often includes the boring, not-fun parts like testing, documentation, and auditing. Therefore closed source software has a higher chance of being audited.
Why do you think a car company would not audit open source software it is using in their cars? They can get publicly ridiculed for low quality of their code. Would you buy a car from a company which was shown to have crappy and insecure code in their cars? This is not like a PC which you can reboot and all is fine. And why do you think a company which does not audit its open source code would audit its closed source code?
We're both just constructing arguments that may or may not be true. My point is that those arguments are irrelevant. A given piece of software either has or has not been audited.
I agree with you. My point is that in the case of a car software the openness of the so
Re: (Score:2)
My point is that those arguments are irrelevant.
Closed source software is written by people that are BOTH not paid to do it and paid to do it. Open source software is written by people that are BOTH not paid to do it and paid to do it. You make incorrect assumptions and irrelevant points in your arguments to illustrate that somebody else's arguments are irrelevant.
Closed source can only be audited by people whom are granted the permission to view the code by the copyright holder (small pool of auditors). Open source software can be audited by anyone (
Re: (Score:2)
Software that people are paid to written more often includes the boring, not-fun parts like testing, documentation, and auditing.
Citation needed.
In my experience, closed source projects are lower quality, and I've never worked on a closed-source project that was audited by a third party (I'm sure it happens sometimes, but it happens a lot with open source). With closed source software, at best an acquiring company will send a manager to skim through the code to determine if it is worth acquiring. Even in those cases, the manager typically doesn't check out the project and build it himself, he just looks over it, sometimes guided by
Re: (Score:2)
Closed source, commercial software is written by people who are paid to do it
1. Not true - e.g. non-open-source shareware
2. Open source software is also at times written by people who are paid to do it.
So imagine " Software that people are paid to written more often includes the boring, not-fun parts like testing, documentation, and auditing"
It is a closed source software at this point, with X level of security. NOW open source it - it becomes Y level of security.
Claim is that Y >= X.
Re: (Score:3)
Better yet, from one of their competitors.
Re: (Score:2)
This is counting angels on the head of a pin. There's no evidence whatsoever that open source gets audited at all. The fact that OpenSSL, the software with the most need to be secure, was broken for many years is evidence that it probably isn't.
The fact that *IF* you had the expertise and the time and reason to audit it if you wanted to is hypothetical and irrelevant if no one ever does.
So is open source, in a surprising number of cases.
And in a surprising number of cases it's done as a side project that no one cares about beyond it performing the specific
Re: (Score:2)
Close... you have to trust not only the auditor's technical proficiency, but also their intentions. With open source, you have the option--no, the power--of getting a second opinion. From someone you select and fund, instead of whomever the original vendor hired.
Right but does anybody actually do this? Like it sounds good in theory but does it work in practise. Strikes me there are a lot of existing open source projects that would be viable candidates to prove this out.
Re: (Score:2)
But does anybody actually audit closed source software?
Like it sounds good in theory but does it work in practise[sic]. Strikes me there are a lot of existing closed source projects that would be viable candidates to prove this out.
As far as guarantee of competent audit goes - it is in neither open nor closed source software. As far as existence of insecure software goes - it is in both open and closed source software.
Re: (Score:2)
This is not addressed to you specifically, but to everyone who supports the proposition that open-sourcing is an important step in achieving security:
1) Did you make any use of OpenSSL before Heartbleed was made public? (if not, are you sure?)
2) If so, did you discover this vulnerability during your inspection of the code?
Re: (Score:2)
No. "closed" => "almost sure not secure".
Opening it is only one step that _must_ be done to make it secure. It is necessary, but not sufficient.
Hence for those too limited to understand implications, it is
"closed == insecure" and
"open == secure or insecure"
Re: (Score:2)
There is no philosophical (or mathematical) argument that supports the notion that "opening" source code is necessary for the software it represents to be secure. Both proprietary and "open" software have examples of both "secure" and "insecure" software.
It's all about the validation process; not who performs it.
Re: (Score:2)
Actually, it is very much about who performs it. "Processes" are basically useless in making anything secure.
And who said anything about "philosophical" or "mathematical"? You are barking up the wrong tree entirely. The arguments are economical and psychological.
Re: (Score:2)
Even if that were true, it would not follow that closed-source code is necessarily insecure.
Re: (Score:2)
And you point is? If you desire to be recognized as a smart-ass, congratulations, you have established that you are. Only a smart-ass talks absolutes in a discussion like this.
You were eager to participate in just such a discussion until I called your bluff.
Re: (Score:2)
And an inflated ego in addition to being a moron. Fascinating.
Re: (Score:2)
And an inflated ego in addition to being a moron. Fascinating.
Your descent into schoolyard taunts gives me the satisfaction of knowing that I have hit the nail squarely on the head.
Re: (Score:2)
Err... Didn't you say that software ABSOLUTELY must be open to be secure up above? Some "must be done" part... Now you're saying not to speak in absolutes. Methinks you lost this one.
Re: (Score:2)
"open == secure or insecure"
So what is an example of an open project that is audited and verified as secure? The ability to do this is very often quoted as a benefit so there should be a lot of examples that could be used as case studies to further justify it.
Re: (Score:2)
Re: (Score:2)
How you licence and distribute your code doesn't equate to its quality.
Normally Open Source code is made to be viewed by others will avoid taking shortcuts, while closed source will try to hide time saving methods. But it isn't always the case. A company who is offering a warranty on their code with a good enough penalty for issues will be more thorough than with an open source project.
Re: (Score:2)
Open == Secure
Closed == Secure
The only secure software is one that is repeatedly tested and fixed to stay that way. Vulnerabilities will exist in both Open and Closed software, the question isn't which has more (or less) it is once discovered, what can YOU (the end user) do to fix it.
In this case Just look at the Android Marketplace and all the various versions of Android out there, and how the Manufacturers support them. If it wasn't for CyangenMod and others many of these usable devices would never get up
Re:guarantee (Score:4, Insightful)
And there is no such thing as security in closed source software.
I'm not so sure you can claim that. Where I will admit that closed source software has less people scrutinizing it and generally more eyes the better, I will not admit that makes it less secure. If security is important enough to the developer of a closed solution, important enough to actually cause the right things to happen during development and test to catch security issues before a solution is released, it can be as secure as any software out there. If you have the right people looking at it, looking for the right things, you can produce secure solutions that are closed source.
You see, open source just allows more folks to look at the details, it doesn't mean that the right kind of people actually do look at it. With closed source, you can get secure by demanding it from your development team and giving them the resources to accomplish it.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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 sec
Re: (Score:2)
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.
Re: (Score:2)
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 the
Re: (Score:2)
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 arithmet
Re: (Score:2)
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 unsupporte
Re: (Score:2)
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 reposit
Re: (Score:2)
And who cares? /sarcasm Because no-one [wikihow.com] ever clones [ibtimes.com] physical [google.com] hardware [youtube.com]
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
Re: (Score:2)
**Anything** can be used, or mis-used. Film at 11.
What you're describing isn't new.
Re: (Score:2)
Just wait till we have fully autonomous cars
We already have fully autonomous cars. You just can't buy one yet.