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

211–220 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#211

Post by [deleted] »

marshray wrote: post #208
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.

Hey, did you hear that scanf() will accept XML and YAML and automatically convert it into pointers handy for you to dereference? Neither did I.

[deleted]

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#212

Post by chunkyslink »

elektronaut wrote: post #210
chunkyslink wrote: post #207

Ok. I'm quite new to Rails. How do I apply this patch? Or am I better upgrading rails completely? How do I do this.

Update to 3.2.11, 3.1.10, 3.0.19 or 2.3.15, and you'll be good.

Already in my gem file ...

gem 'rails', '3.2.3'

I think that patch maybe? But I dont know how. Google is not helping,

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#213

Post by marshray »

tptacek wrote: post #209
marshray wrote: post #208

Earlier quoted context omitted.

Hey, did you hear that scanf() will accept XML and YAML and automatically convert it into pointers handy for you to dereference? Neither did I.

Or how about when you put that 256th character in a ruby string and end up overwriting heap metadata? Man I hate it when that happens.

There are known undefined behaviours and there are unknown defined behaviors.

Which is worse?

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#214

Post by marshray »

steveklabnik wrote: post #206
marshray wrote: post #189

Earlier quoted context omitted.

One should never assume that he has a handle on everyone who knows the existence of a bug. I think you underestimate your adversary. https://twitter.com/mikko/status/288766998228393984

You completely mis-understand my point. I don't think that this is the only person who knows this, that'd be idiotic. They are, however, the only person who posted it in this thread. Giving it more publicity. I don't think that that extra publicity is appropriate.

Even now you still think it's useful to hide information from the "general public" and avoid "extra publicity"?!

The cat is out of the bag. You can no longer negotiate with this reality.

Publicly disclosing a bug is like birthing a baby. Once it's sticking halfway out, just get it all the way out because it's counterproductive to try to hold parts of it back in.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#215

Post by marshray »

steveklabnik wrote: post #118
fwilhelm wrote: post #81

Earlier quoted context omitted.

The post does not include any directly usable exploit code and does not describe command execution vectors. Furthermore information about the bug were published on twitter almost a week ago. But I probably will not convince you about the advantages of Full Disclosure :)

No, I don't see what this adds, I only see how this can cause harm. Anyone who wants to learn more can wait until everyone's had a chance to patch their apps; they can also figure it out themselves. All this does is allow people who want to do harm to not have to figure it out themselves.

No, another thing it does is help people who support web applcation firewalls and intrusion protection sytems to develop rulesets.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#216

Post by tptacek »

marshray wrote: post #213
tptacek wrote: post #209

Earlier quoted context omitted.

Or how about when you put that 256th character in a ruby string and end up overwriting heap metadata? Man I hate it when that happens.

There are known undefined behaviours and there are unknown defined behaviors. Which is worse?

I'll take Ruby over C any day of the week.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#218

Post by homakov »

alexanderh wrote: post #161
ghayes wrote: post #40

Earlier quoted context omitted.

As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…

>why isn't there more of a focus on security here? Because this is ruby we're talking about. A "Fun" language that has 100000 ways todo the same thing, so newbs find it fun and easy. You can almost guess how the language works and almost always be right. Thats cool, great for learning, makes you feel like a superstar when you're just getting started with programming... but its really not such a good thing when it com…

I don't think so, a lot of ruby users are good at security

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#219

Post by ajross »

joevandyk wrote: post #18
tptacek wrote: post #6

Earlier quoted context omitted.

This isn't a SQL injection vulnerability at all.

But you can use this to trigger the earlier SQL injection vulnerabilities, right?

It's (apparently) a remote code execution bug. You can also use it to trigger SQL in the sense of simply executing arbitrary SQL. There's no need to bootstrap or trampoline, the doors are swinging open already.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#220

Post by vinhboy »

tptacek wrote: post #11
10char wrote: post #10

Correct me if I'm wrong, but looks like this should only be a vulnerability if your app uses XML parameters?

No, it's a vulnerability if your app SUPPORTS XML parameters, which all modern Rails apps do . This vulnerability is exploitable even if you don't have any exposed controllers.

Wait, what? What if the app does not parse ANY user provided XML or YAML at all?
Post reply on HN