Was the iOS SSL Flaw Deliberate?

Another sad indicator of the level Schneier is playing at today, in the same vein as &quot;avoid elliptic curves, we don&#x27;t trust the math&quot;.<p>Once again: the only reason this bug got so much attention and press is that it&#x27;s easy for laypeople to get their heads around. All you have to understand is how &quot;goto&quot; works. The bug is vivid, and so (paradoxically) seems scarier.<p>Significantly worse bugs are found every week. Within a few days of the announcement of this TLS bug, a Flash bug was announced, after being detected in exploits in the wild, that enabled reliable drive-by hijackings of browsers --- multiple browsers. It was off the HN front page within an hour.<p>TLS bugs aren&#x27;t even unusual. We get a new one every few years ago. Firefox managed a PKCS1v15 parsing bug that allowed anyone with a Python script and 30 milliseconds to generate a certificate for any domain. Other browsers have screwed up certificate chaining, so that any domain could sign any other domain. But nobody understands PKCS1v15 padding, nobody understands certificate chaining, and so nobody writes stories about these bugs. But their impact is identical to this one.

Often when things like this happen there&#x27;s a large conspiracy at play in some peoples minds, &quot;Apple <i>deliberately</i> left a security vulnerability&quot;. But it falls apart pretty quickly, it&#x27;s in an open sourced package, so the assumption is <i>someone</i> is eventually going to see it, so it&#x27;s not going to remain a secret and thus is useless as a stealth backdoor.<p>The likelihood is pretty simple, someone fucked up. On a potentially <i>huge</i> level, but a fuck up none the less. These things do unfortunately happen, and no doubt it&#x27;ll prompt an internal review of their change management process, and their build chain, and what they can do to isolate issues like this in the future.

As noted in the article, <i>plausible deniability</i> is a key criterion for thinking of this as a possible NSA insertion.<p>In other words, it&#x27;s only possible that it&#x27;s an NSA job if it&#x27;s also possible that it isn&#x27;t. Something tells me therefore that we&#x27;re unlikely ever to know for sure.

If I were at the NSA and wanted to introduce a bug like this, I&#x27;d get access to Apple&#x27;s build servers (either through an exploit or by just talking to an employee who has access) and arrange for a binary patch to be applied to the generated object files at build time. It would be basically undetectable, as no amount of source code auditing would reveal it. Could probably make it look like a compiler bug without too much difficulty.<p>Of course, this presumes that the NSA <i>needs</i> to introduce bugs like this. I imagine they do just fine for now merely taking advantage of naturally occurring bugs.

Well, <a href="http://www.opensource.apple.com/release/os-x-109/" rel="nofollow">http:&#x2F;&#x2F;www.opensource.apple.com&#x2F;release&#x2F;os-x-109&#x2F;</a> has the list of open sourced code from Mavericks. Let the code analysis begin, it would help everyone out.

It&#x27;s not just an &quot;iOS&quot; flaw. It&#x27;s a &quot;latest, greatest Apple OS&quot; flaw.<p>And anyone who given a choice between SSL and TLS relies on TLS is not putting security as a top priority.<p>And why would anyone who cares even the slightest about security use Flash? Are you serious?<p>I guess this is why security consulting could be easy money... clients want to use Flash and &quot;stay secure&quot;. Yeah, sure, we can handle that for you.<p>Well, now you cannot even use a Mac without the potential for HTTPS authentication not working. Better make sure the OS is updated. Sounds a lot like Microsoft. Maybe you could start a business updating Mac OS&#x27;s.<p>&quot;Does anyone know what&#x27;s going on inside Apple?&quot;<p>If they did they couldn&#x27;t say. All employees are sworn to secrecy.<p>I blackhole all traffic from Apple devices to *.apple.com<p>You would not believe (or maybe you would, if you are a &quot;security consultant&quot; or some such)... you would not believe the amount of &quot;phoning home&quot; that these devices do.<p>I agree you can&#x27;t trust &quot;security consultants&quot; who do their marketing via blogs and forums.<p>But you surely cannot trust Apple either.<p>The flaw was one line of code.<p>I&#x27;m curious. What is the size on the update?<p>Imagine if you could make the change yourself, recompile and dd an image to your device.

I&#x27;d like to believe Apple simply as no code review but it&#x27;s odd they removed a specific check -- was it not suppose to be there? Does anyone know if the patch added the line back in or if it removed the duplicate goto?<p>The one thing that points to it not being a backdoor is I doubt Apple would open source the code. Surely they&#x27;d maintain a separate branch or something?

I really hope Apple will disclose its findings on this matter, in name of the transparency they&#x27;re advocating. Imagine if Apple itself states something along the lines of &quot;we found out that the line of code responsible for the bug was planted on purpose&quot;. Should they make such a statement? Better: COULD they make it?

Why is is so important to know wether this bug was left deliberately or not, or even sneaked in by the NSA?<p>To the more important questions &#x27;Did the NSA almost immediately discover this bug&#x27; and &#x27;Did they exploit it&#x27;, I answer with a resounding yes.

I think I&#x27;ll apply Betteridge&#x27;s law[1] to this one.<p>[1]: <a href="http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Betteridge%27s_law_of_headlines</a>

I honestly think it was deliberate. What class of Operating System developer ships their OS releases without 100% CODE COVERAGE? Apple do code coverage testing, surely? I mean, more than the &quot;-warn-dead-code&quot; args that get flung around. I can&#x27;t understand how this would have gotten released into the wild if they were doing industry-standard code coverage tests. And .. if they&#x27;re not doing industrial-strength code-coverage testing on their iOS&#x2F;OSX release builds, thats the real news here ..

It looks like the sort of bug that can be introduced by an erroneous merge in source control.

I don&#x27;t think the bug was deliberate, could of been just an honest mistake.<p>But on the other hand, why didn&#x27;t the compiler generate an &quot;Unreachable Code&quot; warning during build?<p>We have explicitly set this warning to &quot;Treat as Error&quot; during our builds.

Where am I mistaken that having this bug deliberate is meaningful only if you control most of the networks? In which case there are a lot scarier things to worry about.

I prefer always using brace brackets for if&#x27;s...<p>if (cond) { goto fail; }<p>instead of:<p>if (cond) goto fail;

I don&#x27;t think the NSA is nearly as technologically capable as people think they are. If they want info from someone all they have to do is detain them and bust open their kneecaps with a hammer. No one would ever find out. So there&#x27;s really no reason to go through all the shadow games.<p>If this is an intentional bug, I think it&#x27;s likely a hacker or just a disgruntled employee. But I&#x27;d be willing to wager that it was a tiredness error, rushed to implementation by an overworked and likely underpaid engineer deep within Apple.

Wouldn&#x27;t it be way safer and easier for any attacker (NSA or otherwise) to compromise a trusted CA than to compromise the Apple SSL code?

I was wondering if this was going to be one of those pages that just says &quot;Probably.&quot; or similar in large text.

...There are goto statements in the code that is running on my laptop and phone? I feel dirtier now.

&gt; The flaw is subtle, and hard to spot while scanning the code<p>The author can&#x27;t be serious. This particular bug has made the rounds and is understood even by non-programmers.