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, codebases, and websites, fundamentally changing the way “top-down specification” works.

Until the Cookie RFC 6265, 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 way for servers to send cookiesField syntax, which provides the client with a distinct syntax for accepting 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.

Over time, The development of cookies is still slow, but the HTTP specification has been updated many times over the past few decades. More importantly, 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 acceptsContains control codecookie. 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:

Cookie: 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 if you don’t find it on my head).And the latest version of curl already fully complies with the latest The provisions of the draft version of RFC 6265bis.