In macOS Big Sur, Apple has stopped allowing certain types of kernel extensions from third-party developers. This was expected and something Apple started to warn about in Catalina. So far, this does not apply to all kernel extensions, but only to those that have already received a counterpart in Apple’s new ‘system extension’ format. It is a safer and more stable technology for building drivers and other things that were previously run as kernel extensions.

So far, these are kernel extensions that handle antivirus, firewalls of various kinds, input devices and drivers for USB accessories. Other, less common varieties still work, such as virtual file systems. In the future, the idea is that kernel extensions will be removed altogether.

This means big changes for developers, but in some areas also for us users. This applies in particular to users of firewalls such as Little Snitch, VPN services and network limiters such as Tripmode (which only allow traffic from selected programs so that you do not waste limited data when, for example, you are connected via mobile or a 4g modem).

Apple’s own processes bypass filters

Programs like Little Snitch and Tripmode must now use what Apple calls the Network Extension API, a programming interface that provides access to most of the features that previously existed in the corresponding kernel extension. But what Apple has failed to mention to anyone is that there is a system with exceptions that means that these programs can no longer filter exactly all network connections.

You can look at the list itself in the file /System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist , under the key ‘ContentFilterExclusionList’. Here we find processes related to, for example, FaceTime, iMessage, iCloud, Maps and Siri.

If you want to test this for yourself follow these steps: Install Lulu 2.0 from Patrick Wardle (you must both approve the installation of a system extension and that the program filters your Internet traffic). Then activate Block Mode in the settings. This should turn off all traffic, and it works for browsers, Mail and more. Now try opening FaceTime and calling someone – it works and can not be blocked.

David Dudok de Wit, the developer of Tripmode, writes on Medium about the discovery and the consequences it has for users. For Tripmode in particular, this means that you can no longer stop, for example, iCloud from syncing and Messages from downloading new messages, including heavy attachments such as pictures and movies. The result is that the program becomes more or less useless since its main purpose is blocking all internet except the most important when you have an expensive connection.

Objective Development, the developers of Little Snitch, also writes about the discovery – and that they take it for granted that Apple will correct it.

VPN too

VPN programs can also no longer use kernel extensions in Big Sur. Several developers have already switched to the new system add-on variant. But just as for firewalls Apple’s exception also applies to VPN connections. This means that FaceTime and many other built-in processes can continue to communicate with Apple’s servers from your public IP address and not through the VPN tunnel you are connected to.

Our own research shows that this only seems to apply to VPN programs that use a new system extension to implement their own VPN protocol. When we connect via macOS built-in L2TP / IPsec manually set via System Settings, for example, the Mac App Store traffic is sent via VPN, as well as with the third-party program Windscribe. Windscribe can connect via various protocols such as IKEv2 and OpenVPN. These do not run kernel extensions but still work as usual.

Bad for both security and privacy

From a security perspective, this change is serious. If firewalls like Little Snitch and Lulu cannot see or stop traffic from your computer, you can not rely on such programs to prevent malware and fraudulent programs from “calling home”. Patrick Wardle at Objective See has already discovered a technology that allows a malicious program to snag traffic from any of Apple’s exempt processes to send data from the computer, as he explained in this tweet:

In Big Sur Apple decided to exempt many of its apps from being routed thru the frameworks they now require 3rd-party firewalls to use (LuLu, Little Snitch, etc.) 🧐

Q: Could this be (ab)used by malware to also bypass such firewalls? 🤔

A: Apparently yes, and trivially so 😬😱😭 pic.twitter.com/CCNcnGPFIB

— patrick wardle (@patrickwardle)
November 14, 2020

The attack vector for hackers and malware creators goes from “how can we find a way to get around Little Snitch” to “which of Apple’s 56 exempt processes may have a vulnerability we can exploit”. The risk has thus been at least 56 times higher.

Apple often talks about the value of privacy and how much the company does to protect its users from snooping advertisers and more. However, not being able to see and block all outgoing traffic from the computer can in no way be interpreted as an improvement of either security or privacy protection.

