111–120 of 294 posts
I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!
Could you confirm that upgrading to the fixed Rails versions means I don't have to add the line changing `ActionDispatch::ParamsParser::DEFAULT_PARSERS`? Or do I have to do both? Thanks!
I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!
Thank you for your fast hard work on this - this is what makes the Rails community so great and why I love it over the other options out there. I know this has to have been a stressful weekend. Is there a tip jar anywhere for beer money for the team that worked on this?
The 3.2.10 announcement provided an example of `Model.find_by_id(params[:id])` as an exploit, but nobody could figure out how you could get a hash with a _symbol_ key into `params[:id]`, which is what it would take for that to be an exploit. So people were confused.
But the pre-3.2.11 exploit, apparently, possibly provides ways to do just that, eh?
This vulnerability is also present in other other Ruby libraries. I would advise anyone to do bundle install --deployment in there development environment then 'grep -r "YAML::load"' and 'grep -r "YAML.load"' in the vendor/bundle directory. If you have YAML::load(user_controlled_value) or YAML.load(user_controlled_value) then you might be vulnerable to remote code execution. There are some other ruby libraries that a…
Earlier quoted context omitted.
I don't think this is very responsible of you. You should post this, but you should really wait a week or so.
According to tptacek, "it was discovered by multiple teams independently" and "Lots of people have working proof-of-concept exploits for this". I think your week started Jan 02 with CVE-2012-5664.
I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!
As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…
Earlier quoted context omitted.
I don't think this is very responsible of you. You should post this, but you should really wait a week or so.
According to tptacek, "it was discovered by multiple teams independently" and "Lots of people have working proof-of-concept exploits for this". I think your week started Jan 02 with CVE-2012-5664.
Earlier quoted context omitted.
I don't think this is very responsible of you. You should post this, but you should really wait a week or so.
The post does not include any directly usable exploit code and does not describe command execution vectors. Furthermore information about the bug were published on twitter almost a week ago. But I probably will not convince you about the advantages of Full Disclosure :)
All this does is allow people who want to do harm to not have to figure it out themselves.
As a newcomer to the Rails ecosystem all these posts of vunlerabilities and open doors leaves a bad taste in my mouth. God know I love programming in Ruby now, but is Rails really that insecure?
Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues. It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you d…
Rails will always have zero-day security issues; I'd hazard that all web apps of any notable size will. What matters most to me is how the core team and community respond on those three criteria above.
Lately the Rails team has been performing exceptionally.
Earlier quoted context omitted.
I don't speak Ruby. Can you or someone else be more precise about where that introduces the vulnerability? (Surely it isn't that YAML::load(content) can run arbitrary shell code?)
Calling YAML::load on attacker-controlled content in a Ruby app of any complexity is very bad news. As Ben and 'judofyr said: this is remote code execution.