Announcement

Collapse
No announcement yet.

Apple slays scary SSL snooping bug in iOS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Apple slays scary SSL snooping bug in iOS

    OS X Mavericks still VULNERABLE, millions at risk of comms hijacking

    By Chris Williams

    Updated Apple has released updates for its mobile operating system iOS to patch a bug that can blow apart the integrity of encrypted connections.

    Versions 7.0.6 and 6.1.6, available now for download, fixes a vulnerability that could allow "an attacker with a privileged network position" to "capture or modify data in sessions protected by SSL/TLS," according to the iPhone maker. This is due to the Secure Transport component of the operating system failing to validate "the authenticity of the connection," suggesting some sort of failure to verify the certificate or identity of whatever system a vulnerable iDevice was connected to.

    In short, users should apply the security update as soon as possible to avoid falling foul of a man-in-the-middle attack: we can imagine a malicious router or Wi-Fi access point exploiting this iOS flaw to silently masquerade as a legit server, and thus intercept and decrypt the private contents of a supposedly secure connection.

    SSL and TLS are used the world over to prevent eavesdroppers from snooping on network traffic to and from sensitive services, such as banking and shopping websites and email servers. But this only works if the other end of the connection can be verified and trusted.

    Apple admits "this issue was addressed by restoring missing validation steps." It reserved CVE-2014-1266 for the bug on January 8 this year, but when and how exactly the flaw was introduced and subsequently discovered is not clear.

    The patch, weighing in between 16MB and 35MB, can be applied to any handheld running iOS 7, and even iPhone 3GSes and fourth-generation iPods running version 6 – a further clue that Apple considers this a very serious bug.

    The next major release, iOS 7.1, is due out in March once developers have finished beta testing it. ®

    Updated to add

    For those wondering how the bug works, the cat has been out of the bag for hours. It appears that when using iOS's Secure Transport component to establish an encrypted connection, the system does not check that the "common name" record (a hostname pattern, such as *.hetzner.de) in the SSL certificate sent by the server matches the hostname used to connect to the server's IP address (eg, www.hetzner.de, which resolves to a server at 213.133.107.227).

    Exactly how one could exploit this knowledge to spy on a victim is not for The Reg to disclose at this time. But we have been able to confirm it is possible to pull off a man-in-the-middle attack by exploiting this particular bug.

    The bad news is that this blunder is also present in Mac OS X 10.9.1, the latest version of Apple's desktop operating system. We're told it's fixed in the 10.9.2 build in beta among third-party developers and is awaiting release.

    The good news is that software not using Cupertino's faulty Secure Transport component are immune to the bug in that they should flag up failed certificate checks. Developers of download tool Curl, a port of which Apple bundles in OS X, spotted the shift to Secure Transport from OpenSSL back in October.

    "Update your Apple devices and systems as soon as possible to the latest available versions. Do not use untrusted networks (especially Wi-Fi) while traveling, until you can update the devices from a trusted network," advises Alex Radocea of computer security tech biz CrowdStrike in a technical briefing about today's SSL vulnerability.

    "On unpatched mobile and laptop devices, set 'Ask to Join Networks' setting to OFF, which will prevent them from showing prompts to connect to untrusted networks."
    The Hackmaster

  • #2
    I TOLD You Gotos Are Dangerous!

    By Mike James

    A recent security flaw in iOS is down to an error involving a spurious goto statement - but when you look a little more closely there is a bigger lesson to learn from the incident - and not just "goto considered harmful".

    Apple relased an update to patch a cryptography flaw a few days ago but didn't say what it was patching.

    Adam Langley, a web encryption expert at Google, did some digging and discovered that it was all about a single extra goto.

    We all know that goto is harmful but surely there is more too it than this?

    [img]/images/stories/News/2014/Feb/B/gotocartoon.gif[/img]
    Click on this Joy of Tech cartoon to see the remaining nine frames..

    Don't misunderstand me; the goto IS harmful, but because it is one of the clearest examples of unstructured coding - the opposite of structured coding.

    A well structured program makes use of statement blocks that fit together like Lego and cannot be misused. OK, in reality that is "less likely to be misused".

    Take a look at the code that caused the problem:

    Code:
    	if((err=SSLHashSHA1.update(&hashCtx,
                          &serverRandom)) != 0)
         goto fail;
    
    	if ((err=SSLHashSHA1.update(&hashCtx, 
                          &signedParams)) != 0)
    
         goto fail;
    
         goto fail;
    
    	if ((err=SSLHashSHA1.final(&hashCtx, 
                          &hashOut)) != 0)
    
    		goto fail;
    
    	[i]...[/i]
    Code:
    fail: deal with error
    Do you see the silly mistake?

    The second if statement is only associated with the first goto fail, despite the indentation (if only this was Python!).

    The correct indentation makes the mistake perfectly clear:

    Code:
    if ((err=SSLHashSHA1.update(&hashCtx,
                          &serverRandom)) != 0) 
        goto fail; 
    if ((err=SSLHashSHA1.update(&hashCtx, 
                          &signedParams)) != 0) 
        goto fail; 
    goto fail; 
    if ((err=SSLHashSHA1.final(&hashCtx, 
                          &hashOut)) != 0) 
    goto fail; 
    ...
    The problem is compounded by the fact that err contains a successful value, even though it has been passed to the error handler to process, and this means the signature verification never fails.

    How did this happen!

    My guess is that the programmer was copy and pasting "goto fail" into the code and just pressed the keys twice.

    What would have stopped this from happening?

    You might at this point want to jump in with "ban the goto" - I know I would, but this isn't really the problem.

    A simple auto-formatting editor would have drawn the problem to the attention of the programmer, even if it didn't protect against it.

    Having the compiler flag dead code also would have detected the problem - neither GCC or Clang in Xcode flag dead code by default.

    Insisting that curly braces are used to delineate code blocks, even if they are only one line long, would have also stopped the problem.

    Perhaps the most wide reaching solution is to simply not use cascaded Ifs with goto used as an exit. The big problem is how to implement this in C/C++ as a structured statement. You can't use a switch because C/C++ only allows constant expressions in each test and hence you can't make the function calls. Not to mention the fact that the C/C++ switch has problems of its own with the need to include the break.

    The best you can do is use nested ifs:

    Code:
    if((err=SSLHashSHA1.update(&hashCtx,
                         &serverRandom))!= 0){
      [i]call error function[/i]
    Code:
    }
    Code:
    else if ((err=SSLHashSHA1.update(&hashCtx, 
                         &signedParams)) != 0 {
     [i]call error function[/i]

    Code:
    } 
    else if ((err=SSLHashSHA1.final(&hashCtx,
    Code:
    &hashOut)) != 0){

    Code:
     [i]call error function[/i]

    Code:
    }
    else {
     [i]process success[/i]
    }
    Is this as clear as it can be?

    I think not.

    The problem is that you want to call the error function just once if any one of the conditions is true and the success code only if all three are false.

    There is also the small matter that the error function has to be a function and can't be part of the same scope as the success code - unless you use a goto of course.

    So is there a better way in C/C++?

    It makes you realize that when it comes to expressing conditional execution we are still primitive.


    Source: joyof tech.com

    Who would have thought a single extra goto could cause so much trouble!

    More Information

    Details Of The Bug

    Related Articles

    Edsger Dijkstra - The Poetry Of Programming

    The Goto, Spaghetti and the Velociraptor

    Android Security Hole More Stupid Error Than Defect
    The Hackmaster

    Comment

    Working...
    X