New OpenSSL Man-in-the-Middle Flaw Affects All Clients

Trailrunner7 (1100399) writes 'There is a new, remotely exploitable vulnerability in OpenSSL that could enable an attacker to intercept and decrypt traffic between vulnerable clients and servers. The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software. The new vulnerability could only be exploited to decrypt traffic between a vulnerable client and a vulnerable server, and the attacker would need to have a man-in-the-middle position on a network in order to do so. That's not an insignificant set of conditions that must be present for a successful attack, but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought, gaining a MITM position is not an insurmountable hurdle. Researchers who have looked at the vulnerable piece of code say that it appears to have existed, nearly unchanged, in the OpenSSL source since 1998.'

Comments

Key phrase of vulnerability :

[Anonymous Coward]

"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"

Re:Key phrase of vulnerability :

[ColdWetDog]

"but in the current environment, where open wireless networks are everywhere and many users connect to them without a second thought"

As will always be. Any attempt at security by involving the end user is a recipe for failure.

We're doomed.

Re: Key phrase of vulnerability :

[Anonymous Coward]

No, we just need software that isn't a pile of accreted crap.

Cue LibreSSL. Not a moment too soon. Those guys should be paid to do ALL critical security software, because when they do something, they do it RIGHT.

Re: Key phrase of vulnerability :

[AndroSyn]

How does LibreSSL fix users who do stupid things? This I'd like to know...

Re:Key phrase of vulnerability :

[davester666]

Gives new meaning to the NSA denial "We did know about/exploit the heartbeat vulnerability"

Re: Key phrase of vulnerability :

[Anonymous Coward]

LibreSSL does not yet have any users.

Re: Key phrase of vulnerability :

[aix tom]

So it is 100% save!! Yay!! ;-)

Re: Key phrase of vulnerability :

[Anonymous Coward]

Yes, all the files are saved in a revision system, do not worry :)

Re: Key phrase of vulnerability :

[Anonymous Coward]

I guess OpenSSL creators thought they were 100% right too...

Re:Key phrase of vulnerability :

[Anonymous Coward]

It's time to finally consider giving up using passwords. It is not only a weak method of authentication which has been proven a countless number of times, but also tends to worsen the consequences of vulnerabilities and breaches in software.

We are all familiar with recent vulnerabilities in OpenSSL such as OpenSSL HeartBleed or CCS Injection, as well as well-known XSS attacks. They may all have resulted in situations where users' passwords were compromised without their knowing it. If there were no stored passwords to begin with, there would not have been anything to be compromised. While there would still be software breaches, their impact would be significantly lower.

One Time Password dongles, which attempt to make this old-fashioned authentication method up to standards of today's security, client certificates, smartcards and hardware authentication tokens, all of them by comparison are much better alternatives to username and password pairs.

There are number of companies that recently came up with products intended to replace traditional password authentication - Swekey, WWPass, Authy, Toopher just to name a few.

Using those products not only contributes to your safety, but also has the advantage of not having to remember passwords from all the services you use.

Neat

[Anrego]

But if you have a man in the middle position, most of those same users would have just clicked "ignore" or typed yes to the "connect anyway" prompt.

Re:Neat

[Anonymous Coward]

That's like arguing that faulty brakes aren't a safety hazard because people will speed. The tool should be built properly, so that the injuries are entirely the result of user error.

Re:Neat

[bluefoxlucid]

The summary is actually ridiculous.

