

Rack - Important Security Upgrade - dpaluy
http://rack.github.com/

======
ChuckMcM
The RoR security issues have been depressing for me. My daughter had a credit
card stolen from a web site, built on rails by a third party for the owner,
the owner didn't know _what_ powered the web site, they had a really "easy to
use" tool for putting things up there. A code audit showed the site had been
completely re-done to appear the same and provide a card harvesting service
forwarding card information to the Ukraine.

How many more of these are there out there? tens? hundreds? thousands?

~~~
kawsper
Also, as I understand it, many american websites seems to store credit card
details, why is that?

In Denmark we often use a payment gateway, exactly to avoid these types of
attack. If my webshops database got leaked, my customers would not have to
fear creditcard leakage.

~~~
gwright
I suppose it is possible that programmers in Denmark are more skilled in
crafting secure payment processes than Americans, but isn't it more likely
that you're opinion is biased by a reporting bias? You are simply observing
more reports of problems at US websites because they are so many more US
websites than Denmarkian.

~~~
kawsper
I don't believe that programmers in Denmark is more skilled, or more focused
on security.

I have just often wondered why a lot of the webshops in the US that I use
stores all my information, I have never seen it here.

And no, I don't believe that I use more US-based webshops than Danish.

------
wildchild
2.5 years old issue <https://twitter.com/coda/status/299732877745197056>

Impressive.

------
ufo
I searched a bit and found patches that I think help to explain what was going
on and how severe things worse. I'd appreciate if anyone could confirm I found
the correct stuff and if anyone could help explain what happened (in
particular, I don't understand why the timing attack bug would lead to a
remote code execution)

\-----------

The first bug seems to be in some function that checks if you can find a file
in a folder. Currently the funtion counts the number of ".."s to make sure you
don't go out of the folder you started the search in (emitting an error if the
depth becomes less than 0) however, this does not take into account the
possibility of one of the intermediate folders in the pathbeing a symlink,
meaning that the `./symlink/../bar` is not the same as `./bar` and therefore
ruining the logic. The fix seems to be a hack to transform `./xxx/../b`s into
`./b` by hand, without passing it to the fylesystem.

[https://github.com/rack/rack/commit/6f237e4c9fab649d37504825...](https://github.com/rack/rack/commit/6f237e4c9fab649d3750482514f0fde76c56ab30)

The second bug seems to have to do with `==` not being safe and them having to
do a "secure compare":

[https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6...](https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07)

edit: apparently the problem here is the time that `==` takes to run depends
on the inputs. This means an attacker can do multiple carefully crafted
requests and use this timing information to guess your secret key stuff. I
still don't know why guessing the secret stuff would lead to remote code
execution though.

~~~
chrismcbride
The second one is a timing issue. You need to have an equality method that
takes an equal amount of time on success or failure.

Heres a good read on timing attacks in general: <http://codahale.com/a-lesson-
in-timing-attacks/>

~~~
vinhboy
"In short, a timing attack uses statistical analysis of how long it takes your
application to do something in order to learn something about the data it’s
operating on" -- great read.. my mind is blown for today...

------
rachelbythebay
I never realized the rack logo used the same font that Rackspace used to use.
It was a little disconcerting to see that at first.

For those who remember, it's the one which had 8 little rectangular machines,
with one of them pulled out a bit and glowing red. I used to say it was the
one that was on fire, because, well, it happens!

------
Robin_Message
How bad is this? I assume they say that Rails-based sessions are secure as
they are HMAC'd with a secret, which a timing attack won't break unless the
Rails HMAC testing is broken.

~~~
jrochkind1
It is confusing. Because of course rack is used by more than just rails, the
rack team's responsibility isn't reallyto say "If you're using Rails with it's
default signature verification, you're not vulnerable" -- they don't even have
the background to be sure that's true (even rails team might not, security is
hard).

The announcement also implies that the timing vulnerability _might_ only be
exposed to people on the same local network who have sufficient timing
granularity -- BUT that this applies to anything in the cloud, since people on
the same cloud are essentially in same local network. So if you're not in the
cloud...

On the other hand, I've [fucked up
before](<http://news.ycombinator.com/item?id=5003132>) _thinking_ I understood
the vulnerability and that it was unlikely to effect me, when in fact I was
operating without full information and misunderstanding the true extent of the
vulnerability. So now I figure, if the maintainers say "Todays releases are
important. All users should upgrade ASAP!", I better just act as if they are
right. Even though sometimes they won't be and are being over alarmist, I'm
not qualified to know when.

------
trustfundbaby
I imagine there's going to have to be a Rails release to upgrade the Rack
versions used?

~~~
steveklabnik
Three things:

1\. Some Rails apps shouldn't be affected, since Rails uses its own HMAC stuff
to handle this. From the rack homepage: "Some Rails users may not be affected
(if they only use Rails managed sessions)."

2\. You don't need an upgrade of Rails, just `bundle update rack`.

3\. 3-2-stable has already had the rack dependency bumped, so the next release
of 3.2 will include a minium of this latest release.

------
static_typed
Another day, another Ruby security bump. Sigh. Serious point - as Ruby seems
to attract all the younger generation of programmers these days, and the
current trend seems to be dev early, release early, security hole early, could
this be turned around by more experienced hands joining the community?

Could the Ruby way become a bit safer and more secure in time?

~~~
jabo
You mean Rails and not Ruby.

~~~
jrochkind1
I think he means ruby.

I'd agree that, in the ruby community in general, or at least the English-
speaking ruby community, general cultural values seem to be "dev early,
release early, security hole early". Valuing innovation and release-often over
stability/reliability. There are certainly some projects/developers that go
against this cultural norm, but we are certainly not the first to recognize it
as a general cultural norm in rubydom (and it's got benefits as well as
disadvantages).

~~~
static_typed
Yes, given we have seen issues in Core Ruby libraries (only recently updating
the CSV lib), in Rails, in Ruby Gems, in Rack, it seems to pervade the Ruby
Community.

Secure is not cool, nor magic enough, it seems.

~~~
nfm
I'm going against my better judgement in trying to critically engage you, but
what's your background? Are you a security researcher? Have you audited
Django? Have you read the Python source code? Why do you think a given
language community is going to be more secure than another? Is security one of
the tenets of Python?

