With the release of macOS Catalina in October, Apple rolled out a set of interesting new features collectively called System Extensions. System Extensions are a set of user space frameworks encouraging developers who currently maintain and ship kernel extensions to move their features to user space for increased security and stability. One of these new frameworks is the Endpoint Security framework. As a security researcher this framework is of special interest. It’s intended to provide a public and stable API for implementing security products. During the process of looking into what functionality the Endpoint Security framework provided, a privilege escalation bug was identified that would let an attacker execute any code they wanted with root privileges. The following describes both the vulnerability as well as what Apple did to fix the issue.
One of the most exciting things announced at this years WWDC was System Extensions. From a security perspective I think this is a really important advancedment for macOS. It means less third party code running in kernel space which should mean more security and stability. From a programmers perspective I think this is even more important. It means that the code developers previously had to write in C++ can now be written in a more modern language like Swift. Apple has been attempting to wrangle in kexts for a while now and this seems to be the final nail in the coffin. They have said macOS 10.15 will be the last release to fully support kexts without compromises and that in future releases of macOS Kernel Extensions with System Extension equivalents will not load at all. I thought it might be interesting to look at the internals of how System Extensions work.
When reverse engineering macOS binaries that are written in Objective-C, class-dump is a common tool used to extract Objective-C declarations from the runtime information stored in the Mach-O files. With Swift binaries, since there is Objective-C compatability, sometimes you can extract declarations using class-dump but not always. Swift has a rich set of type metadata itself but the documentation is not up to date. With Swift 5 bringing ABI stability I thought it would be interesting to take a look at the type of metadata availble in Swift binaries.
Recently while looking into the Apple
adid daemon, I noticed that I couldn’t attach to the process with
lldb even if SIP was completely disabled. After digging into it a little bit I came to the conclusion that
adid was calling the
ptrace API passing in
PT_DENY_ATTACH. There are numerous other posts out there (like this one) that talk about defeating
PT_DENY_ATTACH if you’re running the application yourself. In my case
adid is started as a LaunchDaemon and is already running by the time a user is logged in. I decided to take a look at how you could defeat the
ptrace call even after the application is already running.