The summary suggests SSL is useful without a man-in-the-middle. SSL protects against eaves droppers on your network; but any eaves dropper can become a MITM. ARP cache poisoning is a common technique; on switched networks, you cannot eaves drop without ARP cache poisoning or ARP flooding. Hubbed networks are similarly easy: packet the target with IP=DEFAUTGATEWAY MAC=YOU and it will start addressing default gateway packets to you (routing works by putting the destination IP on a packet, but the default gateway's MAC on the frame; you enter the IP address of the router, and the OS runs an ARP request to find its MAC).

It's entirely unlikely that SSL does anything if there isn't a man in the middle.

Re:Neat

[bluefoxlucid]

Speed limits are overly conservative, and it is entirely possible to drive fast and drive safely. Risk increases, but driver ability modifies the risk. Good brakes are even more important in such situations.

I don't pay much attention to speed limits. The signs are posted miles apart and easy to miss; I drive with the flow of traffic, slowing down when there is additional risk. Additional risk includes traffic calming zones (whether zoned properly or not), e.g., residential areas with street parking and children, where risk is incredibly high--the proper way to drive these is slow, with your foot off the accelerator, prepared to brake. Other risks include commercial areas with lots of pedestrian traffic and street parking in general, where driving at-speed is fine; in these situations, you must search for hazards and prepare to steer or brake as needed to avoid them.

Driving analogies always show how terrible we are at driving. People care so much about the folks driving 40mph in a 30mph zone, but they don't care about the people cruising mindlessly while staring straight ahead and taking no notice of kids playing by the street, people preparing to exit parked cars, or other cars about to turn in front of them without looking for cross traffic. These are people who will be utterly surprised and incapable of reacting when someone's kid pops out from behind a car, or when a driver exits his vehicle 10 feet in front of them.

Re:Neat

[Anonymous Coward]

Driving analogies always show how terrible we are at driving. People care so much about the folks driving 40mph in a 30mph zone, but they don't care about the people cruising mindlessly while staring straight ahead and taking no notice of kids playing by the street, people preparing to exit parked cars, or other cars about to turn in front of them without looking for cross traffic. These are people who will be utterly surprised and incapable of reacting when someone's kid pops out from behind a car, or when a driver exits his vehicle 10 feet in front of them.

Or those people who barely understand the right of way rules and never signal adding elements of unpredictable randomness to the drive.

Re:Neat

[Anonymous Coward]

The speed limits are there for a reason, and are not for you to interpret. You need to observe them whether you agree with them or not. You WILL be ticketed. That's like saying you don't really follow laws unless you personally think they are good laws. Society is asking you to follow the law, not to interpret or judge its validity. It probably happens that the way you think things should be and the way the law says they must be align most of the time, goody for you then. Not everyone would be able to say the same though and implying that it's OK to break the law if you think you should be allowed to is a bad idea to propagate.

Re:Neat

[duke_cheetah2003]

Society is asking you to follow the law, not to interpret or judge its validity.

Sorry, wrong. Society is asking you drive safely and responsibly. Following the law helps, but not every time, not every circumstance.

Re:Neat

[Anonymous Coward]

Yeah, until speed becomes stupid-high, driver distraction is a much bigger problem than exceeding the arbitrary speed limit. Smarter municipalities have already stopped trying to do speed by fiat and started designing roads such that drivers will automatically intuit and drive at the desired speed.

Re:Neat

[LordLimecat]

And yet everyone threw a hissy fit when Firefox first made it a massive PITA to use self-signed / untrusted certs.

Honestly their implementation is pretty good; you can get through it, but blindly clicking will result in the cert being rejected.

Re: Neat

[Anonymous Coward]

If you're driving reasonably close to the speed limit, you're unlikely to be ticketed. If you're driving no faster than anyone else and somewhat slower than the fastest vehicles, you're even more unlikely to be ticketed.

Re:Neat

[Anonymous Coward]

Not quite on topic for the story, I know... but very much on topic for this thread... but I digress.

Speed limits were invented to have some way to limit traffic accidents after countless people were zipping through and causing havoc in areas where slow driving really is required. Nowadays speed limits in many areas are set for maximum revenue generation. I don't have the cite handy, but on average, a police officer generates $300k a year in ticket revenue, this is definitely documented stuff.

I interpret speed limits on a constant basis and I routinely go 10-20 mph over them when conditions allow and [u]traffic dictates[/u]. This can save hours of time on a long drive (which, I do many). And I routinely go 10-15+ under the posted speed limits when conditions require to ensure my safety and the others around me. In 15 years of driving I've been issued 4 tickets. All of them the 'wrong place at the wrong time' type of thing, and nothing to do with actual traffic safety. One of them was dismissed, and the others were reduced because I wanted to take them to trial, and it's easier (and more cost effective.. aka more revenue, for them to just offer a smaller fine now and have you go away).

Speaking of 'as traffic dictates'... say the posted speed limit is 55 and 80-90% of the vehicles are traveling a minimum of 75 in the right lane and speeding up to at least 80 to overtake in the left lane. So... Mr Anonymous Coward, you are one of those drivers going the posted speed limit, creating a 20mph difference between the majority of the traffic and yourself. People encountering your vehicle on the road have to either do a non-negligible amount of breaking to slow to your speed, causing a chain reaction behind and an incidental less-safe condition with many drivers now having to readjust their speed, or they need to navigate around you because you are causing a situation I term 'a moving roadblock'. This also creates a less-safe condition due to the fact that the more vehicles performing speed and/or lane change maneuvers at the same time produce more possibility for crashes. So, there you go... by going the speed limit, and not going the speed that traffic dictates, *you* are causing an unsafe condition. Whereas if all-else-being-equal except for the aspect of you are not on the road, there's one less moving roadblock to contend with.

In terms of traffic safety.. *tailgating* is the number-one cause of highway crashes these days. Speed is a factor, but if assholes in their 5 ton SUVs wouldn't drive 2 feet from the bumper ahead, they would have sufficient time to react to sudden changes in the environment and not cause a crash.

Re:Neat

[Anonymous Coward]

Everything the government does is meant to be analyzed and interpreted by citizens.
It is your duty as a patriot to break the law when the law is stupid, otherwise ur just like one of the idiots that supports mass surveillance.

Re:Neat

[jhol13]

Speed limits are overly conservative, and it is entirely possible to drive fast and drive safely. [...]
I don't pay much attention to speed limits. [...] slowing down when there is additional risk. Additional risk includes [...]

You are a dangerous idiot. Quite ofthen the speed limit is not to protect you, but others. Quite often the (low) speed limit is due to "addition risk", a risk that might be difficult or impossible for the driver to see. Which you have decided to neglect, because you think you are a "better driver". Hint: your reaction time is most likely not significantly smaller than others.

Re:Neat

[bluefoxlucid]

Wrong.

People driving the speed limit on open freeway often have many drivers passing them. This creates contention points in high-speed traffic, leading to a sharp increase in risk. In other words: if the traffic travels at 80mph, driving at the posted 55mph is forcing a dangerous condition.

Speed limits are not posted based on risk, but on zoning and road design. A two-lane undivided highway in a commercial zone is 30mph, even if that commercial zone has wide lanes, minimal traffic, wide shoulders, and no pedestrians because it's an urban sprawl area. Such roads are effectively equivalent to posted 45mph roads and, in the absence of a speed limit sign, a driver is reasonable to assume the posted speed is likely 45mph.

Conversely, the same speed limits are posted in dense pedestrian traffic areas. Two lane with roadside parking is considered wide enough to post 35mph-40mph in a commercial area; yet the amount of pedestrian traffic and drivers exiting the vehicle makes it dangerous to drive that fast.

I'm too busy looking for hazards to pay attention to the speed limit. I travel with the flow of traffic, or at a speed which seems comfortable in absence of other markings. I've had plenty of close calls at and below speed, from drivers trying to door my car to pedestrians surging out into the street; in many cases, the only thing that prevented some moron from becoming a human speed bump was me noticing the way he was moving while on the sidewalk, 10-15 seconds before he darted into the street. The same applies for people about to change lane without a signal, or run a stop sign: you can tell well in advance if you're paying attention, or you can eye your spedometer every 15 seconds and try to claim vehicular manslaughter doesn't apply to you because you were "driving safely".

This is what happens when you look up from your dash and realize the guy ahead of you is merging into your front fender.

MITM needs to be designed around

[Anonymous Coward]

Ultimately you still need to get the encryption information across securely. The next big thing will be making encryption connection-agnostic.

Re:MITM needs to be designed around

[SuricouRaven]

"Ultimately you still need to get the encryption information across securely"

This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.

Re:MITM needs to be designed around

[sexconker]

"Ultimately you still need to get the encryption information across securely"

This is provably impossible with an active MITM attacker (Though a solution to passive listeners does exist and is in common use). If it could be done, we wouldn't be messing around with complicated certificate signing systems.

Correct. A MITM beats everything done over the wire. You need to secure your shit before you use the wire. You need a pre-shared key to encrypt the initial communication. A certificate sort of does this, but not really because we still trust them blindly and we initially accept them over the same wire. The proper way to do shit would be for you to go to your bank in person, for example, and generate 2 keys - one for you to use to talk to your bank and one for the bank to use to talk to you. You then use that key when establishing your first communication with the bank, and they use theirs. You can use whatever encryption you want, you can deploy a key-changing scheme, or a certificate scheme like we have now, whatever.

Your initial key exchange must be done securely. Doing it in person is the most secure way possible, but it's also the least convenient. Doing it over the wire is NEVER secure against a MITM.

Re:MITM needs to be designed around

[someSnarkyBastard]

Diffie-Hellman Key Exchange allows you to securely share a secret key over an insecure medium. Combining this with asymmetric cryptography to identify parties is how modern handshake protocols work.

The problem here how to trust Bob's asymmetric key really came from Bob and not Eve.

You are correct in that the ideal solution would be to talk to Bob over a different medium (like phone) and ask him if that is his key but there are ways to do this over the wire. As an example, several Linux distros sign their LiveCD images with cryptographic keys and post the keys' fingerprints on their web page. Can these be spoofed? Sure, hack the server hosting the files. That requires additional effort (and risk) though which would dissuade most cyber-criminals from attempting it.

Is this perfect security? No, but there is no such thing short of chucking whatever you want secured into a black hole.

NSA feature request done - NT

[Anonymous Coward]

No Text

Re:NSA feature request done - NT

[Optali]

For $Deitie's sake, gief zeese man a "+1 funee" I runned out of ze moderation pointz, sacrebleu!

Versions

[Anonymous Coward]

Just to be clear, versions 1.01 and 1.02(beta) is the same as saying "Any OpenSSL version released since early 2012", right? It sounds like the summary is trying to downplay the threat a little bit.

Re:Versions

[GameboyRMH]

That's right, it affects all versions that are anywhere close to current.

Re: Versions

[Anonymous Coward]

There are also stable releases of 0.9.8 and 1.0.0 which are still maintained for security updates. Many long-term-stable distros and even some recent network appliances don't use 1.0.1 because of the possibility that code churn and feature dev has made it less secure than 1.0.0. In this case they would be right.

Re:Versions

[Anonymous Coward]

Any version affected by Heartbleed, or those you patched to fix Heartbleed.

Re:Versions

[Anonymous Coward]

especially after everyone panic-upgraded after heartbleed.

Re: Versions

[afidel]

Yup, our Linux based application firewall uses a security maintained 0.9.8 based build so we weren't affected by heartbleed. It looks like we'll need to make sure it's patched to 0.9.8za level to avoid the possibility of this being an issue.

Re:Versions

[Zero__Kelvin]

"especially after everyone panic-upgraded after heartbleed."

You can leave out the "panic". Everyone upgraded. Appropriately. No need for the over-sensationalism.

Re:Versions

[DarwinSurvivor]

FreeBSD 9.0 uses OpenSSL 0.9.8q by default (though 1.0.1 is optionally available in the ports tree), which according the summary should be safe (from this attack at least).

Re:Versions

[XanC]

That's not necessarily true. People may have "panic upgraded" who were using a supported and up-to-date (and not vulnerable) 0.9.8. People may have "panic upgraded" by building and installing the latest OpenSSL, not knowing that their distribution had pushed out a patched version of the version they had been running. Now, their OpenSSL might be totally outside of package management, and they could really be in trouble for this one, unless they're paying a lot of attention (which they aren't, or they wouldn't have screwed up in the first place).

Re:Versions

[Zero__Kelvin]

Anyone who had a version that was vulnerable who upgraded did so appropriately. Anyone who did not have a vulnerable version is, by definition, outside of the set of people about whom we are talking.

Re:Versions

[XanC]

Exactly what definition excludes those people from your assertion that "everyone upgraded appropriately"?

This is awesome

[nctritech]

The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.

Re:This is awesome

[Bengie]

OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases. I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?

Re:This is awesome

[smooth wombat]

If open source has one strength, it's that when many skilled eyes DO converge on the code

Keep making excuses for why open source should get a pass on something like this. The code has been around for 16 years. How many eyes have looked at the code since it was put out?

Open source is no better or worse than closed source. People just like to think it is because of situations like this when someone shouts, "I found a flaw!" but completely ignore the time the problem has existed.

If open source is so great, this flaw wouldn't have been around this long, would it?

Re:This is awesome

[westlake]

it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.

Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.

Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.

Re:This is awesome

[mean pun]

I agree that 16 years for a fundamental flaw like this is bad, but how can you possibly know that closed source is no worse (or no better) than this? Closed-source software vendors are usually not very open about these problems.

Re:This is awesome

[Anonymous Coward]

When the code is hidden nobody except the insiders can see how good/bad the code is that leaves FUD. How much do you trust a huge corporation? Especially one that treats users with disdain and tries to lock users out of their own system to keep support costs down and appease agendas from orgs like big media companies?

Even if the bug rate is no better in open source, the fact that it's open and not potentially hiding things removes some questions and doubt. The security bits that are developed in secrecy might have an NSA back door, or might have a hard coded simple support password, or might have some terrible vulnerability that even if reported is unfixed for months to years because the company can't or won't dedicate resources to fix it. Neither method is perfect but open is open. Anyone who wants to scrutinize it can. I've read previously that openssl is convoluted in many places of the code. There them be dragons and nobody is willing to touch it. I think the same attitude prevails in commercial software (at least the projects I've been involved with). I've seen numerous times a developer could fix something properly but instead does a minimal change or hack and we go back to them 3 times because it wasn't fixed right and more issues crop up.

I like free software because there's a common area without restrictions that any human can get into and use/tinker. There should be an open/free platform with some minimal level of functionality in the commons so that anyone can have access to tech/OS without having to pay some corporate gate keeper like Microsoft or Apple. Those corps will still do fine as they are monetized, professional, and their software (at least Apple's) has more spit and polish and it's more likely to JFW.

Re:This is awesome

[Githaron]

The point is that if a flaw exists, when found, it can be quickly fixed in open source. You can also do your own security audit on open source software if you are really security conscious. With closed source, you have to wait for the vendor to both find and fix it (if they ever do). That said, assuming the vendor is trustworthy and would rather shut down than backdoor their software, heavily auditted close source software could easily be more secure than lightly audited open source software. If the audit levels are the same, open source wins. Part of the problem is that until recently a lot of open source security software/libraries like OpenSSL have not gone though enough auditting and vunerabilities are overlooked.

Re:This is awesome

[Anonymous Coward]

OpenSSL design is fundamentally flawed. Bug fixes will probably introduce more bugs in many cases.

Well, the LibreSSL project is ripping out much of the code and rebuilding it: http://www.libressl.org/

I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?

Ummm, your private key should be randomly generated, otherwise public key encryption doesn't work too well.

But your private key doesn't change, so that isn't a good thing to do. Fixing the entropy is one of the many things LibreSSL is doing: http://www.openbsd.org/papers/bsdcan14-libressl/mgp00016.html

Re:This is awesome

[iamgnat]

open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly

Did you even read the summary? They believe that this flaw has existed since 1998. You have a very strange definition of "quickly" if 16 years falls into that category.

I'm all for OSS, but people like you that continue to trot out this tripe aren't helping it. The benefit isn't that there all these mythical "skilled eyes" looking at the code, it's that you can look at the code.

Re:This is awesome

[evilviper]

If open source is so great, this flaw wouldn't have been around this long, would it?

Closed source software is far worse, you just don't hear about it.

Re:This is awesome

[Dcnjoe60]

I agree that 16 years for a fundamental flaw like this is bad, but how can you possibly know that closed source is no worse (or no better) than this? Closed-source software vendors are usually not very open about these problems.

I agree 100%. The only reason this flaw is known is because the source code was available to review. Obviously, it would have been better if this were reviewed and caught sooner, but that ignores the fact that it was only caught because the source code was available. That seems to be a big plus.

Also what is interesting is that even though the flaw has been there for 16 years, there are no known exploits of it. That would seem to dismiss the notion that open source security software is problematic because bad people can find exploits.

Of course another explanation is that the flaw isn't any such thing and was intentional and because it was open source, certain government agencies will now lose the ability to exploit it.

Regardless of how you look at it, it seems to be an advantage to open source.

Re:This is awesome

[Anonymous Coward]

it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.

Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.

Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.

But there's no guarantee paid developers will actually be better so this is actually something to be judged on a case by case basis.

Re:This is awesome

[js3]

The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.

10 years ago someone said...

"Opensource will eliminate all bugs, because the world can see the source". Doesn't matter if no one reads the source.

Re:This is awesome

[nctritech]

If you've been following OpenSSL Heartbleed coverage, you know that the project has only had one full-time developer working on it. Since Heartbleed (a recent discovery, you'll recall) they've discovered more holes to close such as this one. I'd call less than two months since more eyes started staring at OpenSSL "quickly."

Re:This is awesome

[Dcnjoe60]

it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work.

Open Source does not guarantee unlimited resources. Case in point: TrueCrypt.

Paid developers can work full time on debugging and may have a much deeper understanding of the code and how it is used.

Wasn't the TrueCrypt announcement a form of warrant canary?

Re:This is awesome

[nctritech]

The same problems that OSS has with code not being reviewed is present in closed-source models as well, such as the recent Apple security hole that managed to make it past review and stick around for quite a while. They pay developers to work on this stuff. The devs missed it. Software development is done by humans and humans commit mistakes. No source availability model can ever fully mitigate that.

Re:This is awesome

[Anonymous Coward]

If open source is so great, this flaw couldn't have been around this long, would it?

Are you just trolling, or have you never worked on a large closed source codebase? Believe me, there's a lot worse than this out there, in both open and closed source. Read the daily wtf to learn what it's like in the real world of corporate IT.

Regardless of the "openness" of the sources, the real differences in software quality rest in the organizations that build code; the typical US corporation is pretty much guaranteed to produce far worse software than the typical hobbyist group. Unmotivated wage slaves ruled by a technologically incompetent hereditary elite .vs. geeky people who are doing something purely for the love of it? Pfft. Not much of a contest! The biggest change successful tech companies like 3com and Apple brought was a new generation of leaders, who came from outside the traditional boardroom social class. Jobs was a phreak, Metcalfe was a hacker. Today the communities that exist outside the corporate closed-source programming culture have created all the most powerful software tools we have - including Microsoft Windows, which uses tons of Berkeley code, and the NSA's tools, which are often based on linux or openBSD, and all your communications technologies like smart phones and wireless mesh networks etc.

Anyway, let me paraphrase your own complaint: If closed source is so great, why doesn't it come with a free pony? Ponies are cool.

Re:This is awesome

[Anonymous Coward]

There are STILL open issues in Windows 8.1 that have existed since Win2000, that are actively being exploited today with no fix in sight. Major flaws that have survived supposed "complete rewrites" even though the steps to exploit are the exact same. There is only a large amount of shrill denial and burying heads in the sand. At least that aspect doesn't exist in open source.

Re:This is awesome

[Anonymous Coward]

There are some inconsistencies in the /. summary, or at least some wordings that make it sound worse than it is:

16 years. Nearly unchanged... nearly. What does that mean? Is that tidbit even worth mentioning? If the vulnerability had been there for sixteen years, then we wouldn't be seeing problems in versions from only the past two years. Misleading? Just ignorance? Sensationalist so used? Something doesn't add up there. Either it's a sixteen-year-old bug, or it's not. Versions 1.0.1 and 1.0.2-beta tell us this is not a teenage bug.

Re:This is awesome

[Anonymous Coward]

A trivial flaw has existed in Windows for the same amount of time, and it is actively being exploited. It's trivial to fix, but since disclosing it gets a gag from MS thrown down on you, there is no publicizing it. It is estimated that ~60% of all MS systems are thoroughly owned (although that shouldn't really surprise anyone).

Re:This is awesome

[Anonymous Coward]

SSL is NOT a failure of open source, it is a pure conflict of interest. The group of programmers that maintain OpenSSL primarily make their living from doing consulting about OpenSSL. They even advertise their consulting services on their web site: http://www.openssl.org/support/consulting.html .

The more obfuscated, convoluted, and un-maintainable the code, the more money they make, because if corporate programmers could understand and modify the code themselves, the openssl consulting business would dry up.

It is a direct conflict of interest for the present developers to make their living from consulting while maintaining the openssl code.

Conflict of interest is the cause of this, not open source.

Re:This is awesome

[Anonymous Coward]

http://lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/
The last paragraph: "... whether existing implementations correctly verify these conditions. Most implementations except OpenSSL verify them, more or less. OpenSSL seems not doing at all. Later I confirmed that OpenSSL is actually exploitable."

Re:This is awesome

[Anonymous Coward]

Yeah... 16 years late.

Keep telling us how Open Sewers is more secure because of the number of eyes that are on the code. We'll keep laughing.

Steve Ballmer, is that you? Go home...you're drunk.

Re:This is awesome

[jones_supa]

The point is that if a flaw exists, when found, it can be quickly fixed in open source.

In theory it can be fixed quickly, but even in the recent OpenSSL quality assurance effort, there was fixed a 4 year old publicly reported bug. So it's not guaranteed that anyone fixes the bugs quickly, even if they are already found and described accurately.

It's just like the "given enough eyeballs, all bugs are shallow" law: the bugs can be found if enough professional people are rigorously going through the code. But there is no guarantee that every open source project (even mission critical projects) have enough of eyeballs in practice.

Re:This is awesome

