Bug 713298 - (CVE-2011-2186) CVE-2011-2186 gitweb: persistent XSS by users with commit privileges
CVE-2011-2186 gitweb: persistent XSS by users with commit privileges
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 713302 713300 713301
  Show dependency treegraph
Reported: 2011-06-14 18:15 EDT by Vincent Danen
Modified: 2016-03-04 06:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-06-14 18:15:26 EDT
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"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">

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 18:17:07 EDT
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 18:49:37 EDT
[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 16:33:16 EDT
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 12:14:16 EDT
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-10 21:27:53 EST
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.