SoylentNews

Schneier Speculates on Apple's SSL Flaw

posted by girlwhowaspluggedout on Sunday March 02 2014, @12:01AM   
from the one-bad-apple-spoils-the-whole-bunch dept.

Papas Fritas writes:

"Last October, Bruce Schneier speculated that the three characteristics of a good backdoor are a low chance of discovery, high deniability if discovered, and minimal conspiracy to implement. He now says that the critical iOS and OSX vulnerability that Apple patched last week meets these criteria, and could be an example of a deliberate change by a bad actor:

Look at the code. What caused the vulnerability is a single line of code: a second "goto fail;" statement. Since that statement isn't a conditional, it causes the whole procedure to terminate ... Was this done on purpose? I have no idea. But if I wanted to do something like this on purpose, this is exactly how I would do it.

He later added that 'if the Apple auditing system is any good, they will be able to trace this errant goto line to the specific login that made the change.'

Steve Bellovin, professor of Computer Science in Columbia University and Chief Technologist of the Federal Trade Commission, has another take on the vulnerability: 'It may have been an accident; If it was enemy action, it was fairly clumsy.'"

• Re:Here is the code. (Score: 4, Interesting) by chr1sb on Sunday March 02 2014, @04:36AM

  by chr1sb (2778) on Sunday March 02 2014, @04:36AM (#9401)

  The old maxim "Never attribute to malice what can be attributed to incompetence" applies here too. No human is required to write the code in that specific way for the code to exist in that form. This is the kind of defect that can be introduced by e.g. a merge issue between branches. When code has been modified in both branches, the merge tool will do its best but can easily break the code in this way. This is another reason for good unit tests and code reviews, as pointed out by others. Now, if the unit tests were modified to *no longer* detect that circumstance, then I would be suspicious.
  
  To reduce the likelihood of these issues arising, the code can be structured in a different way, with no need for gotos, more protection against such merge issues and with structural flaws being more obvious:
  
  static OSStatus
  SSLVerifySignedServerKeyExchange(SSLCont ext *ctx, bool isRsa, SSLBuffer signedParams,
                                   uint8_t *signature, UInt16 signatureLen)
  {
      OSStatus err;
  
      // some code
  
      if (   (0 != (err = SSLHashSHA1.update(&hashCtx, &serverRandom)))
          || (0 != (err = SSLHashSHA1.update(&hashCtx, &signedParams)))
          || (0 != (err = SSLHashSHA1.final(&hashCtx, &hashOut))))
      {
          SSLFreeBuffer(&signedHashes);
          SSLFreeBuffer(&hashCtx);
          return err;
      }
  
      // more code
  }
  
  

  Parent

  Starting Score:	1		point
  Moderation		+3
  Interesting=2, Informative=1, Total=3
  Extra 'Interesting' Modifier		0
  Total Score:		4