[Bite The Pillow]

This required knowing how SSL is supposed to work, not just being able to read code.

It was found when someone decided to check whether implementations correctly checked the order of messages. This could have been found by testing against a binary, regardless of the code being available.

Open source is a win here because I can fix it without waiting for a vendor patch. Not that I would, but I can. Code availability for finding the bug is nearly irrelevant.

No known exploits means nothing. Exclusive zero days are expensive, and I would not share it with anyone if I bought it. Use it in extraordinary circumstances only, and it can be undetected for a while.

Re:This is awesome

[Number42]

Apple's SSL implementation is open source too.

Re:This is awesome

[Anonymous Coward]

He said "when many skilled eyes... ". How you got a +5 insightful is beyond me, because wasn't that exactly how this bug was found? Wouldn't the flurry of attention after heartbleed imply more skilled eyes were looking at it because the source was available and the bug was found and fixed for the first time since 1998? You can choke on your "people like you" line too, telling people they're wrong when it's really you who can't read worth shit.

I'm all for OSS, but ...

No you're not, you're trying to condition people to shut up about a key proven benefit of OSS. When many skilled eyes look at code because that code is available it does speed bug finding and other improvements.

Re:This is awesome

[Bite The Pillow]

Gp's point is once it has been found things move quickly. Tested and fixed is in the part you bolded, not found.

You objected to a point gp did not raise.

Re:This is awesome

[rabtech]

It's actually a false dichotomy...

The vast majority of software is poorly written, hacked-together junk written by dicks and idiots.

Open Source *can* be slightly less terrible, but it's all still terrible.

Re:This is awesome

[g1zmo]

Literally no one has ever said that.

Re:This is awesome

[mellon]

(a) if this were closed we still wouldn't know.
(b) OpenSSL is actually really well known to be so ugly that nobody wants to have to look at it. Mountains of cruft piled on mountains.

Open source code quality on average is a bit better than closed, but it's certainly no panacea.

Re:This is awesome

[Desler]

Neither this bug or heartbleed were found by looking at the source code. They were found through binary analysis.

Re:This is awesome

[LordLimecat]

Your post sort of reinforces the point that a blanket statement about one or the other is pretty dumb.

Closed source can have a number of benefits if done right. It has a number of issues, too (like trust).
Open source can have a number of benefits if done right. It has a number of issues, too (like getting volunteers who are experts in crypto, or preventing obfuscated malicious code).

Re:This is awesome

[LordLimecat]

There are STILL open issues in Windows 8.1 that have existed since Win2000,

You care to give examples? Preferably CVE links to Mitre or similarly respected databases.

Re:This is awesome

[LordLimecat]

. You can also do your own security audit on open source software if you are really security conscious.

No, you cant, and if you think you can you have a serious ego problem.

A security audit of something like OpenSSL is not something that should be attempted by someone who does not earn a living doing code and crypto audits.

Re:This is awesome

[nine-times]

I think that if that person knew what he was talking about, he would have said, "Open source has the potential to greatly increase the quality of code because the world can see the source and make fixes."

Just because there's the potential for FOSS to be more reliable and more secure doesn't mean that every project will be. And even so, nothing will eliminate all bugs.

Re:This is awesome

[LordLimecat]

Open source code quality on average is a bit better than closed, but it's certainly no panacea.

This has got to be the mother of all speculation. Closed source software by definition does not have a source that you can compare to OSS; how on earth can you make a statement like that.

Re:This is awesome

[LordLimecat]

Noone knows. Its best to form your own opinion, and if you feel like sharing it with others, to be explicit that it is just an opinion.

The official word is that they "got bored" according to someone who "emailed the devs".

Re:This is awesome

[WaffleMonster]

I mean, OpenSSL will use your actual private key as a source of entropy. How messed up is that?

Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.

Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?

When functioning properly you shouldn't be able to extract anything except entropy from pool. It is surely possible to weaken a pool by providing known data. Likewise a pool initialized in a deterministic way with all known data except a low entropy sensitive key is surely disastrous no matter how carefully the pool is constructed.

In a case where sufficient entropy is provided either solely by a sensitive source or mix of usable sources it is not clear at all to me there is a practical exploit or benefit of having more quality entropy in any way outweigh risks of reduction of usable entropy.

Fear is healthy in this space yet by the same token unfounded fear can also yield counterproductive consequences.

What is clear from previous Internet wide key surveys lack of entropy is widespread in the real world and certainly is something we all need to be afraid of.

Of course it would be better if we had real random numbers (based on decay, thermal noise,etc) and dispensed with the hacks yet these things are not yet universally available and seems to be a lack of trust in the likes of RDRAND to exist in an unmolested form so hacks have to remain on the table in some usage contexts.

Re:This is awesome

[mcrbids]

Another case in point: OpenSSL, which had, until recently, only enough resources for 1 or 2 developers.

Re:This is awesome

[Anonymous Coward]

With closed-source or proprietary vendors, corporations would maintain bug lists, feature enhancements, and a if-you-see-something-create-a-report policy. But there may be time requirements to get something out of the door, so they mark things as will-not-fix or theoretical-issue and low-priority. So those problems can be left on a shelf for years. Then just through natural career progression over a few years, anyone who worked on that code leaves. That happens with startups, corporations and universities. Then the code becomes either an archaeological relic and discarded or becomes sacred ground that no-one-may-enter. Nobody is allowed to change, modify or even recomment it for fear of breaking something. So it just becomes this Zero Point Energy module that gets wired into other systems, but otherwise no-one really understands how it works.

There was also a job demarcation between universities and corporations. The corporations wouldn't do R&D in any field that was under active research by academics. They'd leave it to the cryptographic experts and committees to write the specifications and provide sample code.

Re:This is awesome

[Anonymous Coward]

Literally no one has ever said that.

You must be new here. Welcome to Slashdot!

Re:This is awesome

[Dcnjoe60]

Neither this bug or heartbleed were found by looking at the source code. They were found through binary analysis.

Analyzing the binary indicated their was a bug. Analyzing the source code identified exactly what that bug was. I may know something isn't working, but until I know why it isn't working, I can't fix it.

Re:This is awesome

[StikyPad]

I think "closed" source is a misnomer in regards to the issue of code review. The source is always open to *someone*; it's just a question of who, and whether those people are competent. Effectively, it doesn't matter how many people look at it, as long as the people looking at it know what they're looking at/for. Certainly it can be argued that the set of "all people" includes more experts than the set of "some people," but in practice the subset of "all people" who actually do code reviews appears to be very, very small -- possibly smaller than the set of people who review closed source code. The advantages of OSS are many, but on this point, at best, I think it's a wash, and certainly not a clear and convincing argument for open-source software.

Re:This is awesome

[mr_mischief]

How is it adding entropy to the pool if you keep using the same private key as one of the inputs?

Re:This is awesome

[TubeSteak]

Open source is a win here because I can fix it without waiting for a vendor patch. Not that I would, but I can.

And why wouldn't you?
Probably because you're waiting for some other guy (the vendor) to do compatibility and regression testing.

Re:This is awesome

[jdavidb]

I suspect that in the last year since the Snowden revelations a lot more eyes have suddenly gotten focused on these packages. People are going to be looking for real security and wanting to make sure there are no secret backdoors, intentional or otherwise, in the code they depend on.

Re:This is awesome

[Tharkkun]

The more of these we find, the more secure OpenSSL will be. I hope we continue to find these kinds of problems and see them fixed. If open source has one strength, it's that when many skilled eyes DO converge on the code it can be tested and fixed far more quickly than a corporation with limited resources and only paid developers can do the same sort of debugging work. The trick is getting the eyes there in the first place.

Isn't Opensource supposed to prevent these bugs from happening in the first place? That's the whole argument towards using it. If we find bugs that are just as bad as a closed source product there's no advantage to using the open version. At least with a closed version hackers won't have had access to the source code for 16 years.

Re:This is awesome

[znrt]

Open source is no better or worse than closed source

since it is opensource you can know now with absolute certainty where the bug was and for how long it has been there, and you can check exactly how it is fixed. with closed source you would know next to nothing. definitely worse.

Re:This is awesome

[mpe]

Open source is no better or worse than closed source.

The latter tends to explicitally prevent "outsiders" looking at the code. It's very possible for authors to be "too close" that they will see what should be there rather than what actually is there. Hence in other industries there are the likes of "proof readers".
The other difference is with OSS anyone who spots a bug is able to publish a fix.

Re:This is awesome

[mpe]

There are STILL open issues in Windows 8.1 that have existed since Win2000, that are actively being exploited today with no fix in sight. Major flaws that have survived supposed "complete rewrites" even though the steps to exploit are the exact same.

