Slashdot Mirror

This is, again, why I have an iPhone

Yes, because no iphone has ever had a security vulnerability, now or in the future. It's impossible, IOS is simply impossible to hack, spoof, or do anything bad to, ever. It just can't be done, there is no way to do it. No one has ever hacked an IOS device and no one ever will. Ever. It's just completely out of the question. The words "vulnerability" and "IOS" should never even be found in the same paragraph, let alone the same sentence. IOS has never had a security vulnerability and never will, updates are strictly there to add exciting new features. Everyone knows that.

This is, again, why I have an iPhone

Yes, because no iphone has ever had a security vulnerability, now or in the future. It's impossible, IOS is simply impossible to hack, spoof, or do anything bad to, ever. It just can't be done, there is no way to do it. No one has ever hacked an IOS device and no one ever will. Ever. It's just completely out of the question. The words "vulnerability" and "IOS" should never even be found in the same paragraph, let alone the same sentence. IOS has never had a security vulnerability and never will, updates are strictly there to add exciting new features. Everyone knows that.

This is, again, why I have an iPhone

Yes, because no iphone has ever had a security vulnerability, now or in the future. It's impossible, IOS is simply impossible to hack, spoof, or do anything bad to, ever. It just can't be done, there is no way to do it. No one has ever hacked an IOS device and no one ever will. Ever. It's just completely out of the question. The words "vulnerability" and "IOS" should never even be found in the same paragraph, let alone the same sentence. IOS has never had a security vulnerability and never will, updates are strictly there to add exciting new features. Everyone knows that.

This is, again, why I have an iPhone.

FTFY.

since it is much harder to hide nefarious features inside code that can be publicly inspected

Not THAT crap again.

Heartbleed should put that right to bed.

I don't understand your point here. It was found and then fixed in a few days, and the patches were widely released to anyone willing to update. The system worked exactly like it was supposed to: the fact that a single critical bug garned that much attention should give you an idea of how uncommon it is.

In contrast, Adobe Reader has had not one, not two, but 26 different cripplingly severe vulnerabilities in the last six months alone, and that's only because I got tired of counting after #26. How many people patch Adobe Reader? Would you like to compare Libreoffice to Microsoft Word, FreeBSD to Windows, or Internet Explorer to Firefox? Maybe Apache to IIS, or perhaps OpenJDK to Sun java? Amarok to Itunes? Our very own Adobe Reader to Okular or Evince?

Open source software does indeed have a demonstrably better security record than closed source software, that is undeniable. Further more, even if it didn't, it wouldn't matter because the statement was that it was easier to discover vulnerabilities in open wource software. And he's right. What do you rather do: read source code, or dissassemble a binary?

"the metric doesn't measure deployed instances, or usage, or even active interest", Yes nobody publishes this, so why are you so shocked that this study doesn't? Wouldn't you be more shocked and tin foil if someone actually was measuring backoffice service usage universally?

Your second paragraph is rank with hyperbole without any quantifiable links for verification, so... At least the article source actually tells us their methodology instead of just spewing crap assumptions.

This is how you could have quantified results:
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...

"the metric doesn't measure deployed instances, or usage, or even active interest", Yes nobody publishes this, so why are you so shocked that this study doesn't? Wouldn't you be more shocked and tin foil if someone actually was measuring backoffice service usage universally?

Your second paragraph is rank with hyperbole without any quantifiable links for verification, so... At least the article source actually tells us their methodology instead of just spewing crap assumptions.

This is how you could have quantified results:
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...

"the metric doesn't measure deployed instances, or usage, or even active interest", Yes nobody publishes this, so why are you so shocked that this study doesn't? Wouldn't you be more shocked and tin foil if someone actually was measuring backoffice service usage universally?

Your second paragraph is rank with hyperbole without any quantifiable links for verification, so... At least the article source actually tells us their methodology instead of just spewing crap assumptions.

This is how you could have quantified results:
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...

"the metric doesn't measure deployed instances, or usage, or even active interest", Yes nobody publishes this, so why are you so shocked that this study doesn't? Wouldn't you be more shocked and tin foil if someone actually was measuring backoffice service usage universally?

Your second paragraph is rank with hyperbole without any quantifiable links for verification, so... At least the article source actually tells us their methodology instead of just spewing crap assumptions.

This is how you could have quantified results:
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...

