[Full-disclosure] Update: ViewCVS and ViewVC 'checkout view' content type fixation issue
security at moritz-naumann.com
Wed Mar 28 18:26:23 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Moritz Naumann wrote:
> This does not impact how much the rest of my report applies. My
> findings are now being discussed on the ViewVC developers mailing list
> . They apparently also impact ViewVC. Whether and to which degree
> what I am reporting can be considered a security issue is, however,
> currently subject to discussion.
> For now, please follow up there only. I will be back to the security
> mailing lists as soon as this has been sufficiently discussed and there
> is something noteworthy to be said.
Here's the update I had announced.
Further discussion on the ViewVC development mailing list 
revealed that the content type fixation issue  can be found in both
ViewCVS 1.0-dev (and lower) as well as ViewVC 1.0.3 (and lower).
A 'security information' section will be contained in the 'INSTALL' file
 of the upcoming ViewVC 1.1.0 release. This will explain how
providing HTTP access to a code repository can have negative effects if
code which can be considered malicious for web clients is contained in
The ViewVC code was also changed in that support of the 'checkout view'
functionality (which allows presetting the content type of the HTTP
response) will be optional and disabled by default in future releases of
ViewVC (see changelog ). The changes can already be obtained by
checking out revision 1547 or higher off the ViewVC SVN repository.
I recommend that users and distributors of earlier ViewVC and ViewCVS
versions should either backport the patch which disables the 'checkout
view' or the one which makes it optional and deactivate it by default.
A less simple but less restrictive patch would introduce a content type
Thanks to the ViewVC developers for their proactive support in sorting
dev at viewvc.tigris.org
Here's the explanation of the content type fixation issue, as given in
my previous email on this topic:
> 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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure is hosted and sponsored by Secunia.