iOS7 meets Saltzer & Schroeder


iOS-7 (Image source: Apple)

What iOS 7’s SSL/TLS security patch release tells us

While the commentators, pundits and software guru’s pontificate over Apple’s SSL/TLS goto fail bug’s root cause, the bug does provide an interesting perspective on Least Common Mechanism one of the least understood of Saltzer and Schroede’rs security principles. For those interested in the detail of what actually went wrong with ‘SSLProcessServerKeyExchange()’ click over to the Sophos post on the subject.

Because the crypto key mechanism is a library function, applications that use the function containing the bug are all vulnerable while other (non-Apple) applications not relying on the library, such as Chrome, Skype and Firefox, remain unaffected. So you could squint a little and say that the implementation did adhere to the second part of Saltzer & Schroeder’s last common mechanism principle, i.e. if you have to share a mechanism implement it as a library function so that users can opt out. Of course if you’re going to build a common security mechanism, it behooves you to be very, very, very, very sure that it works. As Saltzer and Schroeder also remark in their Economy of Mechanism principle, normal use (and tests thereof) are unlikely to pick up these sort of problems so intensive line by line inspection of code is required. Said inspections were in this case not done, or not done well enough.

A more subtle error is the fail deadly nature of the code itself, that’s because the function can fail and terminate with the calling function being none the wiser as to whether it has accomplished the security task, which is kind of alarming and kind of also violating Saltzer and Schroeder’s Fail Safe Defaults principle. To make the mechanism fail safe the designer should have reversed the logic e.g. the key status is presumed to be invalid immediately, and until proven otherwise. This invalid status remains until the vital sslRawVerify() is completed then immediately after which the status is set to valid, ensuring that early termination or jumping out will fail to the safe state. An analogous situation is a ‘top entry’ flag set on entry to a safety critical module or section of code that is checked immediately prior to some final critical step to ensure that only valid jumps to the code will initiate the critical action. In our case of course we want to deal with the reverse problem.

The good news is that Apple is/has released a software update for both iOS and OSX, although the staggered release sequence was somewhat 0day ugly. But will Apple step back and think about the broader issues of security centric computing now that the dust has settled? That’s a more difficult question to answer.