"the metric doesn't measure deployed instances, or usage, or even active interest", Yes nobody publishes this, so why are you so shocked that this study doesn't? Wouldn't you be more shocked and tin foil if someone actually was measuring backoffice service usage universally?

Your second paragraph is rank with hyperbole without any quantifiable links for verification, so... At least the article source actually tells us their methodology instead of just spewing crap assumptions.

This is how you could have quantified results:
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...
https://www.cvedetails.com/pro...

You're a fucking moron. Here's a nice example demonstrating that fact. Many other examples exist. -PCP

How long to you think it will be until the first major exploit surfaces?

Looks like it's already happened.

Unfortunately, I don't know that they provide this information in a specific field in the NVD. I mostly get remediation information from our scanner reports or by reading the actual responses/bulletins.

I know that the CVSS v3 specification has a Remediation Level field, but that hasn't been rolled out yet.

It is good that Apple seems to be cleaning up vulnerabilities, although it should be noted that fixing the problems only takes effect if the users are running a version of the software that is patched with the fixes. Apple, I am sure, does its best to ensure updates are installed, but providing a fix does not actually clean the system unless used.

If you want to see pretty graphs and a bit easier read, you can look at: http://www.cvedetails.com/prod...

It's a third party site, so you want to backcheck what information it provides, but it should give you data about any product you like. Apple has 102 products listed there, which includes iOS and OSX, but also things like Bonjour and applications its provides.

Keep drinking the kool-aid

Keep drowning in bullshit. The fact alone that you would have to provide a good dozen links on that site to defragment all the Android vulnerabilities shows how fucking lost you are.

Keep drinking the kool-aid

Remember when we just had to worry about making things functional? It's hard to imagine that just a few decades ago, someone thought it was a great idea if, when you inserted a CD (later DVD, then USB drive) your computer would automatically execute binaries found on that media? Or that you could attach a random executable to an e-mail, send it to anyone in the world, and they could execute said binary with a single click? Remember when Windows computers were attached to the internet with default ports open, so anyone on the internet could see whatever drives and printers they decided to share? How about embedding scripting languages inside documents? Automatically executing binary plugins on the web? Neat stuff!

This was the era in which these technologies were born.

Take a look at this list of vulnerabilities in Acrobat Reader and just shake your head. 434 and counting. Since PDF was invented in 1991 (and presumably Acrobat came shortly after), that's on average a new vulnerability discovered every 20 days over the past 24 years.

Flash is already well ahead at 568 and counting. That's a new vulnerability found every 12 days over the past 19 years. Go Flash!

Remember when we just had to worry about making things functional? It's hard to imagine that just a few decades ago, someone thought it was a great idea if, when you inserted a CD (later DVD, then USB drive) your computer would automatically execute binaries found on that media? Or that you could attach a random executable to an e-mail, send it to anyone in the world, and they could execute said binary with a single click? Remember when Windows computers were attached to the internet with default ports open, so anyone on the internet could see whatever drives and printers they decided to share? How about embedding scripting languages inside documents? Automatically executing binary plugins on the web? Neat stuff!

This was the era in which these technologies were born.

Take a look at this list of vulnerabilities in Acrobat Reader and just shake your head. 434 and counting. Since PDF was invented in 1991 (and presumably Acrobat came shortly after), that's on average a new vulnerability discovered every 20 days over the past 24 years.

Flash is already well ahead at 568 and counting. That's a new vulnerability found every 12 days over the past 19 years. Go Flash!

Show me again which internet browser is perfect and never has any vulnerabilities because I can't seem to remember?

W3M

Oh wait, there were 5 total W3M vulnerabilities

Safari does not do either of these things.

Ah the RDF.

1. There is plenty of safari-specific CSS that renders improperly in competitors' browsers (the same is true of IE, Chrome and Firefox as well). Back in the late 90s/early 00s the problem was you do things the IE way or the Netscape way, many of which were non-standard. Nowadays browsers still introduce their own extensions and ways of doing things with different quirks hence the safari/webkit/chrome/ie/etc CSS prefixes.

2. Here you will find pages and pages disproving you.

Note: All the browsers have such problems, not just Safari. Just calling you out on your false idea that Safari doesn't suffer the problems of other browsers. The point of this article is that Safari is becoming the new IE in the sense that with respect to industry collaboration they are behaving like Microsoft did with early IE. Try not to extrapolate beyond that.

Avoid security vulnerabilities.

