Re: Multiple Vulnerabilties Sambar Webserver

["Steven M. Christey" <coley () linus mitre org>]

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