|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] CD PROPOSAL: Content Decisions for Software Flaws (Interim 8/30)
I have taken the original 5 content decisions related to software flaws and whittled them down to these three. A significant number of candidates could be affected by these content decisions, at least 100. Rapid resolution will significantly help us to have 300 accepted candidates by the SANS big splash. Please vote to ACCEPT, MODIFY, or REJECT each content decision by the scheduled Interim Decision of August 30. I am providing these in the same email in an attempt to reduce the traffic on this list. VOTE ---- SF-LOC: SF-CODEBASE: SF-EXEC: DESCRIPTIONS ------------ 1) Different Line of Code, Different Vulnerability (SF-LOC) Distinguish between vulnerabilities that appear in the same program, but require different modifications to the source code to fix. (Informally, distinguish between different bugs.) 2) Same Codebase, Same Vulnerability (SF-CODEBASE) Do not distinguish between vulnerabilities that have been derived from the same codebase, even if they appear on different platforms or software versions. For vulnerabilities that affect multiple codebases, "roll up" the codebases into a single CVE entry, and use Dot Notation to identify each separate codebase. This is done because separating codebases can be error-prone. The dot notation allows the CVE to maintain accuracy, while providing the precision that is required of this content decision. If the bug is in a library/DLL, then the software that uses that library is NOT discriminated, because the library is effectively the "same codebase." 3) Different Executables, Different Vulnerability (SF-EXEC) If a vulnerability appears in multiple executables which perform different functions, and it does not occur in a library that is shared by those executables, then distinguish them. Executables are not distinguished by OS, except as dictated by SF-CODEBASE. SF-CODEBASE and SF-EXEC may appear very similar. The distinction is that in SF-CODEBASE, we identify a "module" (e.g. program or application) coming from a single source, where the affected portion of that module has been preserved even as the module is modified over the years by various vendors. Each "module" covered by SF-CODEBASE does effectively the same thing, functionally. SF-EXEC covers the cases where a particular coding flaw might be duplicated in multiple programs, e.g. by a cut-and-paste operation, but each program does something functionally different. Informally, SF-CODEBASE separates two functionally similar programs when different programmers made the same mistake. SF-EXEC separates two functionally different programs when different programmers (or even the same programmer) made the same mistake in multiple places. -------------------------------------------------------------------- EXAMPLES -------------------------------------------------------------------- SF-LOC ------ Consider the ColdFusion vulnerabilities related to the Expression Evaluator. An "include" file used by multiple ColdFusion pages allowed an attacker to read or delete files. SF-CODEBASE says not to distinguish between the different ColdFusion pages, since the include file is effectively a library. However, a different capability (not provided in that include file) allows a remote attacker to execute commands by uploading a file. This is a different line of code, thus a different vulnerability. SF-CODEBASE ----------- Consider a buffer overflow in various email clients that decode MIME-formatted messages. A number of clients were affected, including Solaris mailtool, Mutt, Pine, and Outlook. Since all four are conceivably from different codebases, a CVE entry might be created as follows: >Buffer overflow in MIME-compliant email clients, including: > > 1. Solaris mailtool > 2. Mutt > 3. Pine > 4. Outlook On the other hand, the TERM environmental variable buffer overflow in the rlogin program affected many platforms. But the rlogin program was originally written by a single author, thus each instance of rlogin comes from the Same Codebase. So, the associated CVE entry might simply say "Buffer overflow using TERM environmental variable in rlogin" without specifying the affected OSes. SF-EXEC ------- Consider the buffer overflows in the SGI IRIX df, ordist, login/scheme, eject, and pset commands. Each was discovered and patched at a different time, thus they clearly did not share the same library (in which SF-CODEBASE would require combining them). They are different executables that perform different tasks, thus SF-EXEC requires that a separate entry be made for each one.
|
||||
