IOHIDeous OS X Local Kernel Vulnerability
siguza.github.io
siguza.github.io
That said, seriously impressive work and I give him props.
If I had to guess, he waited a month, got blown off, and said, "Fuck it."
Also -- I feel like the underlying bug, ie relying on values in a volatile variable that is shared -- are the sort of thing that source code could be systematically tested for, both mechanically and by humans. But my strong impression is that Apple doesn't care about MacOS and definitely doesn't put the A team on it. Or even the B team.
And an engineer from Apple's security team contacted me a bit after releasing - they had found the bug a while ago, but hadn't verified the subsequent patch which actually didn't fix it. And a while ago I tweeted this https://twitter.com/s1guza/status/921889566549831680 (try diff'ing sources to find it :P). So they do have people on it. I also told that person to extend my condolences to whoever has to come in and fix that now, but they basically said that there's nothing to apologise for and that they (the team) really like such write-ups. So... I guess I'm not that evil?
And I neither wanna watch the world burn nor did anyone brush me the wrong way - I didn't publish this out of hate, but out of love for hacking. If you're concerned about skids hacking you now, they need to get code execution first on your machine. If you're concerned about people who can do that, then those can also get kernel r/w without me, so... nothing really changed for the average user.
PS: Yes, it's really me. Will add keybase proof if my karma gets >= 2. Edit: done, see my profile.
Today's Apple does a lot of security posturing in hardware/platform architecture, like full disk encryption, the iOS device secure enclave thingie, the secure enclave's subsequent inclusion on touchbar Macbook Pros to control the webcam, iOS defaulting to non-networked sandboxing for third party keyboards, etc.
Do you think macOS/iOS development perhaps should slow down from a yearly release cycle to delay releases with continuous big reworking starting with XNU?
With a very rudimentary outsider perspective on QA, it just seems insane to keep pushing big OS changes yearly.
CVE 2018-0001, it's all about namespaces.
EDIT: "No one would ever store the CVE incrementing fragment as a 16-bit unsigned int!"
For additional fun, find a buffer overrun based on the CVE ID.
I was unlucky and it didn't work out, but come December time I do wonder if I should dedicate more time to audits ..
First, the skills and persistence to get all these moving parts going. This must have been weeks of tiring work and exploration.
Second, the fact that the author wrote an incredibly detailed posting with a lot of detail and background information.
Wonderful work.
It looks like a total system compromise is possible. Under what conditions? Any ways to ensure we don't get pwned?
Not sure if this is HN-level, but... I hope it's understandable.
Have Mac users finally started running antivirus?
I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action - user space would ask for something it is permitted to do at first, kernel would read it and proceed to perform access check. User space meanwhile writes something different to the original memory area that specified the action - this time something privileged - kernel comes back successfully performing the access check for the older action and now executes the privileged action from the overwrite.
j00ru/project zero used modified Bochs (BochsPWN) to detect double memory fetch patterns to find similar vulnerabilities in the Windows kernel.
Which may, unfortunately, speak to what management thinks about the security/quality of the macOS codebase.
I wouldn't be surprised the recent and upcoming exploits lead Apple to increase iOS dominance over its future product pipeline.
Apple makes computer and operating system way before it entered the mobile market. The first part is right, but your second part is inaccurate historically.
High spec MBP + some cash goes a long way. Even engrave the freaking laptop to make it “sough after”.
The term you're looking for is "Coordinated Disclosure". Yes, Coordinated Disclosure would involve sending the bug to Apple and waiting for them to publish it.
If you'd like to complain that this disclosure is irresponsible, fine. But try not to do it using the vendor's marketing term, because it's not up to them to decide what is and isn't "responsible". Other reasonable people --- myself included --- will probably disagree with you, and say that getting information out to people as comprehensively as possible is usually the most responsible thing you can do with a security bug.
Its use carries an implicit catch that anything that does not meet the narrow definitions of "responsible" is the opposite. Without naming names there are vendors that have been pretty terrible at handling their end of "responsible" disclosure and appear to be getting worse, down to not even acknowledging there is a problem or even that they have been notified of a problem.
The alternative to disclosing a vulnerability is non-disclosure and, frankly, that's what some vendors mean when they say "responsible".
Vendors and non-vendors alike are all responsible for good security, and that includes working together to make this happen. If you are working against vendors because of some preconceived notion that they are "evil," that's not a good thing.
If it turns out that the author did submit to the vendor and worked together to minimize damage then I'll retract my statement. Until then I think it's irresponsible, not just "uncoordinated".
Cooperation or even coordination takes willingness from both parties. Let's look at the actual page apple has on reporting security issues [0]
"When we receive your email, we send an automatic email as acknowledgment. If you do not get this email, please check the email address and send again. We will respond with additional emails if we need further information to investigate a security issue."
Something seems a bit off here. I would have expected a human to get back within a few working days for a serious security problem. That might be in the auto response email, but I wouldn't be surprised if it wasn't.
"For the protection of our customers, Apple generally does not disclose, discuss, or confirm security issues until a full investigation is complete and any necessary patches or releases are available."
Does this extend to the security researcher that reports the vulnerability? If so, that's probably why there was no coordination.
[0] https://support.apple.com/en-us/HT201220
Edit: removed spelling mistake mistake.
I also think that the vendor has a responsibility to fix the exploit quickly, and if not the researcher should publish and shame the vendor.
It seems to me that nobody but Apple has a responsibility to its users. The public at large certainly doesn't owe Apple (or any other software proprietor) specific performance regardless of whether they report what they've found publicly or when.
Apple is also not being nice to its users by denying them software freedom: most of MacOS is proprietary and the aforementioned bug concerned iTunes, a proprietary media player. So no matter how technically savvy and willing the user is, they're not allowed to diagnose and fix the problem, prepare a fixed copy of the changed files, and help their community by sharing copies of the improved code.
"Responsible disclosure" is indeed propaganda that benefits the proprietor in a clumsy attempt to divert blame for a product people paid for with their software freedom as well as their money.
Because you think you are safe until publication?
What kind of "if I don't know about it, it isn't happening" worldview is that?
"acknowledgment" is the English US form: https://en.oxforddictionaries.com/definition/acknowledgement
Unless you are taking requests from random HN commenters for software that you would like to build them for free, I suggest you rethink your suggestion for highly skilled researchers to donate charity labor to the largest corporation in the world.
And before you interpret this to mean never disclosing publicly, that’s not what I’m saying. But no matter what your opinion is on the best way to handle disclosure, releasing a 0day without any attempt whatsoever to notify the vendor is highly irresponsible and immoral.
https://bugs.chromium.org/p/project-zero/issues/detail?id=10...
I'd say 30 days is enough. Google was generous with ninety. (They too live in a glass house after all).
I consider 24 hours notice bare minimum responsible disclosure, and 1 business day in the operating timezone of the company as an polite courtesy to the human beings who have to respond to uncoordinated security disclosures with emergency builds of their product.
What do you consider the bare minimum notice sufficient to respect the human beings who use the products we find vulns in? One business day? One hour? Zero seconds?
(Siguza, I'd also love to hear from you on this question, if you're willing to share. I know Apple said they don't need advance notice but if they hadn't, and offered no guidance, what would you have chosen?)
You can't possibly be serious? Have I fallen for some trolling here?!
Rabble-rouse all you like, but unless you respond with whatever your personal bare minimum delay is, you risk being perceived as the troll in this exchange.
> I consider 24 hours notice bare minimum responsible disclosure
...it seems rather unfair of you to have a go at my reaction. But somewhat incredibly, it appears you are serious.
I don't have a bare minimum delay - I think the vulnerability discover should coordinate a 'sensible' and 'fair' disclose with the vendor. What 'sensible' and 'fair' means, really depends - how serious is the vulnerability? How many systems are affected? How quickly can the vendor patch, test and document a fix? How quickly can the fix be distributed?
It's a stretch to imagine a scenario where 24 hours is in any way sensible, fair or responsible. I'd be intrigued to know your reasoning.
It also includes disclosure if the vendor drags their feet and does nothing, which is a very common response.
I have no preconceived notion that vendors are "evil," but I sure as hell have a preconceived notion that they're as lazy as they think they can get away with.
- Be more paranoid about allowing r/w direct access to your computer.
- Be prepared to power off or otherwise halt your machine if (on 10.13.12) you see unexpected logouts or similar.
- Safeguard your data and/or consider moving it off of the machine or not using it in some situations.
None of those are great things to rely on or to have to do. A real working patch or detection mechanism would definitely be better. But that's not the same as "no mitigations" whatsoever.
This would be a less serious problem if vendors pushed out fixes faster.
If you knew something is dangerous would you let your family/friends in the dark just to give the Company the time to fix it?
http://github.com/joelparkerhenderson/coordinated_disclosure
But they also argue that you should try to coordinate disclosure the first time at least, and only if a vendor doesn’t cooperate, you should publish future bugs. And they also suggested to coordinate disclosure at least with the club, so the disclosure is handled via official press communications of the club, and they can offer legal protection, too (very often, vendors will just sue any researcher).
This information is from a recording of the 34C3 year in review and PCWahl talks.
But what I think many people forget when they get "responsible disclosure" in their minds is that there are often bandaids users can do to protect themselves immediately regardless of whether a patch is ready, so long as they know about it. And since it's always possible and generally unknowable as to whether someone else might have already found the exploit and be using it, there is extra hard to calculate risk. Releasing it without a patch may lead to some users getting exploited, but it could also actually protect some users from being exploited or at least allow them to minimize the harm. Once it's known about in the wider community, it is also easier to check whether it's been selectively deployed anywhere. The lag time between notification and vendor patching is itself a risk (and of course there is lots of room for perverse incentives in all this).
So the real core issue with Coordinated Disclosure is that there is not in fact a Right Answer in general, any choice may help one group at the expense of another. Many researchers and organizations try to split the difference with standardized policies that seem to strike the balance, perhaps with occasional exceptions if it's serious enough. But ultimately it really is up to the discoverer and it's wrong to insist they conform to what the vendor finds desirable, particularly since ultimately the responsibility for the blunder lies with the vendor. It's a hard area and researchers should be respected for the work they do on their own terms.
I myself have found myself in total agreement in one instance, and then a week or two later a big exploit comes out that makes me really wish some patches had made it out first.
What I think it comes down to is that any vendor needs to assume the exploit can come out any minute after notification, and act accordingly (if it's important, they better damn well get it patched quick). Any researcher should assume that if they act like an asshole and aren't accommodating in some way, they'll get raked over the coals by at least some of the technical public. As tptacek noted, coordination is best, and that requires a dialogue.
Also worth noting is that sometimes there is no patch. Some security problems are of the degree that the entire process is fundamentally flawed, and in those cases there's little to be gained waiting for the vendor, unless the vendor is working to notify all clients and recommend they cease use of the affected service or product. If, for example, you identify a flaw in in how a protocol is defined, and almost all implementations are flawed, the only responsible thing to do might be to publish publicly. Otherwise you're just favoring some groups over others in some way or another.
— https://medium.com/@khaost/your-home-was-not-so-secure-after...
They deny problems until a shit tornado actually starts somewhere and they absolutely love to control the narrative. They are clearly PR first, lobby and fight against right-to-repair efforts because they want to "guarantee the quality of authorized repair", sell expensive proprietary software on proprietary hardware (ostensibly to provide absolute perfection by controlling the entire stack), have slogans like "it just works", "light years ahead", "touch of genius", "say hello to the future", care enough about current social outrages (USA specific ones that is..) to do truly silly crap like water pistol emoji or removing a historic game that featured a confederate flag.
They are also secretive as hell (i.e. 0 social media presence/interaction, YouTube comments off on their channel to prevent criticism, engineers under stricter NDA compared to Google, Microsoft, etc.), instantly fired an engineer for a mere iPhone X video her daughter filmed in Cupertino Campus, actually sent police to raid a house of a Gizmodo reporter and confiscate his stuff (which apparently breaks journalist protection laws both federal and state but oh well, it's USA and Apple, money talks, bullshit walks) when they wrote about a leaked iPhone 4G prototype, ran idiotic misinforming (but funny, so apparently it's okay!) ads in the past like the "Macs don't get viruses" one but still managed to have bugs like infamous "goto fail" or "password got stored in hint" (which are frankly insane to me).
If they cared they could do as much as silently toss a few thousand dollars per big bug, make sentimental/bragging right's rewards (like Knuth's cheques), etc. but chose not to.
They should be thankful that between "sell 0 days on the dark net", "do what Apple says for free" and "post online for cred" actual security hackers pick the last and not the first (I mean, I also would out of principle of not being a criminal, but there is clearly something wrong with a company's image if we have to fall back to a person's moral compass or even criminal justice system for any choice).
To add to the problem a lot of their fans are outright rabid, instantly plunder the Apple stores at each product release and criticizing Apple anywhere near them online results in being called a Microsoft/Android shill, hater, poor, fucker, faggot and such, and Apple's PR fluff being regurgitated at you.
If someone lives lavishly in a multi-billion ivory tower that also has a diamond mine under it while surrounded by their cultists and won't even toss you leftovers when you help them out, what do they expect?
They are a crazily rich, global and long established company and they should stop being excused. They are the world pinnacle of technology business in every sense and if they can't deliver they deserve the criticism. The poor guys working for free on OpenSSL for a bazillion platforms for single digit k of donations per year (and 0 compensation from all the corporate freeloaders from Fortune 500) got torn a new asshole the size of La Manche for HeartBleed but Apple keeps getting excused for not being able to get their shit together (by their own wish, like not having a bug bounty after all the bugs that happened in 2017) while they have the opinion of saints and geniuses and control everything to the tiniest details - shops, repairs, hardware, software, components and information.