Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Actually it's because of an if Statement where they didn't use brackets, and thus screwed up. This is the actual code that is wrong:

Code:
 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
The extra goto fail was added in for some reason and because they didn't use brackets, the goto fail always jumped to the fail area.


Edit: You can see the code here
http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c?txt

O.O - I'm shocked. There are so many problems with that code, I would fire both the person who wrote it and the person who reviewed it.
 
O.O - I'm shocked. There are so many problems with that code, I would fire both the person who wrote it and the person who reviewed it.
Spoilers: They have no unit testing in place either. You could get someone barely familiar with programming to do that (its taught to first years in Uni), and unit tests will normally be mandatory for regression testing at least core functionality.

And for mission critical code, which is what all security code is - the absence is disastrous. Its so severe that whomever made the mistake may be permanently marked as unfit for security based code for the rest of his career. This isn't uncommon when a programmer demonstrates fundamental lack of understanding of basic security design.

This isn't an elaborate or sneaky bug. Its an incredibly basic one, where standard behaviour doesn't work. Its like making a calculator that sums 2 numbers always returning an answer of 0.

The fact that there were no tools in place to detect Unreachable Code is also highly questionable. Note that Visual Studio and Eclipse for example will immediately notify you of this. GCC and Clang can also do it, but requires specific flags to be set.

Heck, any software that does indentation for you would also make it clear that there was something wrong, because it would place the second erroneous line at the same level as the if statements.

Not to perform these checks for sensitive code which really should not fail (especially on such a basic feature) is mind boggling. Kernel and Security code are the two most important things you can ever write.

It also makes me wonder where the hell peer review was. Thats another baseline component of any decent security based code. After which you really should not need to change it for years, and preferably never.

