# \[SEC\] Mongrel Temporary Fix For cgi.rb 99% CPU DoS Attack

**URL:** <https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639>\
**Category:** Rails\
**Created:** [October 25, 2006, 9:42pm UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639 "2006-10-25T21:42:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Zed\_ASShaw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/f475e1/32.png) [@Zed\_ASShaw](https://www.ruby-forum.com/u/Zed_ASShaw)\
**Post date:** [October 25, 2006, 9:42pm UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639/1 "2006-10-25T21:42:38Z")

</div>

This is important so please read this message very carefully.

There is a DoS for Ruby’s cgi.rb that is easily exploitable. The attack  
involves sending a malformed multipart MIME body in an HTTP request.  
The full explanation of the attack as well as how to fix it RIGHT NOW is  
given below.

I’m putting this fix into the Mongrel pre-release process to give Matz  
time to get an official release out. If he doesn’t within the next few  
days then I’ll turn this into an official Mongrel release.

FULL DISCLOSURE

There has been an exploitable bug in the Ruby CGI library named cgi.rb  
which allows:

Anyone on the Internet to…  
Send a single HTTP request to…  
Any Ruby program (NOT just Mongrel) using…  
cgi.rb multipart parsing with…  
A malformed MIME body that…  
Causes the Ruby process to go into a 99% CPU infinite loop killing it.

I broke this down so that it’s as clear as possible, and so you don’t  
miss that it’s for ANY program using cgi.rb mime parsing. Not just  
Rails and Mongrel.

What happens is that the final MIME boundary is sometimes given as:

-ASDFADSFASFD–

Rather than:

–ADFADSFADSF–

And this causes cgi.rb to go into an infinite loop waiting for more  
input that isn’t coming. This is caused by any system that reads  
directly from an input stream that returns “” rather than EOF.

The fix described below has a full exploit/tester script demonstrating  
the defect. It also doesn’t matter if you have file uploads on your  
site or not. I can point this script at your site on any URI and cause  
a DoS on your site.

WHO’S AFFECTED

Currently, the following servers are affected:

- Mongrel – Reads from a StringIO so gets “” rather than EOF.
- Litespeed – Affected but has an internal timeout that nails the  
process.
- CGI Standalone – Impacted since reading from a normal input stream.
- Any other custom server using the above similar operations.

Looks like FastCGI’s FCGIInputStream, WEBrick and mod\_ruby are not  
vulnerable since they either read from a domain socket or don’t use  
normal cgi.rb.

THE FIX

Everyone using Mongrel can get the fix immediately by installing the  
latest pre-release version 0.3.14:

sudo gem install mongrel --source=[http://mongrel.rubyforge.org/releases](http://mongrel.rubyforge.org/releases)

Win32 people and anyone who can’t upgrade that way can get the fix by  
doing this:

1. gem install cgi\_multipart\_eof\_fix  
–source=[http://mongrel.rubyforge.org/releases](http://mongrel.rubyforge.org/releases)
2. Edit your environment.rb to have: require ‘cgi\_multipart\_eof\_fix’
3. Restart your services.

People using other frameworks can get the fix by simply requiring  
rubygems and this fix in some start-up location for your framework.

THE PATCH

If you can’t do the hot fix gem install, then there is also a patch for  
cgi.rb attached to this e-mail. You can apply the patch with the  
following process:

1. Find the original cgi.rb file in your install. Mine’s in  
/usr/lib/ruby/1.8
2. cd /usr/lib/ruby/1.8
3. sudo patch \< ~/cgi\_multipart\_eof\_fix.patch

You can look at the patch. It’s literally changing one line, so you can  
edit by hand if you get really desperate.

FUTURE DEFECTS

Based on how the cgi.rb file is coded it’s most likely that there will  
be more of these kinds of defects in the future. If you find a defect  
like this, then please don’t flip out. Just report it to me or anyone  
else, and I’ll cook up another one of these hot fix releases rather than  
wait for an official fix. I promise immediate turn-around from now on  
using a hot-fix gem if I can’t get an official fix within a few days.

Suggestions on how to do a more standardized hot-fix release process are  
much appreciated.

Flame wars about screwing goats or the merits of full-disclosure are not  
appreciated.

GETTING HELP

I’ll be in the Mongrel lingr room:

[http://www.lingr.com/room/3yXhqKbfPy8](http://www.lingr.com/room/3yXhqKbfPy8)

And on [irc.freenode.org](http://irc.freenode.org) in #rubyonrails, #rails-security, and #ruby-lang  
fielding questions and helping people. If I don’t answer right away  
then wait a bit.

I’ll also answer help e-mails directly if you can’t access any of the  
above.

CREDITS

Most of the work was done by Jeremy K. and Jamis B… They did all  
the work of building the hot fix gem you’ll install and getting the  
right people to finally agree to get this out.

The original report is attached to this message so you can read it in  
full.

* * *

Zed A. Shaw

---

<div class="post-metadata">

**Author:** ![Zed\_ASShaw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/f475e1/32.png) [@Zed\_ASShaw](https://www.ruby-forum.com/u/Zed_ASShaw)\
**Post date:** [October 25, 2006, 10:30pm UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639/2 "2006-10-25T22:30:43Z")

</div>

On 10/25/06, Zed A. Shaw [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> There is a DoS for Ruby’s cgi.rb that is easily exploitable. The attack  
> involves sending a malformed multipart MIME body in an HTTP request. The  
> full explanation of the attack as well as how to fix it RIGHT NOW is given  
> below.
> 
> I’m putting this fix into the Mongrel pre-release process to give Matz  
> time to get an official release out. If he doesn’t within the next few days  
> then I’ll turn this into an official Mongrel release.

To underline and bold: you’re unaffected if you’re in production on  
FastCGI.

The vulnerability has been reported to removed\_email\_address@domain.invalid and the  
various OS distros. Matz fixed it in 1.8 CVS but hasn’t backported,  
hence  
the full disclosure and hotfix now.

Track it at  
[CVE - CVE-2006-5467](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5467)(should  
be up shortly).

jeremy

---

<div class="post-metadata">

**Author:** ![Zed\_ASShaw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/f475e1/32.png) [@Zed\_ASShaw](https://www.ruby-forum.com/u/Zed_ASShaw)\
**Post date:** [October 25, 2006, 11:18pm UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639/3 "2006-10-25T23:18:48Z")

</div>

Can anyone help with a way to have a DIV follow along while a user is  
scrolling down a long screen? I have seen it on several sites, but  
don’t know how to accomplish it.

Thanks,  
Nathan

---

<div class="post-metadata">

**Author:** ![Zed\_ASShaw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/f475e1/32.png) [@Zed\_ASShaw](https://www.ruby-forum.com/u/Zed_ASShaw)\
**Post date:** [October 26, 2006, 1:22am UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639/4 "2006-10-26T01:22:58Z")

</div>

I don’t think it’s possible to this with CSS, I think you need some  
javascript that essentially resets the style.top on the div element on  
the page scroll event.

On 10/25/06, Nathan L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> 

–  
Thomas M.  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![Zed\_ASShaw](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/f475e1/32.png) [@Zed\_ASShaw](https://www.ruby-forum.com/u/Zed_ASShaw)\
**Post date:** [October 26, 2006, 1:37am UTC](https://www.ruby-forum.com/t/sec-mongrel-temporary-fix-for-cgi-rb-99-cpu-dos-attack/73639/5 "2006-10-26T01:37:00Z")

</div>

> I don’t think it’s possible to this with CSS, I think you need some  
> javascript that essentially resets the style.top on the div element on  
> the page scroll event.

Actually it is… depending on what you mean by “follow along”. If you  
don’t mind it being fixed you can…

> **[stu nicholls | CSS PLaY | emulating position fixed for Internet Explorer](http://www.cssplay.co.uk/layouts/fixed.html)**
>
> CSS ~ Cutting edge Cascading Style Sheets. Experiments in CSS