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.
Maybe, in this case, "it's not a bug, it's a feature" is actually true? ;)
Be sure to note this is yet another security leak on Trump's watch.
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
Much of this happens due to shoddy programming practices and marketing's rush to get untested stuff into production.
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.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
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.
...we need to just drop using drop as a synonym for "released."
Never let a lack of data get in the way of a good rant.
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.
If a company does not cooperate (collaborate) with the US spooks . . . the CEO wakes up with a bloody horse head in bed.
That's absurd.
The SEC opens an investigation.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
Weird how, as a user, when you try to look up three passwords in a row, you need to enter your password three times. But when a rogue app asks for it, it can just get the whole decrypted database without needing a password? Pretty bad design fail, there's something seriously wrong at the very core of keychain.
It is normal for certain apps to have access to the keychain without requiring a password. For example, when Safari autofills a website login. But they are only supposed to have access to whatever they stored there themselves, or require explicit user consent. I suppose that's where they messed up.
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
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.
Apple's security is not only totally unimpressive here, Apple has a horrible track record as well. Wardle was quoted as saying he's "continually disappointed in the security of macOS...", "...every time I look at macOS the wrong way something falls over", and "Apple marketing has done a great job convincing people that macOS is secure, and I think that this is rather irresponsible and leads to issues where Mac users are overconfident and thus more vulnerable". I don't know precisely what Wardle was referring to to draw that conclusion. Perhaps he is referring to the time Apple chose to leave a 3-year old remotely exploitable iTunes bug unfixed after being informed about the problem. As Richard Stallman pointed out, "During that time, governments used that security hole to invade people's computers.".
But the worst part is that the software in question is proprietary (in other words, it's user-subjugating and non-free). So even technical users who are motivated to fix this, capable of fixing the problem, and willing to help others by distributing copies of their fix to other MacOS users in an easy-to-install package are rendered helpless. Such technically-inclined and helpful users can't help themselves or their community. They can either switch to a free system where their software freedom is respected or wait for Apple to fix the problem. And as the article says, "Apple did not say if or when it will patch the bug.".
Digital Citizen