Serious vulnerability found in SSL/TLS on OS X Mavericks and iOS, easily exploitable [Update]

Apple has been working hard to get its products into the enterprise but a new security vulnerability is about to put a black eye on their reputation. Sure, we know that many companies have security related issues but it’s the fact of the obvious oversight of this issue that will raise alarm bells.

On Friday, Apple revealed a significant bug in their SSL/TLS implementation:

Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS

Description: Secure Transport failed to validate the authenticity of the connection. This issue was addressed by restoring missing validation steps.

Based on the report, it seems that Apple didn't include (proper) hostname verification for any iOS <7.0.6. See below for updated details.

Matthew D. Green, Assistant Research Professor at the Johns Hopkins Information Security Institute, notes that this is "seriously exploitable."

Aside from iOS, we noted that this also seems to be present in OS X Mavericks, however it seems to be only affecting SSL connections over IP addresses rather than domains. While this does lessen the extent of the vulnerability, it's still a glaring issue into the security of the platform, and there may be a way to bypass this restriction.

An example of the issue can be demonstrated with the following commands in terminal: 
curl would fail, however curl would be successful.

OSX Mavericks: SSL directly over IP is not being validated

If this is in fact the case, then this is a fairly significant security issue for all machines running OSX Mavericks, even if it is only affecting IP addresses and not domains. Many apps reference IP addresses directly, so this is a fairly problematic issue, and there is more than likely a method to get around the limitation.

Adam Langely, security researcher and part of Google's security team, notes that this is affects Safari on both iOS and OSX, and that it breaks SSL completely.

We expect that Apple will address this issue in short order but the fact that they occurred in the first place, is more alarming. With enterprise security (and consumer security) always a highly sensitive subject, such a simple oversight here could lead to profound implications if properly exploited.

UPDATE: Upon review of the SSL implementation, it seems that the function SSLVerifySignedServerKeyExchange was declaring that there was no error before the verification even took place.

As Adam Langely explains:

Note the two goto fail lines in a row. The first one is correctly bound to the if statement but the second, despite the indentation, isn't conditional at all. The code will always jump to the end from that second goto, err will contain a successful value because the SHA1 update operation was successful and so the signature verification will never fail.

Source: Apple | Security image via Shutterstock


Report a problem with article
Previous Story

Microsoft slashes Windows 8.1 pricing 70% to make way for cheaper devices

Next Story

Bing Maps Preview app for Windows 8.1 adds 15 new 3D cities


Commenting is disabled on this article.

0sit0 said,
said you, really.. because Apple said they don't have Windows viruses or spyware .

yes because they are not compatible ... they have OS X malwares ... less then windows just because they have very low market share

"Serious vulnerability found in SSL/TLS on OS X Mavericks and iOS, **easily exploitable**"

"Impact: An attacker with a **privileged network position** may capture or modify data in sessions protected by SSL/TLS"

No, its is not easily exploitable since it requires a man in the middle between your SSL connection.
Right now, exists the next "man in the middle" that can sniff your connection (excluding NSA that holds all the keys)
-Proxy = if you connect to an unsafe proxy.
-LAN = only if the system uses HUB instead of switch.
-WIFI = only if you are connected to an open connection.

Wow, goto statements.
Wrap that block of code in a function and return false on error, or at the very least don't use 'err' as the flag indicating success or failure for the entire block.

"despite the indentation, isn't conditional at all"

People bitch about python's indentation all the time, but at times like this it is a clear win.

pratnala said,
Write an OS in Python?

No, create a variation of C/C++ that uses indentation to define a block instead of curly braces.

Overkill. Following proper, consistent coding standards for quality production code like always blocking (braces) a single statement is the fix.

This is a joke. Apple knew about this in 2011. I know i disclosed this to them when i discover the issue while attempting to secure Apple devices for use at high security center. I found even more then just this, I was able to import any certificate into the system, change the uses and then export them and the certificates were about to be passed off as valid. Apple was pissed and my 'employer' quietly drop their massive order for Apple products. This is only the tip of the iceberg. Apple OSX is incapable of using following basic fundamentals with certificates, and until they correct this MAC OSX is doomed. On MAC OS X, you can install any certificate for any machine, change the uses for said certificate, modify the certificate and re-export, 'seal' the certificate, and steal others email certs and use them. At some point they need to fix they and they are claiming these issues are just minor things.

The issue you're describing here isn't the same as the issue being discussed in the article. Indeed, Mac OS releases before 10.9 aren't vulnerable to the article's issue, and since 10.9 was only released a few months ago, your 2011 timeframe simply doesn't fit.

iOS 7.0.6 is already out for this. Must've been a big one. Unusual for Apple to release an emergency fix to the OS for a single issue.

win2000b said,
Many apps reference IP addresses directly.

Like? Most apps use names surely so they can redirect if needed.

Agreed, the apps that do make a connection to an IP address must be as badly written as those apps in the Windows world that hardcode paths etc.

Mr Nom Nom's said,

Agreed, the apps that do make a connection to an IP address must be as badly written as those apps in the Windows world that hardcode paths etc.


In a license server + client I developed, I use an IP address directly after having resolved the address via DNS. The connection is established via direct IP although a domain name may or may not have been used. This has nothing to do with hard coding anything.

Why on earth would you do that? IT leaves you wide open to a DNS injection attack.

Think about it. Your app resolves the FQDN and gets the wrong host. That host then validates it's own IP instead of the FQDN.

Suggest you rewrite this code right away.

I mostly disagree. While that's a valid security concern, you should be implementing certificate pinning anyway. It would protect against DNS injection attacks, as well as many others.

One of the most annoying thing is Apple's insistence of remanning with an older version of openssl (0.9.8) rather than adopting 1.0.0 which has been out for quite some time - as far as I see it thought it appears that the problem isn't just isolated to OS X or iOS assuming the fault is a shared open source component which is present in a number of projects.