Tamer Sahin <ts@securityoffice.net> said: >This vulnerability already discovered in January of this year. > >http://www.securityoffice.net/articles/sambar/ >http://www.securityfocus.com/bid/3885 According to the vendor's security page (http://www.sambar.com/security.htm), this is a different issue. The most recent paragraph says: All releases prior to the 5.1 production release are subject to [the various issues reported by NISR]. These bugs were reported by Mark Litchfield of NGS Software (many thanks!). A later paragraph says: All versions of the Sambar WWW Server prior to the 5.1 Beta 4 release are vulnerable to a reported DoS attack against the /cgi-win/cgitest.exe sample application. (Reported by Tamer Sahin at www.securityoffice.net). So while the type of problem may be similar, the issues are clearly different enough that the vendor had to make a change. Perhaps the initial patch was incomplete, or maybe the NISR exploit exposed an entirely different problem. Regardless, an administrator who fixed the "Sahin problem" would still be vulnerable to the "Litchfield issue." I run into this sort of confusion on a regular basis, though it rarely sees the light of day. When there are insufficient details, it can cause headaches for vulnerability databases (and CVE) when trying to determine if 2 vulnerability reports are really the same or not. I assume that it causes similar problems for any security administrator who has to worry about the particular software on their own systems. In this case, the Sambar vendor included several important pieces of information that helps to determine that the issue is different: 1) The vendor's description includes some details of the vulnerabilities, instead of a vague statement such as "fixed security problem" (which shows up in many change logs), which can make it difficult to know *which* problem was fixed by the vendor 2) Credit was given to the vulnerability reporters (which in some cases is still insufficient for distinguishing between multiple vulnerabilities found by the same reporter) 3) The vendor publicly acknowledged the problems in the first place, on a page dedicated to security issues (unfortunately, vendor security pages are rare indeed, and only 50% of all reported vulnerabilities have any clear vendor acknowledgement) 4) The affected software has different version numbers for each vulnerability This type of information does not always appear in vendor advisories, however. When the vulnerability reporter and the vendor do not coordinate on a solution and establish the proper facts (for whatever reasons why this breakdown occurs), the result is that it can be difficult or impossible for vulnerability information "consumers" - which includes intermediate information sources like CVE - to tell whether 2 reports are really describing the same problem or not. The situation gets worse when a vendor does not publicly acknowledge the reported vulnerability at all. When vendors write advisories without cross-references and/or credits to the original reporters, or without sufficient details of the particular vulnerability being fixed, this contributes to the difficulty of distinguishing between multiple vulnerability reports. For example, just yesterday I was reading a vaguely-written vendor security advisory that included no cross-references, which *might* have been related to a security issue that had been posted to Bugtraq a month earlier, or maybe it was addressing an even earlier issue. I had to manually inspect the vendor's patch to sufficiently prove that the vendor was really fixing the problem that had been posted a month previous. (thank goodness the source code was available and I knew the programming language, but it still took a half-hour for me to do all the detective work when a single cross-reference would have instantaneously linked the 2 reports). In some cases, the advisories are so vague that it is impossible to know which of several problems have been fixed by the vendor. When an advisory doesn't explicitly state that the vulnerability is different than previously reported bugs, that can also contribute to the confusion, not to mention the effort required by the information consumers to figure out what's really going on in the first place. - Steve
