[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20020623151417.A2554@openwall.com>
Date: Sun, 23 Jun 2002 15:14:17 +0400
From: Solar Designer <solar@...nwall.com>
To: security-audit@...ret.lmh.ox.ac.uk
Cc: owl-users@...ts.openwall.com, cve@...re.org
Subject: Classifying Vulnerabilities for Risk Assessment
Hi,
As some of you might have noticed, I've been trying to provide a
vulnerability Severity rating in Owl change logs whenever there's a
security fix applied to Owl. So far, I used the following syntax,
as illustrated with a recent example:
2002/05/09 Package: vixie-cron
SECURITY FIX Severity: none to low, local, active
Ensure all files are closed in crontab(1) when the editor is run.
This fixes the problem pointed out by Paul Starzetz on Bugtraq where
crontab(1) could leak read-only access to /etc/cron.{allow,deny} even
if those files are made readable to just group crontab.
For more examples please refer to the Owl-current change logs under
Owl/doc/CHANGES in the native tree or online:
http://www.openwall.com/Owl/CHANGES.shtml
Security fixes are always marked specially. The script producing the
HTML version even uses different colors based on the Severity tag.
Basically, there're three fields: Risk Impact (either worst case or a
range of possibilities, always for default settings and worst case),
physical/local/remote classification of the level of access required
in order to exploit the vulnerability, and passive/active classification
depending on whether an attacker has to wait for an opportunity to use
the vulnerability or may perform an active attack whenever they want.
However, I feel that such a convention for specifying vulnerability
severities is still not as good as we can make it with little effort.
It doesn't let one specify the Risk Type (that goes into the change
description and, with the above scheme, may also affect the declared
Risk Impact) and Risk Probability (which, while typically very
subjective and often environment-specific, is still a useful measure).
What I am thinking to use from now on is a more verbose syntax:
Type: integrity/confidentiality/availability (more than one allowed)
Class: (physical/local to) physical/local/remote, (passive to) passive/active
Impact: (none/low/medium to) low/medium/high
Probability: (none/low/medium to) low/medium/high
Confidence (Uncertainty?): low/medium/high
I'd like some feedback on whether others think this is worth it and,
if yes, advice on the following:
Should Risk Type continue to affect the declared Risk Impact, despite
also being specified separately? Right now, I wouldn't set Risk Impact
to high if I know a vulnerability is just a local DoS. But once that
is specified separately (with "Type: availability" and "Class: local"),
it could make sense to set "Impact: high" for a complete DoS of the
entire OS and "Impact: low" for something limiting the ability to use
just the affected service. Opinions?
Would it be better to use "sensitivity" instead of "confidentiality"?
I've seen both used in the same book and with the same meaning.
The Confidence I meant to indicate the degree of confidence in the
above four elements. For example, the Probability estimate, while
always subjective, could be based on detailed analysis of vulnerable
code and attempts at exploiting the vulnerability (high confidence),
or could be based on attacks happening so far (medium), or could be
just a guess (low).
Would Uncertainty be better than Confidence? Again, both terms are
used (to mean exactly the opposite).
There still exist vulnerabilities which don't fit the above syntax
well. A real example:
2002/03/05 Package: openssh
SECURITY FIX Severity: high, local/remote, active/passive
Patched an off by one channel id check bug discovered by Joost Pol.
The bug could be exploited by either a user able to login into a
vulnerable OpenSSH server or a malicious SSH server attacking a
vulnerable OpenSSH client. If successful, this could let one execute
arbitrary code in the context of the remote server or client process.
That is, there exist attacks which are local and active, and there
exist attacks which are remote, but passive. If I specified remote
and active (worst case for each kind of classification), that would
make the vulnerability appear much worse than it really is.
I don't know of a perfect way to deal with that kind of thing. Is my
use of slashes in the example above clear enough without further
explanation? With the new syntax it would be:
Type: integrity, confidentiality, availability
Class: local/remote, active/passive
Impact: high
Probability: high/low
Confidence: high
Is that clear? Also that the "high" Probability refers to "local"
attacks only? Would it be better to use two Severity tags (making the
change log entry _much_ longer, 10 lines where there used to be 1)?
Should I maybe use a brief form similar to the old syntax, all on one
line, and explain the order of fields in a separate document (there
needs to be one to explain their exact meaning anyway)?
Should some Risk Types imply others, less significant ones? There
could be a vulnerability which allows for write-only access to data
that does not include something the modification of which allows for
further attacks, which means "integrity" and "availability", but not
"confidentiality".
Ideally, I would like to define a classification scheme that would be
usable by more than just Owl and more than just OS distributions, but
also by various vulnerability databases (CVE, SecurityFocus', others).
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
