Yeah. I think the key thing in my vulnerability is that it abused a legitimate OS prompt and had the consequences of that prompt be applied to something separate from what the prompt text itself said it would.
No word from them on the payout, yet. They only start deciding on if and how much to pay after the patch. I know for a fact it doesn't fall under the $1,000,000 reward tier as that is for their Private Cloud Compute platform. But it may fall under some of their other categories.
Honestly, I think you have a fair point there. I personally don't believe that any system could be 100% secure. But I do think there is a point to be made on the efficacy of securing the runtime compared to individual app inspection.
The local network popup thing is too overdone in my opinion. However, I do think it is a good choice (in some respects) for Apple to have the "this is a program downloaded from the Internet", even if it can be annoying. It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
It's a double-edged sword in my opinion. I think it's good that the OS is looking out for the user in a lot of cases. I also understand how it can give the users pop-up fatigue.
> The day Apple prevents users from giving sudo access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.
I can see this happening, but it probably won't anytime soon. macOS is still open enough, and with the assumption that sometimes processes need root (see third-party Launch Daemons).
It would probably break quite a lot. But I wouldn't be surprised if they eventually gradually move macOS in that direction.
I guess that's a fair point. It cuts both ways, but given that so many people use Slack as opposed to talking, the exact words people used and when are could be open to view. Whereas, before all of this, you may only just have the minutes of any official meetings. Any side chatter not in the meeting room and/or exact phrasings would be lost to time.
Yeah. I'm guessing there must be some legitimate (internal?) use cases for the behavior I found and they spent all that time working out the kinks to allow those edge cases while also not allowing malicious ones. Or perhaps it wasn't as high on their priority list as it required a higher level of user interaction (the user had to click "Allow"). In any case, though, I do believe that a year is a shockingly long time for them to take.
I mean, at that point and app could just put up a fake prompt using the UI framework. And I think users would be more hesitant to type a full password than just click a button. But if you're talking about a bug similar to mine where an attacker could use the OS's own code against it and make it show a prompt with misleading content, you might be able to report it to Apple Product Security and maybe get a bounty.
This is Apple-specific, though. So there aren't really any other vendors that are relevant to this specific scenario. I will say, they have been quicker with my other reports; taking just a few months as opposed to a full year.
I honestly think this is a good skepticism to have. I generally don't hit "Accept" (or "Allow" or whatever) on any permission pop-up unless I know exactly what it's doing and what I need it for.
Damn. As someone who has dabbled in OS history research Usenix's archives were a God-send. I hope they continue to maintain them, and that other groups can take up the mantle of hosting cutting-edge computer science research (at least to the extent its still happening).
A software updater was going to be my best guess at what this was. I guess I understand the flexibility it brings, but it definitely does have some security trade-offs.
I'm not aware of the "helper tool" popup, but I would definitely be skeptical of it. Even if it is Slack, Slack is just a messaging application. I don't know what legitimate need it would have for a helper tool. I would ask Slack support, though (and hopefully you can get a real answer and explanation).
Fascinating perspective. I understand your point, and agree with it generally. I will point out though that this doesn't really have anything to do with Continuity or any "feature" per-se. It doesn't really have anything to do with "parental controls", that was just the daemon that was exploited. You don't have to have a "child" user account to be vulnerable to this. Every user account is vulnerable to it.
Thanks for the feedback! I was burying the lede a bit on purpose to entice the reader to read more, but I also completely understand your perspective as well.
> A capability-based design should be able to systematically prevent this kind of problems.
I think Entitlements could be considered a type of capability? And if so, then you're right on your this point, as the solution was to require an entitlement to talk to the daemon itself.
Well, it took 8 hours, but this post is now no longer top 5 on the front page (it's #27 now for me, so still front page, just the bottom). Thank you everyone for your comments!