Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 2 Feb 2010 00:32:15 +0100
From: Stefan B├╝hler <>
To: "oss-security" <>
Subject: lighttpd: slow request dos/oom attack [CVE-2010-0295]


Li Ming reported a serious bug in lighttpd:

If you send the request data very slow (e.g. sleep 0.01 after each byte), 
lighttpd will easily use all available memory and die (especially for parallel 
requests), allowing a DoS within minutes.

The problem is that is doesn't append to previous buffer but allocates a new 
buffer for each read; this means that for every received block (which could be 
only one byte) lighttpd may use either 4k or 16k.

In lighttpd 1.4.x this problem is not too bad, as the allocated buffer is just 
as big as the content available to be read (if the system supports FIONREAD); 
but even with ssl (or if the system doesn't support FIONREAD), lighttpd 1.4.x 
will allocate 4k or 16k buffers for each read.

Lighttpd 1.5 (our old development branch) always allocates 16k buffers for a 

Our solution is to append to the previous buffer if it is still in the raw-in 
queue (while waiting for a request header), and to pack the buffers if they 
get moved to the next queue (for the request body).

In order to append to the previous buffer in lighttpd 1.4.x we ignored a 
SSL_read requirement: we don't pass the same buffer in the next call after 
SSL_ERROR_WANT_*; there is no good reason for this, and it has worked in 1.5 
for a long time now.

Please note that lighttpd 1.x always trusts the backend: it will always try to 
read from the backend (cgi,fastcgi,scgi,proxy,...) as fast as possible, so 
backends sending large files will lead to high memory usage in lighttpd.


This bug is tracked as CVE-2010-0295.

Kind regards,
lighttpd developer team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.