ViewCVS 0.9.4 issues
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
*************************************************************************
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
http://viewvc.tigris.org/servlets/ProjectDocumentList?folderID=6005
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
finding.
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)
http://lists.grok.org.uk/pipermail/full-disclosure/2005-January/030514.html
(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:
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/html
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
cvs.sourceforge.jp).
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
http://moritz-naumann.com/tests/xss2.jpg
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.
Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF41Hln6GkvSd/BgwRAgWSAJ47KZFCVAdzLMURunMFZWrKz7AbFACdHxo7
LTzzddXx7obLmXGsot4d1ug=
=T0XX
-----END PGP SIGNATURE-----