Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Desktops (Apple) Portables (Apple) Security iMac Apple Technology

Apple Releases macOS High Sierra; Ex-NSA Hacker Publishes Zero-Day 53

Posted by msmash from the here-we-are dept.
Apple today released the newest version of its operating system for Macs, macOS High Sierra, to the public. macOS High Sierra is a free download, and offers a range of new features and improvements including the new Apple File System, and support for High Efficiency Video Encoding (HEVC) for better compression without loss of quality, and HEIF for smaller photo sizes. Zack Whittaker, reporting for ZDNet: Patrick Wardle, a former NSA hacker who now serves as chief security researcher at -- Synack, posted a video of the hack -- a password exfiltration exploit -- in action. Passwords are stored in the Mac's Keychain, which typically requires a master login password to access the vault. But Wardle has shown that the vulnerability allows an attacker to grab and steal every password in plain-text using an unsigned app downloaded from the internet, without needing that password.
This discussion has been archived. No new comments can be posted.

Apple Releases macOS High Sierra; Ex-NSA Hacker Publishes Zero-Day More

Apple Releases macOS High Sierra; Ex-NSA Hacker Publishes Zero-Day

Comments Filter:

  • WTF (Score:2, Insightful)

    by Anonymous Coward
    Nice quote. Stay on topic, please.

  • Let's retire 'drop' (Score:5, Insightful)

    by RightwingNutjob ( 1302813 ) on Monday September 25, 2017 @02:28PM (#55261483)
    It's ambiguous and sometimes can mean the exact opposite of the intended message, especially when used in short click-baity headlines. How about 'publishes,' 'releases,' or 'exposes' here?

  • It seems inevitable that security holes will be in modern systems. We can argue about the why, or how this system is better than that system. But there is seemingly no end to vulnerabilities simply because of the complexities of modern systems. Too many variables, and it only takes one hole in the fence for the raptors to get through.

    • Re: That didn't take long (Score:2, Insightful)

      by Anonymous Coward

      You should continue posting this into the windows and Android threads too.

      That said, how the hell do you access an encrypted storage area without the key? This sounds like a major fail in design and not a "bug" in the usual sense

      • Maybe, in this case, "it's not a bug, it's a feature" is actually true? ;)

      • That said, how the hell do you access an encrypted storage area without the key?

        . . . oh . . . with the right National Security Letter . . . you would be surprised at what all you can access, with the friendly help of the company that produced the device.

        If a company does not cooperate (collaborate) with the US spooks . . . the CEO wakes up with a bloody horse head in bed.

        So if the spooks have ways of accessing "inaccessible" stuff . . . it will eventually get leaked, and someone else can do it, as well.

      • Re: That didn't take long (Score:4, Informative)

        by TheRaven64 ( 641858 ) on Tuesday September 26, 2017 @04:53AM (#55264855) Journal

        That said, how the hell do you access an encrypted storage area without the key? This sounds like a major fail in design and not a "bug" in the usual sense

        The keychain is a separate process. It decrypts your passwords on login and stores them in wired memory with a few flags on the binary that ensure that the OS won't let you attach debuggers and so on to exfiltrate the passwords and keys. It then uses Mach ports to communicate with other processes. The OS adds security headers to the Mach messages (extended versions of the ones that CMU Mach added) that allow the keychain daemon to identify the UID and the binaries of the application that's communicating with it. This also includes the OS-validated signatures of the application binary and all linked binaries. The Keychain daemon maintains an ACL internally that restricts access to the specific entries to specific programs.

        I don't know the details of this attack, but there are a number of possibilities. The Mach IPC model doesn't fit very well with the UNIX fork/exec model (neither does the BeOS Binder used in Android) and is a likely source of vulnerabilities. There are a lot of potential confused deputy attacks that might work on this - tricking the keychain daemon into thinking it's talking to something like the Keychain Access app that is allowed to access all keychain entries.

        It's also possible, though less likely, that he's found a way of spoofing the security headers on the Mach messages. I say this is less likely for two reasons: it would probably require a kernel-level exploit and it would also give a lot more access to everything (including a way of bypassing the sandboxing mechanisms and so on).

        The Keychain API has quite a few issues with regard to security usability, but the biggest one is that it allows client applications to provide the keychain password, rather than requiring that the keychain daemon (or some other trusted process) prompt. This means that anyone who captures the login password can get complete access to the keychain, but also means that users can be trained to expect untrusted applications to ask for a password that grants them root access (it's the same password that sudo accepts, for example). Microsoft is a lot better about this, with UAC prompts always being given by the OS and using the control-alt-delete sequence to validate that they're real. Apple doesn't have anything like this - there's no way that the user can tell that a password prompt box is from the application that they think it is (and is going to be used in the way that they think).

    • Much of this happens due to shoddy programming practices and marketing's rush to get untested stuff into production.

    • it only takes one hole in the fence

      That's why we need a wall, and we need the hackers to pay for it!

      Sorry, couldn't resist. Carry on.

    • It seems inevitable that security holes will be in modern systems. We can argue about the why, or how this system is better than that system. But there is seemingly no end to vulnerabilities simply because of the complexities of modern systems. Too many variables, and it only takes one hole in the fence for the raptors to get through.

      Equifax Argentina was hacked by using a very old UNIX method, Admin, Admin
      http://www.bbc.com/news/techno... [bbc.com]

      But I do agree with you. The way I see it now, nobody is safe from being hacked and this on a personal level. I've come to trust the users online on my system more than any other way. If more than one, well we'll see.

  • Lets be clear this affects older OS X as well (Score:5, Informative)

    by Anonymous Coward on Monday September 25, 2017 @02:43PM (#55261605)

    This hack affects High Sierra as well as older versions according to the article. The title of this implies that this is specifically something related only to the new OS.

  • "ON TRUMP'S WATCH" (Score:1, Funny)

    by Anonymous Coward

    Be sure to note this is yet another security leak on Trump's watch.

  • Big security flaw that needs to be fixed (Score:5, Informative)

    by 93 Escort Wagon ( 326346 ) on Monday September 25, 2017 @02:54PM (#55261691)

    However the user does need to download and run the app - so the current iteration isn't problematic (nor is it intended to be). And, since it's unsigned, I'm assuming it won't work for most users by default - unless, like me, you change that setting.

    I'm certain we'll see this weapon used soon enough, though... and we regularly do see users get manipulated into running things they shouldn't, even when lots of warning boxes pop up along the way. Plus it's always possible there's another way to exploit the flaw which doesn't have to run under the specific user's account.

    • different attack vector (Score:2, Informative)

      by Anonymous Coward

      This flaw can be exploited by hackers to hide a malicious code in one of the popular macOS app. All they need is to find a few careless developers with poor security. Or to even buy a cheap but popular app.

    • the user does need to download and run the app [...] And, since it's unsigned, I'm assuming it won't work for most users by default

      No on both counts—the app demonstrated in the movie is for proof of existence. The relevant code could exist in any application, even apps MacOS users already have and have been using (since this security flaw is old and also affects earlier variants of MacOS). In other words, sensitive data could have already been uploaded somewhere including changes to those credentials.

  • will no doubt be called 'Death Valley' to cover the lowest elevation in California, followed by Mt Whitney..

  • Seems like the zero-day isn't High Sierra specific, seems kinda odd to tack this on to a headline regarding today's release.

  • Looking to boost their market share clearly. On /. we have people that know the difference between zero-day and user must download malware and do whatever the malware asks you to do to enable the exploit. Also, in a bonus of unlikelihood the app is unsigned.

Slashdot Top Deals

Garbage In -- Gospel Out.

Close