41–50 of 96 posts
Shameless self promotion: we're working on something to make dealing with these patches less painful. It's not out yet, but soon: http://gemcanary.com
Do you plan to open source Gemcanary. Like Rubygems and Rubygems.org?
I want to shamelessly give a shout-out to Ryan from our MTV team on this one; Rails ActiveModel was I think? the first real piece of Ruby code he ever looked at, and he found the permset Blacklist regex bypass (joernchen found the other one) inside of an hour. Everyone here will testify that I was no help to him at all; my contributions mostly consisted of throwing a large rubber balancing ball at him from the other…
I want to send a big thank you to everyone looking closely at Rails right now. I really appreciate all the work that's being done. I can't tell you how happy it makes me to know that Rails becomes more secure every day because of efforts by teams like yours.
Given that there is no 3.0.X update this time, where's a good resource to learn about applying the manual patch?
what is bypass?
In this case, apparently it was possible to 'hide' your attribute behind a newline, making it invisible to the attr_protected code, but somehow the attribute could still be valid (for no reason rails calls #strip on it or something?).
Surely you should be using attr_accessible with config.active_record.whitelist_attributes = true anyway? I can't imagine a situation where you'd want to have to manually blacklist attributes over whitelisting them.
If i have a table with 20 columns, 19 of which i want accessible (lets exclude a private UK). I also expect the schema for the table to be volatile. Why should i even consider while listing 19+ over blacklisting 1?
Is stuff like this vulnerability present in Django as well, and just not being discovered as quickly, or is there something in the water (or was there years ago) in the Rails camp that caused all these bugs?
Beyond that, your guess is as good as mine. I'm sure that /someone/ has been looking at Django at least to see if there are similar issues.
Is stuff like this vulnerability present in Django as well, and just not being discovered as quickly, or is there something in the water (or was there years ago) in the Rails camp that caused all these bugs?
One of the core issues here was a serialization library that was too convenient, with the ability to deserialize into arbitrary classes and end up executing code from them. In the Python world, this vulnerability has been a bit better known for a while (which is not to say that they are immune, but it's at least been common community knowledge for a very long time now, at least a decade). Pickle is well-known to have…
Surely you should be using attr_accessible with config.active_record.whitelist_attributes = true anyway? I can't imagine a situation where you'd want to have to manually blacklist attributes over whitelisting them.
How about when you want the majority of your attributes whitelisted? I understand the urge to whitelist, but lets be reasonable here. If i have a table with 20 columns, 19 of which i want accessible (lets exclude a private UK). I also expect the schema for the table to be volatile. Why should i even consider while listing 19+ over blacklisting 1?
I don't use rails but it seems that the quality of releases have been going downhill over the pass months.
Patio11 is indeed the security soothsayer