Lucene search

HistoryFeb 27, 2007 - 12:00 a.m.

ViewCVS 0.9.4 issues


Hash: SHA1


Short version for the busy ones:
o Security issue on ViewCVS 0.9.4
o Not really exploitable unless malicious users have CVS write access
AND victim visits pre-crafted URL

ViewCVS 0.9.4
is no longer under development, has been abandoned in favor of ViewVC
( and should probably no longer be used in production
environments. Unfortunately this script is still widely used, so I
think it's still worth telling about this otherwise not really important

The issue is one which can hardly be practially exploited (thus this
short and boring 'advisory' and no prior notice to the previous
developers). The source of the problem is that ViewCVS allows users to
specify the content type which the server generated HTTP response will
be sent with.

This was previously considered a HTTP response splitting vulnerability
by Jose Antonio Coret (Joxean Koret)
(BID 12112, couldn't find a CVE, AFAICT it is not CAN-2004-1062)
and, according to him, a patch has been stored on the 1.0-dev CVS
branch. The 0.9.4 release on seems to be unpatched and
it's possible that some Linux distributions and whoever would normally
care were never patched against this.

However, it is actually more than the response splitting issue. For an
example, please compare what your web browser displays on these locations:

The two obviously look somewhat differently, and on the second location
you can see (assuming you have Javascript activated globally) that a
request is made to Google (from within the security context of

This means that ViewCVS and thus the domain it runs in is vulnerable to
Cross Site Scripting, assuming that someone not fully trustable has
write permissions on one of the CVS repositories ViewCVS grants access
to here.

But XSS is just one possibility. This should also work for delivering
VML exploits and other funny stuff, such as … when some victim uses a
funny web browser (such as Internet Explorer 5.5/6/7) and some attacker
stores files such as this
in a CVS repository and makes the victim access it with with
'&content-type=image/jpeg' appended to the ViewCVS URL.

However, all of the above requires that some admin messes around with
CVS write access on the server ViewCVS grants read access to and gave
access to someone with bad intentions or no clue. Of course, both of
this could easily happen on web sites such as Sourceforge (who, however,
introduced separate subdomains for user authentication and web based
access to CVS), or sites which use CVS in the way a version controlled
wiki is used and allow public write access.

I suggest that Linux distributions should patch this issue short term
and deprecate support for ViewCVS mid to long term.

Web application developer lessons learnt (once again):

  1. Explicitly limit your application to the functionality you want and
    need it to have.
  2. More precisely, do not use user generated data provided in HTTP
    requests to specify content types of HTTP responses unless you are using
    a whitelisting approach.

Thanks for reading, have a fine day.

Version: GnuPG v1.4.6 (GNU/Linux)


Use Vulners API to create your own security tool

API usage cases
  • Network scanning
  • Linux Patch management
  • Threat protection
  • No network audit solution

Ways of integration

Integrate Vulners API
Related for SECURITYVULNS:DOC:16195