[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 25 Apr 2009 10:23:01 +0000 (UTC)
From: security curmudgeon <jericho@...rition.org>
To: oss-security@...ts.openwall.com
cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: VDBs (was Re: CVE request: kernel: missing capabilities
in fs_mask)
On Sat, 25 Apr 2009, Eugene Teo wrote:
: >> "When POSIX capabilities were introduced during the 2.1 Linux cycle, the
: >> fs mask, which represents the capabilities which having fsuid==0 is
: >> supposed to grant, did not include CAP_MKNOD and CAP_LINUX_IMMUTABLE.
: >> However, before capabilities the privilege to call these did in fact
: >> depend upon fsuid==0.
: >
: > How is this different than CVE-2009-1072? That CVE is based on the same
: > bug report by Igor Zhbanov, although the description doesn't mention
: > CAP_LINUX_IMMUTABLE.
:
: Hmm. CVE-2009-1072 refers to the missing CAP_MKNOD capability in
: CAP_NFSD_MASK, and this bug refers to the missing CAP_MKNOD and
: CAP_LINUX_IMMUTABLE capabilities in CAP_FS_MASK. Come to think about it,
: both are similar, and probably makes sense to have it part of
: CVE-2009-1072 too?
A question, really?
I'd like to reiterate what Steve Christey said in the last 24 hours, about
the Linux Kernel vulnerabilities becoming a serious drain on CVE.
Historically, OSVDB has relied on Secunia and CVE to sort out the Linux
Kernel vulnerability messes. Both VDBs have full time staff that can
dedicate time to figuring out such nuances as those above.
Not to pick on Eugene specifically, but I feel he makes a great example of
my point. Nuances that a "Senior Security Engineer at Red Hat" who
specialies in "OS and Application Security, Project Management,
Vulnerability Analysis, Code-level Auditing, Penetration Testing, Red Hat
Products and Services, Financial Services Technical Account Management"
cannot definitely distinguish between difference in Kernel
vulnerabilities. If Eugene cannot say with certainty these deserve two CVE
numbers, how can Steve or his staff?
VDBs deal with thousands of vulnerabilities a year, ranging from PHP
applications to Oracle to Windows services to SCADA software to cellular
telephones. We're expected to have a basic understanding of
'vulnerabilities', but this isn't 1995. Software and vulnerabilities have
evolved over the years. They have moved from straight-forward overflows
(before buffer vs stack vs heap vs underflow) and one type of XSS to a
wide variety of issues that are far from trivial to exploit. For fifteen
years, it has been a balancing act for VDBs when including Denial of
Service (DOS) vulnerabilities because the details are often sparse and it
is not clear if an unprivileged user can reasonably affect availability.
Jump to today where the software developers cannot, or will not tell the
masses what the real issue is.
This isn't just a Linux Kernel issue at all. The recent round of
advisories from Mozilla contain obscure wording that allude to "memory
corruption" implying arbitrary code execution. If you follow the links to
the bugzilla reports, the wording becomes a quagmire of terms that not
even the developers can keep up on [1] [2]. That's if they even open the
bugzilla entry reference in the advisory [3]. Again, how are people not
intimately familiar with the code base supposed to understand these
reports and give a reasonable definition of the vulnerability? How do we
translate that mess of coder jargon into a 1 - 10 score for severity?
It is important that VDBs continue to track these issues, and it is great
that we have more insight and contact with the development teams of
various projects. However, this insight and contact has paved the way for
a new set of problems that over-tax an already burdened effort. MITRE
receives almost 5 million dollars a year from the U.S. government to fund
the C*E effort, including CVE [4]. If they cannot keep up with these
vulnerabilities, how do their "competitors", especially free / open source
ones [5], have a chance?
Projects like the Linux Kernel are familiar with CVE entries. Many Linux
distributions are CVE Numbering Authorities, and can assign a CVE entry to
a particular vulnerability. It's time that you (collectively) properly
document and explain vulnerabilities so that VDBs don't have to do the
source code analysis, patch reversals or play 20 questions with the
development team. Provide a clear understanding of what the vulnerability
is so that we may properly document it, and customers can then judge the
severity of issue and act on it accordingly.
I believe this is a case where over-exposure to near-proprietary technical
details of a product have become the antithesis of closed-source vague
disclosures like those from Microsoft or Oracle [6].
Brian
OSVDB.org
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=462517
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=477775
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=478433
[4] Based on FOIA information.
[5] http://opensecurityfoundation.org/
[6] Which are just as difficult to deal with in a totally different way.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
