5 ms·

Multiple vulnerabilities found in Rack

21 points by michaelfairley 14y ago

joevandyk 14y 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 14y 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 http://www.youtube.com/watch?v=ehxjAq59xEw [2] https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6... [3] http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2009/05/28/timing-attack-in-google-key... [4] http://codahale.com/a-lesson-in-timing-attacks/ http://codahale.com/a-lesson-in-timing-attacks/
- trapexit 14y 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 14y ago
How many people use rack? Is it almost always used when deploying rails apps?
- mikeryan 14y ago
  Ruby based web apps, Sinatra is based on Rack and pretty popular for lighter apps.
- michaelfairley 14y ago
  Almost all Ruby web apps are deployed on top of Rack.
- tiegz 14y 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/active_support/message_verifier.rb#L53 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.

If my site is SSL only, is it still vulnerable to the cookie timing attack? Are there details about the file-traversal one?

moonboots 14y 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 http://www.youtube.com/watch?v=ehxjAq59xEw [2] https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6... [3] http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2009/05/28/timing-attack-in-google-key... [4] http://codahale.com/a-lesson-in-timing-attacks/ http://codahale.com/a-lesson-in-timing-attacks/
trapexit 14y 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 14y ago

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

mikeryan 14y ago
Ruby based web apps, Sinatra is based on Rack and pretty popular for lighter apps.
michaelfairley 14y ago
Almost all Ruby web apps are deployed on top of Rack.
tiegz 14y 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/active_support/message_verifier.rb#L53 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.