Bug 713298 (CVE-2011-2186) - CVE-2011-2186 gitweb: persistent XSS by users with commit privileges
Summary: CVE-2011-2186 gitweb: persistent XSS by users with commit privileges
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-2186
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 713300 713301 713302
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-14 22:15 UTC by Vincent Danen
Modified: 2021-10-19 21:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-19 21:48:50 UTC
Embargoed:


Attachments (Terms of Use)

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 John 'Warthog9' Hawley 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)


Note You need to log in before you can comment on or make changes to this bug.