to a number. The code for this is left
as an exercise for the reader. With
that JavaScript, the attacker can run
repeated find queries against the da-
tabase to do a binary search for the se-
rialized encryption key pair:
“Return Patrick if his serialized key
is more than 2512. OK, he isn’t in the
result set? Alright, return Patrick if his
key is more than 2256. He is in the re-
sult set? Return him if his key is more
than 2256 + 2255. …”
A key length of 1,024 bits might
strike a developer as likely to be very
secure. If we are allowed to do a binary
search for the key, however, it will take
only on the order of 1,000 requests
to discover the key. A script execut-
ing searches through an HTTP client
could trivially run through 1,000 ac-
cesses in a minute or two. Compro-
mising the user’s key pair in this man-
ner compromises all messages the
user has ever sent or will ever send on
Diaspora, and it would leave no trace
of intrusion aside from an easily over-
looked momentary spike in activity
on the server. A more patient attacker
could avoid leaving even that.

This is probably not the only vul-
nerability caused by code injection. It
is very possible that an attacker could
execute state-changing JavaScript
through this interface, or join the Per-
son document with other documents
to read out anything desired from
the database, such as user password
hashes. Evaluating whether these at-
tacks are feasible requires in-depth
knowledge of the internal workings
of MongoDB and the Ruby wrappers
for it. Typical application developers
are insufficiently skilled to evaluate
parts of the stack operating at those
levels: it is essentially the same as
asking them whether their SQL que-
ries would allow buffer overruns if
executed against a database compiled
against an exotic architecture. Rather
than attempting to answer this ques-
tion, sensible developers should treat
any injection attack as allowing a total
system compromise.

Be Careful When Releasing
software to end users

One could reasonably ask whether security flaws in a developer preview are an emergency or merely a footnote in the development history of a product. Owing to the circumstances of its creation, Diaspora never had the luxury of being both publicly available but not yet exploitable. As a highly anticipated project, Diaspora was guaranteed to (and did) have publicly accessible servers available within literally hours of the code being available.

People who set up servers should know enough to evaluate the security consequences of running them. This was not the case with the Diaspora

figure 3. a mischievous ‘Person.’

#Person.rb class Person #omitted for clarity key :url, String key :diaspora_handle, String, :unique => true key :serialized_key, String #Public/private key pair for encryption.

key :owner_id, ObjectId #Extraordinarily security sensitive because…

one :profile, :class_name => ‘Profile’ many :albums, :class_name => ‘Album’, :foreign_key => :person_id belongs_to :owner, :class_name => ‘User’ #... changing it reassigns account ownership!

preview: there were publicly accessible Diaspora servers where any user could trivially compromise the account of another user. Moreover, even if one assumes the server operators understand what they are doing, their users and their users’ friends who are invited to join “The New Secure Facebook” are not capable of evaluating their security on Diaspora. They trust that, since it is on their browser and endorsed by a friend, it must be safe and secure. (This is essentially the same process through which they joined Facebook prior to evaluating the privacy consequences of that action.)

The most secure computer system is one that is in a locked room, surrounded by armed guards, and powered off. Unfortunately, that is not a feasible recommendation in the real world: software needs to be developed and used if it is to improve the lives of its users. Could Diaspora have simultaneously achieved a public-preview release without exposing end users to its security flaws? Yes. A sensible compromise would have been to release the code with the registration pages elided, forcing developers to add new users only via Rake tasks or the Rails console. That would preserve 100% of the ability of developers to work on the project and for news outlets to take screenshots—without allowing technically unsophisticated people to sign up on Diaspora servers.

The Diaspora community has taken some steps to reduce the harm of prematurely deploying the software, but they are insufficient. The team curates a list of public Diaspora seeds ( https://github.com/diaspora/ diaspora/wiki/), including a bold disclaimer that the software is insecure, but that sort of passive posture does not address the realities of how social software spreads: friends recommend it to friends, and warnings will be unseen or ignored in the face of social pressure to join new sites.

 

end

#User.rb one :person, :class_name => ‘Person’, :foreign_key => :owner_id

Could Rails have Prevented these Issues? Many partisans for languages or frameworks argue that “their” framework is more secure than alternatives and that some other frameworks are by nature insecure. Insecure code can