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

What The Rails Security Issue Means For Your Startup

kalzumeus.com

Post reply on HN
Print view View original

131–140 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#131

Post by homakov »

benmmurphy wrote: post #129
patio11 wrote: post #88

Earlier quoted context omitted.

You might be thinking of preventing Javascript on host X from sending XMLHttpRequests to host Y. That will not prevent Javascript on host X from adding a form to the web page and having it post to host Y with arbitrary content, or from having an IMG tag on host X attempt to load (via a GET) a URL on host Y (assuming someone finds a pathway that works via GET requests for these or related vulnerabilities).

afaik you can't use cross site requests to exploit either the xml bug or the json bug without also exploiting a browser or plugin bug. both issues depend on setting a request header and you are not allowed to do this in the browser security model. but it sucks that CSRF bug becomes RCE bug :(

>but it sucks that CSRF bug becomes RCE bug :( you just said it - it cant be exploited via CSRF. Because you cannot set header.

NO EXPLOIT FOR LOCALHOST:3000 calm down

Re: What The Rails Security Issue Means For Your Startup

#132

Post by homakov »

kalid wrote: post #87
piuk wrote: post #81

Earlier quoted context omitted.

Wouldn't the same origin policy prevent requests to localhost?

You can dynamically create an iframe in JavaScript and do a regular form post to localhost:3000 thorough it.

how u gonna set content-type?

Re: What The Rails Security Issue Means For Your Startup

#133

Post by homakov »

chimeracoder wrote: post #4
pifflesnort wrote: post #3

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than…

> The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad. Is that seriously what happened? It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github), even though I believe that was a separate set of developers altogether. If so, then that might sugges…

> It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github)

Hey, yes, yaml bug is _very_ similar. Whitelist is better than no list at all

Re: What The Rails Security Issue Means For Your Startup

#134

Post by sanderjd »

pifflesnort wrote: post #26
patio11 wrote: post #17

Earlier quoted context omitted.

Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deseri…

> Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn o…

> This is systemic engineering incompetence that apparently pervades an entire language community

The original target of that claim was the Ruby community. With this comment allowing the same issue existing in the Java community, are you leveling the same claim against it? Does every severe security issue that remains unnoticed by a community for some time and is eventually noticed suggest pervasive engineering incompetence throughout that entire community? Maybe you would be entirely right to make that claim because any security issue is indicative of incompetence at some level, but I think the closer your definition of incompetence comes to including everybody, the less useful that definition is.

Re: What The Rails Security Issue Means For Your Startup

#135

Post by static_typed »

lucian1900 wrote: post #111
hawleyal wrote: post #73

Earlier quoted context omitted.

ಠ_ಠ Because other frameworks are rock-solid. Yup. None of this happens anywhere else on the internet.

Nothing quite this catastrophic tends to happen to things that aren't PHP.

To be fair, other platforms and frameworks have had serialization issues, BUT, and this is the big one, they learned from the experience. Will the Ruby community learn? That is the question. Software Engineering are not dirty words!

Re: What The Rails Security Issue Means For Your Startup

#136

Post by mnarayan01 »

pifflesnort wrote: post #26
patio11 wrote: post #17

Earlier quoted context omitted.

Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deseri…

> Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn o…

Here's the thing. You can not load YAML with attackable data. Period. If you do, you have to assume bad things are going to happen. The fact that psych calls []=(key, val) on instantiated objects in combination with ActionController::Routing::RouteSet::NamedRouteCollection calling eval on the key made for a particularly easy drive-by attack on a huge range of deployments, but even without the []=, there are still plenty of ways to exploit loading arbitrary YAML, though they may require more custom targeting.

In terms of that issue request, I doubt that adding a safe_load option would have stopped the Rails vulnerability. After all, the Rails guys _already knew_ that they should not be loading YAML from the request body; that's why it was not allowed directly. The issue was loading XML, which then allowed YAML to be loaded. Allowing YAML to be loaded there was a mistake; it seems unlikely that someone would make that mistake, while at the same time mitigating it by adding safe_load.

Re: What The Rails Security Issue Means For Your Startup

#137

Post by benmmurphy »

homakov wrote: post #131
benmmurphy wrote: post #129

Earlier quoted context omitted.

afaik you can't use cross site requests to exploit either the xml bug or the json bug without also exploiting a browser or plugin bug. both issues depend on setting a request header and you are not allowed to do this in the browser security model. but it sucks that CSRF bug becomes RCE bug :(

>but it sucks that CSRF bug becomes RCE bug :( you just said it - it cant be exploited via CSRF. Because you cannot set header. NO EXPLOIT FOR LOCALHOST:3000 calm down

i actually lied :) there is #from_xml so if you were doing Hash.from_xml(params[:trololol]) or Post.from_xml(params[:lols]) then you would be vulnerable to localhost:3000 attack. but I don't think there is generic attack it would have to be application specific.

Re: What The Rails Security Issue Means For Your Startup

#138

Post by delinka »

btilly wrote: post #106
delinka wrote: post #101

Earlier quoted context omitted.

You're right. I wasn't seeing all the angles here. But to say this is limited to Macs seems disingenuous.

He didn't say it was limited to Macs. He gave it as a random example of what could happen.

I'm pretty sure OP specifically said "Macbook" in the article. But see patio11's comment beside yours.

Re: What The Rails Security Issue Means For Your Startup

#139

Post by squidsoup »

steveklabnik wrote: post #98
purephase wrote: post #41

Earlier quoted context omitted.

I'd love to. Any helpful guides on how to proceed?

I just wrote a blog post: http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg...

Wasn't aware of bundle --deployment, that's very helpful thank you steve.

Re: What The Rails Security Issue Means For Your Startup

#140

Post by [deleted] »

pifflesnort wrote: post #3

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than…

[deleted]
Post reply on HN