Monday, May 30, 2011

The Weakest Link

The May 2011 issue of Communications of the ACM contains an article called Weapons of Mass Assignment by Patrick McKenzie. The article describes McKenzie's security analysis of the pre-release source code of Diaspora, an attempt to build a "privacy-aware Facebook alternative". The Diaspora home page makes the following claim: "Inherently private, Diaspora doesn’t make you wade through pages of settings and options just to keep your profile secure." Unfortunately, McKenzie was "struck by numerous severe security errors", which were "serious enough to jeopardize the goals of the project."

The first kind of errors McKenzie reports are a result of confusion between authentication and authorization. Authentication means that the system has identified the user using some secure mechanism, so that nobody else can impersonate that user. Authorization, on the other hand, refers to the set of operations that a user can legally perform. Naturally, authorization is meaningless without authentication, since you can't refer to the operations a user is permitted to perform without authenticating that user. But authentication isn't enough; once you know who the user is, you should allow him to perform only operations he is authorized to perform.

In the code release that McKenzie examined (the "pre-alpha developer review"), an authenticated user could delete photos based on their IDs. If you knew the ID of somebody else's photo, you could delete it, and discovering photo IDs was easy. Here is an example of a URL (from another source) that contains IDs: http://ark.intel.com/Product.aspx?id=52215&processor=i7-2600S&spec-codes=SR00E. The part that follows the question mark (shown here in bold) contains a list of parameters and values, which the server-side script accesses to figure out what to do. When you see such URLs, you can often figure out what the IDs refer to, and you can replace IDs in them to create various effetcs. In Diaspora, for example, you could delete one of your own photos to see what that request URL was like, and then replace the photo ID to delete somebody else's photo.

Diaspora uses Ruby on Rails, and suffers from the security vulnerabilities of that platform. In particular, McKenzie points to the Rails feature of "mass update", which is a convenient but dangerous programming tool. It takes a list of keys and associated values and calls the related accessor method for each key. This allows an attacker to add keys that the developer didn't intend to be modified, thus creating serious security vulnerabilities such as allowing one user to take over another's account. If mass update is used on values received from an HTML form (which is often the case), all an attacker needs to do is modify the form to send malicious key-value pairs. Because the form is presented on the attacker's machine, this is an easy task.

McKenzie details several other vulnerabilities, which allow attackers to discover or replace another user's encryption key, thus allowing them to decipher all that user's previous and future communications with the server. This is quite serious in an application whose first priority was security and privacy. A chain is only as strong as its weakest link, and this applies first and foremost to security, where an attacker will deliberately go after the weakest link. The fact that Rails has mass update enabled by default should make you suspicious of any application built on Rails, since it requires positive action by security-conscious developers to disable mass update. The more issues developers need to be careful of, the greater the chance that they will miss some, creating security vulnerabilities. This makes me question whether Rails is a good tool for developing secure web applications (see The Right Tool for the Job). This is unfortunate in tool whose main purpose is to make web development easy.

It remains to be seen whether Diaspora will finally be secure. McKenzie ends his article on a positive note: "This is not a reason to despair, though: every error fixed or avoided through improved code, improved practices, and security reviews offers incremental safety to the users of software and increases its utility." I am less optimistic: an application that boasts its security needs to designed for security from the first, not debugged and reviewed to decrease its vulnerabilities after the fact.