On the other hand it is possible to find situations where things are changed between different versions of Windows for no obvious reason. (Except possibly to deliberatly break old or third party software.)
Sometimes even when the new behaviour is noticably inferior to the old behaviour. e.g. The more recent the version of Windows the longer the login process appears to take.

Re:This is awesome

[Anonymous Coward]

Even if a fix is made and do not make it to the official source, anyone (including distros) can fix it on their own (especially when there is a fix known to work but not included in the official release for *random* reason). In a closed source environent you have to wait for the team to release (which may or may not ever happen - same as open source)

There are no guaratee that every closed source project (even mission critical projects) have enough of eyeballs in practice - or that they are any good at their job. Why you think closed source teams are better than open source teams, simply due to the development model choice. thats just weird.

Re:This is awesome

[Anonymous Coward]

That is why if you are security concious, you audit the source by paying experts in whatever field(s) the code covers. "do your own security audit" does not mean rreading over the code yourself if you have no idea what it means or does - that much is obvious. But the code is right there to do what you wish with, and not everyone who thinks open source is a good thing is adverse to companies offering services around open source - like auditing.

tl;dr: yes, you can. and if you think you cant you have very little imagination.

Re:This is awesome

[Anonymous Coward]

Isn't Opensource supposed to prevent these bugs from happening in the first place?

No.

Re:This is awesome

[Desler]

No, binary analysis can tell you exactly what the bug is. Researchers do it all the time for programs they have no source code to.

Re:This is awesome

[Gr8Apes]

Well, the LibreSSL project is ripping out much of the code and rebuilding it

Which just means they will introduce totally new bugs of their own, essentially 'resetting' all the security testing and reliability that the current code base has.

A bitter OpenSSL proponent?

Re:This is awesome

[Forever Wondering]

And the developer that created this bug in 1998 is the same one who created heartbleed. Some people get a lifetime ban for hacking. Do we need a lifetime ban for coding?

Re:This is awesome

[nctritech]

Most people are not researchers and furthermore don't have the expertise to even FIND this issue, much less fix it properly.

Re:This is awesome

[pipatron]

Is it messed up to add sensitive information to an entropy pool? From choice of wording it seems everyone should immediately and without reservation know better this is a stupid thing to do.

Question is this actually a valid position or more knee jerk based on unfounded fear, ignorance of operation of an entropy pool?

When functioning properly you shouldn't be able to extract anything except entropy from pool.

Emphasis mine. Putting it in the pool is yet another attack vector, and a great way to increase the chance of something going wrong down the line. Either by mistake or by a planned malicious code change in parts of the code that doesn't seem to have anything to do with the private key.

Re:This is awesome

[nctritech]

http://news.softpedia.com/news...

Feel free to look up a CVE for it yourself. This is just one example. Other long-standing MS security holes include the infamous WMF bug. Plenty of such things exist in the wild.

Re:This is awesome

[Dcnjoe60]

Most people are not researchers and furthermore don't have the expertise to even FIND this issue, much less fix it properly.

But for those who do have the skill and expertise, they can't do it without the source code. Think of it like this. You can tune all the settings on a network by the book, but if there is a problem, having a packet sniffer sure makes it easier to correct. Source code is like a packet sniffer. There is a lot of corrective steps you can take without it, but to ultimately fix the problem, whether closed or open source, one needs access to the source code. That doesn't mean each individual is going to fix their own, but only that whomever is working on it needs the access.

Re:This is awesome

[ewibble]

Of course "He did it too" is a valid argument when comparing two methods of software development.

You are comparing the relative advantages of both, against each other, that what comparing means, no on said open source was perfect.

And as a person who has worked on close source, I can assure you people do go around shouting how great closed source is, and I can assure you closed source and as easily be written by people who have no idea what they are doing.

Re:This is awesome

[Anonymous Coward]

Which just means they will introduce totally new bugs of their own, essentially 'resetting' all the security testing and reliability that the current code base has.

Which would be very little. Have you seen some of the stupidities in the OpenSSL code? http://opensslrampage.org/

A great presentation by the libreSSL people is here: http://www.youtube.com/watch?v=GnBbhXBDmwU

Re:This is awesome

[mean pun]

"He did it too, mommy!" is a valid position to take in a debate only if you're 8 years old.

I totally agree, now please explain how am I using this argument, because I don't see it.

Re:This is awesome

[Anonymous Coward]

Open source code is _generally_ of better quality, when comparing apples-to-apples--i.e. commercial and open source projects of similar caliber. This has been proven empirically by several different static analysis vendors.

But, yes, most software sucks. But because most software sucks, I'd much rather use open source software, because then I can personally verify how crappy it is. If it's too crappy I can (and have) decided to use different software.

If it's closed-source software, I usually just assume it's extremely crappy, because these days it's not uncommon for commercial companies to open source (under a restrictive license) their code, but they only do this for code which isn't complete sh*t. That's not to say that there isn't beautiful closed-source code, but I don't like playing the lottery.

Re:This is awesome

[thogard]

Seeding the random source using a private key looks like the same concept as using your encrypted root passwords to seed the TCP sequence numbers. This is not a new concept.

Re:This is awesome

[jhol13]

I knew this excuse would used again and again, long before Heartbleed. I complained loudly (see my history) for your though to be fatally flawed.
The problem is, that this kind of thinking generates more holes than fixes.

But then, I think you were sarcastic and the moderators missed it.

Re:This is awesome

[jhol13]

First, I detest the excuse "some one is worse - or at least you cannot prove it is not, therefore we are actually quite good!"
Then, I call bullshit. Closed source do get "CVE'd" and the companies can be held liable. Foss developers cannot be sued (and get as much money as from G/M/A/...).

But do continue with the same attitude. After next exploit, and 10 more later, just say "yes, someone out there is worse, especially now as we have fixed ALL known vulnerabilities". Although the new version out next month will probably introduce more new holes than what were fixed.

Re:This is awesome

[nctritech]

It is, but it has a massive team of paid developers behind and working on that open source code every single day. My point was that even Apple had such a serious flaw, despite the benefits of both open source code AND hordes of paid developers actively working on it. Every new OpenSSL bug now triggers a bombardment of knee-jerk ignorant armchair quarterbacking about how "OpenSSL is clearly shit and the developers clearly suck and open source software sucks." Yet we see that even taking on the benefits of BOTH sides of software development, somehow Apple's SSL stack ended up with a devastating security-murdering bug not unlike Heartbleed.

At the end of the day, devs are human and make mistakes like everyone else, and that's just not a good enough explanation to some of the people here.

Re:This is awesome

[jhol13]

So what you are effectively saying is "we (foss) did a great job, let's pat each other on the back! Then let's continue our marvellous path of joy and glory".

(translation: we, the cowboy coders, are totally ignoring fatal problems in processes and attitude and won't fix them 'cause we "are better". if the sarcasm was lost in translation, your bad).

Re:This is awesome

[Dcnjoe60]

So what you are effectively saying is "we (foss) did a great job, let's pat each other on the back! Then let's continue our marvellous path of joy and glory".

(translation: we, the cowboy coders, are totally ignoring fatal problems in processes and attitude and won't fix them 'cause we "are better". if the sarcasm was lost in translation, your bad).

Not at all. What I am saying is the OSS provides some advantages over closed software. Both are fraught with bugs. Free as in beer, doesn't mean free from bugs.

Re:This is awesome

[LordLimecat]

Er, there is a patch for those IE flaws, and it was released prior to full disclosure: https://technet.microsoft.com/...
Theyre also only vaguely sort of issues "in Windows 8.1", in the same way that a safari bug is a flaw in OSX.
The WMF bug was patched 8 years ago.

Re:This is awesome

[jhol13]

Wrong. Open source can provide advantages, but only if all processes etc. are followed. Most often they are not.

Re:This is awesome

[Anonymous Coward]

+1 that

Re:This is awesome

[dissy]

You have a very strange definition of "quickly" if 16 years falls into that category.

That is still a much better definition than yours appears to be!

16 years is at least a number and a unit of time. Your argument that "Closed source bugs are found in never years" is the definition of "quickly" most everyone would call strange.

Re:This is awesome

[jones_supa]

There are no guaratee that every closed source project (even mission critical projects) have enough of eyeballs in practice - or that they are any good at their job. Why you think closed source teams are better than open source teams, simply due to the development model choice. thats just weird.

I didn't say that!

Re:This is awesome

[jones_supa]

But, yes, most software sucks. But because most software sucks, I'd much rather use open source software, because then I can personally verify how crappy it is. If it's too crappy I can (and have) decided to use different software.

You don't usually even need the source code to verify if a piece of software sucks or not.

