macOS Exploit Published on the Last Day of 2017 (bleepingcomputer.com)
An anonymous reader shares a report: On the last day of 2017, a security researcher going online by the pseudonym of Siguza published details about a macOS vulnerability affecting all Mac operating system versions released since 2002, and possibly earlier. Siguza did not notify Apple in advance, so at the time of writing, there is no fix for this flaw. Despite the doom and gloom, the vulnerability is only a local privilege escalation (LPE) flaw that can only be exploited with local access to a computer or after an attacker has already got a foothold on a machine. The vulnerability grants root access to an attacker. The issue affects the IOHIDFamily macOS kernel driver, a component that handles various types of user interactions. Siguza said he read about various flaws in this component and took a look at it to find new ways to compromise iOS, Apple's mobile operating system, where IOHIDFamily is also deployed. The expert says he found the LPE flaw in the IOHIDFamily code specific to macOS versions only. In a tweet, Siguza said, "My primary goal was to get the write-up out for people to read. I wouldn't sell to blackhats because I don't wanna help their cause. I would've submitted to Apple if their bug bounty included macOS, or if the vuln was remotely exploitable.
Oh, it's "only a local privilege escalation". No worries then.
For the majority of use cases, that's pretty much it; you still have to convince someone to give you basic (local or remote) access to the box first.
Same story on *any* OS, come to think of it.
Quo usque tandem abutere, Nimbus, patientia nostra?
True, but as far as I can see Apple have never done that.
Early on in Mac OS X's (as it was then) history, Apple released the very first version of Safari. At that point, thanks to the Jobs vision of "It just works" coupled with the way earlier Mac OSes had run, to install an application (including setting it up to open files of a particular type by default) you just needed to copy the application to your hard drive. Anywhere on the hard drive. It didn't matter where. The operating system would automatically set everything up.
(And, to be fair, that's not a bad way to work, except...)
Well, Safari would also open and extract any ZIP or .SIT (a Mac specific archive format) file if you downloaded it. Automatically. It woudn't ask you, it just assumed you wanted that. Because, remember, Steve Jobs, "It just works".
So to install an application on someone else's Mac, all you had to do was make your web page redirect to a ZIP file, containing the application. And if, say, you made that application open files with a common suffix, and you also send a file with that suffix, then the moment the curious user double clicked it, it'd launch your application.
It took months before everyone was able to persuade Apple this was a bad idea and a version of Safari was released that didn't automatically open Zip files.
Jobs had vision. But to infer from that he was security minded would be a mistake. He was interested in making computers easy to use, but security got in the way of that, and it took a long time before anyone inside or outside of Apple figured out how to make security easy to use as well.
You are not alone. This is not normal. None of this is normal.
Without a visionary in charge, the company cuts corners and is losing major ground in 2018.
Apple is losing major ground, one business day in to 2018? Better sell stocks stat!
Reading the writeup I would say this guy really knows his Mac internals. Apple is getting better at security though: the last root exploit only required you to type "root" and no password. And the one before that required a single line of script to get root.
The good news is that even on the absolute first version of OS X, if you wanted to do anything that was outside the user home folder, or even with the user's keychain, it would ask for your password.
I don't know about you, but if you go to a web site and then it starts asking for your system password, YOU DO NOT PUT IT IN.
You are correct that Safari auto-expanding compressed archives wasn't a good idea. However, the inherent security design that the actual engineers managed to persuade Jobs to keep in the OS prevented major damage from things like that, to the point that even Jobs was recounting his at-the-time skepticism and praising that design and those engineers in on-stage interviews years later.
No operating system is without flaws. However, mix a bit of common sense in with good design, and you come out ahead of just good design.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Ya they kinda do.
https://www.techdirt.com/articles/20111107/18193216671/find-vulnerability-apple-software-lose-your-license-as-apple-developer.shtml
They didn't SUE. They simply revoked his Developer Cert.
Which is EXACTLY what they SHOULD have done.
Charlie Miller is no fool. One would ASSUME he knows the rules. But instead, he thought he'd be snarky and submit an iOS App that he KNEW violated his Developer Agreement, and then, when the App got Approved, he LEFT IT UP FOR A MONTH, where ANYONE could have downloaded and "learned" from it.
Yeah, he deserved what he got; regardless of how "altruistic" his intentions were (which I believe they actually were).
But he DIDN'T get SUED.
This looks as if it's exploitable even for sandboxed processes. This isn't such a big deal on macOS, where both users of the Mac App Store might need to worry, but most other people are only running sandboxed apps written by Apple (I'm not sure if WebKit renderer processes have direct HID access - I don't think they do, because HID events are proxied for them from the privileged component, though the XPC vulnerability a few months ago turned sandboxed WebKit component vulnerabilities into whole-machine compromises). It is a much bigger deal for iOS, where most users run not-very-trusted applications from the iOS App Store and rely on the sandbox framework to isolate them. The sandbox framework doesn't work so well on a compromised kernel.
I am TheRaven on Soylent News
If you have a process running on macOS with ambient authority then in most cases a root exploit doesn't give you much - you can already access and modify everything that the user cares about. A vulnerability like this; however, can also be exploited by sandboxed applications (though hopefully not sandboxed daemons, which shouldn't have access to the HIDs).
Most Apple apps are now sandboxed, as are Microsoft Office and anything that is distributed via the App Store. I posted above that most people don't use the App Store, so it's not a huge issue, but I hadn't considered all of the possible vectors. This means that MS Word macro vulnerabilities (and fun things like their OLE bug a little while ago where an incorrect length in a document led to arbitrary code execution), PDF / PNG / JPEG vulnerabilities in Preview, and so on can now be system-level compromises instead of sandboxed-application compromises. That's a pretty big difference: without a vulnerability like this, if I send a Mac user a malicious PDF that they open in Preview and trigger an arbitrary-code execution flaw, I get read access to all of the documents that they have open in Preview (and possibly write access to anything that they've saved in Preview recently), and might be able to trick the user into elevating privilege slightly from there. With this vulnerability, I get complete system access.
I am TheRaven on Soylent News
It's worse than that. It's a local privilege escalation, already patched in macOS 13.0.2 via ROP and race conditions during logout/shutdown of the computer, it requires a LOT of luck and is very time sensitive for it to work, in my testing most of the time the thing will either fail or crash the kernel.
Custom electronics and digital signage for your business: www.evcircuits.com
Stupid. Fucking. Hater. Die Hater, Die!!!
Why the fuck did this get (+5)?
Avantgarde Hebrew science fiction
A vulnerability from back in 2017 is probably old enough to not be worth fixating.
I'll see your senator, and I'll raise you two judges.