Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I have downloaded the patch for my iPad mini, yet no such update is appearing for my iphone 5s. Any idea why? Issue in my carrier side?
 
I can't believe how any developer working on such an important module of the system can act this stupid and how this code could even pass the review. wherever software is developed these days, every change to the code is carefully reviewed by another developer using a specialized review software before allowing it to find it's way into the final code.

For those who'd like to know how this bug was introduced:

PHP:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;

Source: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

adding the second "goto fail;" was more or less the only thing changed in that file, leading to "fail" no matter what the result of the if-statement is. for those who don't know about programming: this is a totally obvious mistake every beginner in programmer and especially the reviewer should be aware of. when reviewing changes to the code, you usually see both files side by side, in this case pointing out: "THIS IS THE ONLY LINE THAT CHANGED. PLEASE CHECK IT" and the reviewer should think something like "WTF IS THIS CRAP?".

This is a real shame. I wonder how developer and reviewer explained this to their line managers.
 
Last edited:
Nope, that's the problem. Since SecureTransport is vulnerable and the traffic can be man-in-the-middled, you cannot be sure the App Store is safe.

Well, you can at home, where at least you can be pretty darn sure.

----------

I can't believe how any developer working on such an important module of the system can act this stupid and how this code could even pass the review. wherever software is developed these days, every change to the code is carefully reviewed by another developer using a specialized review software before allowing it to find it's way into the final code.

For those who'd like to know how this bug was introduced:

PHP:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;

Source: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

adding the second "goto fail;" was more or less the only thing changed in that file, leading to "fail" no matter what the result of the if-statement is. for those who don't know about programming: this is a totally obvious mistake every beginner in programmer and especially the reviewer should be aware of. when reviewing changes to the code, you usually see both files side by side, in this case pointing out: "THIS IS THE ONLY LINE THAT CHANGED. PLEASE CHECK IT" and the reviewer should think something like "WTF IS THIS CRAP?".

This is a real shame. I wonder how developer and reviewer explained this to their line managers.

