if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
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.
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.
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.
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.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.
when are they going to fix this?
READ: Introduced in 10.9. I tested my Safari (running 10.8.5), and it's fine. Yet another Mavericks bugI'll go laugh at my friend who thinks that Mavericks was a worthwhile upgrade.
Very few operating systems are proven to be correct and one of any reasonable size is almost certain to have vulnerabilities.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.
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.
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!
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.
Somtimes in reality things are just much simpler than that.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.
Mountain Lion doesn't appear to have this bug.
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.
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.
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'm a tad confused. What exactly is a "privileged network position"
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.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 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.