• Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.

Major security flaw in iOS and OSX, be sure to update to iOS 7.0.6 ASAP

Status
Not open for further replies.

PFD

Member
Apple released a new iOS update yesterday. Initially, it seemed like a very minor update, and the change log was very brief:

This security update provides a fix for SSL connection verification.

It turns out, this update fixes a major security flaw in the operating system that exists on both iOS and OSX. Apple promised a fix soon for OSX.

Here's what Pod2G (security researcher/major contributor to iOS jailbreaks) had to say about this (read from top to bottom):

pod2g0ou0i.jpg


Here's a technical write-up of why this is bad, linked to by Pod2G
 

IceCold

Member
So stupid...how could that bug go unnoticed for so long. Nobody does tcp dumps there? This is why it's always a good idea to use curly braces with if-statements no matter what.
 

BocoDragon

or, How I Learned to Stop Worrying and Realize This Assgrab is Delicious
Can 7.0.6 still be jailbroken?

I actually value my jailbreak more than security lol.
 

BocoDragon

or, How I Learned to Stop Worrying and Realize This Assgrab is Delicious
word. anyone know?

It's sad but this is also the first thing I thought of. My bank actually sent me an e-mail about this, though...

Looks like it's fine.

MuscleNerd on Twitter said:
Apple didn’t apply even 1 update that would’ve broken evasi0n7 at 7.0.6 (i.e. they let JBers have the SSL fix too). Thanks, Apple! :)

https://twitter.com/MuscleNerd

I'm guessing Apple knows it's a dumb idea to fix their own major flaw and at the same time discourage jailbreakers from doing so.
 

Sayter

Member
Shit. My iP4 can barely handle iOS 6. I wasn't planning on upgrading until the iPhone 6 and iOS 8 came out later this year.
 

Cerity

Member
Guess I won't be doing all that much important stuff on the 3gs that I'm using while my ZU gets repaired then.
 
Interesting, so the theory here is that the NSA would have discovered the bug and that was when they got added to the prism list?

Yes. Depending on how far down the rabbit hole you want to go:

1. NSA have not exploited the flaw.
2. NSA found the flaw and exploited it.
3. NSA had a mole at Apple that purposely put in the flaw.
4. Apple consciously put in the flaw for the NSA.
 

GaimeGuy

Volunteer Deputy Campaign Director, Obama for America '16
Wait this was because someone wrote goto fail twice?

The first goto fail runs only if the update method returns something other than 0 (which I assume indicates an error).

the second goto always runs.

Basically the code in the rectangle reads like this:

Step 1: If failure condition, goto failure code.
Step 2: Goto failure code.

the code in that screen outside and inside the rectangle essentially verifies that the data, client, and server are all SSL-compliant (I assume). But stuck inside that sequence of verifying each aspect is a random "Execute failure code" instruction that will ALWAYS run if the SSL checks up to that point have been valid.
 

GaimeGuy

Volunteer Deputy Campaign Director, Obama for America '16
What I want to know is why Apple is automatically sending data unencrypted if the SSL connection fails? Shouldn't they be alerting the user instead and asking them if they want to still send the data without SSL?

Seems like a combination of both bad code and a terrible design for security purposes.
 

Iolo

Member
What I want to know is why Apple is automatically sending data unencrypted if the SSL connection fails? Shouldn't they be alerting the user instead and asking them if they want to still send the data?

Seems like a combination of both bad code and a terrible design for security purposes.

That's the bug, some security checks are bypassed, so a bad connection looks like a good one to the application.
 

GaimeGuy

Volunteer Deputy Campaign Director, Obama for America '16
That's the bug, some security checks are bypassed, so a bad connection looks like a good one to the application.

Well at least the picture is wrong (or at least, not completely accurate in depicting the problem).

For those of you who don't speak code:

Problem #1: The encrypted connection always fails (pictured).
Problems 2 through 5000000000000000000: When an encrypetd connection fails, the system automatically falls back to an unencrypted transmission.
 

Iolo

Member
OSX too? No fix yet?

*breathing intensifies*

You can mitigate it for web browsing by using Firefox or Chrome, which are not vulnerable. Check https://gotofail.com to see whether your browser is ok. If you are totally paranoid you should use a browser that was already installed instead of downloading a new one over an insecure Safari connection (although the risk is slight). You could use Chrome on iOS as well, in case you can't upgrade your OS, for example if you don't want to cripple your iPad 3 or iPhone 4 with iOS 7.

This does not help the security of other SSL connections like iCloud or the App Store, although I think app and OS updates are digitally signed which provides an additional layer of protection.
 

GaimeGuy

Volunteer Deputy Campaign Director, Obama for America '16
Is this just for Safari? If I use Chrome exclusively on iOS and Mavericks am I solid?

This is from system library code that handles SSL verification from the sounds of it. anything that doesn't utilize its own implementation for Secure Socket Layers (basically every program that connects to the internet and every web browser save for Google Chrome) is vulnerable to sending secure data over an unencrypted channel on Apple devices
 

Iolo

Member
Well at least the picture is wrong (or at least, not completely accurate in depicting the problem).

For those of you who don't speak code:

Problem #1: The encrypted connection always fails (pictured).
Problems 2 through 5000000000000000000: When an encrypetd connection fails, the system automatically falls back to an unencrypted transmission.

Not exactly. You could rename "goto fail" to "goto exit" to remove the confusion; the problem occurs when that block is called with an error code of zero (which is what the second goto does). In other words, when fail is called when there is no failure, it succeeds, bypassing further checks.

Apple's real fail here is not asserting that err is non-zero in the fail block, which would ensure fail is only called on error (and otherwise warn or crash), and would have caught the problem at virtually no cost.
 

BocoDragon

or, How I Learned to Stop Worrying and Realize This Assgrab is Delicious
Is this just for Safari? If I use Chrome exclusively on iOS and Mavericks am I solid?

Chrome on iOS still uses the safari engine, as I understand it (as all iOS browsers are required to). I bet it has the same flaw.....
 

Iolo

Member
Chrome on iOS still uses the safari engine, as I understand it (as all iOS browsers are required to). I bet it has the same flaw.....

Chrome did not exhibit the flaw when I tested it on my iPad with iOS 6. The Mercury browser, on the other hand, is vulnerable.
 
Status
Not open for further replies.
Top Bottom