ViewCVS Input Validation Hole Permits Cross-Site Scripting Attacks
SecurityTracker Alert ID: 1017704|
SecurityTracker URL: http://securitytracker.com/id/1017704
(Links to External Site)
Updated: May 18 2008|
Original Entry Date: Feb 26 2007
Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information|
Exploit Included: Yes |
A vulnerability was reported in ViewCVS. A remote user with certain CVS privileges can conduct cross-site scripting attacks.|
The software does not properly filter HTML code from user-supplied input before displaying the input. A remote user with CVS write access can create a specially crafted CVS entry and a URL that, when loaded by a target user, will cause arbitrary scripting code to be executed by the target user's browser. The code will originate from the site running the ViewCVS software and will run in the security context of that site. As a result, the code will be able to access the target user's cookies (including authentication cookies), if any, associated with the site, access data recently submitted by the target user via web form to the site, or take actions on the site acting as the target user.
A demonstration exploit is shown at:
Moritz Naumann reported this vulnerability.
A remote user with CVS write access privileges can access the target user's cookies (including authentication cookies), if any, associated with the site running the ViewCVS software, access data recently submitted by the target user via web form to the site, or take actions on the site acting as the target user.|
No solution was available at the time of this entry.|
Input validation error|
|Underlying OS: Linux (Any), UNIX (Any), Windows (Any)|
Source Message Contents
Subject: [Full-disclosure] ViewCVS 0.9.4 issues|
-----BEGIN PGP SIGNED MESSAGE-----
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
is no longer under development, has been abandoned in favor of ViewVC
(http://viewvc.org/) 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 viewvc.tigris.org 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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Go to the Top of This SecurityTracker Archive Page