Segfault / DoS (development branch; never released)
During fuzzing we found a denial of service in lighttpd 1.4.56-devel.
Details for reproduction are attached.
==43994==ERROR: AddressSanitizer: negative-size-param: (size=-2) #0 0x49a6fc in __asan_memmove (/usr/local/sbin/lighttpd+0x49a6fc) #1 0x4e7963 in connection_discard_blank_line /path/lighttpd/lighttpd1.4-git/src/connections.c:781:9 #2 0x4df891 in connection_handle_read_state /path/lighttpd/lighttpd1.4-git/src/connections.c:918:13 #3 0x4dd95e in connection_state_machine /path/lighttpd/lighttpd1.4-git/src/connections.c:1373:9 #4 0x4efd83 in network_server_handle_fdevent /path/lighttpd/lighttpd1.4-git/src/network.c:66:3 #5 0x5939ba in fdevent_linux_sysepoll_poll /path/lighttpd/lighttpd1.4-git/src/fdevent_linux_sysepoll.c:43:13 #6 0x540c29 in fdevent_poll /path/lighttpd/lighttpd1.4-git/src/fdevent.c:437:13 #7 0x4d0790 in server_main_loop /path/lighttpd/lighttpd1.4-git/src/server.c:1553:7 #8 0x4ca701 in main /path/lighttpd/lighttpd1.4-git/src/server.c:1594:13 #9 0x7f5a46d260b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16 #10 0x42276d in _start (/usr/local/sbin/lighttpd+0x42276d)
- Subject changed from Segfault / DoS to Segfault / DoS (development branch; never released)
- Category set to core
Thank you for the report. If your tests were from a non-tagged point on the master branch, please provide the commit SHA1 of the point in time you built lighttpd. There is no such tag as lighttpd 1.4.56-devel.
[Edit: bug.zip README.md contains reference to 3e046ccabfe7dff97d3f8e64716852efed311390. Thank you.]
I believe that the bug you are reporting here was fixed on my development branch on 4 Sep 2020
commit a3af9833c6bc341b61b7c5b1e1db81e432250ec2 Author: Glenn Strauss <gstrauss@...> Date: Fri Sep 4 19:22:56 2020 -0400 [core] fix crash on master if blank line request (bug on master branch; never released) (thx avij) fix crash on master if blank line precedes HTTP/1.1 keep-alive request header parsing code previously made assumptions that request was HTTP/1.0 or HTTP/1.1, where a request-line was required, and which would error out elsewhere if request-line was missing. The parsing code also previously looked for "\r\n\r\n" to end headers. The header offset parsing code was modified and invalidated the above assumptions, now looking only for blank line "\r\n", but the calling code had not properly been updated. (until this patch)
- Status changed from New to Fixed
Confirmed fixed by testing with patch backported from a3af9833 (with slight modification for compatibility with tip of master at 3e046cca)
My development branch containing the 4 Sep fix is scheduled to merge into the master branch in the next couple weeks.
Thank you for your report.
Also available in: Atom