Closed
Bug 480044
Opened 15 years ago
Closed 13 years ago
Use dashes instead of colons to separate bug IDs in the BUGLIST cookie, because colons are HTML-escaped, making the cookie bigger than the 4k limit
Categories
(Bugzilla :: Query/Bug List, defect)
Bugzilla
Query/Bug List
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: jruderman, Assigned: LpSolit)
References
Details
Attachments
(2 files, 1 obsolete file)
1.89 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
1.88 KB,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
This happened to me twice (while using WebKit trunk). I had to delete my Bugzilla cookies before I could see any pages on bugzilla.mozilla.org again. Bad Request Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit. Cookie: ... Apache/2.2.3 (Red Hat) Server at bugzilla.mozilla.org Port 80
Reporter | ||
Comment 1•15 years ago
|
||
(According to bug 471971, the gigantic BUGLIST cookie has a different effect in Firefox.)
Comment 2•15 years ago
|
||
Doesn't that sound like a bug in WebKit or a problem in the web server? I would expect there to be limits on these sorts of things... In any case, the problem is most likely limited to bmo, which does things differently with the buglist cookie than upstream does. Can you reproduce this on http://landfill.bugzilla.org/bugzilla-tip/ ?
Comment 3•15 years ago
|
||
Also, reducing severity, because although I understand it's really bad when it happens, you're the only person I've ever heard report this and one would think that if it was a common problem (say, in stable versions of common browsers) that we would hear about this quite frequently. But if it does become common or we do show that it's some actual standards violation in Bugzilla, I'd be happy to raise the severity again.
Severity: critical → normal
Reporter | ||
Comment 4•15 years ago
|
||
How is WebKit supposed to know what limit the Apache instance on bmo has?
Comment 5•15 years ago
|
||
(In reply to comment #4) > How is WebKit supposed to know what limit the Apache instance on bmo has? No, I wouldn't expect that. I just figured that if Apache was instantiating some limit, that it was standard to some degree. Anyhow, it's possible that bmo is doing something bad with the cookie, as I said. I was just wondering if there was some standard on the subject.
Comment 6•15 years ago
|
||
I have experienced this problem frequently (about once a week) for the past few months on our local Bugzilla installation. This has crossed different stable versions of Bugzilla, specifically 3.0.6 and 3.2.2. I and my colleagues usually use Firefox 3, so this is the only browser in which we have seen this bug. The fact we're getting this bug in Firefox implies it's not a specefic WebKit issue. The Bugzilla server is running Apache 2.0.59 in Fedora 8. I recently upgraded our Bugzilla/Testopia installation from BZ 3.0.6 and Testopia 2.1 to BZ 3.2.2 and Testopia 2.2. The "Bad Request" cookie bug remains with us.
Reporter | ||
Comment 7•15 years ago
|
||
Btw this can probably be used as a denial-of-service attack against Bugzilla users.
Comment 8•15 years ago
|
||
Hmm, I suppose it could be. I suppose we'll mark it security-sensitive until we understand what's causing it.
Group: bugzilla-security
Assignee | ||
Comment 9•15 years ago
|
||
(In reply to comment #7) > Btw this can probably be used as a denial-of-service attack against Bugzilla > users. How could this be a DoS? A user cannot have such gigantic cookies without some explicit action.
Reporter | ||
Comment 10•15 years ago
|
||
A malicious web page can make you load a long bug list using a hyperlink or frame.
Comment 11•15 years ago
|
||
I thought this was what that "this bug list is too big for Bugzilla's little mind" warning was supposed to prevent. Are we triggering that too high, and need to cut it shorter?
Comment 12•15 years ago
|
||
Jesse often has queries that include/exclude long lists of bugs from previous queries. Is it possible that a bug list from such a query bypasses the "little mind" cut off?
Comment 13•14 years ago
|
||
So, Apache has an 8K limit on inbound headers, so that's almost certainly the problem--when combined with a very large URL, the cookie the browser sends is exceeding Apache's limit. Essentially, that makes this a dupe of bug 513989, in a way, although if Bugzilla then refuses *all* requests, that would still make this a security issue. If it just refuses further large buglist queries, that would simply make this a dupe of bug 513989. Jesse: Does it refuse show_bug.cgi calls and index.cgi calls also, or just buglist.cgi calls?
Reporter | ||
Comment 14•14 years ago
|
||
I think this happened for other bmo URLs too.
Reporter | ||
Comment 16•14 years ago
|
||
Bug 561348 has steps to reproduce and has identified the root cause. Go timeless!
Assignee | ||
Comment 17•13 years ago
|
||
Replace colons by dashes, which are not escaped (I first thought about commas, but they are escaped too). I still split the BUGLIST cookie on colons to not break existing cookies.
Assignee: query-and-buglist → LpSolit
Status: NEW → ASSIGNED
Attachment #512066 -
Flags: review?(mkanat)
Assignee | ||
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Bugzilla 3.4
Comment 18•13 years ago
|
||
Comment on attachment 512066 [details] [diff] [review] patch for 4.x, v1 Looks good to me. Perhaps add a comment above the split(), on checkin. I think that we should backport this to 3.6, but I don't think it needs a security advisory; we don't usually treat DoSes of this level as confidential.
Attachment #512066 -
Flags: review?(mkanat) → review+
Updated•13 years ago
|
Flags: approval?
Flags: approval4.0?
Flags: approval3.6?
Assignee | ||
Comment 19•13 years ago
|
||
(In reply to comment #18) > I think that we should backport this to 3.6, but I don't think it needs a > security advisory; we don't usually treat DoSes of this level as confidential. But we could still commit it to 3.4 as a security improvement, isn't it?
Comment 20•13 years ago
|
||
> But we could still commit it to 3.4 as a security improvement, isn't it?
Yeah, I suppose we could, that makes sense.
Updated•13 years ago
|
Flags: approval3.4?
Assignee | ||
Comment 21•13 years ago
|
||
Removing the sec flag, per comment 18. I'm going to commit it now.
Group: bugzilla-security
Flags: approval?
Flags: approval4.0?
Flags: approval4.0+
Flags: approval3.6?
Flags: approval3.6+
Flags: approval3.4?
Flags: approval3.4+
Flags: approval+
Assignee | ||
Comment 22•13 years ago
|
||
I forgot to fix one place.
Attachment #512066 -
Attachment is obsolete: true
Attachment #512256 -
Flags: review?(mkanat)
Updated•13 years ago
|
Attachment #512256 -
Flags: review?(mkanat) → review+
Updated•13 years ago
|
Attachment #512260 -
Flags: review?(mkanat) → review+
Assignee | ||
Comment 24•13 years ago
|
||
The patch for 3.6 doesn't apply to the 3.4 branch at all. I don't want to take the risk to break something on an old branch because I omitted to fix one place by accident, so I'm retargetting this bug to 3.6. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/ modified buglist.cgi modified Bugzilla/User.pm Committed revision 7716. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/ modified buglist.cgi modified Bugzilla/User.pm Committed revision 7554. Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.6/ modified buglist.cgi modified process_bug.cgi modified Bugzilla/Template.pm Committed revision 7238.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: approval3.4+
Resolution: --- → FIXED
Summary: Bugzilla sets gigantic BUGLIST cookie, then refuses all my requests → Use dashes instead of colons to separate bug IDs in the BUGLIST cookie, because colons are HTML-escaped, making the cookie bigger than the 4k limit
Target Milestone: Bugzilla 3.4 → Bugzilla 3.6
Assignee | ||
Updated•13 years ago
|
Attachment #512260 -
Attachment description: patch for 3.x, v1 → patch for 3.6, v1
You need to log in
before you can comment on or make changes to this bug.
Description
•