Slashdot Mirror
Apple Releases macOS High Sierra; Ex-NSA Hacker Publishes Zero-Day
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.
Nice quote. Stay on topic, please.
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?
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
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.
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.
#DeleteChrome
will no doubt be called 'Death Valley' to cover the lowest elevation in California, followed by Mt Whitney..
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.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
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...
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.
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).
I am TheRaven on Soylent News