It may not be HTML's job, but certain basics still need to be understood, such as where you load JS from, and what you can access when in HTTPS mode versus HTTP, and why those things matter. 99% of HTML "devs" do not understand a thing about those scenarios. Anyone that says Ruby is secure doesn't have a clue. Python? Seriously? They may have started taking it more seriously, but how seriously can you take a system that doesn't even verify certificates in 2015? (Since it was reported in Dec 2014, and I'm guessing it wasn't a 1 day fix)

Nah. The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used. The other forks, especially LibreSSL and Google's BoringSSL, will be used, too... and that's a good thing. Three fairly API-compatible but differing implementations will break up the monoculture so bugs found in one of them (and they *will* have bugs) hopefully won't hit all three of them. It's tempting to see such apparent duplication of effort as wasteful, but it's really not. Diversity is good and competition is good.

Has the fact that there's three major BSDs and one Linux been in BSD's favor? I have to pick an implementation and live with its bugs, either my machine is compromised or it's not. And those using other implementations will be hit with other bugs compromising their machines. Does it really provide any tangible benefit that not all of us are hit at the same time with the same bug, when we're all vulnerable some of the time? You divide the number of targets, but you also divide the number of developers and testers. For that matter, the eyes in "many eyes makes all bugs shallow" as well. And if you think the only true test is the test of time, the total value and exposure to the bad guys.

Am I supposed to swap browsers every time a vulnerability is found in Firefox/Chrome/Safari/IE? And wouldn't that quickly lead to a monoculture as a project dies every time it screws up big? Or if not, what exactly are the other implementations going to do for me? Software isn't like experimental physics where you want independent verification that if you try the same thing you get the same result. It's more like math where you need a formal proof that the code will always do what you intend for it to do and that it stands up under scrutiny.

We're not talking about something that must have a fail rate, if you get it right it's good. For example look at Apache and IIS, they're massively exposed yet there's very, very few exploits of significance. Okay so that's two not one implementation, but lack of diversity is mostly a problem when you have one bad product like java or flash that is a serial offender. Nobody has a problem with a monoculture that works and there's many of those. Don't allow crap in, code defensively, have reviews and fix the security bugs that get past you in a timely fashion and there won't be any need to reinvent the wheel.

Nah. The OpenSSL codebase will get cleaned up and become trustworthy, and it'll continue to be used. The other forks, especially LibreSSL and Google's BoringSSL, will be used, too... and that's a good thing. Three fairly API-compatible but differing implementations will break up the monoculture so bugs found in one of them (and they *will* have bugs) hopefully won't hit all three of them. It's tempting to see such apparent duplication of effort as wasteful, but it's really not. Diversity is good and competition is good.

Has the fact that there's three major BSDs and one Linux been in BSD's favor? I have to pick an implementation and live with its bugs, either my machine is compromised or it's not. And those using other implementations will be hit with other bugs compromising their machines. Does it really provide any tangible benefit that not all of us are hit at the same time with the same bug, when we're all vulnerable some of the time? You divide the number of targets, but you also divide the number of developers and testers. For that matter, the eyes in "many eyes makes all bugs shallow" as well. And if you think the only true test is the test of time, the total value and exposure to the bad guys.

Am I supposed to swap browsers every time a vulnerability is found in Firefox/Chrome/Safari/IE? And wouldn't that quickly lead to a monoculture as a project dies every time it screws up big? Or if not, what exactly are the other implementations going to do for me? Software isn't like experimental physics where you want independent verification that if you try the same thing you get the same result. It's more like math where you need a formal proof that the code will always do what you intend for it to do and that it stands up under scrutiny.

We're not talking about something that must have a fail rate, if you get it right it's good. For example look at Apache and IIS, they're massively exposed yet there's very, very few exploits of significance. Okay so that's two not one implementation, but lack of diversity is mostly a problem when you have one bad product like java or flash that is a serial offender. Nobody has a problem with a monoculture that works and there's many of those. Don't allow crap in, code defensively, have reviews and fix the security bugs that get past you in a timely fashion and there won't be any need to reinvent the wheel.

You're a bit behind the times. Both Linux and OS X are now more vulnerable operating systems than Windows.

Show me one Linux vulnerability in the last year that didn't require a highly skilled attacker combined with a set of highly unlikely conditions, or rely on the system to be poorly configured. Hell, forget the year limit. Show me one from within the last decade. Good Luck!