Ooo, thanks for the code snippet (I'm an amateur programmer). That's a really lousy mistake. Also, what's with the "goto" statements? Everyone always told me never to use them, even XKCD.

6C1F5.png
 
Last edited:
VPN as a workaround?

Does anyone know whether having all traffic going through a VPN provides an adequate workaround for this on OS X?
 
I'm a tad confused. What exactly is a "privileged network position"

Also many sites are claiming this is a major security issue and they are dismayed Apple allowed it etc. But what attacks have there been and verified using this issue. First time I've recall hearing about it in mass is when this update came out. I would think if some hacker pulled off an attack using it we'd have heard insane amounts about it

There could not be any massive attacks on Mac computers (say, Target style) in general because nobody stores anything of value on Macs. They are simply not used as servers anywhere to warrant such attention.
 
There could not be any massive attacks on Mac computers (say, Target style) in general because nobody stores anything of value on Macs. They are simply not used as servers anywhere to warrant such attention.

They care about people connecting TO servers. Yes, those people store plenty of valuable information like credit cards, source code, and personal information that could be stolen by man-in-middle attacks.
 
They care about people connecting TO servers. Yes, those people store plenty of valuable information like credit cards, source code, and personal information that could be stolen by man-in-middle attacks.
Too small of a catch on the client side, so while certainly doable it's often just not worth the hassle. That's not to say it doesn't happen, just that it wouldn't be anything close to massive generally speaking.
 
when are they going to fix this?

The fact that Apple made iOS it's first priority is very revealing, they could have made it their highest priority to fix both iOS & OS X concurrently.

Furthermore, it reveals how sloppy they're getting. It should have been caught before it was shipped. One minute they patronize the masses, boasting how much they care about their customers, then they pull a stunt like this.

Microsoft wouldn't allow this to go ignored as long as Apple has.

Here's more:
http://www.zdnet.com/apple-and-the-ssltls-bug-open-questions-7000026628/
 
READ: Introduced in 10.9. I tested my Safari (running 10.8.5), and it's fine. Yet another Mavericks bug :rolleyes: I'll go laugh at my friend who thinks that Mavericks was a worthwhile upgrade.

In general it is worth the upgrade, I find Mavericks to work better on my old hardware. Sure there are specific issues that suck, but there are less of them than in the previous release.
 
Security flaws don't matter unless someone who would exploit them knows about them. Look, SHA2 is vulnerable too! I mean, if someone can figure out how to crack it. It hasn't been mathematically proven to be safe.
Very few operating systems are proven to be correct and one of any reasonable size is almost certain to have vulnerabilities.
Anyway, you'll run into fewer bugs and vulnerabilities if you use the most recent revision of the second most recent Mac OS X rather than the latest version there is. I don't know why I impulsively updated to 10.9.0 when it first came out, but that was a serious mistake.

Give me a break that is about the worst advice I've seen in this thread. Apple may have screwed up with this bug but they have also addressed many issues in Mavericks.
 
So now we know the test plans for iOS and OS X don't include checking the SSL code to ensure it actually works.

I hope Tim Cook rips the appropriate people a new one!

Yes, I'm sure life's just as simple as you paint it.

By the way, Tim Cook is not a Test Engineer. His function is to act as an official mouthpiece.
 
I can't believe how any developer working on such an important module of the system can act this stupid and how this code could even pass the review. wherever software is developed these days, every change to the code is carefully reviewed by another developer using a specialized review software before allowing it to find it's way into the final code.

For those who'd like to know how this bug was introduced:

PHP:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
  goto fail;
  goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
  goto fail;

Source: http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

adding the second "goto fail;" was more or less the only thing changed in that file, leading to "fail" no matter what the result of the if-statement is. for those who don't know about programming: this is a totally obvious mistake every beginner in programmer and especially the reviewer should be aware of. when reviewing changes to the code, you usually see both files side by side, in this case pointing out: "THIS IS THE ONLY LINE THAT CHANGED. PLEASE CHECK IT" and the reviewer should think something like "WTF IS THIS CRAP?".

This is a real shame. I wonder how developer and reviewer explained this to their line managers.

Its obviousness and clumsiness tends to support the theory that Gruber talks about today (Daring Fireball) that it was deliberately introduced for spying purposes. I'm surprised no one here thought of it, or refers to it anyway.
 
Its obviousness and clumsiness tends to support the theory that Gruber talks about today (Daring Fireball) that it was deliberately introduced for spying purposes. I'm surprised no one here thought of it, or refers to it anyway.
Somtimes in reality things are just much simpler than that.
 
Mountain Lion doesn't appear to have this bug.

I wonder about Lion. There are 2 Mac Pros in my enterprise environment that only run Lion and other macs that are still running snow leopard but it's a primarily a windows environment. The macs are for graphics and video productions.
 
Interesting!! Guess me not using wifi other than my own secure home network is a good thing. I can't be bothered logging onto a wifi network everywhere I go. LTE all the way with wifi shut off, works for me. :D
 
Can someone explain this bug in detail and why is it important to the average user please? It seems big enough where Apple had to update iOS 6 for the 3GS as well.

If you use wifi networks outside of your home...( I use a hospital network when I'm there) you could be open to attack.

It's probably more likely to occur in city centre hot spots..cafe's and the like.
 
I wonder about Lion. There are 2 Mac Pros in my enterprise environment that only run Lion and other macs that are still running snow leopard but it's a primarily a windows environment. The macs are for graphics and video productions.

From what I can tell, Lion and earlier doesn't appear to even have the function that is affected, and in Mountain Lion the error isn't there, so it seems like it's only in Mavericks. But you should also be able to confirm it with the test in this link provided by Adam Langley who covered this.

https://www.imperialviolet.org:1266/

This should return an error and refuse to load the page.
 
Yes, I'm sure life's just as simple as you paint it.



By the way, Tim Cook is not a Test Engineer. His function is to act as an official mouthpiece.


Yes we get it. There's always an excuse for the bugs that shipped in iOS 7 and OS X Mavericks. Unfortunately this one is a biggie that didn't get caught for more than one year of "testing". I never suggested in the slightest that Tim Cook is a test engineer. As the technology industry has just watched Apple do a major face plant, you can bet Tim Cook isn't just sitting by without having his say and holding people accountable to ensure this embarrassing situation doesn't repeat itself anytime soon.

-ITG
 
I'm a tad confused. What exactly is a "privileged network position"

It means you need to have control of a router, or some way to redirect requests to your own server (e.g. rerouting DNS). Simply sniffing packets on a wifi network, for example, would not be a way to exploit this.
 
Yes we get it. There's always an excuse for the bugs that shipped in iOS 7 and OS X Mavericks. Unfortunately this one is a biggie that didn't get caught for more than one year of "testing". I never suggested in the slightest that Tim Cook is a test engineer. As the technology industry has just watched Apple do a major face plant, you can bet Tim Cook isn't just sitting by without having his say and holding people accountable to ensure this embarrassing situation doesn't repeat itself anytime soon.

-ITG
Stuff like this happens all the time to big and small companies and most of them and the rest of world keep on going just like before.
 
All OSX versions compromised

Please, be careful out there, as all current OSX versions (10.6-10.9) seem to be affected by this bug:

https://threatpost.com/apple-ssl-vulnerability-affects-osx-too/104434

You can test yourself, whether you are vulnerable calling this site in Safari:

https://www.imperialviolet.org:1266/

For the time being it is recommended to use Firefox or Chrome, which utilize their own SSL routines, and not doing any SSL related traffic when on public networks like WIFI hotspots, universities etc.pp. except maybe when you can connect through a trusted VPN.
 
I spent an hour or two after dinner researching this bug, and I'm astounded at how a single redundant line of code can render the entire authentication system open to attack.

This should have been easy to spot. Someone stepping through the code would have realized what would happen: that the Certificate would never be checked.

What I'd like to know now is whether anyone suffered monetary loss because of a criminal using this exploit. Or if governments used it to spy on people.

An hour or two?? Its not that complex a bug!

Governments used it to spy on people? You obviously didn't understand the bug too well after reading it for one or two hours! It would happen only on a local network, a network that you share with someone else.

I hate to break it to you, but the government is already spying on you heavily with pretty much every thing you do online.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.