Security Lessons Learned From The Diaspora Launch • Hacker News Board

Re: Security Lessons Learned From The Diaspora Launch

#131

Post by egmike » Thu, Sep 23, 2010, 5:20 PM UTC

tptacek wrote: post #123

avar wrote: post #107

Earlier quoted context omitted.

First of all you should think hard before taking regexes from users. Even if you do it correctly you'll still (presumably) need to search over your entire dataset, instead of doing something more lightweight like rely on SQL indexes. Use it with care. You should use a regex engine that's explicitly designed to take potentially hostile input. Like the Plan9 engine, or Google's re2 engine which powers Google Code Searc…

This assumes that PCRE doesn't still contain memory corruption flaws, despite not being heavily tested, and being in effect a programming language interpreter. Tavis Ormandy found a couple serious problems a few years ago. I'd just scrub the hell out of strings before passing them to a regex engine.

Good advice, thanks you two!

Re: Security Lessons Learned From The Diaspora Launch

#132

Post by naner » Thu, Sep 23, 2010, 5:34 PM UTC

llimllib wrote: post #18

bl4k wrote: post #13

"For example, if you were logged in to a Diaspora seed and knew the ID of any photo on the server, changing the URL of any destroy action from the ID of a photo you own to an ID of any other photo would let you delete that second photo." When I was working as a pen tester I would completely scold developers for letting this happen - telling them that with everything we know today about security and good programming p…

> That was 11 years ago. The problem is, these kids are from college . They don't teach you stuff like "writing a secure web application" in college, or even try to. (Not that this is unreasonable, though perhaps I'm suggesting that there should be different career paths for CS majors and people who intend to be professional programmers. (I say as a CS-educated professional programmer))

The problem is, these kids are from college. They don't teach you stuff like "writing a secure web application" in college, or even try to.