I guess you've forgotten about this. Or you can search for ShellShock or Heartbleed. And then there are the kernel bugs that cause race conditions last December, or last May's bug that allows users to get privileged access or do a DoS, not too good in a shared hosting / shared server environment. This bug has nothing to do with a "poorly configured system". It's a flaw.

Here's the security vulnerability list for the linux kernel for 2014, with 133 bugs.

Some of these bugs made the evening news, so I don't know how you missed them all,

So OpenBSD had 147 vulnerabilities between 1999 and 2015.

Debian, the best of the Linux distros, had 234 vulnerabilities between 1999 and 2015.

Firefox, which is arguably simpler than both OpenBSD and Debian, managed a whopping 1173 vulnerabilities between just 2003 and 2015.

OpenBSD is clearly doing something right. Mozilla is clearly doing something totally wrong.

So OpenBSD had 147 vulnerabilities between 1999 and 2015.

Debian, the best of the Linux distros, had 234 vulnerabilities between 1999 and 2015.

Firefox, which is arguably simpler than both OpenBSD and Debian, managed a whopping 1173 vulnerabilities between just 2003 and 2015.

OpenBSD is clearly doing something right. Mozilla is clearly doing something totally wrong.

Here's the list, though a few are mis-filed (the arbitrary code execution from this year is actually in Flash, no idea why it appears here), but most of the privilege elevation ones from this year and most of the arbitrary code execution vulnerabilities are real (though several seem to be in Logitech HID drivers).

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Gentoo Linux had more bugs than IE in 2014, 350 to 289 so not even close.

You're comparing an operating system distro to a browser. You do realize that don't you? For a better comparison try Firefox vs IE: 171 vs 289.

In fact as of March this year both Apple and Linux have more bugs than Windows, again by pretty large amounts. For those wanting the figures and don't want to read TFL? OSX is the worst at 147 followed by iOS at 127, Linux at 119, and Windows, which the Linux faithful are always screaming is "full of bugs"? A grand total of...38.

RHEL from 2002 to Q1: 2015: 286, Ubuntu latest LTS: 66, Debian: 214. Compare those to Windows 2008 from 2007-2015: 524, or Windows 2012 from 2012 to Q1 2015: 133, and of course Windows 8.1: 82

Firefox doesnt look so hot when you look at the number of CVEs, particularly remote code execution:

http://www.cvedetails.com/prod...
http://www.cvedetails.com/vers...

It beats IE 11 by a small margin in RCEs, but loses in total vulns. Its really not that great of a browser, lacking common security mechanisms like plugin isolation.

Firefox doesnt look so hot when you look at the number of CVEs, particularly remote code execution:

http://www.cvedetails.com/prod...
http://www.cvedetails.com/vers...

It beats IE 11 by a small margin in RCEs, but loses in total vulns. Its really not that great of a browser, lacking common security mechanisms like plugin isolation.

Showing a static page involves rendering what amounts to a specialized form of code. Even browsers without javascript like Lynx have code execution CVEs-- and thats a browser that isnt even being fuzzed that hard.

Trivially detected by a "modern language"? So then how do you explain away all of these security holes in a framework written in one of these supposed "modern languages"?

The webpage linked shows precisely ONE router model. Or, am I blind?

http://www.cvedetails.com/cve/...

They didn't provide a fact, they expressed an opinion. It's an irrelevant opinion given that other database servers also have had vulnerabilities.

And on server-side, it's as secure as anything. Probably more secure, as you get none of the memory issues or buffer overflow issues

Seriously? Have you looked at the CVEs for Java severside anytime recently?

http://www.cvedetails.com/prod...

For example:
The Double.parseDouble method in Java Runtime Environment (JRE) in Oracle Java SE and Java for Business 6 Update 23 and earlier, 5.0 Update 27 and earlier, and 1.4.2_29 and earlier, as used in OpenJDK, Apache, JBossweb, and other products, allows remote attackers to cause a denial of service via a crafted string that triggers an infinite loop of estimations during conversion to a double-precision binary floating-point number, as demonstrated using 2.2250738585072012e-308.

or an oldie that you'll appreciate given your criticism of C/C++ :-)

Integer overflow in the embedded ICC profile image parser in Sun Java Development Kit (JDK) before 1.5.0_11-b03 and 1.6.x before 1.6.0_01-b06, and Sun Java Runtime Environment in JDK and JRE 6, JDK and JRE 5.0 Update 10 and earlier, SDK and JRE 1.4.2_14 and earlier, and SDK and JRE 1.3.1_20 and earlier, allows remote attackers to execute arbitrary code or cause a denial of service (JVM crash) via a crafted JPEG or BMP file that triggers a buffer overflow.

Simple fact: *nothing* is as secure as you think, that's why you have to design your architecture with layers in mind. This applies to Java just as much as any other platform.

You download a program that appears legit (and may be mostly legit, or be a hacked version of a legit program), and are running it.

But why would I do that?

Ok, try this: You browse the Internet using Firefox. Lots of vulnerabilities discovered each month, 4 remote code executions already in 2015. An attacker has infected an add or a legitimate or fringe site you visit. Attack code executes and the attacker now runs his code in your Firefox. The malicious code hooks into X. The code can intercept the lock screen, but it can *also* monitor each and every keystroke entered into ANY other window - including terminal windows - without you noticing it. Lock the screen and unlock it and your password is compromised. Run a sudo in a terminal window and you are pwned!

How's that?

Then again, I haven't seen too many security patches for gcc or libstdc++ or glibc

Then have a closer look.

For #2, I know at least fail2ban had a security exploit. so far sshguard has not. I would be cautious about installing these as sometimes the defense itself can introduce new security problems!

Most of the fail2ban exploits have been DoS, and the one that wasn't required a nonstandard installation.

Nevertheless, that is a really good piece of advice. "Keep it simple, stupid" is (or should be) the core mantra of the security field. Reacting to events (banning IPs trying to brute force passwords) is almost never as good of a solution as not needing to react to events (not (only) accepting passwords in the first place).

I see nobody has mentioned that if they for some reason suspected/knew that server was the SR server (how? that is another question) then getting access to PHPmyadmin might have been almost as good as getting root access to the box.. http://www.cvedetails.com/vuln... The screenshot in the article does not indicate exactly what version of PHPmyadmin was used, so we do now know if they used a known security hole or not to get at it. And we can only guess how they knew that they should visit that IP in the first place. It could of course be that someone (NSA?) scanning the internets for /phpmyadmin/ found that it was exploitable and looked at what was there and noticed it was the SR. Who knows. One thing we can know for sure is that anyone who has a public-facing webserver can grep for /phpmyadmin/ in their log (regardless of what is actually there) and see dozens and dozens of access attempts daily.

I know the phone well.

Battery life, camera, sound quality, gps resolution aren't as good. You have to root the phone to be able to control your privacy, and if you're talking about privacy, forget Google apps. Best go go Cyanogenmod.

Wasn't your last update was 10 months ago? http://www.engadget.com/2013/10/31/google-galaxy-nexus-kitkat/, https://en.wikipedia.org/wiki/Android_Jelly_Bean

Leaving three unpatched vulerabilities?

http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/version_id-161187/Google-Android-4.3.1.html

A while back synology had a problem with unauthorized bitcoin miners running on their devices:

http://www.cvedetails.com/vuln...

There seems to be a culture of fast and loose with regards to software development at Synology.

I love my Synology NAS, but you have to be nuts to put these things on the internet.

The OpenSSH security track record is excellent, almost perfect.

And yet OpenSSH also has its share of vulnerabilities:

http://www.cvedetails.com/vulnerability-list/vendor_id-7161/product_id-12081/Openssh-Openssh.html

Sure, none of those happened to be a total compromise, but that's basically luck. Consider:

"The key_certify function in usr.bin/ssh/key.c in OpenSSH 5.6 and 5.7, when generating legacy certificates using the -t command-line option in ssh-keygen, does not initialize the nonce field, which might allow remote attackers to obtain sensitive stack memory contents or make it easier to conduct hash collision attacks. "

Bugs happen in all software. :)

As a orthogonal point, weirdly the OpenSSL CVE score is only 5.0...

http://www.cvedetails.com/vulnerability-list/vendor_id-217/Openssl.html

Perhaps the money is going to a more qualified team, the OpenBSD team

http://www.cvedetails.com/vuln...

Only 2 years? Pretty quick for uninteresting part of code. For comparison, there were 88 bugs fixed in 13 year old Windows XP last year, and most of those bugs were dragged for all 13 years from version to version, ending up even in Win7/Win8.

Thanks, that's a load off my mind. Now all we have to worry about is the X thousand other critical priv escalations in Windows OSs because the codebase is proprietary.

Wonder how many times this one was used before it was found:
http://www.cvedetails.com/cve/...