0

I'd like to protect against unauthorised system extension teardown that are triggered by the container application following this command:

self.deactivationRequest = 
        OSSystemExtensionRequest.deactivationRequest(
                    forExtensionWithIdentifier: extensionIdentifier, queue: .main)
self.deactivationRequest!.delegate = self
OSSystemExtensionManager.shared.submitRequest(self.deactivationRequest!)

Is there a callback in the endpoint extension code, that can be invoked upon this deactivation request, and may block/allow it ?

thanks

Zohar81
  • 4,554
  • 5
  • 29
  • 82
  • Do you want to protect your own system extension from deactivating through you own application, or you have a 3rd party app-sysext pair, which you want to protect? – Arthur Bulakaiev Jan 02 '23 at 20:02
  • The first option. I'd like to allow the deactivation only if some requirement is met. – Zohar81 Jan 02 '23 at 20:13
  • Why can't you put some condition before that deactivation code branch? – Arthur Bulakaiev Jan 02 '23 at 20:49
  • Ideally, for security reasons, I'd like to prevent it from the extension itself and protect from a case where the application has been tampered/breached. – Zohar81 Jan 03 '23 at 09:40
  • thanks for your response ! perhaps you can also take a look at another network extension related question that I've posted https://stackoverflow.com/questions/74998070/how-to-enable-multiple-proxy-managers-waiting-for-user-approval-event – Zohar81 Jan 03 '23 at 19:55

1 Answers1

1

There is no public API to control the system extension deactivation with EndpointSecurity or inside sysext itself (activation and deactivation management, I think, is a job for some daemon, like sysextd).

I could advice to try two approaches for your case:

  1. You may still be able to deny deactivation with EndpointSecurity, just not in direct way. To deactivate sysext the responsible processes would do a lot of stuff, including opening some specific files, reading them, etc. In case you are lucky, you may be able to fail the deactivation process by blocking one of such operations before it really deativated. However, the context of operation (how do you know the target is your extension) may vary and be less than you need.

  2. You may intercept the OSSystemExtensionManager.shared.submitRequest call inside your application, and add some condition to really call original method from interception method. The interception for submitRequest will be a swizzling. Or you can place an old good hook on something deeper, like xpc_* stuff, and filter your deactivation request by some unique string from request, also calling original method only on some condition.

Both ways are not bulletproof from perspective of tampering protection ofc, but nothing really is, we just requesting additional efforts from hacker.

If you haven't disabled library validation for your app, there are two ways of tampering it: either turning SIP off, or using some 0-day system breach. You can't really protect your app from such treats: 0-days are new, you don't know what it may be, and with SIP off the one may unload/disable/alter all possible kinds of protection stuff.

Arthur Bulakaiev
  • 1,207
  • 8
  • 17