←back to thread

Apple's apps bypass firewalls like LittleSnitch and LuLu on macOS Big Sur

(twitter.com)
1183 points robenkleene | 6 comments | 20 Oct 20 15:51 UTC | HN request time: 0.001s | source | bottom
Show context
jjoonathan ◴[20 Oct 20 16:03 UTC] No.24838965[source]▶
"You don't need kernel extensions, we'll provide APIs for you! We won't abuse the power that gives us, promise!"

...and now Apple has altered the deal and we must pray they do not alter it further. Disgusting. Predictable, expected, unsurprising -- but still disgusting.

replies(6): >>24839165 #>>24839174 #>>24839249 #>>24839470 #>>24839566 #>>24840061 #
Skunkleton ◴[20 Oct 20 16:18 UTC] No.24839165[source]▶
You understand that Apple could bypass kexts too? This is an issue of trust, not a technical issue.
replies(2): >>24839232 #>>24839336 #
CountSessine ◴[20 Oct 20 16:23 UTC] No.24839232[source]▶
Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes. Pushing these guys out of the kernel lets Apple cheat them and Mac users clean and easy.
replies(1): >>24839452 #
gruez ◴[20 Oct 20 16:38 UTC] No.24839452[source]▶
>Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes

why would that be the case? All you'd need to do is provide some sort of private network api, and only allow apple signed code to use it.

replies(1): >>24839467 #
1. throwaway2048 ◴[20 Oct 20 16:39 UTC] No.24839467[source]▶
that is not how kexts work(ed), they can do completely arbitrary things to the kernel, including removing any theoretical code signing requirement.
replies(1): >>24839599 #
2. gruez ◴[20 Oct 20 16:50 UTC] No.24839599[source]▶
any access? On Windows, you can write a driver that would run in kernel mode, but critical sections can't be modified[1]. I'd imagine there's something similar for mac.

[1] https://en.wikipedia.org/wiki/Kernel_Patch_Protection

replies(2): >>24839831 #>>24839933 #
3. SCHiM ◴[20 Oct 20 17:06 UTC] No.24839831[source]▶
KPP is not considered a security boundary. That means, in Windows security jargon, that it's a feature that helps security. But not something that you or anyone else should consider a fail proof solution, or even something that would result in a patch if breached.
replies(1): >>24840129 #
4. comex ◴[20 Oct 20 17:15 UTC] No.24839933[source]▶
There hasn’t been anything like that on macOS. macOS on Apple Silicon will have a form of kernel patch protection, like on iOS, but it’s designed to guard against exploits from userland, not approved kexts. It’s definitely possible for third party kexts to bypass that somehow, but possibly only by disabling Secure Boot; I haven’t looked into it.
5. gruez ◴[20 Oct 20 17:32 UTC] No.24840129{3}[source]▶
If patching the kernel to intercept network requests is sufficiently hard enough that you're forced to use their "approved" way of intercepting network requests, then it's very easy for them to sneak requests through. Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole because apple can sneak as many changes as they want with each macos release. It heavily favors apple, not the developers of such firewalls.
replies(1): >>24840780 #
6. CountSessine ◴[20 Oct 20 18:29 UTC] No.24840780{4}[source]▶
Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole

Exactly - but the game itself is the problem. Firewall vendors will go hunting through kernel code for jump targets and structs to plug into hidden interfaces, and Apple will remove and change them, causing crashes and instability. Apple has some leverage if they have a program like WHQL, but even then driver writers will commit shenanigans. Push them out of the kernel altogether and now only Apple can engage in shenanigans and break user trust. Which they already have.