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.
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.
The CVE identifier of CVE-2010-3846 has been assigned to this issue.
Created cvs tracking bugs for this issue Affects: fedora-all [bug 645386]
Comment #41 => VERIFIED
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
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.
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
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).
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).