Possible vulnerability in apache 2.0.49 posted to FD: Description: There is denial of service in apache httpd 2.0.49. It is possible to consume arbitrary amount of memory. On 64 bit systems with more than 4GB virtual memory this may lead to heap based buffer overflow whose exploitation is unclear at the moment. Details: The problem is in server/protocol.c ap_get_mime_headers_core: ------
Possible vulnerability in apache 2.0.49 posted to FD: Description: There is denial of service in apache httpd 2.0.49. It is possible to consume arbitrary amount of memory. On 64 bit systems with more than 4GB virtual memory this may lead to heap based buffer overflow whose exploitation is unclear at the moment. Details: The problem is in server/protocol.c ap_get_mime_headers_core: ------ if (last_field != NULL) { if ((len > 0) && ((*field == '\t') || *field == ' ')) { ... fold_buf = (char *)apr_palloc(r->pool, alloc_len); ----- If header lines starts with TAB or SPACE, apache allocates memory for it. This allows making arbitrary long header lines. The following applies to 64 bit systems with a lot of virtual memory if sizeof(long)==8 and sizeof(int)==4. This code can be hit on line 743: ap_escape_html(r->pool, last_field), last_field can be arbitrary long. Looking into ap_escape_html shows: ---- int i, j; for (i = 0, j = 0; s[i] != '\0'; i++) if (s[i] == '<' || s[i] == '>') j += 3; else if (s[i] == '&') j += 4; if (j == 0) return apr_pstrmemdup(p, s, i); x = apr_palloc(p, i + j + 1); ---- (i+j+1) can be made almost arbitraty because of int signedness. On linux x86_64 it was confirmed that sending about 820MB of data overflows (i+j+1) which leads to a crash in memcpy, but with good heap layout more can be done. Probably only (i) can wrap, but because of the way in which apache leaks memory this is not tested yet.
zul: as I mentioned on IRC -- this is unconfirmed save for the original link.
It hasnt made into apache cvs yet. I will add it when it does..version bump yadda yadda
Patch has been added to apache-cvs. Im making sure that the patch applies cleanly and nothing goes wrong. A version bump should be available shortly. chuck
Ebuild with patch has been added. Please have other arches test it.
All Arches : please test and mark stable
MANUAL_VERSION="2.0.49-r3" in the -r4 ebuild is incorrect... I'm changing it to ${PVR} stable amd64
Won't build on ~mips, can't keyword it for now. config.status: creating support/logresolve.pl config.status: creating support/phf_abuse_log.cgi config.status: creating support/split-logfile config.status: creating build/rules.mk config.status: creating include/ap_config_auto.h config.status: error: cannot find input file: include/ap_config_auto.h.in Portage 2.0.51_pre10 (default-mips-1.4, gcc-3.4.0, glibc-2.3.4.20040605-r1, 2.4. 23-mipscvs-20031128) ================================================================= System uname: 2.4.23-mipscvs-20031128 mips R5000 V1.0 FPU V1.0 Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 ACCEPT_KEYWORDS="mips ~mips" AUTOCLEAN="yes" CFLAGS="-O2 -mips4 -march=r5000 -mabi=32 -pipe" CHOST="mips-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mips4 -march=r5000 -mabi=32 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg ccache" GENTOO_MIRRORS="http://evildrop/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://evildrop.home/gentoo-portage" USE="berkdb gdbm gpm libwww mips ncurses opengl pam perl python readline ruby sdl slang ssl tcpd vim"
stable on sparc
Looks like the problem I had on mips was caused by ccache. Builds fine with ccache disabled, so stable on mips.
Stable on x86.
*** Bug 55618 has been marked as a duplicate of this bug. ***
GLSA drafted: security please review.
Stable on hppa.
Stable on alpha.
Stable on ppc.
GLSA 200407-03
stable on arm
stable on ia64