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