Bug 713298 (CVE-2011-2186)

Summary:	CVE-2011-2186 gitweb: persistent XSS by users with commit privileges
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	dac, warthog9
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-19 21:48:50 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:	713300, 713301, 713302
Bug Blocks:

Description Vincent Danen 2011-06-14 22:15:26 UTC

It was reported [1] that there is a persistent XSS in gitweb, which requires a user to have commit access to the repository that gitweb is configured to display.  The vector is that gitweb serves up XML files which can embed HTML that could be used to perform an XSS attack.  For example:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
</head>
<script>alert(1);</script>
</html>

and viewed at http://$HOSTNAME/$PATH_TO_GITWEB/?p=lolok;a=blob_plain;f=lol.xml

Upstream does not consider this to be much of a security issue [2], and that it is done by design.  However, there is a patch to make the $prevent_xss setting default [3], which will correct this issue, erring on the side of caution.

[1] https://bugs.launchpad.net/ubuntu/+source/git/+bug/777804
[2] http://seclists.org/oss-sec/2011/q2/543
[3] http://seclists.org/oss-sec/2011/q2/614

Comment 1 Vincent Danen 2011-06-14 22:17:07 UTC

Created gitweb-caching tracking bugs for this issue

Affects: fedora-all [bug 713300]
Affects: epel-5 [bug 713301]
Affects: epel-6 [bug 713302]

Comment 2 J.H. 2011-06-14 22:49:37 UTC

[3] as suggested by Jakub, fundamentally changes a default behavior which I very very highly disagree with.  The documentation is there, it's not like it was unclear and flipping that switch will just break people's usage of gitweb.

I further object that this was not taken to Junio and myself as well as Jakub, with Junio being the, currently, official maintainer of Git & Gitweb, and myself being the only real maintainer for gitweb-caching.

I agree with Jakub's original position [1] that this isn't a bug, it's a feature and I further object to the suggested fix proposed to make this the default.  I'm not sure why this is even considered a CVE since there's already a switch in place to disable this should it be a concern.

From a gitweb-caching perspective, I can't turn this on by default as it *WILL* break large public websites.

Comment 3 Vincent Danen 2011-06-15 20:33:16 UTC

Thanks for the info.  I've sent a dispute to MITRE regarding this -- (I just filed the bug, I didn't request the CVE).

Feel free to close the trackers as NOTABUG if this is something we cannot "fix".  Maybe this is documented somewhere, I'm not sure, but if not, perhaps the "fix" is to more clearly document why this is not enabled by default and what can/will happen if it is enabled?

Comment 4 Vincent Danen 2013-08-02 16:14:16 UTC

This is still unfixed in the current version of gitweb-caching as present in Fedora and EPEL, however it looks like [1] a patch to make this behaviour the default is present, or was at least suggested.

Curiously, the URL specified in the RPM [2] shows no such repository so I'm wondering whether or not this is something that is completely unmaintained at this point?

[1] http://seclists.org/oss-sec/2011/q2/614
[2] http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary

Comment 5 David A. Cafaro 2014-12-11 02:27:53 UTC

Gitweb is now part of git (as of version 1.4.0)