Re: rsync-2.5.2 has security fix (was: Re: [RHSA-2002:018-05] New rsync packages available)

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

Jim Knoble <jmknoble () pobox com> said:

> I can't seem to find any information about this issue at cve.mitre.org;
> it simply says:
>
>  ** RESERVED ** This candidate has been reserved by an organization or
>  individual that will use it when announcing a new security problem.
>  When the candidate has been publicized, the details for this
>  candidate will be provided.

[Background: CVE is a naming standard for computer vulnerabilities
that is being increasingly used by security product vendors and
services, as well as software vendors.  It is led by MITRE and
supported by many leading security-related organizations.]

These "** RESERVED **" candidates arise because of a necessary "race
condition" in the CVE process.

It is best to have CVE candidate names in vulnerability reports when
they are first released to the public, especially for issues that
affect multiple vendors.  This makes the candidate numbers immediately
available to people who use them, and it makes it easier to correlate
multiple reports or advisories that are describing the same issue.
MITRE provides certain organizations with candidate names before the
issue has become public.

To ensure that there is no "information leak" of vulnerability details
before the related issue has been publicized, a generic description is
initially assigned to the candidate, as quoted above.  The reserved
candidate is then placed on the CVE web site to ensure that
*something* is there when the issue has been publicized.

A short time after the issue has been publicized (normally 0 to 2
business days), the candidate is given a legitimate description and
references, and the CVE web site is updated accordingly.

So, there's a built-in delay with these "reserved" candidates.

Note that there are now details available for CAN-2002-0048.

> I've seen at least three announcements about rsync from different Linux
> distribution vendors, but no information at all about what versions are
> actually vulnerable, or when the vulnerability was discovered (or
> fixed).

Some people try to use CVE as an original source of vulnerability
information, but it is not designed to provide these kinds of details.
(Other information sources, such as vulnerability databases and
reporting services or vendor and researcher advisories, should be
consulted instead).  CVE's focus is on providing enough information
for people to understand which vulnerability is being identified, to
allow them to distinguish between similar vulnerabilities, and to
allow prople to correlate information from other sources.

That said, it does seem to be difficult sometimes to get the necessary
information from an advisory.  It's not just version numbers.

For CVE's purposes, I have found that the following details are
critical:

1) The affected version(s) and product names, and which versions have
   been fixed.

2) Whether the problem is remotely or locally exploitable (for some
   definition of "remote" and "local;" there are some variations in
   how these words are used)

3) The general type of the problem (buffer overflow, signedness error,
   misconfiguration, etc.)

4) In the case of a researcher or third party advisory: some
   information about whether the vendor was informed, who was
   informed, what their response was (if any), and (where possible) a
   pointer to a place where the vendor publicly acknowledges the
   problem.

5) Cross-references to other documents (e.g. Bugtraq posts, CERT
   advisories, and/or CVE names).  For vendor or third party
   advisories, crediting the person who reported the problem will
   often help to correlate the document with others (though that can
   still be insufficient information, e.g. when a prolific researcher
   finds different bugs in the same software over a period of time,
   and some vendors are reluctant to credit people who don't report a
   problem responsibly).

6) If similar vulnerabilities have been discovered in the past, a
   distinct statement that references those earlier vulnerabilities,
   and says why they are different.

Obviously there is more information that other people need, such as
links to patches, detailed analysis of the vulnerability, or some
notion of how severe the problem is.


> I find it tiring that vendors neglect to disclose this sort of
> information in their public announcements.  A simple statement such as
> "Plain-vanilla versions of rsync less than 2.5.2 are vulnerable.
> However, we've backported the fix to our sparkling new package of
> rsync-2.4.6.  Customers who use our Strawberry Linux Forever
> distribution should upgrade to our packages, listed below: ...."

In the case of version numbers in Linux advisories, sometimes the
version numbers are buried in the list of RPM's for fixes (since the
filename may contain the version number).  The problem is made worse
because different Linux distributions will fix different versions of
the same software.

Another issue occurs when "wildcards" are used to specify ranges of
versions that are affected, for example, when someone says "this
problem appears in version 4.x." (or worse, "in all versions").  In
the future, the vendor may release many other non-vulnerable versions
that would appear to "match" the 4.x version.  For example, consider
when the vendor fixes the problem in version 4.5, and someone sees the
advisory after they've installed version 4.10.  Old CERT/CC advisories
from the early 1990's would sometimes use the wildcard phrases; if
those advisories were interpreted literally today, they'd still apply
to current software.  For example, CERT CA-1991-19 still says "This
patch is available for all AIX releases ...  to the current release."

Listing specific range(s) of affected versions would address this
problem.

One would think that most consumers of vulnerability information need
to know at least (1) the affected version numbers, (2) whether the
problem is remote or local, (3) some idea of the severity of the
issue, and (4) cross references.  But many advisories don't even
contain this information.  This makes things harder for consumers of
vulnerability information, including CVE, because it makes it
extremely difficult to distinguish between similar vulnerabilities, or
to tell if 2 different reports are really talking about the same
issue.  CVE can help to address the problem of correlating multiple
reports and distinguishing between similar vulnerabilities.

However, without direct vendor involvement in CVE, we are often
working with the same amount of information that everyone else
is... and there are often significant gaps that can produce errors in
CVE (and other vulnerability information sources).  In fact, we have
had to modify some of our own consistency guidelines for CVE content,
because many reports do not provide sufficient information.  I suspect
that erroneous or missing information information often arises when
researchers and vendors do not work together to research and resolve
an issue.  (Yep, it all comes down to disclosure practices.)
Sometimes this happens even when people have the best of intentions.



Steve Christey
CVE Editor