

Multiple vulnerabilities found in Rack - michaelfairley
https://groups.google.com/forum/#!msg/rack-devel/mZsuRonD7G8/DpZIOmMLbOgJ

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

Are there details about the file-traversal one?

~~~
trapexit
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
How many people use rack? Is it almost always used when deploying rails apps?

~~~
tiegz
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...](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/message_verifier.rb#L53))
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.

