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

Why the Latest Rails Exploit Is Indicative of a Bigger Problem

blog.sdelements.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#31

Post by sanderjd »

bithive123 wrote: post #20
sanderjd wrote: post #16

Earlier quoted context omitted.

I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured. All software deals in layers of abstraction, which makes it easier to reason about general…

I would tend to agree, except that Rails can't be all things to all people. Experienced developers don't find it nearly as magical as most of the people being told to "just learn Rails" when they get interested in web development. I totally get that abstractions can obscure security issues, but some of the reactions I've been seeing to Rails having security issues are akin to a parent giving a child a dangerous toy w…

I think we agree on all points. People with less experience with Rails see "magic" where people with more experience see abstractions with all the trade-offs implied, and importantly, know how to dig into those abstractions to understand what is really going on. But that digging in process tends to be spurred by surprising behavior, rather than security consciousness.

I like your analogy to toys and children, except that the danger of these toys is not immediately apparent to adults either. But the toy company has been very prompt and transparent in finding ways for people to avoid the danger once it becomes apparent.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#32

Post by papsosouid »

adamors wrote: post #21
papsosouid wrote: post #15

Earlier quoted context omitted.

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you…

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable…

No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a

    parse_yaml_from_get_params_with_a_really_long_rails_function_name()
function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#33

Post by tedunangst »

alinajaf wrote: post #24
sanderjd wrote: post #16

Earlier quoted context omitted.

I agree with you about the grating self-satisfaction of a certain vocal set of commenters, and have argued in the past myself that there is no "magic" in Rails, but I think what people really mean when they say "magic" as related to a chunk of software, is that it has so many layers of abstraction that its function is obscured. All software deals in layers of abstraction, which makes it easier to reason about general…

> they mean that Rails has drawn that line quite far toward the abstraction side, which is true Can you give a concrete example of this?

I would not expect rails to parse random snippets of xml fed to it just because it can.

Not even security related. If I decide to move from rails to django, now I have to wonder if somebody out there decided to talk to my app using json instead of regular get/post, and deal with migrating/breaking that client.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#34

Post by tptacek »

rambot wrote: post #27
tptacek wrote: post #18

Earlier quoted context omitted.

Yes. No other security framework has ever had problems like Rails had. It's definitely not like enterprise Java frameworks that were designed from the outset to satisfy security demands from F-500 appsec teams have had repeated remote code execution flaws. And if they did, they definitely weren't as simple to trigger as "hitting a URL that maps to an embedded Java scripting language". No, only Rails has bugs like the…

Where does the post suggest Rails is the only framework with bugs like this? The article opens with: "The latest Rails security flaw is example of a common anti-pattern. ... a similar issue may also exist in Python’s YAML parser ... I am reminded of similar flaws in other frameworks and libraries." I don't think the goal here was to pick on Rails, but to highlight that its recent security woes might be a sign of a bi…

I'm responding to the comment above, not the post.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#36

Post by vidarh »

adamors wrote: post #21
papsosouid wrote: post #15

Earlier quoted context omitted.

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you…

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable…

First of all let me make it clear that I'm not against all "magic", but let me address this:

> But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up?

There is a vast difference between a framework that does stuff for you when you explicitly ask it to, and where what happens is fairly transparent, and a framework that does stuff for you because of code that without knowledge of the framework looks fairly "inert".

E.g. calling methods to define attributes and attribute-accessors on a class that maps to a database is not magic (though depending on how extensive, you might argue parts of what a specific ORM does in that case is): The code makes it plain that something will happen, and unless the naming of the method is atrocious, a developer will have a good shot at guessing roughly what from the code itself. You can make a framework that does a lot for a developer while still being explicit like this.

Automatically defining attributes pulled from the database based just on including a module, or inheritance, on the other hand, is well into "magic" territory: Not only might it not be clear it's going to be pulling stuff from the database and define lots of attributes for you, you don't know what it will define at all without looking at a schema that might not even be available together with the code, and that might change independent of the code.

It's not an either-or, but a sliding scale, and what is magic to some will be plain and obvious to others (the Arthur C. Clarke quote springs to mind). E.g. "everyone" who knows Active Record will know at least the basics of what Active Record will do to your class, and so won't be surprised by most of the method that to another seemingly magically materialize on it.

The trade-off is how far you go before the surprises to your target audience become too many.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#37

Post by [deleted] »

metaphorm wrote: post #13
bithive123 wrote: post #11

Earlier quoted context omitted.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

[deleted]

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#38

Post by hackinthebochs »

metaphorm wrote: post #13
bithive123 wrote: post #11

Earlier quoted context omitted.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

"Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#39

Post by kyllo »

adamors wrote: post #21
papsosouid wrote: post #15

Earlier quoted context omitted.

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you…

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable…

>As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.

I beg to differ on the readability of the Rails source code. Even for someone with a strong command of Ruby, there are a lot of layers of abstraction, functions that call other functions that call other functions, and subclasses of subclasses of subclasses, spread across many different files in different places in the folder/project structure. It's quite difficult to figure out what is actually going on when you look under the hood of Rails, because it's complicated to the point where it's "indistinguishable from magic" until you have spend a lot of time with it.

Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem

#40

Post by hackinthebochs »

metaphorm wrote: post #13
bithive123 wrote: post #11

Earlier quoted context omitted.

There is no magic in Rails, it's just Ruby code. There will always be APIs that shouldn't be given untrusted data. When this happens anyway, calling it an "anti-pattern" does not mean you have perceived some kind of systemic fundamental flaw in the framework. That's just a transparently self-serving way for you to feel superior because after all you're a "serious developer".

magic is just a shorthand for "code executed automatically, behind the scenes, based on some reasonable assumptions". Rails does a whole lot of this type of magic, as does basically every framework.

"Magic" code is code that gives little or no indication that it's being executed in the contexts that are affected. Think of this as the "locality" of code. Do the names and operations being referenced in the current context completely describe the functionality that is being executed? Then the code has high locality. Magic code is code with low locality.
Post reply on HN