We will see in the future if Apple will comment and if we get any explanation. Because we can not see any reasonable reason to circumvent firewalls or VPN connections. “Send all traffic over VPN” should do just that – all traffic does not mean “all traffic except from reliable Apple processes “.

But we have an extremely hard time believing that Apple would make it impossible to send all traffic over VPN on purpose. This is something many companies set as a requirement to buy and use computers and Apple hardly wants to lose that market. Since the system’s built-in VPN function still seems to work fully, we guess it’s a mistake on Apple’s part that the exception list also applies to new VPN programs.

With that said, it is in no way acceptable not to be able to filter all traffic including all system processes via firewalls.

Riots around certificate checks

In addition to the above-mentioned problems, another concern in Big Sur, which also applies to Catalina, has been discovered in the past week – and has been discussed extensively on Twitter and various Mac sites. This is about how the system checks developer certificates to make sure you are not running any program from a developer whose certificate has been revoked.

MacOS has a background process called trustd that handles this (which also checks the certificates for secure websites). Hacker Paul Jeffrey first wrote that the Apple server ocsp.apple.com was down when many users tried to update to Big Sur and how it made programs start extremely slowly even on Catalina. The reason is that Gatekeeper checks when you start a program, which is cryptographically signed by the developer, if the certificate is still valid. Read: Macs ‘call home’ unencrypted to notarise apps.

OCSP stands for online certificate status protocol. It’s an internet standard and not something Apple has invented. It has been noted that the messages sent there are not encrypted, but this is because the protocol itself is designed that way. Paul Jeffrey described it as macOS sending information about which program you open, but, among others, Jacopo Jannone has taken a closer look at this and it is not entirely true. Firstly, it is a serial number for the developer certificate that is sent (which can not differentiate between different programs from the same developer), and secondly, it is not every time you start the program but from time to time.

But some developers only have one program and each certificate check for it reveals that someone at your IP address has used that particular program at least at that time.

However, Apple has already responded to this criticism and announced in a support document that a new certificate control system will be developed where all traffic is encrypted so that your Internet operator and others can not spy on which developer’s program you use. The system will also be better at handling server problems (so that it does not take half an eternity to start a program) and finally a system setting will be added to turn off the controls completely for those who do not want to share any data with Apple.

How to protect yourself

Until we have a straight answer from Apple about network filtering, there are still some things you can do to stop Apple’s applications.

The first method is to turn off parts of System Integrity Protection (SIP) in macOS, so you can use the old versions of Little Snitch, Lilu, Tripmode and so on with kernel extension. Apple can not stop these from filtering their own traffic. Because this makes the Mac less secure in general, it is not something we recommend to regular users, but something we leave to experts who understand how it works and who can handle the risks.

What some comments on Twitter and elsewhere have pointed out is that a firewall that runs on the device from which you want to filter Internet traffic can still never be trusted one hundred percent. An advanced malware that has infiltrated your computer can always find ways to bypass your computer’s software. The second method is therefore to use an external firewall, for example an advanced router with open source firewall pfSense. This is far from easy to get started with and not nearly as user-friendly as Little Snitch or Lulu.

Miles Wolbe at tinyapps.org describes a third method of editing Apple’s exception list – which is not the easiest with all the protections Apple has added to Big Sur.

If you’re not interested in stopping Apple’s traffic but want to make sure it goes through a VPN, it’s a little easier. If your router already has a built-in VPN client, you can configure it so that the entire network is behind the VPN, and if not, you can get one. You can also check if your current router supports open source software such as DD-WRT or OpenWrt which also has a built-in VPN client.

Hopefully Apple realises the problem and restores the ability to filter all traffic. If nothing else, it is said to be a compulsion from many companies, and if there is one thing we can count on, it is that Apple is thinking with its wallet.

We have some Mac security tips that you might find useful. Also, for more advice about using a VPN read: Best VPN for Mac.

This article originally appeared on Macworld Sweden. Translation by Karen Haslam.