Bug 642146 (CVE-2010-3846) - CVE-2010-3846 cvs: Heap-based buffer overflow by applying RCS file changes
Summary: CVE-2010-3846 cvs: Heap-based buffer overflow by applying RCS file changes
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-3846
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 641784 644813 644814 645386
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-12 07:47 UTC by Jan Lieskovsky
Modified: 2023-05-11 15:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-22 15:44:49 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0918 0 normal SHIPPED_LIVE Moderate: cvs security update 2010-11-29 21:08:24 UTC

Description Jan Lieskovsky 2010-10-12 07:47:05 UTC
An array index error, leading to heap-based buffer overflow was found
in the way CVS version control system applied certain delta fragments
changes from input file in the RCS (Revision Control System file)
format. A local attacker, with access to the system controlling the
repository, could store a specially-crafted RCS file into the CVS
repository and trick the remote user to checkout (update their
CVS repository tree) with this file, which could lead to arbitrary code
execution with the privileges of the CVS server process on the
system hosting the CVS repository.

References:
[1] http://www.gnu.org/software/rcs/

Upstream changeset:
[2] http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/src/rcs.c?r1=1.262.4.65&r2=1.262.4.66&sortby=rev


Acknowledgements:

Red Hat would like to thank Ralph Loader for reporting this issue.

Comment 4 Jan Lieskovsky 2010-10-12 08:30:43 UTC
This issue did NOT affect the versions of the cvs package, as shipped
with Red Hat Enterprise Linux 3, 4, or 5.

--

This issue affects the versions of the cvs package, as shipped with
Fedora release of 12 and 13.

Comment 15 Jan Lieskovsky 2010-10-14 17:31:28 UTC
The CVE identifier of CVE-2010-3846 has been assigned to this issue.

Comment 39 Jan Lieskovsky 2010-10-21 13:04:03 UTC
Created cvs tracking bugs for this issue

Affects: fedora-all [bug 645386]

Comment 43 Martin Cermak 2010-11-10 09:31:54 UTC
Comment #41 => VERIFIED

Comment 44 errata-xmlrpc 2010-11-29 21:08:29 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2010:0918 https://rhn.redhat.com/errata/RHSA-2010-0918.html

Comment 45 Alexander Peslyak 2010-12-01 07:39:20 UTC
The description of this vulnerability in RHSA-2010:0918-1 is inconsistent with one in Jan's comment on this bug.  So one of these must be wrong, and I'd like to know which one.

Specifically, RHSA-2010:0918-1 says "... arbitrary code execution with the privileges of the CVS server process on the system hosting the CVS repository" - but the attacker was already assumed to have direct write access to the repository, so this would be a relatively minor issue.

Jan's comment says "... arbitrary code execution with the privileges of the user running cvs client executable".  So this is an attack on the CVS client by a malicious or compromised CVS server.  This is more of a security issue.

Additionally, the RHSA-2010:0918-1 description is internally-inconsistent: it mentions a remote "victim", but then says that the attack is on the CVS server anyway (in which case the remote user is not a victim).  Thus, I find it more likely that Jan's description is the correct one.

I did not try to match this against the code.  I see that src/rcs.c is being patched, but I did not check whether this file is part of the server or/and the client.

Comment 47 Jan Lieskovsky 2010-12-02 12:10:50 UTC
Hi Solar,

  thank you for your comments.

(In reply to comment #45)
> The description of this vulnerability in RHSA-2010:0918-1 is inconsistent with
> one in Jan's comment on this bug.  So one of these must be wrong, and I'd like
> to know which one.

  Yes, my original description (c#0) stating that this would lead to
'arbitrary code execution with the privileges of the user running cvs
client executable' was wrong. See below for further details.

> 
> Specifically, RHSA-2010:0918-1 says "... arbitrary code execution with the
> privileges of the CVS server process on the system hosting the CVS repository"
> - but the attacker was already assumed to have direct write access to the
> repository, so this would be a relatively minor issue.

  Yes, the above description is the correct one. Also, the assumption
the local attacker would need to have access to the system, controlling
the repository, is the proper one. The scenario of the CVS checkout
process is as follows:
1, client initiates CVS checkout,
2, server receives the request, retrieves the original form of the
   file to be checkout-ed, together with changes applied in the meantime
   to it,
3, server creates the final form of the checkouted file and then sends
   it to the client.

So all the code is executed on the side of the server. If something
goes wrong (like in this case, the server 'checkout' process
aborts), the client is informed about this fact via standard error
file descriptor and client displays the message.

> 
> Jan's comment says "... arbitrary code execution with the privileges of the
> user running cvs client executable".  So this is an attack on the CVS client by
> a malicious or compromised CVS server.  This is more of a security issue.

See above, the checkout preparation / performing steps are not executed
on the client. Client only receives the result or error message if some
failure occurred.

> 
> Additionally, the RHSA-2010:0918-1 description is internally-inconsistent: it
> mentions a remote "victim", but then says that the attack is on the CVS server
> anyway (in which case the remote user is not a victim).  Thus, I find it more
> likely that Jan's description is the correct one.

Yes again, the 'remote victim' part in the advisory text is not correct.
To say 'remote user' is more appropriate. In fact, the checkout of the
remote user is needed only / is a way only, how to achieve CVS server crash.

> 
> I did not try to match this against the code.  I see that src/rcs.c is being
> patched, but I did not check whether this file is part of the server or/and the
> client.

Please see the above described CVS checkout scenario for further details.

Note: The original c#0 was corrected / updated to reflect the current
      knowledge.

Solar, let us know, if there is still some confusing / unclear description
left yet, and we will clarify.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Comment 48 Ralph Loader 2010-12-03 06:55:00 UTC
Re:

> the attacker was already assumed to have direct write access to the repository

This might not be quite accurate.

An attacker with read access could trigger the bug on a repository holding an already corrupted file.

I discovered the problem by doing read-only access on a repo that for some unknown reason was already corrupted (it was a reasonably old repo, so possibly a long-fixed bug).

Comment 49 Jan Lieskovsky 2010-12-03 10:21:55 UTC
Hi Ralph,

(In reply to comment #48)
> Re:
> 
> > the attacker was already assumed to have direct write access to the repository
> 
> This might not be quite accurate.
> 
> An attacker with read access could trigger the bug on a repository holding an
> already corrupted file.

  Yes, but this to succeed requires the repository to be already corrupted
locally. Then it is only question of time till someone checkouts that
particular file. Repository corruption seems not to be possible remotely.
So in that scenario, the real attacker is the person, who corrupts the
repository. The remote user action is just a way, how to perform the
attack.

> 
> I discovered the problem by doing read-only access on a repo that for some
> unknown reason was already corrupted (it was a reasonably old repo, so possibly
> a long-fixed bug).


Note You need to log in before you can comment on or make changes to this bug.