List for cgit developers and users
 help / color / mirror / Atom feed
From: Jason at zx2c4.com (Jason A. Donenfeld)
Subject: Fwd: CVE Request: CGit - Multiple vulnerabilities
Date: Thu, 14 Jan 2016 18:01:01 +0100	[thread overview]
Message-ID: <CAHmME9pQn+vQHZ3X-P6evtTu-KdMukbMnn_ny9PDBPWpQyZ4yg@mail.gmail.com> (raw)
In-Reply-To: <20160114165546.103516C019E@smtpvmsrv1.mitre.org>

---------- Forwarded message ----------
From:  <cve-assign at mitre.org>
Date: Thu, Jan 14, 2016 at 5:55 PM
Subject: Re: CVE Request: CGit - Multiple vulnerabilities
To: Jason at zx2c4.com
Cc: cve-assign at mitre.org, oss-security at lists.openwall.com,
krzysztof.kowalewski at eset.pl, erik at includesecurity.com


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> 1. Reflected Cross Site Scripting & Header Injection in Mimetype Query
> String [Katowicz-Kowalewski]
>
> The ui-blob handler accepted a mimetype as a query string and then
> echoed this string verbatim back. A malicious user could provide a
> string like:
>
>   http://git.zx2c4.com/cgit/blob/cgit.c?mimetype=text/html%0d%0a%0d%0a<script>xss</script>
>
> This has been fixed by removing support for the mimetype query string parameter:
> http://git.zx2c4.com/cgit/commit/?id=1c581a072651524f3b0d91f33e22a42c4166dd96

Use CVE-2016-1899.


> And then restricting to only generic mimetypes:
> http://git.zx2c4.com/cgit/commit/?id=92996ac2a6fc4e944c3d723e12d5ab244a43508e
> And finally, just in case, setting the IE anti-sniffing header as well
> as a restrictive CSP header:
> http://git.zx2c4.com/cgit/commit/?id=9ca2566972db968df4479108b29bb92551138b57

There is no CVE ID associated with either of these other changes,
which seem to be for defense-in-depth purposes.


> 2. Stored Cross Site Scripting & Header Injection in Filename
> Parameter [Donenfeld]
>
> A user who has write access to the git repository could create
> filenames containing new lines that would result in that filename,
> including the newlines, being included in a header, resulting in
> header injection and eventually XSS.
>
> This has been fixed by properly escaping filenames in headers:
> http://git.zx2c4.com/cgit/commit/?id=513b3863d999f91b47d7e9f26710390db55f9463

Use CVE-2016-1900.


> Additionally, while the redirect for the /about -> /about/ page does
> *not* appear to be vulnerable due to mitigating conditions, the
> following commit was made to similarly harden potential injections
> here:
> http://git.zx2c4.com/cgit/commit/?id=4291453ec30656c2f59645d8a74cf295ce0253a9

There is no CVE ID associated with this additional issue.


> 3. Stored Cross Site Scripting in Git Repo Files [Katowicz-Kowalewski]
>
> A user who has write access to the git repository can add HTML pages
> and then serve them with an HTML mimetype. A user could therefore
> upload pages with malicious javascript executing in the same origin as
> the cgit web site. While this is ordinarily not a problem for
> single-use users - and indeed some users rather like being able to
> serve html from cgit - sites that allow potentially malicious third
> party users may not find this behavior desirable.
>
> This has been fixed by adding a configuration option,
> "enable-html-serving", which is by default off:
> http://git.zx2c4.com/cgit/commit/?id=aaba5f8b925f44f7d5ffb0a45fe349642d478513
> This flag sets anti-sniffing, CSP, and restricts mimetypes to
> non-"application/" (except for application/pdf and
> application/octet-stream) and non-"text/" (except for text/plain).

There is no CVE ID associated with this report, which seems to be
about adding new security-related functionality. We realize that other
perspectives may have existed, especially because the attacker for
both 2 and 3 is "A user who has write access to the git repository."
However, we typically don't want to have a CVE for a design change
that probably breaks a number of existing installations unless
reconfigured. Also, it seems that another possibility may have been
creation of a framework for segregating the user-uploaded HTML files
into a different origin (admittedly this may not be worthwhile because
running a cgit service with two domain names probably isn't what the
ordinary cgit customer wants).


> 4. Integer Overflow resulting in Buffer Overflow [Cabetas]
>
> ctx.env.content_length is an unsigned int, coming from the
> CONTENT_LENGTH environment variable, which is parsed by strtoul. The
> HTTP/1.1 spec says that "any Content-Length greater than or equal to
> zero is a valid value." By storing this unsigned int into an int, we
> potentially overflow it, resulting in the following bounding check
> failing, leading to a buffer overflow.
>
> This has been fixed by this commit:
> http://git.zx2c4.com/cgit/commit/?id=4458abf64172a62b92810c2293450106e6dfc763

Use CVE-2016-1901.

- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWl9JtAAoJEL54rhJi8gl5lQEP/RNIfyGohJ7Z/SHub/OW/Bl0
39LctMT9FcOTD6WBIvub4bWE6Q/c2FlWfDjeier2cO+pm3xJnXZEvGDMxZEI2wYI
ErO9spu++XX6JDak0Il9fdxPTTzjSJj+c+8O8fKI3mJyUVxNhmWYUxIdG83or9zx
ZUko+9LmXStUliIwG7FKGdqbP9gHvFI+ZLdfwtPomNJs9MEzJPipOEuSh6/Ia822
4rXxn9Jb+wCVWdIhsaGUkuM4wq2SZsMcpJ13ww4IOOnCErfDKbRrODXvt03MRwyE
yE0R7aI0RoSzqzUAyiqJZZfgVgrPl1Ofx3n6mnbV3Y93Ypo8MparXUXf7+LDTT7I
Q9M7CWc5YYOnRBg12XFaUmJY25UQRlc4PjVUpX6DZY2vyzuO8cj3k64Vi4wcQ/Nc
OtyqNuKUJMPH77mVmMZHy7jfbtq/I20H34B57+jfBkCyLs50tQAP+8EAze0yEFF4
ZXv87eMrUNJJu/qOoZeJaf57PAzuFaoANtYBQ+p/hUfMwsm8iGoy6Ko0ZXO3ZW3k
9kACdNt3QX0OfNVLws2r6qr+CFERrHMp+ha6JZbBFGAPNO4QP9ATzaixQzJ76nSU
pPrqObQ6H58Mmq+ACRtBTNLVnccMNLsMDPgSWeLmlXZpe5DP/EPyQuSduC7gDkB/
8Td7FtAmzPUi1aORc6OK
=F6i1
-----END PGP SIGNATURE-----


      parent reply	other threads:[~2016-01-14 17:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 14:21 Jason
2016-01-14 14:46 ` Jason
     [not found] ` <20160114165546.103516C019E@smtpvmsrv1.mitre.org>
2016-01-14 17:01   ` Jason [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9pQn+vQHZ3X-P6evtTu-KdMukbMnn_ny9PDBPWpQyZ4yg@mail.gmail.com \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).