Bug 143980 - www/lighttpd: slow request dos/oom attack
Summary: www/lighttpd: slow request dos/oom attack
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Xin LI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-16 05:00 UTC by john
Modified: 2010-02-16 21:30 UTC (History)
0 users

See Also:


Attachments
file.diff (839 bytes, patch)
2010-02-16 05:00 UTC, john
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description john 2010-02-16 05:00:13 UTC
 slow request dos/oom attack
=============================

 Description
-------------

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
read.

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.

http://redmine.lighttpd.net/issues/2147

Thanks to Li Ming who reported the issue.

 Affected versions
-------------------

all versions before 1.4.26 / svn revision 2710

 Fixed in
----------

1.4.x: http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2710
1.5: http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2711

 Solutions or Workaround
-------------------------

There is no workaround.
Apply lighttpd-1.4.x_fix_slow_request_dos.patch
or lighttpd-1.5_fix_slow_request_dos.patch

This bug is tracked as CVE-2010-0295.

Fix: Patch attached with submission follows:
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-02-16 06:30:00 UTC
Responsible Changed
From-To: freebsd-ports-bugs->mnag

Fix synopsis and assign.  Set 'critical' due to nature of bug.
Comment 2 Xin LI freebsd_committer freebsd_triage 2010-02-16 21:19:35 UTC
State Changed
From-To: open->closed

Patch applied with secteam@ hat due to publicly available 
exploit. 


Comment 3 Xin LI freebsd_committer freebsd_triage 2010-02-16 21:19:35 UTC
Responsible Changed
From-To: mnag->delphij

Take.
Comment 4 dfilter service freebsd_committer freebsd_triage 2010-02-16 21:22:09 UTC
delphij     2010-02-16 21:22:00 UTC

  FreeBSD ports repository

  Modified files:
    www/lighttpd         Makefile distinfo 
  Log:
  Security update to 1.4.26.
  
  PR:             143980
  Submitted by:   john <smallpox gmail com>
  Security:       vuln 1a3bd81f-1b25-11df-bd1a-002170daae37
  With hat:       secteam
  Feature safe:   yes
  
  Revision  Changes    Path
  1.77      +1 -1      ports/www/lighttpd/Makefile
  1.41      +3 -3      ports/www/lighttpd/distinfo
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"