Package: lighttpd Version: 1.4.45-1 Tags: security patch While debugging a problem with lighttpd on behalf of my current employer Intenta GmbH, I found an out of bounds read.
http://sources.debian.net/src/lighttpd/1.4.45-1/src/mod_scgi.c/#L1828 | for (c = hctx->response_header->ptr, cp = 0, used = buffer_string_length(hctx->response_header); used; c++, cp++, used--) { | if (*c == ':') in_header = 1; | else if (*c == '\n') { | if (in_header == 0) { | /* got a response without a response header */ | | c = NULL; | header_end = 1; | break; | } | | if (eol == EOL_UNSET) eol = EOL_N; | | if (*(c+1) == '\n') { | header_end = 1; | hlen = cp + 2; | break; | } | | } else if (used > 1 && *c == '\r' && *(c+1) == '\n') { The loop is constructed such that up to `used` bytes can be read starting from `c`. Thus the access to `*c` is ok. However accessing `*(c+1)` may be out of bounds. The condition should check for `used > 1` before accessing `*(c+1)`. Both the later condition checking for CR LF in the excerpt above and an even later condition checking for double CR LF do check for sufficient buffer contents. It's only this one occurrence that misses the check. In practise, this can result in lighttpd sending corrupted responses to its clients when its SCGI reads are chunked in a bad way (i.e. they end with '\n'). The following patch fixes the problem: --- a/src/mod_scgi.c +++ b/src/mod_scgi.c @@ -1826,7 +1826,7 @@ if (eol == EOL_UNSET) eol = EOL_N; - if (*(c+1) == '\n') { + if (used > 1 && *(c+1) == '\n') { header_end = 1; hlen = cp + 2; break; It is unclear whether this issue can be used to corrupt the memory of a lighttpd. The actual impact beyond malformed responses is not clear and thus no attempt has been made at allocating a CVE. Helmut _______________________________________________ Secure-testing-team mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/secure-testing-team
