Slashdot Mirror
Security Lessons Learned From the Diaspora Launch
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."
Because of course, obscurity is proper security.
Um, and if closed-source project were to receive the same level of public scrutiny, the users would be any less screwed?
Here is a list of alternative open source Peer-to-peer social networking softwares
Note that The Appleseed Project has existed since 2004 and is the first.
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 proprietary software. I think that maybe, just maybe he's biased against FLOSS?
In soviet russia the government regulates the companies.
The editor forgot to mention that the post didn't actually end with what he claims it did, making out the writer to hate diaspora, the post actually ended with:
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.
Orwell was an optimist.
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.
It doesn't really matter that it's pre alpha, or whatever designation you want to give it. A platform touted as being a secure replacement for facebook ought to consist of secure code from day 1. Security needs to be built into the bones of the program, and If you read the article, you'd see that the errors made were pretty egregious. Fact is, any programmer worth his or her salt would not have started out with code like this with a plan to fix it later in future releases, they'd get it right from the very beginning. That they made these mistakes so early on speaks wonders about how inexperienced these programmers were (and hopefully are no longer now that they've learned their lesson). I'm still rooting for Diaspora but am a little disappointed by this.
Quid festinatio swallonis est aetherfuga inonusti?
Africus aut Europaeus?
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.
I think the point they are trying to make (and perhaps badly) is that anytime you have to rely on volunteers you have the potential to get bit in the ass. Any volunteer organization or group has this problem, it's not just open source. Churches, after school groups, the Elks, etc. When volunteers are the main way you expect to get support, you are at their whim. This week people are busy, so no one shows up, or the kids have a soccer game, or some new more exciting group has their interest so you lose a few people.
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.
I will shred my adversaries. Pull their eyes out just enough to turn them towards their mewing, mutilated faces. Illyria
Exactly. It does exactly what it's supposed to do: Instead of having a single mega-corp have complete control of your data, it does completely the opposite and lets everyone in the world have complete control of your data! It truly is the anti-Facebook.
You're overlooking a few points.
TFA's author acknowledges that it's a pre-alpha preview release. In a sane world, that means no one should ever go on-line with this code. But this is not a sane world, and he very specifically addresses how this release should have been done:
In other words, defang the thing before you turn it loose on an unsuspecting community. If I can successfully develop an open-source backyard nuclear fission generator, and release the pre-alpha blueprints, I would be rightly criticized for the occasional containment failure and subsequent deaths or injuries.
Also, the attitude of "meh, the security issues are trivially easy to fix" completely misses the point. If the known issues are trivially easy to fix, why weren't they trivially easy to avoid in the first place? Because, apparently, the core developers aren't sufficiently competent or committed to actual application and architectural security. So there's no reason for confidence that there won't be another batch of crippling security flaws with each new release.
Yeah, a lot of the backlash is probably in response to the hype around Diaspora. But much of the danger is also because of the hype. If Diaspora were just another quiet little Sourceforge project, it might have the luxury of a slow and casual crawl towards reliable application security. But guess what, Diaspora is the current Open Source equivalent of Paris Hilton. Being this screwed up is not an option, when the project is under such scrutiny and subject to such high expectations.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
My work here is dung.
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.
I would agree, but that code was some junior level bullshit. Granted I haven't been doing this for 20 years, but damn that was some horrible coding going on there. Especially when they tout it as some super great OSS alternative to facebook. It almost made me question how good of a choice Ruby on Rails was for the entire project.
Hold up, wait a minute, let me put some pimpin in it
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.
The summary took the quote slightly out of context. what i understood from TFA is that they are screwed in terms of meeting their (one month?) deadline.
The team is manifestly out of their depth with regards to web application security, and it is almost certainly impossible for them to gather the required expertise and still hit their timetable for public release in a month.
$ unzip, strip, touch, finger, grep, mount, fsck, more, yes,fsck,fsck,fsck,umount, sleep
Read the authors blog just a bit, I am not really sure the guy even wrote this article he may have had it commissioned. The author is a crapware distributor and this article is nothing more
than a attempt at driving traffic to his site which worked. Now his claim to fame is some "bingo card printing software for teachers".
A few minutes with a compiler and a few dictionary files will show him exactly what "Open Source" is good for. I could really care less about what he wrote but if I was pissed about it there would be a new open source bingo card printing software package released within the next two hours.
Got Code?
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.
Taxation is legalized theft, no more, no less.
I work HfH construction once in a while. They hire professionals to do the important bits and the large stuff; excavating, pouring the foundation, wiring, plumbing, and often the finish carpentry. If you happen to have someone relatively skilled there, they may assist the pros; I've helped with all; wiring, plumbing, finish carpentry. But you don't let someone who is enthusiastic but doesn't know what they're doing do finish carpentry, they'll probably just wind up wrecking a lot of material. And if you let them do plumbing in an area where code requires copper pipe, you'll probably wind up with a mess that will take a pro 3 times longer to fix than if he'd just done it himself to start with.
I think the latter may be the case when it comes to this project. I really, really hope this project comes together, but as a programmer I fear that if they've built this thing from the ground up without a good basic understanding of web security, the thing may have to be gutted and rewritten to get to where it needs to be.
Lots of people can write web apps. Heck, I pretty much write web apps all day long, but I write them for intranet use, they're not accessible to the internet at large. If my stuff had to be hardened against the kind of general attack Diaspora is going to have to endure, I'd have to learn a lot more than I know now.
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).
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.
WALSTIB!
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
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.