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-----