Understanding the Aesthetics of Apple’s SSL Bug   16 comments

Apple’s latest SSL bug (which impacts both iOS and Mac OS) is covered in detail by the venerable Adam Langley on his blog. My blog post is much less ambitious and focuses on one question: if we evaluate the bug aesthetically, without any knowledge of the circumstances that led to it, does it appear more like a bug or more like a backdoor?

The indented if statement

The if statement which contains the two goto fail statements is indented in a way which makes it easy to immediately assume that both goto fails are being evaluated as part of the statement itself. However, the if statement is not bracketed! This is interesting because sslKeyExchange.c (the file where the vulnerable code occurs) uses a bunch of if statements, and many of them are indeed bracketed. For example:

if (message.length < 2) {
    	sslErrorLog("...");
        return errSSLProtocol;
}

This bracketing happens out of necessity, since we are executing more than a single line of code as part of the if statement. However, since our vulnerable if statement is not bracketed (it doesn’t start with a { and end with a }), only its first instruction gets executed as part of the if condition. The second goto fail line is executed whether the if statement’s conditions are satisfied or not.

It’s interesting to note that had the programmer used an initial if statement in that method followed by else if statements, their code would not only most likely be more efficient when compiled, but the second goto fail statement would have been detected as invalid by the compiler. This vulnerability would have then been avoided. But the programmer went for a less efficient method which made the bug possible.

The repeated goto statement

Generally, when there is a security bug in a piece of code, it is the case that the programmer wrote the bug falsely thinking that they were contributing something positive to the code (this is what happens every time I am the source of a security vulnerability).

However, there is no reasonable practical reason that I can imagine for putting two goto statements, that point to the same method, right after each other. I simply can’t come up (and I don’t think anyone can) with a use case where this could be useful. This is because once the first goto is identified, execution jumps to (or goes to, so to speak) the referenced method and continues from there, end of story. The second goto statement is never needed and can’t possibly be construed as offering something useful, even innocently. So why was it added in this diff (line 631)? What was the reasoning? This is an unanswered question.

In conclusion, the especially significant circumstance here is that we had an unjustifiable repetition of a goto instruction which can’t reasonably be falsely construed as useful, inside an indentation that made it appear as part of an if statement that already included that instruction in the first place.

Posted February 22, 2014 by Nadim in Computing, Security

RiseUp Is Not for Activists

I’ve been meaning, for a few months now, to write a blog post regarding why I believe that RiseUp’s email service is contributing dangerously to political activists, and why I believe that the short-term mitigations they are performing in relation to that are not solving the problem. I am writing this post to warn activists that, in spite of what seems to be the public perception, RiseUp’s email service must not be considered secure for use by those concerned by surveillance, and to explain why I have this belief.

I sincerely understand that armchair critiques are infinitely easier, and less helpful, than conjuring solutions, and I am not writing this post to disparage the difficult and necessary effort made by RiseUp since 1999. I use RiseUp to maintain a mailing list for a local volunteer-operated charity initiative, and in that context, it is an excellent service that I am thankful for. However, I’ve been on the receiving end of many a discussion where RiseUp has been suggested as a secure email service, and those suggestions must be put to rest as endangering the security of privacy-seekers and politically engaged individuals worldwide. I have discussed these issues months ago with RiseUp members, and the responses I’ve received have varied, but generally has not been enough to mitigate RiseUp’s current security issues.

Promises versus actual offerings

According to this RiseUp fundraiser campaign (which RiseUp was indeed an active member of),[1] RiseUp email is marketed as a tool to “Fight the NSA”, and offers the opportunity to become “officially a member of the elite team of activists using technology for social change!” To their credit, on the RiseUp website, the email service is marketed with technical accuracy, and yet markets the service exclusively towards “people and groups working on liberatory social change.”

The problem with this kind of rhetoric, which RiseUp has been actively maintaining for years, is that it promotes RiseUp’s email service as one that is meant almost exclusively for activists, offered by activists, and that it is resistant to the privacy threats that bigger, corporate and certainly-not-indie-and-cool email providers like Gmail are affected by. In working with activist groups around the world, I overwhelmingly meet activists that are under the impression that they are safer, and that their privacy is more guaranteed, by using RiseUp.

Just four months ago, this August, email service Lavabit shut down its services entirely in order to protest a government wiretap order. They did the right thing, and another secure email service provider, Silent Circle, also followed suit with its own email service in order to avoid potential government wiretap orders.[2] Later, when Lavabit’s founder offered to revive his project as open-source software, security researcher Moxie Marlinspike correctly pointed out that Lavabit’s email services were insecure, and that the project should not be revived as-is. But RiseUp’s email services, which depend largely on SSL connections and server-side encryption for security, are very similar to Lavabit and suffer from exactly the same kind of security weaknesses. And yet, even though RiseUp’s servers are largely located in the United States, and that therefore these servers, being marketed almost solely towards activists, have previously been seized outright by the FBI and returned only weeks later, RiseUp’s email services were not shut down.

RiseUp stated that it had not received any government requests (aside from the FBI seizure) and that it would do everything in its power to fight government surveillance requests. This is laudable, but the issue here is that large-scale adversaries do not need to send RiseUp any requests in order to access its email communications. The same kind of massive SSL man-in-the-middle attacks that affect bigger, and much more capable, services such as Gmail can easily affect RiseUp. While RiseUp is in fact implementing advanced measures such as forced HSTS in the Chrome browser, it falls short of also implementing certificate pinning, and therefore can have its entire email servers quickly and easily monitored by large-scale adversaries. Not only is RiseUp’s email service vulnerable to any attack that affects Gmail and other services, but their chosen audience ensures that they receive even more tailored attention from surveillance bodies.

By centralizing the emails of thousands of activists under a single network of servers located in the United States, RiseUp is creating an incredibly valuable target for such surveillance. Using RiseUp actually decreases your chance towards privacy as an activist, because you are centralizing yourself along with thousands of other activists, in a US-based email service that is marketed almost exclusively towards activists and that operates on a very weak security premise. On top of this, emails exchanged through RiseUp are also not protected from monitoring by RiseUp staff or individuals with illegitimate access to RiseUp’s servers.

RiseUp is not entirely to blame

This isn’t RiseUp’s fault. The individuals behind RiseUp are experts who have been in the field for more than a decade. They are working on LEAP, a promising (although I’ve only skimmed it!) successor to RiseUp’s email, and they understand the issues and can be trusted to work towards resolving them. The real issue here is that secure email is currently impossible, and that RiseUp has maintained its attempt to offer an impossible service, marketed towards those who want to believe in an impossible service. It’s not RiseUp’s doing that secure email is currently not achievable. But something needs to be done regarding their insistence on garnering the trust of activists with regards to what their services can securely offer. It’s irresponsible, inaccurate and dangerous. Steps need to be taken to relieve the consciously adopted image that RiseUp gives to its users regarding its email service.

 

Footnotes

[1] RiseUp staff members initially denied involvement with this campaign but later admitted it. To me, this initial denial is discomforting. I was actively misled by RiseUp regarding their involvement in this campaign, and that is not okay.

[2] In addition, Silent Circle founder Jon Callas wrote that “the problem isn’t crypto, it’s SMTP”.

Posted December 2, 2013 by Nadim in Internet, Security