Multiple vulnerabilities found in Rack

https://groups.google.com/forum/#!msg/rack-devel/mZsuRonD7G8/DpZIOmMLbOgJ

by michaelfairley • 13 years ago

21 7 13 years ago

groups.google.com

joevandyk• 13 years ago

If my site is SSL only, is it still vulnerable to the cookie timing attack?

Are there details about the file-traversal one?

moonboots• 13 years ago

SSL doesn't protect against this timing attack. The vulnerability allows an attacker to generate a malicious cookie that the rack server believes is authentic. The attacker sends repeated http/https requests to your server with the malicious cookie and calculated variations in the cookie's authentication code, using slight differences in the server's response time to determine how much of the auth code is correct. It's possible to measure these timing variations, especially if an attacker rents a box in the same data center [1].

The relevant commit [2] and an explanations of equivalent vulnerabilities [3][4]

[1] http://www.youtube.com/watch?v=ehxjAq59xEw

[2] https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6...

[3] http://rdist.root.org/2009/05/28/timing-attack-in-google-key...

[4] http://codahale.com/a-lesson-in-timing-attacks/

trapexit• 13 years ago

The file traversal vulnerability allows an attacker to access unauthorized files outside of the document root, assuming that there exists a symlink from inside the document root to a path that is outside of it.

For example:

Symlink: public/foo -> /secret/path/not_very_secret

An attacker could request /foo/../really_secret, which the OS would interpret as /secret/path/really_secret and happily serve up.

The attacker is limited in the number of ".." components they can add to the path by the number of real path components that precede it, i.e. they still cannot do /foo/../../../etc/passwd

The fixed version of rack correctly removes ".." path components before passing the resulting path to the OS, i.e. "/foo/../really_secret" is translated to "/really_secret", and results in a 404 error instead of a security breach.

This vulnerability is particularly concerning for Rails apps deployed using Capistrano (unless config.serve_static_assets = false). This is because there are typically symlinks from public/assets and public/system to the corresponding directories under the Capistrano deploy's "shared" directory, and also under "shared" are typically things like logs, configuration, and a copy of the application code!

Fortunately, Rails ships by default with a production configuration that sets serve_static_assets to false, relying on the frontend web server to serve up all static content (so the attacker will just get a 404). This directory traversal bug is not present in current versions of Apache or nginx.

jtchang• 13 years ago

How many people use rack? Is it almost always used when deploying rails apps?

mikeryan• 13 years ago

Ruby based web apps, Sinatra is based on Rack and pretty popular for lighter apps.

michaelfairley• 13 years ago

Almost all Ruby web apps are deployed on top of Rack.

tiegz• 13 years ago

Rails has been built around Rack for a couple years, but I think its sessions are safe from this Rack vulnerability. Rails' CookieStore class inherits from Rack::Session::Cookie, but it overwrites the unpacked_cookie_data() method which was open to a timing attack. Rails uses its own MessageVerifier class (https://github.com/rails/rails/blob/master/activesupport/lib...) to do a constant time comparison, which would avoid this attack.

Any other frameworks/libs that use Rack's session cookies should upgrade though, afaik.

Multiple vulnerabilities found in Rack

Related Stories