curl: CVE-2023-38039: HTTP header allocation DOS

It was found that curl does not currently limit the amount of HTTP headers to be received leading to a potential DOS for the users.
If an attacker sets up a malicious HTTP server that continuously sends new headers and keeps the socket open, curl will continuously listen on the socket and parse new received headers. This leads to the user’s machine allocating more and more resources until the system is eventually exhausted.
From research the vulnerable function seems to be located at https://github.com/curl/curl/blob/master/lib/transfer.c#L420.
For comparison, modern browsers abort the connection once they reach a threshold.
One potential fix to not affect functionality too much would be to set an arbitrary limit to the amount of headers to receive, which I believe is the solution adapted by most modern browsers to solve this issue.

Screenshot

{F2513231}
My excuses for the French in screenshot (I’m sorting programs by RAM usage, and the top one is of course the windows terminal from which I executed curl). On there you can see my user terminal (windows) launching curl 127.0.0.1:80 to the left, on the right we see the attacker’s server (attaching full source code to this report). Throughout testing memory usage kept increasing alarmingly high.

Malicious server code extract:

void send_payload(int fd)
{
	memset(speedup, 'a', sizeof(speedup));
	//first we send the start of a valid HTTP request with status line and a few headers
    send(fd, validreq, sizeof(validreq), MSG_MORE);	
	while (1337)
	{
		//this is used to speed up the dos process sending extra bytes
		send(fd, speedup, sizeof(speedup), MSG_MORE );
		//now we're spamming the curl client with the header "a:b" then telling it there's more to come !
		send(fd, "a:b\x0d\x0a", 5, MSG_MORE );
	}
}

Steps To Reproduce:

1. Compile exploit.c and execute the server binary.
   Note: depending on your system, feel free to play with the ATTACK_SPEED define of the code, to speed up testing.
2. Open up another terminal and as the victim try curl 127.0.0.1:80
3. Observe system metrics.

Impact

DOS/overloading of user’s system through malicious HTTP server interaction with curl’s header parsing.