Re:This is awesome

[Anonymous Coward]

It's just that without telling what the flaw is, your message might as well be complete bullshit.

Re:This is awesome

[Anonymous Coward]

Sixteen years? I thought only recent versions of OpenSSL were affected?

Re:This is awesome

[Anonymous Coward]

And closed source would have been better because ...?

Re:This is awesome

[Anonymous Coward]

This means that all the bugs no detected by that one person is the fault of that one person. That one person must be one hell of a person indeed.

Re:This is awesome

[Anonymous Coward]

Well let's say that 100% of the closed source and 100% of the open source people are looking at the outcome of the solutions. Let's also say that 100% of open source and closed source people will check the source. Usually there are more eyes checking the outcome of the closed source than the outcome of the open source, right?

Re:This is awesome

[donaldm]

It's actually a false dichotomy...

The vast majority of software is poorly written, hacked-together junk written by dicks and idiots.

Open Source *can* be slightly less terrible, but it's all still terrible.

There are good and bad programmers. The bad ones don't last long before their credibility is in tatters and they never get to work in the programming field again. One major thing I always look for in software is it's ability to be maintained. If not, as far as I am concerned it is junk and should be replaced and replacing is not that difficult when you know the core requirements of the software.

Just saying all software is terrible (I won't de-nigh that some is) and insulting all people who do programming is very short sighted and your credibility in saying that is effectively shot.

Re:This is awesome

[Anonymous Coward]

Anecdotal, but not necessarily speculative. Closed source software still *has* a source, by definition. Hopefully someone making this claim actually programs for a living, in which case he or she likely has seen and worked on closed source projects, and as a result can compare it to open source.

Re:This is awesome

[WaffleMonster]

Emphasis mine. Putting it in the pool is yet another attack vector, and a great way to increase the chance of something going wrong down the line. Either by mistake or by a planned malicious code change in parts of the code that doesn't seem to have anything to do with the private key.

Insufficient entropy also has costs. It is not prudent to look only at one side the ledger and make decisions based on it alone.

Re:This is awesome

[WaffleMonster]

How is it adding entropy to the pool if you keep using the same private key as one of the inputs?

The entropy estimate is zero when the keys are used.

From evp_pkey.c

RAND_add(p8->pkey->value.octet_string->data,
        p8->pkey->value.octet_string->length, 0.0);

The question is are you better off doing it than not? There are a number of valid arguments for not doing it. Fears of implementation errors and limited utility of reusing same data are valid points.

The cost however of insufficient practical randomness in a system is dire.. only question that matters in my opinion does the cost of doing it outweigh the benefits? The answer seems to be context dependent and far from obvious or simple to resolve.

Re:This is awesome

[Fnord666]

but in practice the subset of "all people" who actually do code reviews appears to be very, very small -- possibly smaller than the set of people who review closed source code.

I'm going to disagree here. For a given company that has a closed source implementation, there may be small group of people qualified to look at the code and understand it, but that in no way means that they are or have done so. Corporate politics, capitalizable time, access restrictions, etc. all play a part in whether any one at all actually looks at the closed source code for vulnerabilities.

Re:This is awesome

[Fnord666]

Software development is done by humans and humans commit mistakes

I see what you did there. Nothing like a little bit of source code repository humor. Well played sir, well played.

Re:This is awesome

[iamgnat]

If you've been following OpenSSL Heartbleed coverage, you know that the project has only had one full-time developer working on it. Since Heartbleed (a recent discovery, you'll recall) they've discovered more holes to close such as this one. I'd call less than two months since more eyes started staring at OpenSSL "quickly."

Are you seriously arguing that this one developer is the only person that ever looked at the code? That goes counter to your original implied assertion that because it's OSS then "many skilled eyes DO converge on the code". You can't have it both ways, either there are lots of people looking at the code or there aren't.

How many people actually looked at the code is irrelevant though. Your original assertion was that OSS is somehow magically safer/better because "many skilled eyes" look at it. The reality, however, is that in complex projects there will always be bugs that even the most skilled will miss unless they know exactly what they are looking for. The source being open or closed makes no difference in that regard.

Re:This is awesome

[iamgnat]

Your argument that "Closed source bugs are found in never years" is the definition of "quickly" most everyone would call strange.

I made no such argument and I made no argument for closed source. My argument was/is purely against the myth of OSS being better/safer than closed source just by the virtue that it can be looked at. That isn't true both because smart people miss bugs (especially they they occur due to separate parts of a large project interacting with each other) all the time and it makes the assumption that people are actively looking at it for flaws.

What is true is that the end user has the ability to review it themselves, fix it if they find problems, and support/modify it beyond what the developer(s) does as they see fit. OSS is a good thing and it has many advantages over closed options, but people trying to spread the "belief" that OSS is somehow safer is no better than those that used to talk about how Macs were more secure than any other platform.

Re:This is awesome

[nctritech]

Not being the one who made the assertion, I was simply attempting to illustrate that very long-standing security holes can and do exist in modern operating systems in common use. I'm not here to defend that assertion as it is not necessarily correct (most security holes in 8.1 are as-yet undiscovered since the OS itself is quite new!) The bugs I've pointed out existed for many years before being found and fixed. The standard response to "open source is better because people can find and fix the bugs" is to wait for a bug to appear, then screech loudly about how the existence of the bug shows that open source is a fatally flawed security-hole-ridden model of software development, blah blah blah ad nauseam. Clearly this is complete and utter bullshit since an infinite pool of available code reviewers != all bugs preemptively fixed, but such is the process of arguing with zealots on the Internet, so the next best thing is to illustrate that closed source is no better than open source.

I'd like to point out that in one of my other comments here, I've tried to explain that Apple's critical SSL bug was there for years even though Apple leverages the full advantages of both closed- and open-source models in their Darwin kernel. If that happened despite having the positives of BOTH models available, how the hell is anyone in either-or supposed to avoid making the same mistakes? Humans code, humans commit errors, end of discussion.

Re:This is awesome

[Anonymous Coward]

The systemd code base is slam full of these sorts of NOTABUG fix rejections. Used to be the same for glibc until Ulrich Drepper went away. There are some really shitty egos in open source; the interesting part is that many of them seem to work for Red Hat and they control code that is the foundation of thousands of other projects...and wrecking ball that code when they decide that they're smarter than anyone else. Kay Sievers and Lennart Poettering can both shove it too.

Re:This is awesome

[Anonymous Coward]

It can be quite difficult to pinpoint the problem without any access to the source code. There is no good way to slap a debugging printf statement in there or otherwise generate logs that show the state of things as work progresses. It can be done, but it involves a lot more time and effort than having source code available would involve.

Bet the NSA knew about this...

[GameboyRMH]

...and it was like ten Christmases to them. They're probably really down that they just lost one of their best toys.

Not as bad as it seems...

[Anonymous Coward]

This flaw can only be exploited if both the client and server are running a vulnerable version of OpenSSL.

While OpenSSL is very common on the server side, it is much less common on the client side.

For example, most web browsers don't use OpenSSL.

Re:Not as bad as it seems...

[Anonymous Coward]

Chrome on Android uses it and tons of apps on Android that open SSL connections also use it. So to claim OpenSSL is not used on clients is a total joke.

Re:Not as bad as it seems...

[Anonymous Coward]

Plenty of client applications make SSL connections and OpenSSLis used for that.

How are people affected in their day to day lives?

[tlhIngan]

This is a flaw, but it requires both ends use vulnerable OpenSSL versions. Which means your day-to-day life may or may not be affected that much.

I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows) - since Apple and Microsoft have their own SSL implementations. If you have an Android phone or tablet, then yes, it's quite likely an issue, and while both are popular, people generally don't use them that much for data (iOS traffic, after 7 years, has finally dropped to below 50% of all mobile traffic out there, despite Android outselling iOS by a huge margin). And nevermind the oddball Linux user.

So the real question is, how many people really ARE affected?

Heartbleed affects everyone because it exposes server secrets irrespective of the client side. But this vulnerability is only really present if both ends use OpenSSL.

REST APIs, Datacenter-to-datacenter transfers

[Anonymous Coward]

If you use HTTPS from, say, your Node.js app to connect to someone's PHP-based REST service, you're vulnerable and so are your users. Wouldn't surprise me a bit if this is being used in the wild by state actors to attack entire web applications/services, in order to target just a few of their users. They don't care about collateral damage.

Closed source software

[93 Escort Wagon]

Given all the open-source SSL/TLS security flaws (OpenSSL, gnutls, Apple SSL) that have come out these past few months - mostly thanks to renewed interest in hunting flaws, thanks to the Snowden revelations, I suspect - I hope that companies like Microsoft are also seeing this as a wake-up call driving them to do code reviews on their closed-source SSL/TLS code.

