|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CD] CD Proposal: SF-EXEC (Software flaws in multiple executables)
The following content decision (CD) is related to cases in which the same software flaw appears in multiple executables within the same software package. CD Proposal Date: 6/12/2000 Voting Period: 7/10/2000 Final Decision: 7/24/2000 ************************************************************************ CD:SF-EXEC (Software flaws in multiple executables) ************************************************************************ Type: ABSTRACTION Version: 1.0 Proposed: 6/12/2000 Final Decision: N/A Short Description ----------------- If the same software flaw appears in multiple executables in the same package, then record it in a single entry. Definitions ----------- All definitions are informal. A "software package" is loosely defined as a collection of software that is normally bundled together, provides a single overall capability, and is offered on the same platform by a single vendor, or for multiple platforms by the same developer. Affected Candidates ------------------- All active candidates that are affected by this content decision can be obtained via the following URL: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CD:SF-EXEC Application ----------- If a * appears before a CD item, then if that item applies to P1 and P2, then the remainder of the CD should not be applied. Note: this CD is closely related to CD:SF-LOC and CD:SF-CODEBASE. CD:SF-EXEC intersects with CD:SF-LOC with respect to software flaws that occur in libraries, because a library bug may appear in multiple executables, and the exploitation of that bug may vary depending on the executable. CD:SF-EXEC intersects with CD:SF-CODEBASE if a software package is offered by multiple vendors, but a portion of its codebase originates from a single developer. Consider a problem P1 in an executable E1, and a problem P2 in a different executable E2. *1) If E1 and E2 are not in the same software package, then this CD does not apply. *2) If P1 and P2 do not exist at the same time (i.e. are not in the same package "version"), then they must remain SPLIT. *3) If P1 and P2 are not fixed by the same patch or set of patches, then they must remain SPLIT. 4) If the method of exploitation for P1 and P2 is the same (with the exception of which executable is exploited), and the results of the exploitation are the same, then P1 and P2 should be MERGED. 5) 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. 6) If P1 and P2 are fixed by the same patch, and there is no evidence that they require different exploitation methods, then they should be MERGED. 7) If there is strong evidence that P1 is an exact copy of the source code used by P2 (e.g. in a cut-and-paste operation by the same developer), or P1 and P2 were introduced by the same individual at the same time, then P1 and P2 should be MERGED. 8) If there are conflicting recommendations from previous items in this CD, then the first item that applies should be used to determine whether P1 and P2 should be SPLIT or MERGED. 9) If no item in this CD (besides this one) suggests whether P1 and P2 should be MERGED or SPLIT, then they should be MERGED. Guidance -------- If E1 and E2 may share the same library, and P1 and P2 look similar, then make sure to apply CD:SF-LOC, which covers libraries. Examples -------- ********************************************* CAN-1999-0840: Buffer overflow in CDE dtmail and dtmailpr programs via the -f option. Should dtmail and dtmailpr be SPLIT into separate entries, or should we keep them MERGED? SF-EXEC.2 and SF-EXEC.3 do not apply. SF-EXEC.4 - MERGE. Overflow is in -f command line option, and the same EIP is returned according to UNYUN SF-EXEC.5 - does not apply SF-EXEC.6 - MERGE. Same patch fixes both problems. SF-EXEC.7 - does not apply. There is not strong evidence, because we do not have the source code. Since dtmail and dtmailpr may have the same bug, we need to examine this using CD:SF-LOC as well. ********************************************* CAN-1999-0840 and CAN-1999-0841 CAN-1999-0841: Buffer overflow in CDE mailtool allows local users to gain root privilege via a long MIME Content-Type. Should we MERGE CAN-1999-0840 and CAN-1999-0841? They were both discussed in the same Bugtraq posting, and they both have the same Bugtraq ID. dtmail, dtmailpr, and mailtool all have similar software functionality. But mailtool is in the OpenWindows environment, according to UNYUN's post, whereas dtmail and dtmailpr are for CDE. So they are in different software packages, so SF-EXEC.1 says to keep them SPLIT. Let's suppose that these *are* in the same package anyway. Then SF-EXEC.2 does not apply. These are not fixed by the same patch, so SF-EXEC.3 would require that we SPLIT them. But let's go one step further, and suppose that these are fixed by the same patch. The buffer overflow for dtmail/dtmailpr is via a -f command line option, and mailtool is via a long Content-Type: mail header. The method of exploitation is different, so SF-EXEC.4 does not apply, but SF-EXEC.5 suggests that we SPLIT. SF-EXEC.6 does not apply, and neither does SF-EXEC.7. So, all recommendations suggest a SPLIT. So we will keep CAN-1999-0840 and CAN-1999-0841 separated. ********************************************* CAN-1999-0736, 0737, 0738, 0739. (various vulnerable .asp files in IIS/Site Server). These all *could* be due to the same flaw in a library function, so we should consider applying CD:SF-LOC. But each .ASP is a different executable, so we need to examine it from the CD:SF-EXEC perspective as well. [NOTE: since it's not a library problem, SF-LOC doesn't really apply, so the following text makes it more complicated than it needs to be. *If* Microsoft had "fixed" the server.mappath function, then it would be a library function, and SF-LOC *would* apply. But it's not a library problem and there are different executables, so we use SF-EXEC instead.] CAN-1999-0737 (viewcode.asp) has different KB articles than the others, and only Site Server is affected (the others have IIS and Site Server). Each .asp has different source code patches, so CD:SF-LOC.4 says that these candidates should remain SPLIT; however, the hotfix is the same, so CD:SF-LOC.4 doesn't apply if we consider the hotfix to be the patch. SF-LOC.6 clearly doesn't apply because there are separate patches for each .ASP file, so it's not a library. BUT, the KB article for 0737 says that ViewCode.asp 'uses "server.mappath" without any restrictions on what is passed to this function' and the KB article for the others uses this same description. So, *if* the patch had involved modifying the server.mappath function, then this function would be like a library function, and all the different candidates would be merged via SF-LOC.2. CD:SF-EXEC also applies here, but again we must decide what we mean by "patch." If we consider the source code modifications to be the patches, then SF-EXEC.3 suggests that we should keep these candidates SPLIT. But if we regard the hotfix as the patch, SF-EXEC.3 doesn't apply. SF-EXEC.4 and SF-EXEC.6 apply and suggest a MERGE. ********************************************* CAN-1999-0435: MC/ServiceGuard and MC/LockManager in HP-UX allows local users to gain privileges through SAM. SF-EXEC.2 does not apply. In most cases, including the most recent affected release, different patches are required for these programs, so SF-EXEC.3 suggests SPLIT. Exploits are unknown, so .4 and .5 do not apply, although the vague description suggests that .4 might apply as a MERGE. SF-EXEC.6 does not apply because the patches are different. SF-EXEC.7 does not apply due to lack of evidence. "Common sense" says that these should probably be MERGED, but due to the lack of information suggesting otherwise, SF-EXEC.3 suggests SPLIT. Perhaps we should have a general approach to MERGE in cases where: (a) the executables are in the same software package; (b) patches are provided at the same time; (c) there is very little information available otherwise. On the other hand, this approach could unfairly reduce the number of CVE entries for vendors who do not provide technical details. ********************************************* CAN-1999-0467 (Webcom guestbook, wguest.exe and rguest.exe) CD:SF-EXEC.3 is unknown. SF-EXEC.4 suggests MERGE. SF-EXEC.5 and SF-EXEC.6 do not apply. SF-EXEC.7 suggests MERGE. So, keep these MERGED. ********************************************* CAN-2000-0213 (Sambar server, ECHO.BAT and HELLO.BAT both call "echo" and support metacharacters). SF-EXEC.4, SF-EXEC.6, and SF-EXEC.7 suggest MERGE. The "patch" is to delete the batch files, both of which contain the same vulnerable "echo" command. ********************************************* CAN-2000-0163 (FreeBSD asdmon and ascpu). asdmon and ascpu are similar-looking, but different packages that appear to be by different developers. Details are a little sketchy, and there isn't much information out there for either of these third party programs, but it appears that the bug is in how FreeBSD ported the software. The FreeBSD advisory says it's similar to a problem in their port of wmmon (CAN-2000-0018), which would read a user-modifiable configuration file which defined commands that would be executed upon certain mouse events. The problem is that it was setgid kmem; privileges weren't necessary for the original Linux versions, so this was a bug in FreeBSD's port of the software. Since FreeBSD made the same mistake again in 2 different packages, it's reasonable to separate these out. The "as" prefix for the programs appears to be related to the specific window/display manager they were written for. Since these are not fixed by the same patch, CD:SF-EXEC.3 dictates that this candidate should be SPLIT. If SF-EXEC.3 weren't applicable, then there's no other real solid evidence for or against a SPLIT, so the default would then be to MERGE. Dissenting Opinions ------------------- Upon approval of this CD, this section will include a summary of any dissenting opinions.
|
||||
