curl has a 23.9-year-old DOS vulnerability

Daniel, the author of curl, blogged about curl’s 23.9-year-old DOS exploit.

In October 1998, curl 4.9 was released, curl 4.9 was the first version with a “cookie engine” that could receive HTTP cookies, parse, understand, and correctly return cookies on subsequent requests.

Of course, curl’s audience was small at the time, and it wasn’t until a few months later that the curl website announced that curl version 4.9 had reached 300 downloads. And there was no clear specification for cookies at the time, the only specification describing how cookies worked was a very short document from Netscape called cookie_spec.

In the days that followed, the IETF (Internet Engineering Task Force) worked hard to create a cookie specification, but mostly failed. Because cookies are a bit special, they are implemented by many different authors, repositories, and websites, fundamentally changing the way “top-down specifications” work.

Until Cookie RFC 6265 was published in 2011 , this is the real cookie specification, explaining what a cookie is and what it should follow. But this also raises some questions, RFC 6265 provides a field syntax for how servers send cookies , and a very different syntax for clients to accept cookies. The double syntax causes two problems:

• It’s hard to read the spec because it’s easy to get stuck in one of the syntaxes and assume the syntax is valid for all use cases.
• Defining the syntax for sending cookies is of little use, since the client really decides how to receive and handle cookies. Existing large cookie parsers (like browsers) are fairly liberal in the format of content they accept, and no one pays attention to whether the server follows the syntax in the RFC specification.

Cookies have continued to evolve slowly over time , but the HTTP specification has been updated many times over the past few decades. What’s more, HTTP server implementations have implemented stricter parsing policies: if incoming HTTP requests look “illegal” or malformed, HTTP servers start rejecting them prematurely. Now try to send a request with a control code to a new HTTP server, and the server just rejects the request and returns a 400 response code.

A 23 year old bug

In late June 2022, curl received a report of a suspicious security issue with curl, which led to curl subsequently issuing CVE-2022-35252 .

It turns out that the 1998 curl cookie code accepts cookies containing control codes . The control code can be part of the name or content, and if the user enables the “cookie engine”, curl will store these cookies and return them on subsequent requests. for example:

Set -Cookie: name ^a= content ^b; domain=.example.com

^a and ^b represent control codes, byte codes one and two. Since the domain can mark the cookie as another host. Therefore, the cookie will be included in requests to all hosts within the domain. When curl sends such a cookie to an HTTP server, it includes a header field like this in outgoing requests:

Cookies : name^a=content^b

Whereas the default configured server will respond with 400. For scripts or applications that receive these cookies, as long as the cookies continue to be sent, further requests will be denied, creating a denial of service DOS attack.

These vulnerable cookie codes have been in curl since version 4.9 (day 201 of the curl project) and were not fixed until version 7.85.0 (day 8930 of the curl project), which took 8729 days in between (23.9 years).

Of course, according to Daniel, these cookie codes were released without problems, and they were used without problems for most of the user’s time. (It’s not my pot without finding my head) . And the latest version of curl has fully complied with the latest draft version of RFC 6265bis .