Closed Bug 660053 (CVE-2011-2976) Opened 14 years ago Closed 14 years ago

[SECURITY] If a BUGLIST cookie is compromised, it can be used to XSS show_bug.cgi and inject HTML into <head>

Categories

(Bugzilla :: Creating/Changing Bugs, defect)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.16
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Bugzilla 3.4

People

(Reporter: mkanat, Assigned: mkanat)

References

(
URL
)

Details

(Whiteboard: [3.4.x and older only; 3.6 and newer not affected][infrasec:xss][ws:moderate])

Attachments

(1 file, 1 obsolete file)

v2
3.41 KB, patch
LpSolit
: review+
Details | Diff | Splinter Review
Bugzilla 3.4.11 and below are affected by an XSS that is only possible if the user's BUGLIST cookie is somehow compromised. The bug_list.first and bug_list.last variables in the bug/navigate.html.tmpl template are not properly escaped when displayed. As far as we know, it is not possible to compromise the BUGLIST cookie in Bugzilla, and as such we are not treating this as a high-priority security issue, but still something that we should fix for the 3.4 branch in case administrators have customized their installation in such a way that BUGLIST could have been compromised, or there are other programs on the user's system that could somehow have compromised the cookie.
Attached patch v1 (obsolete) — — Splinter Review
Simple untested patch for the issue. (It does pass 008filter.t.)
Assignee: create-and-change → mkanat
Status: NEW → ASSIGNED
Attachment #535428 - Flags: review?(dkl)
For the record, 3.6 and newer are not affected as bug 509108 added filters.
Severity: normal → minor
Whiteboard: [3.4.x and older only; 3.6 and newer not affected]
Comment on attachment 535428 [details] [diff] [review] v1 You also have to fix global/site-navigation.html.tmpl.
Attachment #535428 - Flags: review?(dkl) → review-
Severity: minor → normal
Summary: If a BUGLIST cookie is compromised, it can be used to XSS show_bug.cgi → [SECURITY] If a BUGLIST cookie is compromised, it can be used to XSS show_bug.cgi
Whiteboard: [3.4.x and older only; 3.6 and newer not affected] → [3.4.x and older only; 3.6 and newer not affected][infrasec:xss][ws:high]
Attached patch v2 — — Splinter Review
Thanks, fixed in this patch.
Attachment #535428 - Attachment is obsolete: true
Attachment #535431 - Flags: review?(LpSolit)
URL: http://www.cloudscan.me/2011/05/bugzi... → http://www.cloudscan.me/2011/05/bugzi...
Whiteboard: [3.4.x and older only; 3.6 and newer not affected][infrasec:xss][ws:high] → [3.4.x and older only; 3.6 and newer not affected][infrasec:xss][ws:moderate]
Summary: [SECURITY] If a BUGLIST cookie is compromised, it can be used to XSS show_bug.cgi → [SECURITY] If a BUGLIST cookie is compromised, it can be used to XSS show_bug.cgi and inject HTML into <head>
Comment on attachment 535431 [details] [diff] [review] v2 r=LpSolit
Attachment #535431 - Flags: review?(LpSolit) → review+
Flags: approval3.4?
(In reply to comment #0) > As far as we know, it is not possible to compromise the BUGLIST cookie in > Bugzilla, and as such we are not treating this as a high-priority security > issue, but still something that we should fix for the 3.4 branch in case > administrators have customized their installation in such a way that BUGLIST > could have been compromised, or there are other programs on the user's > system that could somehow have compromised the cookie. Unfortunately this is not true. One of the peculiarities with cookie handling in all browsers is that anyone can set a cookie for any user on any site provided they are able to intercept some traffic from the victim to any other HTTP site. I wrote a post and diagram on this issue which further describes the issue: http://michael-coates.blogspot.com/2010/01/cookie-forcing-trust-your-cookies-no.html The only solution to this issue is to enable HSTS. HSTS will prevent the victim's browser from being forced by the MITM to issue a HTTP request to the site in question.
> anyone can set a cookie for any user on any > site provided they are able to intercept some traffic from the victim to any > other HTTP site. But being able to set cookies is a significantly worse vulnerability than this, no? That is, if you can MITM somebody, you've already entirely encompassed this vulnerability and then some.
(In reply to comment #7) > > anyone can set a cookie for any user on any > > site provided they are able to intercept some traffic from the victim to any > > other HTTP site. > > But being able to set cookies is a significantly worse vulnerability than > this, no? That is, if you can MITM somebody, you've already entirely > encompassed this vulnerability and then some. So the difference here is that the attacker is not actually MITM the SSL connection, that connection is totally valid and untouched. Instead the attacker MITMs other HTTP request made by the victim to different sites (e.g. maybe they are also browsing google or there browsing is sending requests for HTTP updates of some sort). That's what makes this issue so frustrating, the attacker can intercept and modify a HTTP request by the victim to foo.com and use this to ultimately cause a new cookie to be set for the user's interaction with the bugzilla site.
(In reply to comment #8) > That's what makes this issue so frustrating, the attacker can intercept and > modify a HTTP request by the victim to foo.com and use this to ultimately > cause a new cookie to be set for the user's interaction with the bugzilla > site. Yes, but what could you do with an XSS that you couldn't already completely do with that MITM? If you can MITM somebody you own them, period, unless there's SSL, right?
Let's mark it as a blocker to keep it in our radar for the next security releases.
Flags: blocking3.4.12+
Blocks: 660528
Use CVE-2011-2976 for this bug
Alias: CVE-2011-2976
2.16rc1 is the first version affected by this problem, see bug 110012.
Version: 3.4.11 → 2.16
Flags: approval3.4? → approval3.4+
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.4/ modified template/en/default/filterexceptions.pl modified template/en/default/bug/navigate.html.tmpl modified template/en/default/global/site-navigation.html.tmpl Committed revision 6805.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Security advisory sent, unlocking this bug.
Group: bugzilla-security
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: