Project

General

Profile

Actions

Bug #3281

closed

`lighttpd -tt` segfaults in mod_gnutls.c

Added by mwhitlock 11 days ago. Updated 11 days ago.

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

Description

Although Lighttpd 1.4.79 seemingly runs okay, it crashes when invoked with the -tt option to check the config. The crash occurs at line 241 in mod_gnutls.c. That's in the function mod_gnutls_kp_rel. The pointer that is passed in appears to hold a garbage address (one that was never returned by mod_gnutls_kp_init). The same issue occurs in 1.4.78. I did not check older.

Actions #1

Updated by gstrauss 11 days ago

  • Status changed from New to Need Feedback

lighttpd using mod_gnutls does not crash for me with a simple config on Fedora 42.

Please provide more details. Try reducing your lighttpd config and posting a simplified config.
How to get support

Actions #2

Updated by gstrauss 11 days ago

If you have misconfigured lighttpd TLS and have the ssl.engine enabled, but have not configured a default cert, I see that there is the possibility that something might have a garbage pointer.
Here's an untested patch, which matches what is done in lighttpd mod_openssl:

--- a/src/mod_gnutls.c
+++ b/src/mod_gnutls.c
@@ -2389,7 +2389,7 @@ mod_gnutls_set_defaults_sockets(server *srv, plugin_data *p)
         /*conf.ssl_ctx = NULL;*//*(filled by network_init_ssl() even on error)*/
         if (0 == network_init_ssl(srv, &conf, p)) {
             plugin_ssl_ctx * const s = p->ssl_ctxs[sidx] =
-              ck_malloc(sizeof(plugin_ssl_ctx));
+              ck_calloc(1, sizeof(plugin_ssl_ctx));
             s->ssl_session_ticket = conf.ssl_session_ticket;
             s->priority_cache     = conf.priority_cache;
           #if GNUTLS_VERSION_NUMBER < 0x030600

Actions #3

Updated by mwhitlock 11 days ago · Edited

gstrauss wrote in #note-1:

Please provide more details. Try reducing your lighttpd config and posting a simplified config.

The following is a minimal configuration that reproduces the crash:

server.modules = (
    "mod_gnutls" 
)

server.document-root = "/var/www/localhost/htdocs" 

$SERVER["socket"] == ":443" {
    ssl.engine = "enable" 
    ssl.pemfile = "ssl/localhost.crt" 
    ssl.privkey = "ssl/localhost.key" 
}

$HTTP["host"] == "example.com" {
    $SERVER["socket"] == ":443" {
        ssl.pemfile = "ssl/localhost.crt" 
        ssl.privkey = "ssl/localhost.key" 
    }
}

Of course, in reality the virtual host uses a different certificate and key than the default server, but specifying the same pair suffices to demonstrate the crash. It's just a self-signed sha256WithRSAEncryption certificate.

You can also put the ssl.* directives directly inside the $HTTP["host"] block, and you will still get a crash as long as you have some other conditional block inside there, such as:

$HTTP["host"] == "example.com" {
    ssl.pemfile = "ssl/localhost.crt" 
    ssl.privkey = "ssl/localhost.key" 
    $HTTP["scheme"] == "http" {
    }
}

Actions #4

Updated by gstrauss 11 days ago · Edited

Thanks. I will test the configs you shared.

Please note that lighttpd TLS docs specifically call out that nesting $SERVER["socket"] should not be nested inside other conditions:

Note: ssl.* configuration options are generally valid only in global scope or in the top level of a $SERVER["socket"] configuration condition, as they are needed when the socket connection is established, before the host is known. In cases where the client adds SNI (server name indication), some ssl.* options can be specified in $HTTP["host"] or $HTTP["scheme"] conditions, e.g. to select certificates for that specific connection. All other conditions occur after TLS negotiation has completed, so ssl.* directives nested in other configuration conditions may be ignored, including $SERVER["socket"] or $HTTP["host"] or $HTTP["scheme"] nested in other configuration conditions.

Actions #5

Updated by gstrauss 11 days ago · Edited

  • Status changed from Need Feedback to Patch Pending
  • Target version changed from 1.4.xx to 1.4.80

If I compile with -fsanitize=address and link with libasan, then I can reproduce the issue. The issue is fixed with the patch above.

Actions #6

Updated by gstrauss 11 days ago

  • Status changed from Patch Pending to Fixed
Actions #7

Updated by mwhitlock 11 days ago

gstrauss wrote in #note-6:

Applied in changeset 3d550097d2ededc34ac67dc8f63c156afdcdd768.

I confirm that this patch fixes the issue for me. Thanks for the speedy resolution.

Actions

Also available in: Atom