Bingo. I went to Georgia Tech, which has a pretty damn good CS program, and I had to hunt for security classes. One was a "special topics" course that wasn't available very often and didn't have anything to do with application security (was a Net. Sec. course). The other was not a CS course but a Comp. Eng. course and was focused on penetration testing. :/ I actually earned a "Network Security" certificate with my degree which I never even knew was available (it wasn't mentioned anywhere in the course literature).

Since I've graduated they have redone the whole CS dept so I don't know if things have changed, though.

But like someone else said, a lot of this stuff is common sense, especially if you're a programmer and have systems knowledge. And I think most programmers have the habit of imagining all the different ways things could break when they are coding, too. Like a hackers curiosity that most of us share. I know when something looks obviously wrong on a website or in an application I'm using I start to poke around and see what I can uncover.

Re: Security Lessons Learned From The Diaspora Launch

#133

Post by code_duck » Thu, Sep 23, 2010, 5:45 PM UTC

jodrellblank wrote: post #95

code_duck wrote: post #81

Earlier quoted context omitted.

Maybe they should take that strength and build on it! Then they can say they were visionaries instead. I agree though, these aren't like subtle security holes that would need a security expert to review. Checking that a user own the resource on which they are requesting modification is basically common sense.

You've said this twice now, and it still isn't true. Don't be the Youtube commenter who, on a video on how to hold and what to call parts of a musical instrument and how many people got it wrong, said "this video is useless, it's all common sense". If it were common sense to do it, they would have done it. It's not. It's a very distinct thought pattern shift from "the browser is a part of the execution of our code an…

Sure, I've said this a few times because I'm talking to various people, in my perception of how posting here works.

Your assumption that everyone shares in common sense equally is a bit optimistic.

So, then you must agree that they clearly don't understand, as you say "the user can request anything at any time no matter what links we have or haven't generated or what they can see on screen". To me, this shows a lack of understanding of basic guidelines of web programming, namely that you can never, never trust user input, whether it's form submissions or cookies.

Perhaps not common sense, but nor is it an advanced principle. If you've ever used Firebug for more than a couple of hours, you'd have figured out on your own that you can change forms and then submit them. If you've even used a browser for a while, you will have realized you can type in different numbers in query strings. If they haven't noticed that by now - what are they doing taking on a project like this?

Re: Security Lessons Learned From The Diaspora Launch

#134

Post by code_duck » Thu, Sep 23, 2010, 5:47 PM UTC

zeemonkee wrote: post #90

code_duck wrote: post #83

Earlier quoted context omitted.

Indeed, the level of errors shown in this demonstrates that they would probably need about 2-3 years of experience to be decent at doing work like this. I think the best thing they could have done is hired 3 skilled developers to work for 6 months at $5k a month.

Which begs the question - where did the money go ? What they've released looks like your average weekend github side-project. I suspect a large % of Hacker News members have projects like this (though hopefully with better security ;-)). So what did they spend the money on ?

For their sake, I hope they still have most of it!

Re: Security Lessons Learned From The Diaspora Launch

#135

Post by code_duck » Thu, Sep 23, 2010, 5:51 PM UTC

equark wrote: post #112

code_duck wrote: post #84

Earlier quoted context omitted.

Why would the community of experienced developers who are supposedly expected to be interested in working on this project, find it rewarding to sit around and wait for them to work through their training wheels? This whole situation really is absurd.

It doesn't seem absurd to me that a few college friends want to hack together a project to fix a problem they see. I think it's great, regardless of whether they succeed. Nobody is forcing you to join them.

Nothing at all is absurd about what they're doing - what is surreal is all the media attention and the expectations it has created in the average person regarding this. I don't think it's in the benefit of these four guys, actually. They're lucky in some ways and really unfortunate from other perspectives. I don't even know how I'd feel if I was in their shoes right now.

The idea that 'these guys are going to get all this money, and work for three months, and then surely deliver this top notch 'facebook killer' that we all want to use!' is a bit absurd, that's all, given that there are plenty of other projects working in this area, and there would be no reason at all to think that this one would be superior, the best, or even suitable. If it wasn't for the nytimes, etc. this would be just another project on github. The media has taken a normal situation and screwed it up majorly, and it doesn't appear to me that it's going to turn out that great for anyone involved.

Re: Security Lessons Learned From The Diaspora Launch

#136

Post by 10ren » Thu, Sep 23, 2010, 6:17 PM UTC

10ren wrote: post #120

What idiots those Diaspora guys are! All that excellent security consulting, for free! They don't know the first thing about software development! It makes me so mad, I'm going to write up a carefully researched and detailed account of other errors they've made! Then they'll see how clueless they are - again! Ha, what amateurs !

EDIT here because too late to edit my above comment I just want to clarify, to distance myself from the recent genius/tragedy submission: I'm mocking the people who criticize the Diaspora guys for not being perfect. I'm pro release early, release often and anti perfectionism. IMHO, Patrick is doing exactly the right thing - helping to build something better. But my post could be interpreted as mocking Patrick - that's not what I meant, and I apologize for the ambiguity.

On reflection, I shouldn't have expressed this through mockery at all, but through helping. :(

Re: Security Lessons Learned From The Diaspora Launch

#137

Post by avar » Thu, Sep 23, 2010, 6:37 PM UTC

tptacek wrote: post #123

avar wrote: post #107

Earlier quoted context omitted.

First of all you should think hard before taking regexes from users. Even if you do it correctly you'll still (presumably) need to search over your entire dataset, instead of doing something more lightweight like rely on SQL indexes. Use it with care. You should use a regex engine that's explicitly designed to take potentially hostile input. Like the Plan9 engine, or Google's re2 engine which powers Google Code Searc…

This assumes that PCRE doesn't still contain memory corruption flaws, despite not being heavily tested, and being in effect a programming language interpreter. Tavis Ormandy found a couple serious problems a few years ago. I'd just scrub the hell out of strings before passing them to a regex engine.

Even if it does it's a pretty remote possibility that it'll be exploitable if you limit the input to say 100 bytes. Pretty hard to get a Perl or Ruby level program of that size to exploit some memory corruption at the C level.

Re: Security Lessons Learned From The Diaspora Launch

#138

Post by jmspring » Thu, Sep 23, 2010, 8:16 PM UTC

It is funny, I have looked at the code and am not a big ruby/rails person, but see obvious flaws and security holes. However, a lot of the discussion around these have been either in the "it is amateurish" bucket or the "are they expecting help from the OSS community? that is leveraging eyeballs, that may not come".

Now, while it hasn't been their primary intension (most likely), to have the OSS community (and others curious about the code) provide fixes and feed back, they sure have gotten a lot of input and advice. I also suspect they have learned quite a lot through the feedback - positive, constructive, and inflammatory. You really can't ask much more -- aside from some direct help.

While I have no plan to run my own Diaspora node, I do look forward to seeing how the code and project evolve.

Re: Security Lessons Learned From The Diaspora Launch

#139

Post by adamdecaf » Thu, Sep 23, 2010, 10:03 PM UTC

Well, I for one am glad that I learned from articles like this. It's a hell of a lot easier to read discussion from "real programmers" and learn from them. Now that I'm in college stuff like this is second nature.

Re: Security Lessons Learned From The Diaspora Launch

#140

Post by code_duck » Thu, Sep 23, 2010, 10:59 PM UTC

ekidd wrote: post #86

code_duck wrote: post #80

Earlier quoted context omitted.

Well... basically, it sounds like Ruby's regex engine needs some work, hmm?

No, people should know better than to write regexes like /X(.+)+X/, with gratuitous doubly-nested "+" characters. :-) This code performs fine when written as /X(.+)X/, and it matches the same set of strings. Regexp engines are subtle beasts, and there's a couple different ways to implement them (DFAs vs NFAs, simple engines vs lots of clever special cases, etc.). See O'Reilly's "Mastering Regular Expressions" for an…

It just seems to me that if Perl's regex engine handles this without a problem, and Ruby's implementation freaks out, something should be improved about the Ruby one.