CVE-2016-0752 is explained in more detail here: https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-...
Great overview, thanks!
Multiple security vulnerabilities in Rails
61–66 of 66 posts
Re: Multiple security vulnerabilities in Rails
#62Aah Aaron. Thanks. Everywhere he codes he refactors, fixes performance issues, finds bugs, he's so my hero.
tenderlove is the best. Not only does he work on both Ruby and Ruby on Rails, he's also very active in the community (conferences, workshops, talks) and working hard on promoting a spirit of humility and respect (see the humorous Adequate HQ, the Friday Hug, the overwhelmingly positive and generous attitude he's always had towards anyone, famous or not, in the Ruby community). I have nothing but respect for that man…
Really really well said. So grateful to have him in our lovely community.
Re: Multiple security vulnerabilities in Rails
#63Earlier quoted context omitted.
Some programming styles are not defensive from a security perspective. As a programmer one should acknowledge that using "render" passing a param right from the request, without validating it, is not a good thing, right? That's my point. Some issues here can be solved just by taking the right approach, but won't solve for all of them, of course. XSS mitigation works better with encoding rather than sanitization. If y…
I mean ideally you should 1) strip tags 2) encode 3) use X-XSS headers 4) use CSP headers. That way if any one of these fails, the others will catch it. That said, there still shouldn't be security holes in the framework.
Stripping tags before encoding is security theatre. Encoding is just replacing 2–4 characters; if it’s not implemented properly, there’s no way tag stripping is.
Re: Multiple security vulnerabilities in Rails
#64On one hand, I find that Rails often has security issues. On the other hand, perhaps it is just indicative of its popularity and interest. When a framework has no security issues, is it because there are none or is it just that no one can be bothered to look for some?
The last entries on the Rails security list before this were from June of 2015. Does that seem like a lot to you?
Re: Multiple security vulnerabilities in Rails
#65I've grouped the patches for 4.1 and 4.2 here: https://drive.google.com/file/d/0BwnrE2iUdypUMkpqWVVPTXNzNVU... -- because download one by one is boring. Don't trust me, verify each file before patching. Some comments: [CVE-2015-7581] Object leak vulnerability for wildcard controller routes in Action Pack: Look for routes that contain ":controller" and change it to something else. Hopefully you didn't have this weird…
As an everyday Rails user, most of these aren't really that surprising. Sure, one could cite 'defensive programming' or whatever, but a lot of these behaviors are warned against in the documentation.
and static analyzers would yell at you for one or two of them, too
Re: Multiple security vulnerabilities in Rails
#66Doesn't look too bad, although there are a lot of CVEs to go through: - A timing attack if you're using HTTP basic auth - A couple of GC related DoS attacks - An issue with `accepts_nested_attributes_for` if you're using both the `allow_destroy` and `reject_if` options - A validation bypass exploit if you're calling `SomeModel.new(params[:some_model])` instead of using StrongParams - An information leak exploit if yo…
>- A timing attack if you're using HTTP basic auth I'd say that qualifies as pretty bad. How the hell does that even happen? Using time constant string comparison is authentication 101. That's really not something you can mess up by mistake, it's something you mess up by not understanding what you're doing. And that's is all ignoring the fact that there's no reason to not use hashing here.
Turns out, deciding how to compare two strings when they may be differing lengths is tricky.