Advisory EM10/2004: Chora CVS/SVN Viewer remote vulnerability

                           e-matters GmbH

-= Security Advisory =-

Advisory: Chora CVS/SVN Viewer remote vulnerability
Release Date: 2004/06/13
Last Modified: 2004/06/13
Author: Stefan Esser []

Application: Chora <= 1.2.1
Severity: A vulnerability within Chora allows remote shell command
Risk: Critical
Vendor Status: Vendor has released a bugfixed version.


Chora is the Horde Project's CVS/SVN repository viewer. (SVN support only
in CVS version) It is used to provide web-based access to repositories.
Currently, these features include:

* Directory-based views, with a summary of the most recent activity.
* View full log history on a single file, with the ability to stick
to a single branch.
* Request arbritrary differences between versions and branches. These
can be viewed in a variety of formats, ranging from raw diff output
to human-readable HTML.
* Visual branch viewing for a single file, which graphically represents
the history of the file with respect to branches from the main trunk
of development
* Annotation (otherwise known as 'blame') support, which shows which
authors are responsible for which portions of a file's contents.

During a security audit of Chora a vulnerability within the diff viewing
functionality was discovered. This hole allows arbitrary shellcode injection.
Combined with PHP's file upload functionality this gives the opportunity
to upload arbitrary binaries and to execute them. (In default configurations)


Because Chora runs on a number of bigger project's webservers it was
audited for the most obvious PHP programming mistakes. This reveales a
problem in the diff handling code for CVS and SVN repositores. While
the SVN support is only in the CVS and the 3.0 ALPHA version of Chora
the CVS code exists since the very first version of Chora.

In both cases the diff utility is executed via exec() with several
parameters. When the actual shell command is constructed a certain
variable (the number of diff context lines) is assumed to be always
a number and therefore not properly escaped. Unfourtunately there
is nowhere a check within Chora to ensure that the function is only
called with a number and therefore it is possible to inject an
arbitrary shell command into the command stream.

On a default configured server this means a remote attacker is able
to use PHP's file upload functionality to upload an arbitrary binary
to the /tmp directory (where PHP's temporary files are usually stored)
of the server, chmod it to executable and execute it.

The nature of this problem allows it, to exploit this bug disguised
as usual diff request through a single POST request.

Proof of Concept:

e-matters is not going to release an exploit for this vulnerability
to the public.

Disclosure Timeline:

12. June 2004 - The Horde project was informed about the vulnerability.
Additionally the information was shared with vendor-sec
and a few bigger projects running Chora.
In the night Horde released Chora 1.2.2 which fixes
this issue without notification. The release announcement
downplays the vulnerability as minor security fixes.
13. June 2004 - Public Disclosure after realising that Horde has already
spreaded the new version (on a weekend @!"$%&).


It is strongly recommended to upgrade to the latest version of Chora,
because in every default configuration this problem is a serious


pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam
Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC

Copyright 2004 Stefan Esser. All rights reserved.

© Hardened PHP Project