The initial bug in Ruby/Rails is striking in its stupidity.[1] You can send something to Ruby/Rails in a session cookie which, when unmarshalled, stores into any named global variable in the namespace of the responding program. It's not a buffer overflow or a bug like that. It's deliberately designed to work that way. It's like doing "eval" on untrusted input. This was on YC years ago.[2] Why was anything so idiotic ever put in Ruby at all?
Something like this makes you suspect a deliberate backdoor. Can the person who put this into Ruby/Rails be identified?
I think you're overextrapolating here, though I admit my knowledge on this isn't totally up to date.
As I understand it, Ruby's Marshal function, which takes text data and deserializes it, is not safe by default. So, is that a flaw of Ruby? I guess...except that this kind of serialization seems to be a standard feature in languages (well, Ruby and Python, the two things I currently use):
> Warning The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.
So the true bug seems to be that in Rails ActiveSupport (in a deprecated class, which uses some of Ruby's fun meta magic to deal with missing methods -- so basically, the classic obfuscation of functionality as a tradeoff for some sugary magic, all in a deprecated function that likely no one revisits), you can trigger a set of functions and routines in which the final decoding step, for whatever reason, ends up invoking Ruby's Marshal (via Rack: http://www.rubydoc.info/github/rack/rack/Rack/Session/Cookie...)
Also, only the server is allowed to put things into the session cookie, which is enforced by checking the cookie's signature which is generated from a key that only the server is supposed to know. Using a "native object" serializer (like Marshal or pickle) for session data and storing the secret token in a file that is easy to accidentally check into source control are both stupid things to do, but they're also common mistakes and you have to do both at the same time for this attack to work, so it seems quite overboard to suggest it was done deliberately.
Completely right. If the secret server token is compromised, it is presumed that you can fake any data. Should that allow for RCE? That's where Ruby steps in and provides the double whammy.
This might be a useful attack vector against ad servers and trackers. Those use complex cookies. The next step in the ad blocker war may be taking over ad servers.
Something like this makes you suspect a deliberate backdoor. Can the person who put this into Ruby/Rails be identified?
[1] http://robertheaton.com/2013/07/22/how-to-hack-a-rails-app-u... [2] https://news.ycombinator.com/item?id=6110386
reply