Bug #2188

Lighttpd returns 400 Bad request

Added by Anonymous over 4 years ago. Updated 12 months ago.

Status:InvalidStart date:2010-04-16
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Missing in 1.5.x:No

Description

Lighttpd version : 1.4.26

when cookie has bad code ,Lighttpd returns 400 Bad request

ie : 8%20Å

???.jpg (78.5 KB) , 2010-04-16 03:53

???.jpg (120 KB) , 2010-04-19 04:11


Related issues

Related to Bug #2423: Firefox cookie handling bug results in permanent ban Duplicate 2012-07-10

History

#1 Updated by icy over 4 years ago

  • Status changed from New to Need Feedback

And the problem is? Browser sends bad request and lighty sends "400 bad request" response. Seems like correct behaviour to me.

#2 Updated by over 4 years ago

but some bad code lighty return 200,some return 400,I want know why?

#3 Updated by icy over 4 years ago

What bad request does lighty return 200 for, do you have an example?

#4 Updated by over 4 years ago

#5 Updated by over 4 years ago

200:

400:

#6 Updated by kamil.chm@gmail.com over 4 years ago

I found a place where status 400 is set. In request.c starting at line 1047:

default:
  if (*cur >= 0 && *cur < 32 && *cur != '\t') {
    if (srv->srvconf.log_request_header_on_error) {
      log_error_write(srv, __FILE__, __LINE__, "sds",
                      "invalid char in header", (int)*cur, "-> 400");
    }

    con->http_status = 400;
    con->keep_alive = 0;

    return 0;
  }
  break;
}

In my case *char equals to ASCII char with code 5. I excluded it from <0, 32> condition. No 400 now.
Can someone tell me is there any exposure in my solution?

#7 Updated by stbuehler over 4 years ago

  • Status changed from Need Feedback to Invalid

Character 5 is a control character and shouldn't be in a http header.

#8 Updated by kamil.chm@gmail.com over 4 years ago

What is the reason to reject control character from header value field?
Is there some specification that disallow it, or is it because the server can't handle control characters in futher processing?

#9 Updated by cicik almost 2 years ago

  • Status changed from Invalid to Reopened

Almost every site has installed google analytics code. This code sets some cookies specific for campaign tracking. This mechanism can be used to set any value for this cookie. Look at this url:

www.domain.com/?utm_source=test&utm_medium=test&utm_campaign=te%05st

when google analytics is installed on the site it will set cookie with parameters present in this url. Look at the last one. There is special character number 5 which will be saved in the cookie. Next, any requests from this visitor to this domain will end up with 400 Bad request error.

This mechanism may be used to ban the page to it's visitors. Some atacker may share this buggy link with others and the site may be blocked for many many people (!!!).

I think that you shouldn't block the request when cookie contains some control characters. It is completely legal and possible by scripts to save such character in the cookie - so you shouldn't block it.

I had to change the sources of lighttpd and compile it today because some versions of some browsers (ex. IE, Firefox) changed polish specific letter "?" into control character number 5. This character was saved in cookie and website was blocked for many many people. The same mechanism may be used by atackers.

#10 Updated by stbuehler almost 2 years ago

  • Status changed from Reopened to Invalid

The RFCs are pretty clear: CTL chars are not allowed. The current draft is also easy to read.

There is also a security aspect of this - allowing CTL chars might lead to new security issues.

So just stop tracking your users with google analytics, or tell google to fix it (or both). It might also be a good idea to tell browser vendors not to accept broken cookies.

#11 Updated by cicik almost 2 years ago

stbuehler wrote:

The RFCs are pretty clear: CTL chars are not allowed. The current draft is also easy to read.

Being compliant with specification is good but despite the specification there is also a normal life.
If saving special chars in cookies is possible and all browser allows for it lighttpd should handle such cookies.
There are some clever things that lighttpd may do. It may simply delete such chars or delete this one header containing this char etc.

But it is very bad idea to simply send "Bad Request" and ban a website for many many users. Maybe there should be some configuration directive telling what to do in such situation?

I checked other web servers and they accept cookies with special chars and there i no error.

So just stop tracking your users with google analytics, or tell google to fix it (or both). It might also be a good idea to tell browser vendors not to accept broken cookies.

Hahaha... I want to see when Google, Mozilla, Microsoft, Apple, Opera etc. will listen to this advice.

#12 Updated by kamil.chm@gmail.com almost 2 years ago

We need to exploit it and then report critical security bug to Google, Mozilla etc. :)
Or add some option to lighttpd configuration to allow CTL chars in cookie values if we can't exploit it.

#13 Updated by cicik almost 2 years ago

wrote:

We need to exploit it and then report critical security bug to Google, Mozilla etc. :)

Yeah, Lets start today :-)

http://www.allkpop.com/?utm_source=test&utm_medium=test&utm_campaign=te%05st
http://www.chefkoch.de/?utm_source=test&utm_medium=test&utm_campaign=te%05st
http://eztv.it/?utm_source=test&utm_medium=test&utm_campaign=te%05st

All this sites comes from the list of websites powered by lighty (http://redmine.lighttpd.net/projects/lighttpd/wiki/PoweredByLighttpd)

I think that owners of this websites wouldn't be happy if they have been banned for millions of visitors.

#14 Updated by stbuehler almost 2 years ago

I tried some weeks ago and couldn't reproduce it with any of those links - perhaps analytics got fixed.
With JavaScript I still could set broken cookies (funny enough they don't like "\r" or "\n", so there seems to be some kind of check already).

#15 Updated by cicik over 1 year ago

stbuehler wrote:

I tried some weeks ago and couldn't reproduce it with any of those links - perhaps analytics got fixed.

The links work. You must go to these websites and then reload them :-)

#16 Updated by stbuehler about 1 year ago

I sent it to oss-security (http://thread.gmane.org/gmane.comp.security.oss.general/9864) and got:

In general the web browser vendors are CNAs (CVE Numbering
Authorities) so they would handle this on their own end. You should
probably email this to the various web browser security teams/etc.

Someone forwarded it to the mozilla tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=858215

Also available in: Atom