In the wake of a recent unexpected iOS update, researchers quickly discovered that the major flaw Apple intended to fix with the patch, was a problem inherent to the company's entire SecureTransport platform, not just iOS.

Rather than fail, “goto” success

on Feb 26, 14 • by Roy Sarkar • with No Comments

You’ve probably heard about Apple’s goto fail vulnerability (if you haven’t, read our summary about it or this deep dive into the problem by Google researcher Adam Langley). The short story is, within a sequence of if statements, two goto fail; statements were placed one after the other like this: if ((err =...

Home » Static Analysis » Rather than fail, “goto” success

You’ve probably heard about Apple’s goto fail vulnerability (if you haven’t, read our summary about it or this deep dive into the problem by Google researcher Adam Langley). The short story is, within a sequence of if statements, two goto fail; statements were placed one after the other like this:

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
	goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
	goto fail;
	goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
	goto fail;

This code is located deep inside the SSL/TLS security layer for both iOS and MacOS and could cause the last if statement, part of an overall check for valid SSL certificates, to never execute. This omission means that anyone could perform an attack spoofing a secure website and potentially gain access to your iPhone or MacBook. Adam Langley actually built a site to test this (if you can load this HTTPS site on port 1266, your system is vulnerable).

What about Klocwork?

The good news for users of Klocwork Insight is that this vulnerability is easily detected by one of our standard checkers, UNREACH.GEN. Basically, this checker looks for statements in code that will never be executed during runtime. As our documentation states, “the presence of unreachable code can lead to code vulnerabilities when that dead code is responsible for guarding specific resources or code branches”, which is exactly what happened to Apple here.

We’ve coded up a succinct example to show how this basic check would appear in our Visual Studio environment (click to expand):

Screenshot showing checker messages

As you can see, it’s pretty straightforward. And don’t forget, since Klocwork works on-the-fly, this warning would’ve appeared as soon as the code was being typed in, well before code reviews or system testing.

If you’re a current user of Klocwork Insight, try coding up the example above and see what you get. If not, here are some security-related resources you can check out to learn more:

Catch the Security Breach Before It’s Out of Reach webinar
Defend Against Injection Attacks white paper (PDF)
A list of all our checkers

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top