Re:Closed source software

[js3]

Given all the open-source SSL/TLS security flaws (OpenSSL, gnutls, Apple SSL) that have come out these past few months - mostly thanks to renewed interest in hunting flaws, thanks to the Snowden revelations, I suspect - I hope that companies like Microsoft are also seeing this as a wake-up call driving them to do code reviews on their closed-source SSL/TLS code.

Not quite sure what you mean there. Closed source gets more code review than opensource apparently.

Re:Closed source software

[93 Escort Wagon]

Not quite sure what you mean there. Closed source gets more code review than opensource apparently.

Speaking as someone who, in a past job, reported a number of brain-dead flaws in their products to Microsoft - I'm curious what experience has led you to draw that conclusion.

Re:Closed source software

[swillden]

Closed source gets more code review than opensource apparently.

Clearly you've never worked in the software industry.

Re:Closed source software

[BadDreamer]

And you base this on what comparative statistics? How many security related bugs have the closed source developers found and fixed while these bugs were closed by a community scouring over the code?

Re:Closed source software

[BadDreamer]

And how long have the bugs in the Windows networking code been sitting there? Oh, right, you can't know, because they're not telling us.

Perhaps you should use some of that logic which you wish others to experience.

Re:Closed source software

[93 Escort Wagon]

Most of the bugs I reported to Microsoft were flaws in their Fortran and MASM (assembly language) offerings, back in olden days of yore (otherwise known as the 1990s).

With the added complexity of modern Microsoft dev tools, though, I'm sure bugs never make it into production nowadays.

Re:Closed source software

[Number42]

Apple's SSL implementation is actually open source, but true, the only upstream contributor to that repository is Apple.

Re:Closed source software

[Bite The Pillow]

Samba reverse engineered smb with a clean room effort, but I'm sure they didn't get it right the first time. The effect was fuzzing the windows service as they developed.

Similar efforts have been done on lots of proprietary binaries, and plain old assembly level disassembly has also been done.

I'm not saying everything has been tested. But "you can't know" is clearly wrong. If you want to know, you can. Just like if you wanted to know openssl is secure, you can. You had 16 years to read source code and you didn't find this bug. If there are flaws in proprietary software, it is because someone didn't look. Not because they didn't know.

How do black hats find vulnerabilities if they "can't know"?

Re:Closed source software

[Anonymous Coward]

So no proprietary software has 16yr flaws?

Re:Closed source software

[Anonymous Coward]

And that IE flaw the other day that goes back at least to IE 6? Granted, IE6 came out in 2001 so it's only 13 years old.

OpenSSL is shit, but let's not pretend that commercial companies are known for anything but SHIP IT!

Re:Closed source software

[swillden]

Closed source gets more code review than opensource apparently.

Clearly you've never worked in the software industry.

Clearly neither did any of the code inspectors that reviewed the code for 16 years...

Non sequiteur.

Re:Closed source software

[BadDreamer]

Quite correct, compiled code is scanned all the time. And in doing this, bugs are CONSTANTLY found. Big, bad ones which leave wide open holes.

And many of them are around for years before they are patched. Many years. Some are still not fixed, after many years.

And yet more of them are not possible to detect until other changes in the software or architecture exposes that part of the executable to a new environment. The bug could have been there for dozens of years - yes, there is code in Windows that old - and still not be patched today.

The difference is, with open source, we know exactly how long the bug has been there, and when it was fixed. With closed source, we have no way of knowing. None. Really. All we can know is what is exposed in the builds we have access to with the interfaces we have access to.

And you know, if "someone didn't look" then they didn't know. Srsly. What kind of brain damage produced that line of reasoning?

Re:How are people affected in their day to day liv

[Anonymous Coward]

I mean, if you use iOS, OS X, or Windows, you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)

Ummm, firefox uses NSS, not OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services

Re:How are people affected in their day to day liv

[Anrego]

The real limiter for your average user is the requirement for man in the middle position.

Even without this flaw, most users will just click through any warning that comes up during a man in the middle attack.

It's still a bad thing that the mechanism designed to protect us from man in the middle is broken, but for the average user, the mechanism is already broken via apathy.

LibreSSL

[Anonymous Coward]

does this affect LibreSSL?

Re:LibreSSL

[melstav]

Yes. If you're using libressl and the snapshot of the source you compiled is older than Thu Jun 5 15:46:24 2014 UTC, you're affected by this, too. See: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/s3_clnt.c

Re:LibReSSL

[skovnymfe]

But ultimately irrelevant?

Re:How are people affected in their day to day liv

[Argilo]

Firefox uses NSS, not OpenSSL.

So my old OpenSSL library is fine then?

[Jezisheck]

The flaw affects all versions of the OpenSSL client and versions 1.0.1 and 1.0.2-beta1 of the server software.

If I understood it correctly, my older OpenSSL package (openssl 0.9.8o-1ubuntu4.6) should be fine, right?

Re:So my old OpenSSL library is fine then?

[Elessar]

If you are using OpenSSL as a client then you are vulnerable. On the server side the bug is till there but there is no known way of exploiting it prior to 1.0.1. You are still recommended to upgrade - but ubuntu will provide the relevant fixes.

Re:So my old OpenSSL library is fine then?

[Anonymous Coward]

This bug dates right back to 1998 so your older version has to be from 1997 or older...

Re:How are people affected in their day to day liv

[Dcnjoe60]

So the real question is, how many people really ARE affected?

That would depend on how much, if any, of OpenSSL code was incorporated into Microsoft and Apple products regardless of the GPL. After all, 1998, was a long time ago.

Stupid summary

[cryptizard]

That's not an insignificant set of conditions that must be present for a successful attack

But it is exactly the point of TLS, to protect against such an attacker. If you know you don't have a man-in-the-middle then you don't even need it in the first place.

True that the server might not be running that version, but a non-trivial number of them are.

Re:How are people affected in their day to day liv

[Blue Stone]

you're more than likely NOT using OpenSSL on the client side (except say, if you use Firefox on Windows)

That's quite the parabolic sentence there. I hope you didn't give yourself whiplash.

How are people affected in their day to day lives?

[Anonymous Coward]

Firefox has its own SSL stack across all OSes (libnss), so it shouldn't be vulnerable. AFAIK, chrome/chromium uses OpenSSL across all platforms.

1998? 16 Years?

[Anonymous Coward]

A flaw just sitting in the open for 16 years? Man, surely that's impossible what with it being open source and all those fervent well-trained altruistic supposed eyes constantly scanning the code.

Clearly, this demonstrates the strength of open source software.

Re:How are people affected in their day to day liv

[CaptainDork]

I agree with your assessment and conclusion, and while I can't refute that apathetic users are a problem, I submit that apathetic users should NOT be a problem. In our current state of the art, users take a lot of blame for not implementing best practices regarding credential quality, changing passwords frequently, failing to read warnings, privacy statements and terms of conditions, etc. Users are also held accountable for not updating their operating systems and the programs that ride on the (Flash, Java, Other). The real burden, in my opinion, rests solely with the experts in the field. Users are reading about Heartbleed, OpenSSL, Man In The Middle, client, server, encryption, ... Users want to level up on Candy Crush Saga and they want to leave all that mumbo-jumbo to people like we here on this board. I think that's fair.

Advisory is a bit unclear

[dpapenthien]

After reading the advisory from OpenSSL, I'm still confused by what is vulnerable and what isn't. The flaw requires both the client and server to be vulnerable. If the client is using OpenSSL, they're vulnerable for 0.9.8/1.0.0/1.0.1. But if the server is using OpenSSL, they're only vulnerable if using 1.0.1/1.0.2(beta). Yet the bullet list of recommendations points out that servers should upgrade even if they're using 0.9.8: * OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. Let's say I have a server using 0.9.8 and client using 1.0.0. If I understand their explanation correctly, then this scenario is *not* vulnerable. Is that the same conclusion others would draw from their explanation?

LibReSSL

[Archwyrm]

The project name is written as LibReSSL. Clever, clever..

Sensationalist inconsistencies

[Anonymous Coward]

There are some inconsistencies in the /. summary, or at least some wordings that make it sound worse than it is:

16 years. Nearly unchanged... nearly. What does that mean? Is that tidbit even worth mentioning? If the vulnerability had been there for sixteen years, then we wouldn't be seeing problems in versions from only the past two years. Misleading? Just ignorance? Sensationalist so used? Something doesn't add up there. Either it's a sixteen-year-old bug, or it's not. Versions 1.0.1 and 1.0.2-beta tell us this is not a teenage bug.

