|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CD] Reconsidering "split-by-default" in content decisions
Following is a writeup of some rationales for a new approach I plan on taking with respect to some content decisions. This will be discussed in more detail at the CVE Board meeting. The short intro is: in mid-2000, Editorial Board members suggested adopting a "split-by-default" approach for handling closely related candidates. For example, if you're not sure whether you should create 1 candidate or 2, then create 2 if you don't have conclusive information. The short thesis is: Split-by-default doesn't work very well for CVE. It's just an accident that the first examples are in Cisco products (seriously), but maybe Andy Balinsky and Kevin Ziese can give us some insider feedback. Similarly for David LeBlanc, as some Microsoft examples follow. This writeup discusses CD:SF-LOC, which covers multiple bugs in the same executable. However, the same principles could be applied to CD:SF-EXEC, which covers the same apparent bug appearing in multiple, closely related executables. - Steve --------------------------------------------------------------------- CD:SF-LOC in action - present and past --------------------------------------------------------------------- Consider these candidates: ====================================================== Candidate: CAN-2001-0019 Proposed: 20010202 Reference: ATSTAKE:A013101-1 Reference: URL:http://www.atstake.com/research/advisories/2001/a013101-1.txt Reference: CISCO:20010131 Cisco Content Services Switch Vulnerability Reference: URL:http://www.cisco.com/warp/public/707/arrowpoint-cli-filesystem-pub.shtml Arrowpoint (aka Cisco Content Services, or CSS) allows local users to cause a denial of service via a long argument to the "show script," "clear script," "show archive," "clear archive," "show log," or "clear log" commands. ====================================================== Candidate: CAN-2001-0020 Proposed: 20010202 Reference: ATSTAKE:A013101-1 Reference: URL:http://www.atstake.com/research/advisories/2001/a013101-1.txt Reference: CISCO:20010131 Cisco Content Services Switch Vulnerability Reference: URL:http://www.cisco.com/warp/public/707/arrowpoint-cli-filesystem-pub.shtml Directory traversal vulnerability in Arrowpoint (aka Cisco Content Services, or CSS) allows local unprivileged users to read arbitrary files via a .. (dot dot) attack. ---------------- I view these as different, since one involves accessing files via .. directory traversal (one type of bug), and another involves effectively a buffer overflow. There are clearly 2 different places in the code in which some error occurs. While it's the same product in both cases, they're effectively 2 different types of bugs, so we create separate candidates. This approach is generally in line with how others distinguish between vulnerabilities. This is a good example of the application of the CD:SF-LOC (software flaws in different lines of code) content decision. Below are the affected bullets from that CD: >The "trigger code" is the specific line in the source code whose >execution affects the system's security. For example, the trigger >code for a buffer overflow might be a call to the strcat() function >which causes the overflow and overwrites a stack pointer > > [...] > >*2) If it can be proven that the trigger code for P1 is different than > the trigger code for P2, then P1 and P2 must remain SPLIT. > > [...] > >6) If the method of exploitation for P1 is significantly different > from the exploitation of P2, then P1 and P2 should be SPLIT. For > example, P1 might appear to be a buffer overflow that is caused by > sending a long command line argument, whereas P2 might follow > symbolic links improperly. So, we've got sufficient reason to separate the apparent buffer overflow from the .. directory traversal problem. However, note that CAN-2001-0019 involves a DoS that is visible through the execution of 6 different commands; the exploit and the result are basically the same. However, CAN-2001-0019 could be 1, 2, or 6 separate bugs, depending on the actual source code. For example, perhaps the piece of code that processes a "show" command is different than the code that processes a "clear" command. Internally, the code might look something like: if (strcmp(cmd, "show") == 0) { /* Buffer overflow 1 */ strcpy(str, long_cmd_argument); process_show_command(str); } elsif (strcmp(cmd, "clear") == 0) { /* Buffer overflow 2 */ strcpy(str, long_cmd_argument); process_clear_command(str); } If the above code is what's "really" going on within the Cisco source code, then one could say that there are 2 different buffer overflows. But then again, the source code could be: /* Buffer overflow 1 */ strcpy(arg, long_cmd_argument); if (strcmp(cmd, "show") == 0) { process_show_command(arg); } elsif (strcmp(cmd, "clear") == 0) { process_show_command(arg); } in which case there's only one point in the code where the overflow occurs. But even still, the code could be: if (strcmp(cmd, "show") == 0) { if (strcmp(arg1, "script") == 0) { /* Buffer overflow 1 */ strcpy(arg2, long_cmd_argument); show_script(arg2); } elsif (strcmp(arg1, "archive") == 0) { /* Buffer overflow 2 */ strcpy(arg2, long_cmd_argument); show_archive(arg2); } elsif (strcmp(arg1, "log") == 0) { /* Buffer overflow 3 */ strcpy(arg2, long_cmd_argument); show_log(arg2); } } elsif (strcmp(cmd, "clear") == 0) { if (strcmp(arg1, "script") == 0) { /* Buffer overflow 1 */ strcpy(arg2, long_cmd_argument); show_script(arg2); } elsif (strcmp(arg1, "archive") == 0) { /* Buffer overflow 2 */ strcpy(arg2, long_cmd_argument); show_archive(arg2); } elsif (strcmp(arg1, "log") == 0) { /* Buffer overflow 3 */ strcpy(arg2, long_cmd_argument); show_log(arg2); } } If this is the case, then there are 6 different buffer overflows. So, depending on the actual source code, we have either 1, 2, or 6 overflows. Ideally, we'd want to create a separate CAN for each separate bug. However, we don't have access to the source code, so we can't tell for sure. The vendor could tell us, but what if they believe it's only 1 problem, even if our content decisions say it would be 6? Last August, the Editorial Board said: "when in doubt, SPLIT," i.e. create separate candidates unless you have solid proof that the issues really stem from the same vulnerable line of code. So, I went ahead and started separating candidates. But this did several things: 1) CVE's level of abstraction (LOA) started becoming a lower level than the LOA of other security databases and tools. In general, CVE should probably live somewhere in the middle. 2) The LOA definitely started getting too low level for system administrator purposes. For example, a sysadmin doesn't necessarily care whether there's 1 buffer overflow or 5, it's more important to know that a particular package has a problem. While system administrators aren't the only type of CVE user out there, they are definitely a major user community, so we should be mindful of them. 3) The LOA would vary depending on the amount of information that was available, e.g. source code or detailed exploit information. Generally, the more information that was available, the more candidates you'd create for closely related issues. Effectively, we wind up penalizing those vendors with open source code, or those who are more closely analyzed. We also end up "helping" vendors who release little or no information at all. This seems backwards. 4) Since "SPLIT by default" is effectively arbitrary, it's probably going to be wrong half the time. Because we're affected by the amount of available information as described in (3) above, split-by-default won't be consistently applied to every vulnerability. 5) It gets more difficult to write descriptions that adequately differentiate between closely related bugs. For example, in OpenBSD, you might have a bug in stdio.c in line 340; but that same bug is in line 476 in stdio.c in FreeBSD, and it's in line 78 in file somethingelse.c in Linux. The poster children for problems 1, 2, 3, and 4 are CAN-2000-1081 through CAN-2000-1088, which describe buffer overflows that are *triggered* through different functions in Microsoft SQL Server. Each function got its own candidate. However, there could be a single point of failure in a piece of code that's shared by all those functions, so maybe it's only 1 bug. Also, all the bugs happen in SQL Server. From a sysadmin's perspective, there's only one major point of concern - vulnerable SQL Server - instead of 8 concerns, which argues for 1 candidate. The poster children for problem 5 are format string problems, which generally seem to be found and fixed in bunches. Since various Unices are doing the fixing, and each Unix has a slightly different code base, identifying and differentiating these becomes near impossible and would require close code evaluation of each affected OS to be accurate. So, I'm backing off of the split-by-default suggestion, and adopting a more consistent approach that's less susceptible to lack of information, "politics," and deep analysis, and is more in line with what I've generally seen in other databases: 1) Create separate candidates for separate types of bugs, e.g. buffer overflows versus .. problems. 2) If P1 and P2 are the same type of bug, *and* they are both present in the same version of software, *and* they are both fixed by the same version (if fixes are available), then create a single candidate for them. 3) If there's a possibility that there are multiple similar bugs as seen through (2), then try to clearly distinguish them in the CVE description, so people will know that it could be multiple bugs. 4) Make the content decisions more directly available to the public, and annotate each CVE item with its associated CD's, so that users can tell which CVE items might be at an "incorrect" level of abstraction. Now, the challenge will be actually discussing this at the face-to-face meeting in March :-) - Steve ====================================================== Candidate: CAN-2000-1081 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1081 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2030 Reference: URL:http://www.securityfocus.com/bid/2030 The xp_displayparamstmt function in SQL Server and Microsoft SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_displayparamstmt, xp_enumresultset, xp_showcolv, and xp_showcolv should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1082 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1082 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2031 Reference: URL:http://www.securityfocus.com/bid/2031 The xp_enumresultset function in SQL Server and Microsoft SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_displayparamstmt, xp_enumresultset, xp_showcolv, and xp_showcolv should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1083 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1083 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2038 Reference: URL:http://www.securityfocus.com/bid/2038 The xp_showcolv function in SQL Server and Microsoft SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_displayparamstmt, xp_enumresultset, xp_showcolv, and xp_showcolv should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1084 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1084 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 Microsoft SQL Server extended stored procedure vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570878710037&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2039 Reference: URL:http://www.securityfocus.com/bid/2039 The xp_updatecolvbm function in SQL Server and Microsoft SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_displayparamstmt, xp_enumresultset, xp_showcolv, and xp_showcolv should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1085 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1085 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2040 Reference: URL:http://www.securityfocus.com/bid/2040 The xp_peekqueue function in Microsoft SQL Server 2000 and SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_peekqueue, xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1086 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1086 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2041 Reference: URL:http://www.securityfocus.com/bid/2041 The xp_printstatements function in Microsoft SQL Server 2000 and SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_peekqueue, xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1087 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1087 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2042 Reference: URL:http://www.securityfocus.com/bid/2042 The xp_proxiedmetadata function in Microsoft SQL Server 2000 and SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_peekqueue, xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together. ====================================================== Candidate: CAN-2000-1088 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1088 Phase: Proposed (20001219) Category: SF Reference: ATSTAKE:20001201 SQL Server 2000 Extended Stored Procedure Vulnerability Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=97570884410184&w=2 Reference: MS:MS00-092 Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms00-092.asp Reference: BID:2043 Reference: URL:http://www.securityfocus.com/bid/2043 The xp_SetSQLSecurity function in Microsoft SQL Server 2000 and SQL Server Desktop Engine (MSDE) does not properly restrict the length of a buffer before calling the srv_paraminfo function in the SQL Server API for Extended Stored Procedures (XP), which allows an attacker to cause a denial of service or execute arbitrary commands, aka the "Extended Stored Procedure Parameter Parsing" vulnerability. Analysis ---------------- Vendor Acknowledgement: yes advisory Content Decisions: SF-LOC ABSTRACTION: CD:SF-LOC suggests having separate items, one for each buffer overflow in each separate "line of code." Thus xp_peekqueue, xp_printstatements, xp_proxiedmetadata, and xp_SetSQLSecurity should be separate. However, CD:SF-LOC is still under discussion by the Editorial Board, so these may be MERGED together.
|
||||
