Multiple vulnerabilities found in Rack(groups.google.com)
groups.google.com
Multiple vulnerabilities found in Rack
https://groups.google.com/forum/#!msg/rack-devel/mZsuRonD7G8/DpZIOmMLbOgJ
2 comments
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.
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.
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/
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/
How many people use rack? Is it almost always used when deploying rails apps?
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.
Any other frameworks/libs that use Rack's session cookies should upgrade though, afaik.
Ruby based web apps, Sinatra is based on Rack and pretty popular for lighter apps.
Almost all Ruby web apps are deployed on top of Rack.
Are there details about the file-traversal one?