Perhaps it is notable that the only place this sensational "fact" comes to light is from "researchers", and even there it has no mention of the relevance for this bug and only mentions this code is "nearly unchanged", meaning it was changed.

You silly silly fools

[Anonymous Coward]

Still believe you can secure data.

Re:How are people affected in their day to day liv

[Iarwain Ben-adar]

WRONG. If the server is vulnerable, your session can be hijacked. http://ccsinjection.lepidum.co...

Re:How are people affected in their day to day liv

[Anrego]

Oh I totally agree with this. Relying on the user to "make the decision" is (or should be) the last resort when a programmer can't figure out how to deal with a situation.

In the specific area of certificate verification on web browsers, the problem has been too many false positives. Lots of people are sloppy with their certificates, and users have gotten used to the idea that any error mentioning a certificate is probably no big deal (because the other 100 times they clicked the ok button the world didn't end). This then served only to encourage people to be even more sloppy (the user will just click the warning that comes up, no big deal).

Things are moving in a good direction now, with most of the major browsers making the dialog more menacing and (in the case of firefox at least) requiring several not-so-intuitive steps, and this having the effect of making letting your certificates expire/using incorrect certificates more of a big deal because you will lose traffic. I think we are at least at a point where most users will stop when they get one of these more complicated warnings and they are doing something like banking or buying something online.

Closed source software

[Anonymous Coward]

SInce most EULA prohibit you from filing al lawsuit about your use of the software there is absolutely ZERO business motivation for any corporation to even look for security vulnerabilities - let alone devote money toward fixing them when they are the only ones who know if they have a vulnerability.

sounds pretty insignificant to me

[Anonymous Coward]

any ISP would be in a middle man position and able to decrypt your SSL traffic.

Grrr...

[Anonymous Coward]

Time to change ALL my passwords again.

Would it be a sin?

[jones_supa]

I see a lot of comments that try to convince that "closed source isn't any better". So my actual question is: would it be some kind of sin if closed source was actually better?

Re:Would it be a sin?

[cmburns69]

The accusation implied in that response is that "open source must be weak because vulnerabilities are found".

Whether or not closed source is better is largely irrelevant. Whichever fulfills your needs the best (be they verifiable security, price, etc) is what is "better" for you.

Re:Would it be a sin?

[jones_supa]

Actually I just received another comment like which I talked about. It still seems to be important for people here to point out that "closed source isn't any better".

Personally I (rather unsurprisingly) agree with you: select the best tool for the job.

only DTLS is affected.

[Anonymous Coward]

...which nobody in their right mind would use anyway. Granted though, openssl is still a piece of shit.

FreeBSD

[Lawrence_Bird]

at least my install still uses 0.9.8n though who knows what other nasties lurk in that one

Re:FreeBSD

[cpghost]

FreeBSD just issued a security advisory w.r.t. OpenSSL. You better update to -STABLE asap.

Re:FreeBSD

[Lawrence_Bird]

oh man why you ruin my day

Re:How are people affected in their day to day liv

[Anonymous Coward]

regardless of the GPL

OpenSSL is BSD licensed, not GPL licensed. They can incorporate all the code they want.

I love how openbsd was specifically excluded

[Anonymous Coward]

read the timeline here: https://plus.google.com/app/basic/stream/z12xhp3hbzbhhjgfm22ncvtbeua1dpaa004 ...and note how openbsd was specifically excluded from being notified. the openssl guys seem like real haters.

'new, exploitable vulnerability' ... 'since 1998'

[mr_mischief]

Something does not add up. How is there a new vulnerability that's been in the source for sixteen years? How are older versions of the server code not vulnerable if it's sixteen years old?

Re:How are people affected in their day to day liv

[Anonymous Coward]

Anyone who is trying to communicate securely yet has someone with the resources to have access to the pipes at a point along the way. The people with that kind of access and resources are generally governments, spooks, etc. eg, it's the definition of something the NSA/Iran/China/UK et all would want in order to be able to seamelessly pull off MITM attacks on traffic, and if the NSA wants it, other agencies/regimes/etc. would have real use for it too.

Basically, just about everyone is affected.

OpenSSL is a permanent source of embarrassment

[Anonymous Coward]

Let's itemize some of its problems:

    - A codebase that seems to have been implemented by a bunch of retards.
    - A documentation that is pitiful most of the time, and misleading the rest of the time.
    - A constant source of deeply serious bugs.
    - An absurdly complex, and very poorly documented, API that insists in forcing the application programmer to deal with aspects of the SSL/TLS protocol that ought to have been sorted out by the library.

The fact that so much of the security of the Internet depends on this sorry piece of software is scary and depressing.
   

how about libressl?

[Anonymous Coward]

how about libressl?

OpenVPN

[manu0601]

Is OpenVPN affected?

Re:OpenVPN

[Anonymous Coward]

It's safe as long as you also use tls-auth

many eyes, my ass!

[Anonymous Coward]

open source fucking sucks, it's a failed experiment.

Re:many eyes, my ass!

[Anonymous Coward]

Yeah, Windows works far much better...that is why I dont use it.

Thank you for saving me time.

[Anonymous Coward]

Thank you for saving me time. He is a dangerous idiot, unfortunately like 90% or so of drivers. What you said is exactly 100% correct. I would give you a higher percentage but there is a limit ;-)

Driving is a cooperative endeavor, and when you speed you are not just breaking the law, but that covenant. Someone else driving at above the speed limit makes it harder for less skilled drivers, thus clearly contributing to greater danger for everyone.

Re:Thank you for saving me time.

[bluefoxlucid]

And your insurance company thinks driving slow is dangerous.

OpenSSL NSA

[Anonymous Coward]

Instead of attempting to rewrite OpenSSL can't some leaker just send us the patches the NSA uses on Linux installations?

Re:OpenSSL NSA

[Anonymous Coward]

Instead of attempting to rewrite OpenSSL can't some leaker just send us the patches the NSA uses on Linux installations?

The problem isn't that not enough eyes are looking at the source it's that the fixes aren't being contributed back ;)

So is there a fix?

[Anonymous Coward]

The blurb mentions a problem, but not a patch or fix. The heartblead notice came out with a new version (the new version came out the day they announced the vulnerability). Its this just a notice without a fix?

OK, the bug comes with patch version h.

[Anonymous Coward]

The patch comes with patch version "h". I just built it for Linux (ubuntu 14.04 with kernel 3.15.0-rc8). I should be able to incorporate it in my website within 45 minutes or so (it takes that long for a corei7 to build the 26 pieces of software I use for my site including apr, apr-util, curl, fftw, gmp, Imagemagick, lcms, libevent, libmcrypt, libmemcached, libpng, libtool, libxml2, libxslt, lua, mcrypt, memcached, mhash, modsecurity, openssl, pcre, re2c, t1lib, mariadb, apache, mariadb, and php.

Re Versions

[donaldm]

I run Fedora 20 and have just got the latest upgrade of SSL. Yesterday it was:
openssl-libs-1.0.1e-37.fc20.1.x86_64
openssl-1.0.1e-37.fc20.1.x86_64
With the last entry in the "libs" change log being Mon Apr 07 2014.

Today:
openssl-libs-1.0.1e-38.fc20.x86_64
openssl-1.0.1e-38.fc20.x86_64

From the "libs" changelog (removed the accents from the name):
* Thu Jun 05 2014 Tomas Mraz 1.0.1e-38
- fix CVE-2010-5298 - possible use of memory after free
- fix CVE-2014-0195 - buffer overflow via invalid DTLS fragment
- fix CVE-2014-0198 - possible NULL pointer dereference
- fix CVE-2014-0221 - DoS from invalid DTLS handshake packet
- fix CVE-2014-0224 - SSL/TLS MITM vulnerability
- fix CVE-2014-3470 - client-side DoS when using anonymous ECDH

Not bad a fix, virtually on the same day the vulnerability is announced. Of course in a production environment you should not be using Fedora but if you are using Redhat there is a fix already, however any self respecting System Admin should now be raising change requests to upgrade the relevant packages (you most likely don't even need a reboot although managers normally feel better with one) after checking with their software support. Actually the same procedures should apply for any Linux distribution that is used in a production environment.

I suppose the NSA didn't know about this one

[Anonymous Coward]

I suppose the NSA didn't know about this one as well ?

Rather...

[Anonymous Coward]

Any code that has finalized it's development and only has bugfixes, not new features/code can be auditable and secure.

Any project with random new features added in a non-development, and non-major version builds should be considered suspect as a matter of course.

Unfortunately very few projects hold to the stable/development cycle and especially open source projects are prone to 'bleeding edgism' since that's what pays developers bills, not creating a well architected piece of code that will require no other changes other than to fix preexisting bugs.