Not exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder".

It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.

> If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app

There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.

So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?

Apple Security would instantly close it as "don't see the problem here" if you reported it to them. They have a poor reputation around TCC bug reports.

That makes it OK for you to not responsibly disclose a vuln? Cool I guess)

I have nothing to do with any of this.

But since they don't consider these as vulnerabilities in the first place, then yeah, sure.

It's very common for large companies to "close" or downplay vulnerabilities. That doesn't exempt researchers from responsible disclosure timelines. There have been plenty of instances where a company reverses course after some back & forth and the looming threat of going public.

You literally made a statement justifying not responsibly disclosing vuln because apple process sucks

whether it is a vuln is different argument (it's sandbox escape and definitely usable as part of an exploit)

Not really, just an unintuitive security feature. You still need the user's permission to access that folder, but that permission is then persistent. I consider it a UX bug for sure but not an exploit.

I agree, it's a ui/ux problem. It would seem that using the open file dialog should also request access but I'm guessing that was too intrusive and the user action is seen as implicit authorization. Security is one of those things that should aways be explicit though.

if having to run an arcane terminal program to disable access while GUI is as if access was not granted is "unintuitive security feature" for you, I can't even.