Bitcoin Forum

In the 0.6.3 thread Graet asks a good question:  what's do we mean by "critical" versus "serious" vulnerability?

Here's what those terms mean to me.  All examples are hypothetical:

A critical vulnerability is one that will have disastrous consequences if it is exploited. Examples might be a remote code exploit, a bug that somebody could use to take down the entire bitcoin network, or a bug that could be exploited to steal your entire wallet.

A serious vulnerability is one that will have serious consequences if it is exploited.  Examples might be a bug that can be triggered by network traffic and will cause the software to stop working or a bug that could be exploited to misdirect your next bitcoin transaction so it goes to an attacker instead of the intended recipient.

The 0.6.3 denial-of-service problem I consider "serious" -- an attacker who figures out exactly what the vulnerability is (we haven't disclosed that yet) can make bitcoind or Bitcoin-Qt stop processing transactions.

Then there are run-of-the-mill vulnerabilities; things like Sybil attacks that require an attacker to round up hundreds or thousands of machines, or denial-of-service attacks that require that the attacker be able to send the victim gigabytes of network traffic. Dealing with these often doesn't even merit a mention in the release notes, because they affect so few people and require an attacker willing to spend a fair bit of money and/or effort just to be annoying.

Good to know, thanks again for your superb work !
(small donation sent)

I think that critical/serious definition given here sounds fine, though I wonder if I'll remember it— especially if people come up with a number of similar sounding names.

The problems with names is that always get confused, people spend time arguing over them, and people get hurt when they misunderstand them, this is one of the reasons that CVSS (http://nvd.nist.gov/cvss.cfm?calculator&version=2) was created— though I've run some example Bitcoin cases through the standard scoring criteria and I think it gives broken results. (E.g. giving more sever ratings for technically easy attacker-effort-proportional DOS attacks than for harder coin theft attacks).

My preference is to actually state what the risks is  "An attacker can crash your Bitcoin if he connects to it"  vs an opaque "Code yellow" kind of label,  at least where being descriptive won't imperil people.   This avoids getting stuck in word games over "serious" vs "severe" and other such matters of angels dancing on pins, and allows people to assess their own risks in ways that no boilerplate classification can do.

I suspect that any issue where you can't even say as much as what an attacker could do without unacceptable risk is by definition the most severe kind, Critical, or whatever you'd like to call it.

Why not introduce something like risk or even better severity levels / rating, however they may be called.

E.g.

Level 1 (highest)
Level 2 (medium)
Level 3 (lowest)

Now we would need to define what conditions or characteristics imply which rating.

E.g. (only examples, didn't bother thinking in detail for now)

Level 1:
- remote code execution
- take the whole Bitcoin network offline
- steal all coins

Level 2:
- slow down the Bitcoin network
- steal coins

Level 3:
- crash a node without further code execution
- DoS single nodes

So we have a table, which defines the severity. Now consider a vulnerability, which can lead to stealing coins and crashes the client without code exec, this would be a Level 2 vunlerability (highest condition counts). I think this can be worked out by the devs with input from users to create a transparent catalog. As an example take a look what MS does: http://technet.microsoft.com/en-us/security/gg309177.aspx

Dia

Good starting point.

We have to add to the levels the required resources needed for the attack. Sometimes it requires very few, some times it requires massive amounts. Also taking down the entire Bitcoin network at once is far worse than remote code execution.

My list would be:

Level 1:
- Take the whole Bitcoin network offline (DoS)
- Steal coins from all or a subset of users at once

Level 2:
- Remote code execution (of single nodes)
- Steal coins from single users

Level 3:
- Slow down or temporally disrupt the Bitcoin network
- Crash a node without further code execution
- DoS single nodes

Level 4:
- Lost of privacy / pseudo-anonymity of single nodes.

DoS single nodes seems equivalent to disrupt the Bitcoin network, since you can prevent users from connecting by taken down each node that accepts connections.
What do you think?

There are really only two cases:

1. People could lose bitcoins
2. The network could be disrupted.

Gavin's original post included these two examples:

(a) a bug that could be exploited to steal your entire wallet ("critical")
(b) a bug that could be exploited to misdirect your next bitcoin transaction so it goes to an attacker ("serious")

As far as I'm concerned, those bugs are of the same level of seriousness: "people could lose bitcoins".

I think "1 2 3 4" is bad.  4 is more than 1, so a level 4 vulnerability is worse, right?

I still like critical/serious/other.  More gradations than that and I think we'll just waste time arguing over "is this a level 3 vulnerability?  level 4?  ok, let's make it a pi vulnerability (3.1415...)"

Let's use complex numbers. The imaginary part is the assumed mass histeria the bug will cause.

"We consider this bug to have severity log(-1)."

Let's use sounds (scream, shout, whisper ) or maybe odors....

I agree with the sentiment that descriptions of what can happen is more useful than generic severity levels. Could we make buckets for the likely scenarios? Categorize into: Wallet Theft, Remote Code Execution, Next Transaction Theft, Incorrect Coin Creation, Low-Effort DOS, Information Disclosure, Other, or Unknown?

Though, even with that, I'm not sure where the "encrypted wallets still had unencrypted keys in them" vulnerability would have gone, or the "blocks weren't checked during downloading" problem (assuming that it had security implications, which I'm still not sure of).

Description based levels of vulnerabilities like what MS used below offers the better clarity of any other number-based (1,2,3,4) levels.