Date: Wed, 28 Mar 2007 19:26:23 +0200
From: Moritz Naumann <security@...itz-naumann.com>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>,
	bugtraq@...urityfocus.com, moderators@...db.org
Cc: users@...wvc.tigris.org, dev@...wvc.tigris.org,
	security@...ian.org, security@...too.org
Subject: Update: ViewCVS and ViewVC 'checkout view' content type fixation
 issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi!

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
> [1]. 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 [1]
revealed that the content type fixation issue [2] 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
[3] 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 repository.

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 [4]). 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
whitelisting approach.

Thanks to the ViewVC developers for their proactive support in sorting
this out.

Moritz

[1]
dev@...wvc.tigris.org
http://viewvc.tigris.org/servlets/SummarizeList?listName=dev

[2]
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:
> 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.

[3]
http://guest@...wvc.tigris.org/svn/viewvc/trunk/INSTALL
http://viewvc.tigris.org/source/browse/viewvc/trunk/INSTALL?view=log

[4]
http://guest@...wvc.tigris.org/svn/viewvc/trunk/CHANGES
http://viewvc.tigris.org/source/browse/viewvc/trunk/CHANGES?view=log

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGCqU/n6GkvSd/BgwRCpB9AJ4nJ0dm6OiSlHxgNL8Lc1rgGMvPVwCfY8ow
AJkoyXF/fETiBiHGLOt9j/s=
=Ht8z
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists