lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: coley at mitre.org (Steven M. Christey) Subject: RE: The new Microsoft math: 1 patch for 14 vulnerabilities, MS04-011 > Well, which is it? 3, 21, 20, "over 30", "at least 20"? As we've learned in CVE, there are legitimate reasons for any of these numbers, such as: 1) The "role" of the person viewing the numbers. For example, an IDS person may care about each individual attack vector; a sysadmin may only care about the number of patches to apply; a vendor may want to reduce the "information overload" for customers; a detail-oriented vulnerability researcher may care about the number of underlying issues, in which a single program error could have many attack vectors, etc. 2) The amount of detail available for the issue(s). This isn't necessarily an open- vs. closed-source thing, either; for example, the just-announced neon vulnerability (CAN-2004-0179) has "various format string vulnerabilities," but even if you put in the effort to dig up the source and do a diff, how many of those bugs are actually reachable/controllable by an attacker? And PROTOS-style vulnerability analyses are often so effective that they have the interesting dichotomy of being simultaneously replete and dereft of details (e.g. here are 2000 test cases, but which vendor was affected by test case number 472?) 3) The maturity of the vulnerability information. The understanding of a vulnerability can change over time, and new information can result in a re-assessment (and perhaps re-counting) of the vulnerability/ies. 4) Something a little more subtle: the intention/programming style of the software developer. Example: suppose you have an application that manages files, and there is a development "policy" of trimming long file names. It forgets to do this in one particular routine in the code, which leads to buffer overflows in two lower-level functions that assume that the filename has been trimmed. Is that one vulnerability or two? (We're excluding the question of whether the underlying design choices count as vulnerabilities themselves.) There are likely others that don't immediately pop into mind. At this point in time, the best way to "count" vulnerabilities is to look within the advisories and use a sufficiently consistent mechanism to NORMALIZE how many vulnerabilities there are. That's one of our main goals in CVE, as reflected in its content decisions, but most "vulnerability databases" (or similar resources) have their own consistency rules. - Steve
Powered by blists - more mailing lists