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

Rails SQL injection vulnerability: here are the facts

blog.phusion.nl

Post reply on HN
Print view View original

111–120 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#111

Post by BUGHUNTER »

PommeDeTerre wrote: post #12
tptacek wrote: post #9

This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote. Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…

As a developer it is best to enable yourself to collect some relevant facts about technical questions and come to a decision based on that data.

Basing an argument about technical things on "what people say" will not succeed, no matter what your goals are.

Re: Rails SQL injection vulnerability: here are the facts

#112

Post by FooBarWidget »

tptacek wrote: post #85
bstar77 wrote: post #47

Earlier quoted context omitted.

How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.

The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.

I thought the issue discovered yesterday is a totally unrelated issue than the one I described in this article. Am I mistaken?

Re: Rails SQL injection vulnerability: here are the facts

#113

Post by FooBarWidget »

tptacek wrote: post #100
bstar77 wrote: post #96

Earlier quoted context omitted.

It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app. This issue is is built up to be serious because many people seem to enjoy attacking rai…

I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs. But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug"…

> some guy said you needed the right HMAC key on a cookie to exploit the bug

That is definitely not the intention of the article. There are other exploitable scenario and the reader is encouraged to check his code base for those instances. The article merely spends many words on what I believe would be the most scenario. The severity depends on the codebase.

Re: Rails SQL injection vulnerability: here are the facts

#114

Post by FooBarWidget »

PommeDeTerre wrote: post #107
jwilliams wrote: post #103

Earlier quoted context omitted.

Ok, but what's your point and how does it relate to the article? Your original post points to smugness, a lax approach to security and incorrect statements -- none of which I witness or interpreted from this blog post. In fact I'd argue this blog post actually refutes all of the points you are making. It's factual, detailed, to the point and it doesn't make light of the issue at all.

Follow the entire thread of discussion, right back to tptacek's original post, and the article itself. The article's conclusion says, "... it is not a “giant bug”, it is much more subtle than that and requires a specific combination of code and circumstances to work. Most apps are not vulnerable." To me, Thomas Ptacek appears to be suggesting that maybe there is more to this situation than meets the eye, and that may…

I believe you've accidentally omitted the following important and relevant pieces from the article and the following author comments:

"There are other exploitable scenarios, but it really depends on what your app is doing. Since it is impossible to prove that something isn’t insecure, you should take the vulnerability seriously and upgrade anyway even if you think you aren’t affected." - article subsection "Summary: what is this vulnerability?"

"a leaked key is NOT necessary to exploit the bug" - author comment on the article.

"Another (unrelated) Rails vulnerability has been found today. That vulnerability has not been publicized yet, but suffice to say it is a very embarrassing and serious vulnerability that deserves immediate attention. Please keep your eye open on future advisories." - author comment on the article.

"Not disagreeing with you there. After all there's no way to prove that something doesn't exist. What's why I wrote that everyone should upgrade, just in case. :) The goal of the article is not to defend Rails. It is to inform about the nature of the vulnerability and to replace the feeling of panic with rational thoughts." - author comment on HN

Re: Rails SQL injection vulnerability: here are the facts

#115

Post by FooBarWidget »

fpal3 wrote: post #109
derwiki wrote: post #92

Earlier quoted context omitted.

Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).

2647 connections per server per second is pretty abysmal for modern server hardware, especially if you had to rely on a whole bunch of caching front-end complication and proxy web servers to make it happen.

You can't say that without knowing what the app does.

A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.

Re: Rails SQL injection vulnerability: here are the facts

#116

Post by FooBarWidget »

After giving many of the comments here a thought, I've written a follow-up article "Securing the Rails session secret" in which different ways to secure the session secret are considered. Feedback is more than welcome. http://blog.phusion.nl/2013/01/04/securing-the-rails-session...

Re: Rails SQL injection vulnerability: here are the facts

#117

Post by phillmv »

PommeDeTerre wrote: post #98
phillmv wrote: post #19

Earlier quoted context omitted.

I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own. I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?

The attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier. I'm sure you can find numer…

I'm asking you to explain why any of it is an issue, and to back it up with the comments of other people.

I want to see people who have written "the fact that this project is in Ruby is the bane of my existence and here is why these problems would not have occurred in my language of choice".

>lack much of the functionality that makes code maintainable after many years, or even decades.

This is just FUD. LOL, what inherent property is this that makes it maintainable?

Great trolling, btw.

Re: Rails SQL injection vulnerability: here are the facts

#118

Post by tptacek »

FooBarWidget wrote: post #113
tptacek wrote: post #100

Earlier quoted context omitted.

I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs. But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug"…

> some guy said you needed the right HMAC key on a cookie to exploit the bug That is definitely not the intention of the article. There are other exploitable scenario and the reader is encouraged to check his code base for those instances. The article merely spends many words on what I believe would be the most scenario. The severity depends on the codebase.

On this very thread you have a vulnerability researcher confirming a generic exploit of the vulnerability. Again: you're buying this article wholesale, but it's author may not know what they are talking about.

Re: Rails SQL injection vulnerability: here are the facts

#119

Post by tptacek »

FooBarWidget wrote: post #112
tptacek wrote: post #85

Earlier quoted context omitted.

The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.

I thought the issue discovered yesterday is a totally unrelated issue than the one I described in this article. Am I mistaken?

I believe you are.

Re: Rails SQL injection vulnerability: here are the facts

#120

Post by PommeDeTerre »

FooBarWidget wrote: post #115
fpal3 wrote: post #109

Earlier quoted context omitted.

2647 connections per server per second is pretty abysmal for modern server hardware, especially if you had to rely on a whole bunch of caching front-end complication and proxy web servers to make it happen.

You can't say that without knowing what the app does. A recent project that I've been involved with switch from Java to Ruby and they reduced the number of servers by 10 times (!). But I don't blame Java, I blame the programmers of the last code base. You can write unmaintainable messes in any language.

Were the exact same servers reused?

I once interviewed a Rails developer who was bragging about a Java-to-Ruby conversion he'd worked on. He was proud that they went from 50 servers running the Java system to only 30 for the Ruby one.

Upon further questioning, he admitted that those 50 servers used by the Java system were from 2003, and the ones powering the Ruby-based system were from 2011! They didn't even halve the number of servers required, but the new servers were many, many times more powerful than the old ones.

Post reply on HN