From owner-freebsd-ports-bugs@FreeBSD.ORG Tue Feb 16 05:00:13 2010 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C46106566B for ; Tue, 16 Feb 2010 05:00:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C0B4A8FC16 for ; Tue, 16 Feb 2010 05:00:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1G50D9T002391 for ; Tue, 16 Feb 2010 05:00:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1G50DF1002390; Tue, 16 Feb 2010 05:00:13 GMT (envelope-from gnats) Resent-Date: Tue, 16 Feb 2010 05:00:13 GMT Resent-Message-Id: <201002160500.o1G50DF1002390@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, john Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B60AB1065670 for ; Tue, 16 Feb 2010 04:50:39 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 65C928FC0A for ; Tue, 16 Feb 2010 04:50:39 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o1G4od46022240 for ; Tue, 16 Feb 2010 04:50:39 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o1G4odE4022239; Tue, 16 Feb 2010 04:50:39 GMT (envelope-from nobody) Message-Id: <201002160450.o1G4odE4022239@www.freebsd.org> Date: Tue, 16 Feb 2010 04:50:39 GMT From: john To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: ports/143980: slow request dos/oom attack X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 05:00:14 -0000 >Number: 143980 >Category: ports >Synopsis: slow request dos/oom attack >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Feb 16 05:00:13 UTC 2010 >Closed-Date: >Last-Modified: >Originator: john >Release: 7,2 >Organization: >Environment: >Description: 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. >How-To-Repeat: >Fix: Patch attached with submission follows: --- Makefile.orig 2010-02-15 20:39:47.000000000 -0800 +++ Makefile 2010-02-15 20:40:03.000000000 -0800 @@ -6,7 +6,7 @@ # PORTNAME= lighttpd -PORTVERSION= 1.4.25 +PORTVERSION= 1.4.26 CATEGORIES= www MASTER_SITES= http://download.lighttpd.net/lighttpd/releases-1.4.x/ --- distinfo.orig 2010-02-15 20:39:57.000000000 -0800 +++ distinfo 2010-02-15 20:40:10.000000000 -0800 @@ -1,3 +1,3 @@ -MD5 (lighttpd-1.4.25.tar.bz2) = 2027c49fb46530e45338c5e2da13c02f -SHA256 (lighttpd-1.4.25.tar.bz2) = 7e803089f18b179097cb33b64b37d8a3b537ce9c196c88e3fb09881b471c88ce -SIZE (lighttpd-1.4.25.tar.bz2) = 628267 +MD5 (lighttpd-1.4.26.tar.bz2) = a682c8efce47a2f4263a247ba0813c9b +SHA256 (lighttpd-1.4.26.tar.bz2) = d7c25a5bb08c8dbc3e8d86f9e564c90ebf0c365d7fcf5ee801e912fb3c2357fd +SIZE (lighttpd-1.4.26.tar.bz2) = 627971 >Release-Note: >Audit-Trail: >Unformatted: