Project

General

Profile

Actions

Bug #3117

closed

Trigger crash when using lighttpd -1 with pipes

Added by povcfe-bug 8 months ago. Updated 8 months ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:
No

Description

1. vulnerability recurrence(lighttpd-1.4.61)

1.1 lighttpd default configuration

server.document-root = "/var/www/html/" 

server.port = 8080

mimetype.assign = (
  ".html" => "text/html",
  ".txt" => "text/plain",
  ".jpg" => "image/jpeg",
  ".png" => "image/png" 
)

1.2 compilation
wget https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.61.tar.gz
./configure
make
make install

1.3 demo

image1

1.4 ASAN

image2

2. analysis of the causes of vulnerabilities

'lighttpd -1' binds the input pipe to the same http-con as the output pipe, If the input pipeline is closed immediately after an incorrect http message is entered, the following process is triggered:

  1. http message parsing error, http-con is marked as CON_STATE_ERROR
  2. The input pipeline close action triggers "epoll FDEVENT_HUP", When processing http-con with the CON_STATE_ERROR flag, the http-con will be cleared and the output pipe will be closed
  3. The output pipe closing action triggers "epoll FDEVENT_HUP" again. Because the output pipe is bound to the same "http-con" as the input pipe, and the output pipe does not know that the "http-con" has been cleared, "server_oneshot_handle_fdevent" triggers a null pointer reference.
static handler_t server_oneshot_handle_fdevent(void *context, int revents)
{
    ...
    // fdn = con->fdn == NULL´╝îcause fdn->handler to generate null pointer references
    fdnode * const fdn = con->fdn; /* fdn->ctx == con */
    handler_t rc = ((fdevent_handler)NULL != fdn->handler)
      ? (*fdn->handler)(con, revents)
      : HANDLER_FINISHED;
    ...
}

3. Remote Scenes

'lighttpd -1' is designed to handle requests similar to 'xinetd', and if the input pipe is closed immediately after passing data, the vulnerability will be triggered remotely and produce a denial of service


Files

clipboard-202112011700-wbx3a.png (42 KB) clipboard-202112011700-wbx3a.png image1 povcfe-bug, 2021-12-01 09:00
clipboard-202112011702-phhxw.png (167 KB) clipboard-202112011702-phhxw.png image2 povcfe-bug, 2021-12-01 09:02
http.txt (42 Bytes) http.txt http.txt povcfe-bug, 2021-12-01 09:19
Actions #1

Updated by stbuehler 8 months ago

Where exactly is the DoS when crashing a process that only handles the single request that triggered the crash?

Actions #2

Updated by gstrauss 8 months ago

If run from xinetd, then stdin is a socket, not a pipe.
If run from nc (netcat), stdin and stdout pipes will be independent pipes.

I'll take a closer look at the scenario you have presented, but my initial quick review suggests that this can not be triggered remotely from xinetd.
Thank you for the report and for the test scenario.

Actions #3

Updated by povcfe-bug 8 months ago

gstrauss wrote in #note-2:

If run from xinetd, then stdin is a socket, not a pipe.
If run from nc (netcat), stdin and stdout pipes will be independent pipes.

I'll take a closer look at the scenario you have presented, but my initial quick review suggests that this can not be triggered remotely from xinetd.
Thank you for the report and for the test scenario.

Indeed, he cannot be reproduced on xinetd.I mean there's a chance he'll be in a scene like 'xinetd'.

Actions #4

Updated by povcfe-bug 8 months ago

stbuehler wrote in #note-1:

Where exactly is the DoS when crashing a process that only handles the single request that triggered the crash?

When the output pipe 'epoll FDEVENT_HUP' is triggered again after 'http-con' is cleared due to http parsing error, 'server_oneshot_handle_fdevent' is called, in which 'con->fdn == NULL'

Actions #5

Updated by gstrauss 8 months ago

Indeed, he cannot be reproduced on xinetd.I mean there's a chance he'll be in a scene like 'xinetd'.

No, no there is not. The bug you found is in lighttpd's handling of lighttpd -1 with pipes, e.g. with nc (netcat). This will not occur with xinetd. No chance.

The bug occurs with lighttpd -1, which by definition is one-shot. This does not cause a denial of service, since the next independent request will result in a new instance of lighttpd.

What you have found is a bug that causes lighttpd to crash in a very specific use case, which is not common. Still, lighttpd should detect this situation and should not crash.

Actions #6

Updated by gstrauss 8 months ago

  • Subject changed from Security - Trigger denial of service vulnerability when using lighttpd -1 to Trigger crash when using lighttpd -1 with pipes
Actions #7

Updated by gstrauss 8 months ago

Quick patch should work around this issue. However, I am still reviewing to see if there are better solutions.

--- a/src/server.c
+++ b/src/server.c
@@ -444,7 +444,7 @@ static handler_t server_oneshot_handle_fdevent(void *context, int revents) {
     fdevent_fdnode_event_set(con->srv->ev, oneshot_fdn, n);

     fdnode * const fdn = con->fdn; /* fdn->ctx == con */
-    handler_t rc = ((fdevent_handler)NULL != fdn->handler)
+    handler_t rc = (fdn && (fdevent_handler)NULL != fdn->handler)
       ? (*fdn->handler)(con, revents)
       : HANDLER_FINISHED;

Actions #8

Updated by povcfe-bug 8 months ago

good work, 'lighttpd -1' is usually used in resource-limited spaces, and will use more resources anyway. Is it possible for me to get a cve number

Actions #9

Updated by gstrauss 8 months ago

I do not believe this is a bug in a real-world use case. As such, I do not believe this qualifies for a CVE.

As I mentioned above, this bug occurs with pipes on stdin, and the bug does not occur with sockets. The bug does not occur with lighttpd -1 from xinetd.

As I mentioned above, the bug is not a denial of service, since lighttpd -1 handles one connection in one-shot mode. The next independent request will result in a new instance of lighttpd -1.

Please justify why you think a CVE is appropriate for a bug which is not a common use of lighttpd (lighttpd -1 on a pipe) and has no real effect besides not sending an HTTP response to the request after the input pipe is quickly closed.

Actions #10

Updated by povcfe-bug 8 months ago

Okay, I get it, looking forward to the next collaboration

Actions #11

Updated by gstrauss 8 months ago

Thank you for your bug report. The bug has been determined to be low-impact and not a denial of service.

.

Reposting generic info I have posted elsewhere in the past:

Not all bugs are vulnerabilities. Vulnerabilities are a subset of bugs.

From the official CVE site:
https://www.cve.org/ResourcesSupport/Glossary?activeTerm=glossaryVulnerability
https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_7-1_what_is_a_vulnerability

More specifically, a bug must violate security policy and have an impact.

Actions #12

Updated by gstrauss 8 months ago

  • Status changed from New to Fixed
Actions #13

Updated by gstrauss 8 months ago

  • Target version changed from 1.4.xx to 1.4.64
Actions

Also available in: Atom