
New Severity Level, "Critical" - runesoerensen
https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/
======
LoSboccacc
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.

~~~
glass-
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.

~~~
dragonwriter
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.

~~~
tptacek
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!

~~~
dragonwriter
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.

Your point, however, is well made.

------
Someone1234
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.

~~~
tptacek
It's often hard to determine whether a vulnerability is merely a denial of
service vector, which is one reason the descriptions are kept abstract.

~~~
Someone1234
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.

~~~
tptacek
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.

~~~
Someone1234
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.

~~~
tptacek
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.

------
robinhoodexe
Firefox throws an error related to security when connecting. How ironic.

[http://i.imgur.com/WGBQ8U9.png](http://i.imgur.com/WGBQ8U9.png)

~~~
arbitrage
works fine for me.

~~~
ubernostrum
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.

~~~
drdaeman
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.

------
noir_lord
Fast forwards twelve months and we'll have "Ridiculously Critical" and after
that "Ludicrously Critical" and then eventually Plaid.

~~~
SEJeff
True, but that is still better than Vogon poetry

------
adricnet
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!

edit: spell acronyms right!

~~~
tptacek
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.

[https://nvd.nist.gov/CVSS-v2-Calculator](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.

~~~
tedunangst
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!

~~~
tptacek
I gave Heartbleed no integrity impact.

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.

------
GhotiFish
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](https://www.first.org/cvss/calculator/3.0)

------
LukaAl
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".

