Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ActiveRecord Vulnerability - Circumvention of attr_protected

groups.google.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#51

Post by LawnGnome »

jerf wrote: post #40
IgorPartola wrote: post #29

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…

I'd be surprised if there wasn't at least one reasonably major PHP framework with similar sorts of vulnerabilities: while PHP's JSON decoder should be safe (it can't create any objects other than stdClass objects, which are simple property buckets), the use of unserialize() in older frameworks was rife (mostly due to a lack of alternatives), and that's definitely not safe with arbitrary user data -- as we've seen with the RoR issues, it only takes one code path where user data unexpectedly gets in somewhere it shouldn't.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#52

Post by josegonzalez »

jerf wrote: post #40
IgorPartola wrote: post #29

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…

AFAIK, the only way this could be an issue with the language is if you use serialize/unserialize, which can be used on classes. It goes without saying that this can be useful in certain contexts - such as file-based caching - but should not be relied upon too heavily.

I cannot remember the last time I came across a php project that did something similar.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#53

Post by fxn »

pjungwir wrote: post #38
tptacek wrote: post #26

Earlier quoted context omitted.

This is an extremely common bug that is not specific to Rails. It would be worth reviewing your code to look at every regex to see if you have similar flaws.

I seem to remember a blog post about this regex issue here on HN a few months ago. It definitely surprised me to learn that Ruby doesn't treat $ as end-of-string by default.

I blogged in http://advogato.org/person/fxn/diary/498.html some key differences between Perl and Ruby regexp flags (which includes this gotcha).

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#54

Post by SoftwareMaven »

jey wrote: post #47
jerf wrote: post #40

Earlier quoted context omitted.

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…

I doubt it's an issue of Python community vs Ruby community. Instantiating arbitrary objects is the sort of feature I'd expect an object serialization library to have, but not a document serialization library. Pickle is clearly an object serialization library, and I would have naively assume that YAML is a document serialization format, but apparently either the authors of the Ruby YAML parser or the creators of YAML…

Python's YAML library is also capable of serializing python objects[1]. My understanding is the YAML spec allows these extensions but does not require them.

If you are using PyYaml.Loader instead of PyYaml.SafeLoader for anything coming from a user, you are at risk of this problem.

http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPython...

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#55

Post by tomjen3 »

sync wrote: post #2

This one seems pretty amateur and should have been caught as part of a pull request/code review process. - @regex = /^(#{Regexp.escape(@prefix)})(.+?)(#{Regexp.escape(@suffix)})$/ + @regex = /\A(#{Regexp.escape(@prefix)})(.+?)(#{Regexp.escape(@suffix)})\z/ ^ and $ only match the first line in ruby, whereas \A and \z match across all lines.

So basically this attack relies on putting a not-blacklisted identifier on the first line?

How do you then get rails to assign it to the correct (blacklisted) identifier?

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#56

Post by SoftwareMaven »

IgorPartola wrote: post #29

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?

For all the complaints in the Python community that Django contains too much magic, Rails is far more magical; and that magic add complexity that allows these kinds of problems to show up.

That is not to say Django doesn't have issues; it undoubtably does. I just think the hidden surface area is smaller.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#57

Post by yxhuvud »

Tomdarkness wrote: post #7

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.

I have 170 tables in an app and a similar amount of controllers. 3 of those refer to the logged in user and in no place except the admin controller itself can you modify an object, or what an object refer to, in such a way where an administrator can access anything he or she shouldn't. Admins have different accounts not to restrict what they can do but to (automatically outside what can be modified by posting params to models) keep track of who has made what changes and to keep them for making incompatible changes at the same time.

So no, I'd rather not start whitelisting my models.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#58

Post by dcu »

Looks like this is actually an ActiveModel vulnerability and maybe mongoid is affected too.

Just like when rails people said they had a vulnerability in action dispatch but it was actually a YAML vulnerability. (both used in a lot of non-rails projects)

So please don't overlook this issue even if you are not using rails.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#59

Post by tptacek »

yxhuvud wrote: post #57
Tomdarkness wrote: post #7

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.

I have 170 tables in an app and a similar amount of controllers. 3 of those refer to the logged in user and in no place except the admin controller itself can you modify an object, or what an object refer to, in such a way where an administrator can access anything he or she shouldn't. Admins have different accounts not to restrict what they can do but to (automatically outside what can be modified by posting params…

This is ostensibly why attr_accessible has a "role" parameter.

Re: ActiveRecord Vulnerability - Circumvention of attr_protected

#60

Post by mpk »

sync wrote: post #2

This one seems pretty amateur and should have been caught as part of a pull request/code review process. - @regex = /^(#{Regexp.escape(@prefix)})(.+?)(#{Regexp.escape(@suffix)})$/ + @regex = /\A(#{Regexp.escape(@prefix)})(.+?)(#{Regexp.escape(@suffix)})\z/ ^ and $ only match the first line in ruby, whereas \A and \z match across all lines.

That depends on how long it's been in the codebase. As this case is covered in the Rails security guide _and_ the Ruby security reviewer's guide I'd expect it to be quite old and now being found because it hasn't been properly audited before or indicate that the review process needs some work.
Post reply on HN