Security Lessons Learned From the Diaspora Launch 338
patio11 writes "Diaspora, the privacy-respecting OSS social network, did a code release last week. Attention immediately focused on security. In fact the code base included several severe security bugs. This post walks through the code, showing what went wrong, and what it would let an attacker do to someone who was using Diaspora." The developer who wrote the post ends with: "You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora’s banner and ferret out all the issues. You might also believe in magic code-fixing fairies. Personally, I’d be praying for the fairies because if Diaspora is dependent on the OSS community their users are screwed."
Let's give it more than a few hours ... (Score:1, Insightful)
I think the hysterical jeremiads a little over-done.
Give it a couple of months and get back to me. I expect production deployments to be fairly reasonable in terms of security.
...huh? (Score:4, Insightful)
Because if Diaspora is dependent on the OSS community their users are screwed.
Isn't that a bit like saying "if getting this building completed is dependent on construction workers, we're screwed"? Why would you make such a disparaging remark about the very people that will be keeping this thing going?
wit a minute (Score:1, Insightful)
and because yo can see the code these bugs were found
imaigne htis being the windows os
you cant see it it dont exist until....too late
YEA this developer that point sit out PROVES OSS is a better way
Re:Security (Score:3, Insightful)
WTF? (Score:4, Insightful)
Invalid Argument (Score:5, Insightful)
if Diaspora is dependent on the OSS community their users are screwed.
If it wasn't for the OSS community, everybody would believe they've released a safe program. Thanks to OSS, we now know that installing it is not the best decision yet.
I'd say the users would be screwed if diaspora was not open source. Linus Law once again.
I was not surprised to find out that the author sells [bingocardcreator.com] proprietary software. I think that maybe, just maybe he's biased against FLOSS?
Re:Well, the "developer" doesn't get it (Score:5, Insightful)
Include here the disclaimer that I like OSS, think the Diaspora team is really cool, and don’t mean to crush their spirits when I say that their code is unprofessional and not ready to be exposed to dedicated attackers any time soon.
He was doing exactly what OSS is for, reading the code, finding the bugs, and informing the developers so they can be fixed, he's only being vilified because the summary is written that way.
Re:Axe job (Score:3, Insightful)
What "launching"? They aren't launched, they just had a public pre-alpha to invite people to come take a look and provide feedback.
If that *had* been a launch, you'd be right. I tested the pre-alpha, and I provided my feedback. Let's let them go fix it now and see if the beta is better.
Re:Let's give it more than a few hours ... (Score:5, Insightful)
Re:Axe job (Score:5, Insightful)
Re:Axe job (Score:5, Insightful)
but the conceptual idea of Diaspora is sound
That may be and nobody is arguing about the concept itself. But a concept with not of much use without any usefull implementation.
And hell, the majority of the security issues found appear to be rather simple to fix.
This is exactly why this is so bad. The mistakes are so big and so obvious for any developer with experience in web applications that the developers which worked on Diaspora can not be trusted to write secure code. They have clearly demonstrated that they have absolutely no knowledge of security. They did not just make a security hole due to some obscure implementation detail, they designed and implemented a framework with no security at all.
And security is not something you can add after you write the code. Just ask Microsoft about that.
The only solution I see is to get a new team which know how to write code, and then ask them to take over(Or rewrite) the application.
Volunteers (Score:5, Insightful)
I don't think the idea is that the open source community is going to screw people, but that the idea of expecting volunteers to always be plentiful and useful is a good way to cause yourself problems.
A Snippet from the Criticism (Score:5, Insightful)
I mean, nothing seems to point to me that this is shill garbage coming from facebook, but the conceptual idea of Diaspora is sound and the code was released for the precise reason of improving it, as it has done ...
Okay well, sometimes I look at code and I think "good start" and then sometimes I feel like Simon Cowell ... and ask them to start over. So to determine where I stand with the Diaspora code, allow me to quote the article:
This basic pattern was repeated several times in Diaspora’s code base: security-sensitive actions on the server used the params hash to identify pieces of data they were to operate on, without checking that the logged in user was actually authorized to view or operate on that data. 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. Rails makes exploits like this child’s play, since URLs to actions are trivially easy to guess and object IDs “leak” all over the place. Do not assume than an object ID is private.
Okay, I taught myself how to use the rails framework and code Ruby. And one of the things I was amazed at was the Rails magic. Because of how powerful it can be (both good and bad). Yes, it helps you prototype but it's errors like these that make me pause and reconsider if the person coding Ruby on Rails really understands how the framework is attempting to assist them. Obviously if you allow any user to enter any ID of a record in their URL for any CRUD action ... you aren't really understanding what those routes are trying to do for you. And you're a danger to your users.
While I could quickly remedy the above problem for the Diaspora team by improving the authentication and authorization code checks, it might be better to just start over. Now, I've devoted none of my time to the concept of liberating social network users and for that I thank the Diaspora team. This blog posting -- if true -- sure is a vote of no confidence for their capabilities of developing a realistic system. Can they improve? Certainly. But if you're making errors like that, you might be better off letting someone else take a stab at this. It's a harsh thing to say but you don't understand the tool you're using to prototype if you're even starting at this point.
I wish them the best of luck and I hope the community reaches out to them. But I'm not interested in recoding everything. I'd sooner simply start my own project.
BAD slashdot! (Score:5, Insightful)
Someone wrote a blog post to point out some security issues that need fixing in the pre-Alpha version of Diaspora, and here you are using his words for pointless sensationalism that undermines the work of the Diaspora team and propagates the "Diaspora is shite" gossip that will most certainly haunt the project even after the code has hit Beta. Shameful.
If you want to do something useful, then instead of repeating how doomed the project is, ask for people to join them (I think we have some capable individuals around here) and help out.
And no, I'm not affiliated with Diaspora, I'm just annoyed by what this sort of news reporting.
Re:...huh? (Score:3, Insightful)
Provided those bystanders are also construction workers.
Re:Axe job (Score:5, Insightful)
Arrogant "security researcher" bullshit (Score:4, Insightful)
I don't really understand what's wrong with this blog author, this "Patrick" fellow. Diaspora is git-release of a pre-alpha. It's essentially proof-of-concept which was released so we can have a look at it and contribute. The author's "if this is OSS, we're screwed" assertion apparently ignores the fact that Chromium, Mozilla, Linux, and dozens of other open source projects work perfectly fine. Additionally, the "their code is unprofessional" accusation is simply wrong-headed. It was never intended to be "professional", so there's no way for it to be "unprofessional". It's a foundation released to the public that other people can build on.
As for all this worry about zero-day holes...every piece of software has them. If you think that these kids aren't professional because they can't make a perfect, idealized, secure pre-alpha, then you're riding the slopes of a Nirvana fallacy. The entire reason it was open-sourced was to allow researchers the opportunity to improve the code INSTEAD of going public in order to gain visits to their arrogant blog posts and acting like there's some huge problem not covered by the disclaimer. OOPS SORRY IS THAT TOO CLOSE TO HOME, PATRICK? I have never seen more arrogant douchebaggery in a security blog post. This "these are errors that shouldn't be present in any code!" bullshit is a result of Patrick and his circlejerk buds building the project up in their own heads, then being disappointed when the pre-alpha wasn't a facebook-killer.
Yes it has errors. But the very fact that it's 1) open source, and 2) being debugged even by douches such as Patrick, means that the whole "OSS Diaspora" concept ACTUALLY WORKS IN PRACTICE.
Impatience (Score:2, Insightful)
Release early, release often. (Score:1, Insightful)
I thought that was the OSS mantra.
Seriously though, they're only some inexperienced kids, they released a pre-alpha version of their code, cut them some slack. Not everyone is born with 20 years of programming experience (actually no one is born with 20 years of experience, but from the way some people talk you'd think they were).
Ruby (Score:3, Insightful)
My problem with their efforts is they used Ruby. Which might be really nice and all, but not that many people use it. Thus it is really hard to find people who understand it well enough to help them work on the code and or just check the code for bugs.
Re:Axe job (Score:4, Insightful)
Yeah, but his point is that [security] is *the* major feature of diaspora. How could it be missing from any release? It should be in there from the beginning, in the core architecture.
You make it sound like security is just some on/off switch that they forgot to turn on before making the code publicly viewable. That's not how it works. There will always be security improvements to be made to anything, and even... *gasp*... bugs. Especially in a pre-alpha. (If you don't believe me, then show me a major piece of software that's never had a security patch released).
I mean, christ, the code isn't done! They were just making it viewable it to the public so they could get suggestions for improvement. You know, open source and stuff?
Re:Axe job (Score:4, Insightful)
Because, apparently, the core developers aren't sufficiently competent or committed to actual application and architectural security.
That is the entire point of having an open source project is that the developers don't have to be experts. Diaspora was developed not because some guys who were great at security decided one day to lunch an uber secure network, it was developed because people were tired of all the crap that FB had so they developed it. Now that the source code is out, security experts can audit the code and make improvements.
The original developers of an OSS project are like the managers, yeah, they know a little bit about the technical aspects but the main thing they have is vision then people who use it work on it to improve it. Or do you think Linus is some great wizard of security back when he wrote the very first version of Linux?
Just because the current main developers aren't that great of security doesn't mean security is compromised, actually its the opposite, they can get security advice from professionals and other people who are good at security.
Re:Axe job (Score:2, Insightful)
I am really on their side (and the side of all attempts at open social networking like XMPP's OneSocialWeb and Status.Net's OStatus), but they could have developed in the open from the beginning, and with the press they got, they would have had input on these problems when the code was in its infancy. It seems to me that the D team isn't open enough -- it's riding the fence and getting itself killed for the effort of doing so.
Re:BAD slashdot! (Score:2, Insightful)
The issue is that the community gave them $200,000. Frankly I'm surprised that so many people trusted 4 college students with this task. But now their incompetence is showing. Don't get me wrong, I'm sure they're brilliant -- *for college students* (actually I'm not so sure about that either, but even if they actually are at the top of their class, that does not mean they have any good experience). I chose to donate time and money to another project with more competent developers. They did nothing to prove that they have any experience. Look at your college undergrad classmates. If you were to pick 4 of them at random (when they were in college/graduating, if you've since graduated), do you really think they would be able to do what this Diaspora team is trying to do? My classmates came up with all sorts of good ideas, but they didn't have the practical experience to be able to implement anything significant.
Re:Let's give it more than a few hours ... (Score:3, Insightful)
it didn't "launch". as i understand it, they released some kind of alpha. I know i've worked for many managers who have this weird idea that software should be perfect before it's even done, but i didn't expect so many people in this community to hold that ideal.
There is a difference between perfect and free of fundamental errors in numbers so large that their correction became problematic if not resource-infeasible. There seem to be engineers who failed to understand this particular tenet (usually blaming managers as the ones who "never get it".)
Re:Volunteers (Score:5, Insightful)
...the idea of expecting volunteers to always be plentiful and useful is a good way to cause yourself problems.
Software projects in business suffer from the same problem, actually. Oh, programmers are plentiful as long as you have budget to spare, but not all professional programmers are created equal, peer reviews / code inspections are slipshod or even omitted, and testing is haphazard. In fact sometimes there's a conscious decision to take shortcuts in those areas because of pressure on the timeline.
The potential to be bitten in the ass by substandard work that goes undetected is always there, in business as well as OSS projects.
Re:Axe job (Score:5, Insightful)
There is no Silver Bullet in coding. You can't get it right from the beginning always...
Oh come *on*. The errors in this code were deeply fundamental, and patently obvious to anyone paying any attention. Not authorizing actions performed by authenticated users? Really?? Jesus christ, that's *basic*.
Sorry, no, what we're talking about, here, are fundamental flaws in their security architecture (or, more to the point, a complete lack of security architecture). And security architecture is something you *have* to get right up front (which is why good software architects cost a lot of money... it's necessary work, and hard to do well).
Re:Let's give it more than a few hours ... (Score:5, Insightful)
A former employer of mine had a team build a proof of concept for a large and critical piece of software, on which much of the business would rely. The team worked for several months and produced a functioning proof of concept, which they demonstrated to the management. Management took a good look and said, "Great, install it, and support it."
Within a few more months almost all of the team had resigned in frustration.
As far as I know, that proof of concept is still in place, with teams of people dedicated to keeping it duct taped enough to keep staggering on.
The real, serious, carefully constructed and tested software never got built.
Somehow, I doubt this is a unique tale.
Moral of the story: start it the way you intend to keep on.
Re:Arrogant "security researcher" bullshit (Score:5, Insightful)
I don't really understand what's wrong with this blog author, this "Patrick" fellow. Diaspora is git-release of a pre-alpha. It's essentially proof-of-concept which was released so we can have a look at it and contribute.
And it contains flaws in its security architecture that are so basic, so deeply fundamental, that it's impossible to have any confidence in the development team. Security and scalability *must be architected up front*. Tacking it on after the fact is a recipe for disaster. And it's blatantly obviously that the people working on the project don't understand this.
Re:Alternatives to Diaspora (Score:1, Insightful)
If you run the software, there's a hell of a lot more than 8 features, and even if there were, that's 7 more than Diaspora has.
It was not a "launch" (Score:3, Insightful)
There was no "launch", this was an alpha code release. Alpha code often has bugs, sometimes major. They even called it a "Developer Release". So I don't understand the uproar about *gasp* bugs in alpha code! If they had branded it beta code then I'd be more concerned with fundamental bugs, but even the developers said it had security bugs when they released it:
http://www.joindiaspora.com/2010/09/15/developer-release.html [joindiaspora.com]
Feel free to try to get it running on your machines and use it, but we give no guarantees. We know there are security holes and bugs, and your data is not yet fully exportable. If you do find something, be sure to log it in our bugtracker, and we would love screenshots and browser info.
These are design problems, not coding problems (Score:5, Insightful)
Security is part of the design, not the implementation.
Most developers still haven't learned that security isn't something you check for at various access points in the code: it is something you build directly into the business layer. For example, your code should not have a method like this anywhere:
public DeletePicture(int pictureID)
The method should be:
public DeletePicture(SecurityCredentials user, int pictureID)
This way it is impossible for your web to accidentally call DeletePicture() without checking for security. The security check is built-in to the lower-level and there is nothing you can do about it. Having worked on secure web services before, I realize I did not do this in my design, which was great for making simple tools, but it meant that all user-facing code had to have checks for security loopholes. The web is especially weird because users can hack the pages and the HTTP requests to call your methods in ways you never
Re:Security (Score:3, Insightful)
I'm not blasting the model, just asking the questions.
A private enterprise with its product and profit to think about would have had to get it up to a minimum level before showing or releasing even a beta version. (Of course, they could also have just delayed launch until it was right, which is not necessarily better)
Re:wit a minute (Score:3, Insightful)
Why are you making the assumption that "noone really cares yet to work on it?"
These security flaws were found very VERY fast in the code, I suspect because there are many people who want to look it over and, perhaps, work on it.
Re:Let's give it more than a few hours ... (Score:3, Insightful)
r0ml said it best at OSCON 2008, when describing how "real" software development and adoption methodologies work:
1. Commit to a version control repository.
2. Think about what you have right now, and release that crap.
3. Bug Reporting
4. Inventio: Ideas to fix the software.
5. Triage the problems.
6. Integrate the fixes.
He then went on to say "Some of you may notice something missing. There are no requirements. You just have bug reports. There is no development, there’s only maintenance."
He was working the crowd for a laugh of course, but quite a few folks weren't laughing.
Re:Axe job (Score:5, Insightful)
This is where the author's claim is rather worrying. His claim in the article (unfortunately rather lost in this attempt at a summary) is that the team completely lacks the necessary expertise and experience to build secure web apps, and has no chance of finding that experience through the open source model before their timetabled release.
I suppose it largely just boils down to what has often been apparent: an awful lot of volunteer coders have had no education in computer programming or security. While this is not always an issue, attempting to substitute enthusiasm for ability fails rather catastrophically when, as here, the task becomes difficult.
Re:Let's give it more than a few hours ... (Score:3, Insightful)
More generalized moral of the story: There is no such thing as a temporary solution.
Either whatever you did solved the problem kinda well enough (which quickly turns it into a permanent solution), or it doesn't (in which case it's no solution at all). That means that when you do something to mitigate a problem temporarily, make it clear to any management types that the problem isn't really solved.
One idea for preventing the deployment of a proof-of-concept is to make the UI for the proof-of-concept as ugly and difficult to use as possible.
Re:Security (Score:3, Insightful)
Diaspora has the benefit of being Open Source, much anticipated, and security aware. Thus, some number of security flaws have been found.
Diaspora is lucky in that regard. Bugs have lain dormant in even open source code for decades before being discovered. "Open Source" does not guarantee that bugs will become obvious. Open Source does not even guarantee that there will be people looking at the code, only that they CAN.
These are cultural problems, not design problems (Score:4, Insightful)
As I said here: http://groups.google.com/group/diaspora-dev/msg/17cf35b6ca8aeb00 [google.com] ... Ideally (though few manage this), security needs to be woven intrinsically and mutually throughout an entire endeavor at all levels of the social process, and from beginning to end, from recruitment to developer training to coding standards to code reviews (or whatever works) to archiving procedures to product announcements to bug fix procedures to communications with the public, as well as at all levels of the code itself, the tests, and so on. For many situations, security is often like a chain -- any weak link makes it fail. The less a project embodies this end-to-end security ethic, the more constant vigilance or constant exercise of power is required by everyone involved in it (extrinsic security and/or unilateral security). ... :-( ... ..."
"The central issue many people are concerned about (reading comments elsewhere) is that security is not an "add on".
So, in that sense, security is cultural. If you try to bolt on security after the fact (like trying to use a big military to defend long oil supply lines instead of having local power sources like solar panels, or trying to be the one who has all the power and everyone is afraid of rather than being the one who has a lot of friends who all share power and look out for each other) you end up spending a lot of time, money, and lives on "security" and you possibly still end up insecure.
Unfortunately, intentional or not, the first Diaspora release has been taken by some people to be a statement about the culture of Diaspora development as regards end-to-end security, even if it was not an intentional statement or even it it perhaps may not be accurate assessment relative to intent or plans. So, it is going to take a bit of work to recover from that, but no doubt it can be done by showing steady progress to creating a developer culture that has a security mindset woven throughout it.
So how does one get security in practice, assuming you want to do it end-to-end? What engineering attitude may be best to cultivate within that mindset?
Often, the best security is just simplicity.
Re:Axe job (Score:1, Insightful)
How about I take option 4 and call apologists like you retarded assclowns that are willing to excuse any crappy code as long as it's "open source"?
Re:...huh? (Score:2, Insightful)
The words "professionals" and "volunteers" are compatible, especially when discussing free software projects.
Re:WTF? (Score:1, Insightful)
Thank you! I've routinely skipped the articles I see with kdawson under them. His whole purpose is to create inflamatory articles to stir up trouble and anger people.
Re:BAD slashdot! (Score:4, Insightful)
These aren't "security issues that need fixing". These are "My First Web Application"-level mistakes -- things like failure to sanitize input, allowing code injection and SQL injection, and assuming that "user is logged in" or "user provided the super-secret URL" is equivalent to "user is allowed to do this". If these errors are as pervasive as the article says, the best thing that could happen to the code is a ground-up rewrite.
Re:Arrogant "security researcher" bullshit (Score:3, Insightful)
I don't understand, the code hasn't been designed yet. Patch it. The problem is there aren't any security assertations built into some transactions? How hard is submitting a patch with an "if GUID_allowed() != true then gtfo()" ?
The fact that you think it's this simple to build a solid security architecture demonstrates, all too well, the kind of simplistic thinking that has already damaged this project.
What kind of security model? Fine or coarse-grained? Are actions authenticated based simply on action type, or are there permissions associated with individual objects? If you want a fine-grained system, does that mean you want roles as well (managing fine-grained access control without roles is a huge pain in the ass)? How are you going to centralize these operations so that you aren't duplicating important code everywhere? How are you going to ensure that security checks are always done when necessary?
Designing security into a product so that it's a) pervasive, b) maintainable, and c) useable is *hard*. It's not just about throwing a couple if-then-else checks in. It's an entire fucking mindset. It's absolutely an *architectural* problem, and software architecture can't be hacked in after the fact. It must be thought through right at the outset.