Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search

Goto Fail

If you've haven't heard about Apple's security flaw registered as CVE-2014-1266 on apple website, you probably were on planet Mars.
Basically, it was unsafe to use https connections. I couldn't help but write an article about this!
Components dealing with secured connections are abolutely critical. Applying rigorous development process is the best chance to avoid any trouble with these components.

The guilty code

Here is the code with the security flaw in Apple's ssl library:

static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err =, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }

Quote from Adam Langley's ImperialViolet blog, who quoted it from Apple's published source code.

How to reduce the probability of such flaw?

Even is it's tempting to blame the developer on its code, that's not the right way to avoid such situation to happen again. It's the development process as a whole that is questioned here.
Namely in every step of the process. Considering that collecting user requirements, writing specifications and designing architecture are not called into question (this is ssl, look at the rfc and stuff, ok?), the situation can be avoided by putting safeguards during coding and testing.


Tests are a good way to find bugs, not all of them but most of them.
There are plenty of ways to test software (see "the big picture" in this article about tests): unit tests, user tests and so on.

According to Adam's article, the problem could only be discovered by doing very specific tests with a custom-made TLS stack.
Needless to say that such tool would be itself subject to errors. How to test a complex test tool?. It would need IQ, OQ an PQ, to be qualified as the right testing tool. Or, for ISO 13485 aficionados, a tool validation protocol according to section of that ISO standard.

Thus it appears that tests are probably not enough to run after this kind of bug.


We only have the coding phase left!
There are two possiblities, to trap this kind of bug:

  • Verifying what developers code,
  • Changing the way developers code.
Verifying code

Here we have two possibilities:

  • Human verification,
  • Automated verification.

Human verification is achieved by doing peer code reviews, whereas automated is done with the help of static analysis tools or advanced compiler checks.
Both have their advantages or drawbacks (dealing with humans or dealing with machines designed by humans).

BTW: these kinds of verification are in line with IEC 62304 requirements about software units verification found in sections 5.5.2, 5.5.3 and 5.5.4 of the standard.
So if you want to be in line with IEC 62304 in class B (and C for 5.5.4) I can only urge you to either implement unit tests and/or plan coding reviews.

If you're skeptical about the benefits of code reviews, I invite you to read this previous article about code reviews vs tests.

Changing the way developers code

Here we have two levers:

  • Pair programming,
  • Coding standards.

I can only urge you to try to impose coding standards and try pair programming with your development teams!
IMHO this is the most efficient way to avoid such bug.

Coding standards however are more efficient if there is a static analysis tool to verify that they are applied. They're usually a document with more than 10-20 rules and they're difficult to know by heart!

Pair programming is not easy to implement, especially when managers see it as doubling costs! That's the biggest obstacle to this method!

For the hell of a goto

Another remark: strongly ban goto's in your coding practices.
If I were to configure a C compiler on a build server, a goto wouldn't compile.
Just for the hell of it! :-)


The best way to put the odds on our side is to combine several methods:

  • Peer coding reviews and/or pair coding,
  • Coding conventions,
  • Static code analysis,
  • Classical tests.

You will be totally in line with sections 5.5, 5.6 and 5.7 of IEC 62304.

The stricter the development process, the less bugs. Hence the software security classes.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed