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

Multiple vulnerabilities in parameter parsing in Action Pack

groups.google.com

Post reply on HN
Print view View original

281–290 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#281

Post by tptacek »

mattbee wrote: post #263
tptacek wrote: post #226

Earlier quoted context omitted.

It breaks YAML deserialization in other places. You could enable and disable it on demand in the XML parser, but a more sensible solution is just to get YAML the hell out of the XML processor. Trying to make YAML safer is probably not the right approach.

It's meant to partially break YAML deserialization :) My apps do care about YAML, so I've an interest in cleaning this up. Is there some unintended consequence? You can still instantiate some Ruby classes (Regexp, Symbol etc.) in the YAML loader, or you can go through @@tagged_classes and pick out any other types you don't want. But by taking out Object, YAML is only left with a whitelist of types that are safe, anyt…

What I mean by that is, this workaround breaks application code that depends on other portions of Rails that use XmlMini. In exchange, it allows you to potentially expose YAML to HTTP requests, which is still an extremely bad idea.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#282

Post by mattbee »

tptacek wrote: post #281
mattbee wrote: post #263

Earlier quoted context omitted.

It's meant to partially break YAML deserialization :) My apps do care about YAML, so I've an interest in cleaning this up. Is there some unintended consequence? You can still instantiate some Ruby classes (Regexp, Symbol etc.) in the YAML loader, or you can go through @@tagged_classes and pick out any other types you don't want. But by taking out Object, YAML is only left with a whitelist of types that are safe, anyt…

What I mean by that is, this workaround breaks application code that depends on other portions of Rails that use XmlMini. In exchange, it allows you to potentially expose YAML to HTTP requests, which is still an extremely bad idea.

I don't see why YAML is a dangerous serialization format - the other type deserializations in the code seem sane and limited enough. (I wouldn't use YAML over e.g. JSON these days but I'm fixing up quite old projects)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#283

Post by chimeracoder »

tedunangst wrote: post #244
drstewart wrote: post #241

Earlier quoted context omitted.

I still believe you may not understand the difference between a language and a framework.

The distinction is rather academic with ruby and rails. 90% of the answers to "how do I do this in ruby" on forums are actually "how to do this with rails" answers, but they never mention that little detail, because who'd ever write a ruby program without rails, right? Trying to find straight ruby answers is annoying as hell.

I've had frustrations with certain "ruby" libraries requiring methods like "blank?" (IIRC) that are provided only via Rails, not Ruby. It made developing on a machine that Ruby but not rails rather annoying.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#284

Post by chimeracoder »

papsosouid wrote: post #277
phillmv wrote: post #52

Earlier quoted context omitted.

This is a straw man. These kinds of issues are open to all software. I'm happy you work in the kind of place that audits all of its software, though. I'm sure you've all read through all of Hibernate, Spring and not to mention all the .NET framework code.

>These kinds of issues are open to all software Really? Could you show me how I could possibly create such a hole in a language like ocaml or haskell?

> Could you show me how I could possibly create such a hole in a language like ocaml or haskell?

First you'd have to write the equivalent of Rails in Haskell (I'm not talking about an MVC framework, but something as large, complex, and featureful.)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#285

Post by Turing_Machine »

tedunangst wrote: post #244
drstewart wrote: post #241

Earlier quoted context omitted.

I still believe you may not understand the difference between a language and a framework.

The distinction is rather academic with ruby and rails. 90% of the answers to "how do I do this in ruby" on forums are actually "how to do this with rails" answers, but they never mention that little detail, because who'd ever write a ruby program without rails, right? Trying to find straight ruby answers is annoying as hell.

"The distinction is rather academic with ruby and rails."

No, it isn't.

"90% of the answers to "how do I do this in ruby" on forums are actually "how to do this with rails" answers"

You're looking in the wrong places.

"who'd ever write a ruby program without rails, right?"

People who are writing shell scripts? People who are using Sinatra? People who are writing desktop Ruby programs?

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#286

Post by Turing_Machine »

tptacek wrote: post #271
regularfry wrote: post #270

Earlier quoted context omitted.

Sorry, would you mind clarifying? Any Ruby app? So a Sinatra app which happened to YAML.load would also be at risk?

Yes, if attackers controlled the content of the YAML message.

In much the same way that letting attackers control the parameters to fork() would be a bad idea for a C program or letting attackers control the parameters to Runtime.exec() would be a bad idea for a Java program.

This is a Rails vulnerability, not a Ruby vulnerability.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#287

Post by Turing_Machine »

alexanderh wrote: post #231
Turing_Machine wrote: post #168

Earlier quoted context omitted.

Yes, you're right. There have never been any security problems with "serious" "nonfun" languages like C, or Java, or the .NET stack. :-/ This has nothing to do with the Ruby language, by the way, any more than a hole in IIS is a problem with .NET. If you're going to talk smack, at least learn what you're talking about.

You misinterpreted my comment. I agree, the language is largely inconsequential. Its the culture around the language that is the problem. Ruby's is particularly bad. All I'm saying is the "1000 ways todo the same thing" nature of Ruby, has the unfortunate consequence of attracting newbs, and making 'best practices' hard to nail down. Other languages tend to have more support in corporate/educational areas, tend to ha…

"quality of code shows this. (in the core of the language"

Your examples of this would be?

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#288

Post by papsosouid »

chimeracoder wrote: post #284
papsosouid wrote: post #277

Earlier quoted context omitted.

>These kinds of issues are open to all software Really? Could you show me how I could possibly create such a hole in a language like ocaml or haskell?

> Could you show me how I could possibly create such a hole in a language like ocaml or haskell? First you'd have to write the equivalent of Rails in Haskell (I'm not talking about an MVC framework, but something as large, complex, and featureful.)

No, I am asking how you could actually create this vulnerability in haskell at all. No framework required, just actively, intentionally trying to create this hole.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#289

Post by techiferous »

moe wrote: post #89

I hope in consequence of this incident the Rails-team will build in an automatic security-update notification mechanism. I'd like my apps to poll rails.org (or whatever) every few minutes and by default shutdown hard when an incident like this is announced.

This actually sets up a single point of failure for many apps. If a hacker were to hack rails.org, they could take down any site polling it.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#290

Post by bradleyland »

moe wrote: post #187
xnxn wrote: post #162

Earlier quoted context omitted.

Just playing devil's advocate here: a truly evil attacker could use the access logs from all the apps phoning home to build a list of vulnerable targets! :)

Well, you are right, the idea wasn't thought out very well. I was in a bit of a bad mood during patching up various rails deployments around here... However, perhaps they could just promise to post a signed message, in a specified format, on a dedicated twitter account, if such a thing happens again. This would seem like a relatively low-tech approach, about adequate for such a rare event (just keep that secret key s…

Your entire thread of comments here make me want to gouge my eyes out. A signed message on twitter? Low tech? What in the hell are you talking about?

I'm going to be the asshole here, because it is vitally important that no one responsible for security ever listen to what you're saying. You're advocating some Orwellian kill-switch mechanism based on unspecified "signed messages" over a third-party social messaging service (limited to 140 chars, no less), and throwing in meaningless phrases like "low tech". What about this problem leads you to believe we all need something low tech?

I am not qualified to design such a system. You are negatively qualified to even comment on such a system. Please stop.

Post reply on HN