[UNIX] CVS Entry Line Flag Heap Overflow
From: SecuriTeam (support_at_securiteam.com)
Date: 05/19/04
- Previous message: SecuriTeam: "[UNIX] Libneon Date Parsing Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 19 May 2004 15:18:35 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
CVS Entry Line Flag Heap Overflow
------------------------------------------------------------------------
SUMMARY
Concurrent Versions System (CVS) is the dominant open-source version
control software that allows developers to access the latest code using a
network connection.
Stable CVS releases up to 1.11.15 and CVS feature releases up to 1.12.7
both contain a flaw when deciding if a CVS entry line should get a
modified or unchanged flag attached. This results in a heap overflow that
can be exploited to execute arbitrary code on the CVS server. This could
allow a repository compromise.
DETAILS
Vulnerable Systems:
* CVS feature version 1.12.7 and prior
* CVS stable version 1.11.15 and prior
While auditing the CVS source a flaw within the handling of modified and
unchanged flag insertion into entry lines was discovered.
When the client sends an entry line to the server an additional byte is
allocated to have enough space for later flagging the entry as modified or
unchanged. In both cases the check if such a flag is already attached is
flawed. This allows to insert M or = chars into the middle of a user
supplied string one by one for every call to one of these functions.
It should be obvious that already the second call could possibly overflow
the allocated buffer by shifting the part after the insertion point one
char backward. If the alignment of the block is chosen wisely this is
already exploitable by malloc() off-by-one exploitation techniques.
However carefully crafted commands allow the functions to be called
several times to overwrite even more bytes (although this is not really
needed if you want to exploit this bug on e.g. glibc based systems).
Disclosure Timeline:
02 May 2004 - CVS developers and vendor-sec were notified by email Derek
Robert Price replied nearly immediately that the issue is fixed
03 May 2004 - Pre-notification process of important repositories was
started
11 May 2004 - Sourceforge discovered that the patch breaks compatibility
with some pserver protocol violating versions of WinCVS/TortoiseCVS
12 May 2004 - Pre-notified repositories were warned about this problem
with a more compatible patch.
19 May 2004 - Coordinated Public Disclosure
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396>
CAN-2004-0396
Recommendation:
Recommended is an immediate update to the new version. Additionally you
should consider running your CVS server chrooted over SSH instead of using
the :pserver: method. You can find a tutorial how to setup such a server
at: <http://www.netsys.com/library/papers/chrooted-ssh-cvs-server.txt>
http://www.netsys.com/library/papers/chrooted-ssh-cvs-server.txt
ADDITIONAL INFORMATION
The information has been provided by <mailto:s.esser@ematters.de> Stefan
Esser.
The original article can be found at:
<http://security.e-matters.de/advisories/072004.html>
http://security.e-matters.de/advisories/072004.html
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[UNIX] Libneon Date Parsing Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