A final thought to really worry about though. This error was introduced in 2012 (though it didn't make it into OSX until 2013); if they missed something this trivial, what else have they missed?
 
Last edited:
Beyond the error, is there anything but missing braces.

Nope. technically that is the only line that broke everything. I'm going to guess that it was probably a merge conflict and it just got duplicated (or if you put on your tin hat.... someone injected it on purpose).

As 'crappy' as the code is, it worked fine until that commit, which I think was updated in the past 1-2 years.

Edit: The diff between 10.8.5 and 10.9 had the extra goto statement. Thus, all macs on MLion are actually not affected by this bug.... only mavericks.
 
Last edited:
Nope. technically that is the only line that broke everything. I'm going to guess that it was probably a merge conflict and it just got duplicated (or if you put on your tin hat.... someone injected it on purpose).

As 'crappy' as the code is, it worked fine until that commit, which I think was updated in the past 1-2 years.

I know. My point was, beyond the brace-less clause, there doesn't seem to be anything that is out of the ordinary.
 
I think the issue was these apps all use the same SSL certs and now that is all fixed.

A serious question. Is the true threat as serious as some are making it? Wouldn't the "evil-doer" need to be on the same wifi network?

When you have a cryptology expert say that it's, "as bad as you could imagine, that's all I can say." Yes it's serious.
 
Spoilers: They have no unit testing in place either. You could get someone barely familiar with programming to do that (its taught to first years in Uni), and unit tests will normally be mandatory for regression testing at least core functionality.

Adam Langely said:
A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes. In Chromium we have a patched version of TLSLite to do this sort of thing but I cannot recall that we have a test case for exactly this. (Sounds like I know what my Monday morning involves if not.)

https://www.imperialviolet.org/2014/02/22/applebug.html

Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world. - See more at: http://www.rsaconference.com/speakers/adam-langley#sthash.DEVFCJfY.dpuf
 
So are Apple going to block all these vulnerable apps from running until a fix is available? Or us that kind of calling-out just reserved for Flash.

They'd have to block every native app that relies on TLS so it would kind of cripple your iphone.
 
Well, the fix for this was already released before the weekend for iOS.
His point is that this has absolutely nothing to do with Apps. But it affects apps because they are reliant on Apple's API to perform the validation.

Thus when Apple broke it, the apps were broken. Once Apple fixed(IOS)/fixes it, the apps are healed. No patch or change in the apps themselves involved.

'Blocking' would involve essentially disabling HTTPS in the browser, mail clients, IM clients, and lot of background utilities and services. So forget banking, Facebook, logging onto work, or anything of the like. You're essentially asking the machines to be bricked.

Those blocks would also need to include the update service.
 
If Apple (and all companies) don't work with independent, third party security firms, this is one reason why they should. Increasingly we are putting our most private information in the cloud and transmitting it daily. Apple needs to step up and have their systems/software tested/hacked by firms which they hire so these issues can be found out before mass release. Some of the stuff that has gotten by Apple in the past was pretty crazy how it wasn't caught. Some stuff has little impact in day to day use. This one is big however.

What one man makes another man given the time and wherewithal, can find a way around or through it.That's the nature of the beast. The best we can hope is that manufacturers can stay a step ahead of the offenders.
 
His point is that this has absolutely nothing to do with Apps. But it affects apps because they are reliant on Apple's API to perform the validation.

I know that's what he meant!

My point was that the patch is already out, so why not update it instead? The comment about blocking applications referred to OS X since there is no patch out yet.
 
Spoilers: They have no unit testing in place either. You could get someone barely familiar with programming to do that (its taught to first years in Uni), and unit tests will normally be mandatory for regression testing at least core functionality.

And for mission critical code, which is what all security code is - the absence is disastrous. Its so severe that whomever made the mistake may be permanently marked as unfit for security based code for the rest of his career. This isn't uncommon when a programmer demonstrates fundamental lack of understanding of basic security design.
It might be that this code was not targeted by unit tests for reasons outlined here: https://www.imperialviolet.org/2014/02/22/applebug.html

A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes. In Chromium we have a patched version of TLSLite to do this sort of thing but I cannot recall that we have a test case for exactly this. (Sounds like I know what my Monday morning involves if not.)

However, unless I'm wrong, this basic bug would be caught by static code analysis which they should indeed run, especially for security related code.

Also, they should maybe consider start using braces even if there is a single line of code.
 
Which is a terrible idea, as you're virtually asking for every machine running 10.9 to be bricked.

So what? I didn't make a comment that aimed to give a grade to the idea!

Just saying that the original comment was referring to OS X, while the comment I responded to mentioned iPhones. Mkay? ok.
 
I'm not worried about my government spying on me and if it stops the next 911 I'm all for it.

That's funny! You actually think that 9/11 would not have happened if you were all being spied on at the time? And you also think they can prevent something silimar happening again? Wake up man. Your government knew it was going to happen and they turned a blind eye, for various reasons!

They don't give a rats ass about 'the people'.
 
Beyond the error, is there anything but missing braces.

I was alluding to the fact that they used a goto at all, but I'm now wondering if maybe this is a second legitimate use case for a goto...

----------

Spoilers: They have no unit testing in place either. You could get someone barely familiar with programming to do that (its taught to first years in Uni), and unit tests will normally be mandatory for regression testing at least core functionality.

Although I agree with most of your post, I'd like to mention that in my Computer Engineering Bachelor's program, which I'm wrapping up in 2 months, I was never taught unit testing in any of my classes. I learned it independently and have discussed it with the head of the department that we really need to be teaching Unit Testing, Source Control, Code Review, and Pair Programming. The Computer Science department at my school (which I've taken a few classes within as electives,) covers Unit Testing but fails to teach the other things I mentioned.
 
Although I agree with most of your post, I'd like to mention that in my Computer Engineering Bachelor's program, which I'm wrapping up in 2 months, I was never taught unit testing in any of my classes.
Curious, and noted.
 
I was alluding to the fact that they used a goto at all, but I'm now wondering if maybe this is a second legitimate use case for a goto...

It's common for error handling in C when you need to clean up resources and return. You'll find it in many large projects, Linux kernel and the like.
 
That's funny! You actually think that 9/11 would not have happened if you were all being spied on at the time? And you also think they can prevent something silimar happening again? Wake up man. Your government knew it was going to happen and they turned a blind eye, for various reasons!

They don't give a rats ass about 'the people'.

I totally agree they knew and no it would not have stopped 911. I hate politics so I'm not even gonna argue about it, my point was spying is gonna happen across all governments it's reality. I don't do anything out of the ordinary so I don't care go ahead spy on me.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.