Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in Bugzilla 3.6

Status

()

Bugzilla
Query/Bug List
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: Frédéric Buclin)

Tracking

unspecified
Bugzilla 3.6
Bug Flags:
approval +
approval4.0 +
approval3.6 +

Details

Attachments

(2 attachments, 1 obsolete attachment)

1.89 KB, patch
Max Kanat-Alexander
: review+
Details | Diff | Splinter Review
1.88 KB, patch
Max Kanat-Alexander
: review+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
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

9 years ago
(According to bug 471971, the gigantic BUGLIST cookie has a different effect in Firefox.)

Comment 2

9 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

9 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

9 years ago
How is WebKit supposed to know what limit the Apache instance on bmo has?

Comment 5

9 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

8 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

8 years ago
Btw this can probably be used as a denial-of-service attack against Bugzilla users.

Comment 8

8 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

8 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

8 years ago
A malicious web page can make you load a long bug list using a hyperlink or frame.
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?
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

7 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

7 years ago
I think this happened for other bmo URLs too.

Updated

7 years ago
Duplicate of this bug: 561348
(Reporter)

Comment 16

7 years ago
Bug 561348 has steps to reproduce and has identified the root cause.  Go timeless!
(Assignee)

Comment 17

7 years ago
Created attachment 512066 [details] [diff] [review]
patch for 4.x, v1

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

7 years ago
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Bugzilla 3.4

Comment 18

7 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

7 years ago
Flags: approval?
Flags: approval4.0?
Flags: approval3.6?
(Assignee)

Comment 19

7 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

7 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

7 years ago
Flags: approval3.4?
(Assignee)

Comment 21

7 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

7 years ago
Created attachment 512256 [details] [diff] [review]
patch for 4.x, v1.1

I forgot to fix one place.
Attachment #512066 - Attachment is obsolete: true
Attachment #512256 - Flags: review?(mkanat)

Updated

7 years ago
Attachment #512256 - Flags: review?(mkanat) → review+
(Assignee)

Comment 23

7 years ago
Created attachment 512260 [details] [diff] [review]
patch for 3.6, v1

Backport for 3.x
Attachment #512260 - Flags: review?(mkanat)

Updated

7 years ago
Attachment #512260 - Flags: review?(mkanat) → review+
(Assignee)

Comment 24

7 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
Last Resolved: 7 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

7 years ago
Attachment #512260 - Attachment description: patch for 3.x, v1 → patch for 3.6, v1
(Assignee)

Updated

7 years ago
Duplicate of this bug: 365587
(Assignee)

Updated

7 years ago
Duplicate of this bug: 290977
You need to log in before you can comment on or make changes to this bug.