Future versions of Firefox are going to be much more strict about security and SSL configuration, and some of those changes are already in the nightly/beta/developer-edition builds.
I already know there are some sites I can't use from the developer edition due to things like outdated/insecure cipher suites, but which continue to work in the released version and in other browsers.
Works for me on Fx 41.0, but I had just noticed Mozilla had removed all the useful information from the popup that appears on clicking the padlock icon. The only text here is pointless "secure connection" (even for EV certificates!). Firefox UI team must've gone insane.
Can you translate that error for us? It seems to be
"Secure connection failed
"The connection to www.openssl.org was interrupted while the page was loading."
What certificate do you see, and have you configured any security settings in your browser or installed any custom "security" solutions / MITM proxies on your computer? openssl.org supports only TLS 1.1 and v1.2, so it's possible that some older proxies, DLLs, etc. can interfere.
Can I just say, while I have no specific issue with adding critical or traffic light systems in general:
> The headsup doesn’t contain any details of the issues being fixed apart from the maximum severity level and a date a few days in the future.
Maybe it would be advantageous to include a short summary of the issue (DoS, local security, remote security (exploitable), remote security (unexploitable), etc)? The "bad guys" still wouldn't know where to look, and it isn't like people aren't actively working to find exploits in OpenSSL daily. But this gives the "good guys" information which you yourselves say they need to evaluate the risks to them.
If that were true then this new critical moniker doesn't make sense. The whole justification for them adding it is that they have (past tenths) made that determination.
I don't understand your rebuttal. The "Critical" designation confirms that a vulnerability is known to have applications beyond DOS in real-world configurations. "High" does not; it includes memory corruption vulnerabilities that are believed to be capable only of crashing a process, but not known to be so limited.
You said they cannot put broad notes onto their release because they may not know enough. I am saying that the new critical term has been coined because they claim they do know enough to classify it.
If they cannot make these determinations then the whole high/critical distinction is impossible. They've made a determination in order to categorise them.
Still not following. "Critical" is the term they plan to use when they do know enough to say that there are immediately available better-than-DOS exploit vectors.
I hate the generic sounding levels anyway, they explain nothing. I'd much prefer to see business relevant levels.
Those vulnerability still can fit into nice categories like 'remote code execution' 'denial of service' 'local code execution' 'remote information leak' 'loacal information leak' and those could also directly communicate what the bug is all about without 500 words explanation for each single level.
With those categorisations a maybe-probably-theoretical-phase-of-the-mooon vulnerability such as CVE-2010-1633 gets put into the same category ("remote information leak") as Heartbleed. This is why severity levels exist.
But it seems to me the difference you are pointing to is in probability of the adverse possibility being realized rather than severity of the impact if the adverse possibility is realized. In risk management, these are usually rated on separate axes.
That probability assessment is pretty dangerous to rely on. Lots of vulnerabilities look extremely improbable, until the exploit tool starts to circulate. This is an age-old problem in software security: when you try to score things in a risk management rubric, you wind up hair-on-fire over simple vulnerabilities that managers can understand, and wind up not fixing sophisticated vulnerabilities that will be commonplace among attackers soon.
It's also important to remember that there's a window in which this stuff gets fixed, probably just weeks long, anchored to the announcement of the vulnerability. Once that window passes, any update you're going to see about exploitability is basically going to announce "everyone is now owned". That's a failure of vulnerability scoring!
I don't disagree with the idea that probability has a lower value in this type of software security risk assessment than some others; my point was that probability is a different thing than severity, so that it is not necessarily an error that issues with a different probability of being exploited but similar consequences get the same severity rating.
Okay, so looking over the post they didn't feel like CVSS 2 was giving a clear indication of risk, and CVSS 3 isn't done yet and lacks perfection. That's sensible enough, I suppose.
I hope they took more than a glance at what some other vendors are doing (EG Microsoft) before adding to what can already be a confusing collection of incompatible qualitative ratings :/
As noted by other commenters here a vague description of the category and some idea of the global risk, with a spot for you to add local risk seems a good tool here that serves both attack and defense with some balance. Oh, wait, we have that already in CVSS!
I don't know many practicing software security people that put much stock in CVSS. CVSS v2 in particular was not very useful in practice. Further: there aren't many people even in the security industry that have an intuitive feel for how to respond to CVSS scores.
As an exercise, go to the CVSS v2 calculator and score Heartbleed. I bet you end up with something different than I do, and different from the next person to do it.
I polled my security friends Slack to do Heartbleed on CVSS3. Four different people, four very different scores, and the differences were significant; for instance: some people gave it integrity impact, others didn't. Also: CVSS version 3 remains as inscrutable as ever.
It's very murky whether loss of confidentiality should count as a loss of integrity. Obviously, the answer is almost always yes. If the system coughs up the root password to an exploit, and then you use the root password to rm /, there goes integrity and availability too. But should that be included in the score? Or is that simply a natural consequence that should be understood.
I vote the latter. Otherwise every bug reads like a classic medical waiver: "may result in death!" Severity: 10!
The funny thing is: bumping up "integrity" from zero to nonzero only gets you from 8.x to 9.x. Which is obviously ridiculous! All things being equal, the difference between RCE (which CVSS can only encode as "integrity") and anything else is night and day.
I really dislike CVSS, and I think I speak for a big chunk of software security when I say that.
Ok, probably was just me but when I saw in the title the words "Severity" and "Critical" with the site being openssl.org I thought: "OMG, here we go again".
just as a side note: Check out the CVSS calculator. That's a really straightforward way to classify vulnerabilities. They have tooltips that go into detail about each field: https://www.first.org/cvss/calculator/3.0
30 comments
[ 3.4 ms ] story [ 80.8 ms ] threadhttp://i.imgur.com/WGBQ8U9.png
I already know there are some sites I can't use from the developer edition due to things like outdated/insecure cipher suites, but which continue to work in the released version and in other browsers.
(ingen means 'not' in Swedish)
"Secure connection failed
"The connection to www.openssl.org was interrupted while the page was loading."
What certificate do you see, and have you configured any security settings in your browser or installed any custom "security" solutions / MITM proxies on your computer? openssl.org supports only TLS 1.1 and v1.2, so it's possible that some older proxies, DLLs, etc. can interfere.
> The headsup doesn’t contain any details of the issues being fixed apart from the maximum severity level and a date a few days in the future.
Maybe it would be advantageous to include a short summary of the issue (DoS, local security, remote security (exploitable), remote security (unexploitable), etc)? The "bad guys" still wouldn't know where to look, and it isn't like people aren't actively working to find exploits in OpenSSL daily. But this gives the "good guys" information which you yourselves say they need to evaluate the risks to them.
If they cannot make these determinations then the whole high/critical distinction is impossible. They've made a determination in order to categorise them.
Those vulnerability still can fit into nice categories like 'remote code execution' 'denial of service' 'local code execution' 'remote information leak' 'loacal information leak' and those could also directly communicate what the bug is all about without 500 words explanation for each single level.
It's also important to remember that there's a window in which this stuff gets fixed, probably just weeks long, anchored to the announcement of the vulnerability. Once that window passes, any update you're going to see about exploitability is basically going to announce "everyone is now owned". That's a failure of vulnerability scoring!
Your point, however, is well made.
I hope they took more than a glance at what some other vendors are doing (EG Microsoft) before adding to what can already be a confusing collection of incompatible qualitative ratings :/
As noted by other commenters here a vague description of the category and some idea of the global risk, with a spot for you to add local risk seems a good tool here that serves both attack and defense with some balance. Oh, wait, we have that already in CVSS!
edit: spell acronyms right!
As an exercise, go to the CVSS v2 calculator and score Heartbleed. I bet you end up with something different than I do, and different from the next person to do it.
https://nvd.nist.gov/CVSS-v2-Calculator
Later
I polled my security friends Slack to do Heartbleed on CVSS3. Four different people, four very different scores, and the differences were significant; for instance: some people gave it integrity impact, others didn't. Also: CVSS version 3 remains as inscrutable as ever.
I vote the latter. Otherwise every bug reads like a classic medical waiver: "may result in death!" Severity: 10!
The funny thing is: bumping up "integrity" from zero to nonzero only gets you from 8.x to 9.x. Which is obviously ridiculous! All things being equal, the difference between RCE (which CVSS can only encode as "integrity") and anything else is night and day.
I really dislike CVSS, and I think I speak for a big chunk of software security when I say that.