How dangerous is it in allowing kernel extensions from CalDigit and Rogue Amoeba by Reducing Security?

[Luba]

"Audio Capture Engine, generally referred to as “ACE”, is Rogue Amoeba's powerful audio handling component. ACE captures audio on your system, allowing so it can be used with Audio Hijack". I used to use Audio Hijack to record/capture audio on FaceTime or Skype calls for podcasts. I previously had an old Mac Pro running High Sierra and wasn't asked to reduce my security. I'm now running Big Sur on the new 2021 iMac.

I bought CalDigit's Element Hub (Thunderbolt hub/dock) and it also wants me to "reduce my security" to install a kernel extension, namely 'CalDigit USB Hub Support'.

Is it safe to allow Rogue Amoeba's Audio Hijack and CalDigit's Element Hub to install kernel extensions? What's the danger? What do kernel extension or system extensions do?

Thanks in advance.

 

[chrfr]

"Audio Capture Engine, generally referred to as “ACE”, is Rogue Amoeba's powerful audio handling component. ACE captures audio on your system, allowing so it can be used with Audio Hijack". I used to use Audio Hijack to record/capture audio on FaceTime or Skype calls for podcasts. I previously had an old Mac Pro running High Sierra and wasn't asked to reduce my security. I'm now running Big Sur on the new 2021 iMac.

I bought CalDigit's Element Hub (Thunderbolt hub/dock) and it also wants me to "reduce my security" to install a kernel extension, namely 'CalDigit USB Hub Support'.

Is it safe to allow Rogue Amoeba's Audio Hijack and CalDigit's Element Hub to install kernel extensions? What's the danger? What do kernel extension or system extensions do?

Thanks in advance.

The Caldigit extension is to allow for higher powered USB charging as would be needed to run the Apple USB Superdrive or to charge an iPad. If you’re not going to connect those to it, there’s no need for that extension.
If you’re no longer using the Rogue Amoeba app, then don’t enable that extension either. The fewer extensions you use, the more stable your system will be.

 

[Luba]

The Caldigit extension is to allow for higher powered USB charging as would be needed to run the Apple USB Superdrive or to charge an iPad. If you’re not going to connect those to it, there’s no need for that extension.
If you’re no longer using the Rogue Amoeba app, then don’t enable that extension either. The fewer extensions you use, the more stable your system will be.

Ok, I'm using the Apple USB Superdrive, but I'll just use it on one of the iMac's USB-C ports. That port should give it enough power, correct?

How do I delete the CalDigit extension? Is it as simple as going into (root, not user) \Library\Extensions and deleting "CalDigitUSBhubSupport.kext"? No other files to delete like when I delete an app I have to hunt around for other files like .plist etc?

 

[casperes1996]

If you trust the developer and the kernel extension is properly written without any vulnerabilities, it's not dangerous at all.

But the things is, a kernel extension runs in kernel space. The name sort of gives that away, but it's important. Running in kernel space basically means there's nothing it's not allowed to do. Read and write to any and all memory in the system? Sure! Directly write to hardware, no problem. - That is both the power of a kernel extension and the problem. And if a kernel extension crashes, it's not like an app crash. It's a system crash; Whole thing goes down.

That's not to discourage kexts entirely; I run some myself. But it is about the greatest privilege you can give any code. To run as a kernel extension is to have absolute control

 

[Luba]

If you trust the developer and the kernel extension is properly written without any vulnerabilities, it's not dangerous at all.

But the things is, a kernel extension runs in kernel space. The name sort of gives that away, but it's important. Running in kernel space basically means there's nothing it's not allowed to do. Read and write to any and all memory in the system? Sure! Directly write to hardware, no problem. - That is both the power of a kernel extension and the problem. And if a kernel extension crashes, it's not like an app crash. It's a system crash; Whole thing goes down.

That's not to discourage kexts entirely; I run some myself. But it is about the greatest privilege you can give any code. To run as a kernel extension is to have absolute control

Whoa! I definitely don't need to run the CalDigit kernel extension. I'll just plug the Apple Superdrive into one of the iMac's dedicated USB-C ports.

How do I delete/uninstall the kernel extension? It's "almost" installed. I just need to provide the permission. I looked in \Library\Extensions and "CalDigitUSBhubSupport.kext" is there, as well as "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext". Do I simply delete "CalDigitUSBhubSupport.kext" and I'm done?


Any idea what "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext" are for? I didn't install them. I hope they came from Big Sur. "SoftRAID.kext" sounds like it's a software program to create RAID arrays. I have no idea what "HighPointIOP.kext" and "HighPointRR.kext" are for.

Thanks.

 

[casperes1996]

How do I delete/uninstall the kernel extension? It's "almost" installed. I just need to provide the permission. I looked in \Library\Extensions and "CalDigitUSBhubSupport.kext" is there, as well as "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext". Do I simply delete "CalDigitUSBhubSupport.kext" and I'm done?

If you haven't granted them permission they aren't loaded into the kernel and so they're entirely harmless. But yeah if you want to get rid of them from the hard drive, just delete the kext bundle as you say. I can't guarantee they don't have supplemental files anywhere, but most kernel extensions don't, they just have their kext bundle and that's it.

Any idea what "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext" are for? I didn't install them. I hope they came from Big Sur. "SoftRAID.kext" sounds like it's a software program to create RAID arrays. I have no idea what "HighPointIOP.kext" and "HighPointRR.kext" are for.

I only know SoftRaid for sure. And yeah, it's exactly that.
They've been in the market for a long time

OWC SoftRAID for Mac and Windows

The powerful software RAID utility for macOS and Windows offering max volume capacity, optimal drive performance, and data protection.

www.softraid.com

From this point on my message is just extra unnecessary background info.

Apple is sort of phasing out kernel extensions. That is, they have released a users-ace frameworks called DriverKit, so that a lot of things that previously required kernel extensions can now be done from Userspace. Which means the programs won't need full system access, and they will effectively be as harmless as any other program, while still being able to for example make drivers to interact with USB devices.

Kernel extensions that have a users-ace replacement in place are considered deprecated. However there are still some things you can't do without a kernel extension so that is still supported, though Apple will likely keep expanding the DriverKit model to encompass more use-cases. Sort of making these extensions more like exokernel designs in a way.

The FUSE project sort of tries to do the same for file system support, though FUSE on the Mac right now is itself a kernel extension, but then it allows user-space programs to exist that act as file system extensions going through the FUSE kernel extension without each file system extension itself needing to be in the kernel.

The reason you need to enter reduced security to have kernel extensions now is new hardware features with T2 and newer Macs (T1 maybe? I can't remember when it was introduced).
In the highest security mode, the whole kernel is checked against a hash of what Apple knows at build-time. If it doesn't match it's considered no longer trusted. Since a kernel extension lives in the memory space of the kernel, it would change the hash value so this function needs to be turned off.
That and of course the fact that kernel extensions will inherently open more attack vectors to kernel privilege levels

I will add though that I'm writing this by memory so if there are slight flaws in how I've remembered this feel free to correct me. I feel confident in what I say but mistakes can always slip into one's memory

Again if a kernel extension adds functionality you want/need and you trust the developer and feel certain enough about the quality of the product I wouldn't worry too much. Be wary about what you let run in the kernel, but don't stop using something you need like a kext required by your employer for their infrastructure or something

 

[casperes1996]

How do I delete/uninstall the kernel extension? It's "almost" installed. I just need to provide the permission. I looked in \Library\Extensions and "CalDigitUSBhubSupport.kext" is there, as well as "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext". Do I simply delete "CalDigitUSBhubSupport.kext" and I'm done?

Oh, I should add, you can disable all third party kernel extensions from loading by running

kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName>

from the Recovery terminal. It reboots the Mac the same way it would if a kext had caused a kernel panic. And if that happens it disables all of them until you re-enable them from System Preferences.

You can also use

spctl kext-consent list

and

spctl kext-consent remove <kext team ID>

respectively to see what the kext permission policy is and remove permissions. - Listing can be done on a booted system but adding and removing I believe requires recovery terminal

 

[chrfr]

Any idea what "HighPointIOP.kext", "HighPointRR.kext", and "SoftRAID.kext" are for? I didn't install them. I hope they came from Big Sur. "SoftRAID.kext" sounds like it's a software program to create RAID arrays. I have no idea what "HighPointIOP.kext" and "HighPointRR.kext" are for.

Thanks.

These are all included by Apple.

 

[casperes1996]

OK now that I'm already spamming commands at you, haha

kmutil showloaded

will show all loaded kexts. Note though that you will see a lot that are first party kexts from Apple as well. You can load and unload at will with kmutil as well and all sorts

 

[Luba]

Oh, I should add, you can disable all third party kernel extensions from loading by running

kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName>

from the Recovery terminal. It reboots the Mac the same way it would if a kext had caused a kernel panic. And if that happens it disables all of them until you re-enable them from System Preferences.

You can also use

spctl kext-consent list

and

spctl kext-consent remove <kext team ID>

respectively to see what the kext permission policy is and remove permissions. - Listing can be done on a booted system but adding and removing I believe requires recovery terminal

Making sure . . . <YourVolumeName> would be Macintosh HD (the name of my internal SSD)?

<kext team ID> would be from the kext-consent list?

 

[casperes1996]

Making sure . . . <YourVolumeName> would be Macintosh HD (the name of my internal SSD)?

<kext team ID> would be from the kext-consent list?

Yep

For the Volume name, remember to put quotes around the whole thing “/Volumes/Macintosh HD” or escape the space
/Volumes/Macintosh\ HD
You can use the tab key to have it autocomplete, so you just write /V(tab key)M(tab key) - though if there are multiple options it won’t necessarily fill out the whole thing, just stop at where it diverges, so Macintosh HD might not be filled out in its entirety of you also have a drive named MacDrive 2 or whatever if you hit the tab key after just the M.
Works for all command line stuff to autocomplete with tab

 

[HDFan]

kmutil showloaded

maybe systemextensionsctl list is a bit easier, as it just shows your loaded extensions?

Getting rid of extensions with big sur is a big pain. You can't just delete them from the folder. The accepted way is to delete the application which installed the extension. When that doesn't work you can do a sudo systemextensionsctl uninstall (extension name) in recovery mode with SIP off.

 

[casperes1996]

maybe systemextensionsctl list is a bit easier, as it just shows your loaded extensions?

Getting rid of extensions with big sur is a big pain. You can't just delete them from the folder. The accepted way is to delete the application which installed the extension. When that doesn't work you can do a sudo systemextensionsctl uninstall (extension name) in recovery mode with SIP off.

systemextensionctl list is not the same thing. It will list different extensions.
Allow me to demonstrate

I have the Cisco any connect system extension as you can see, with the TeamID DE8Y96K90QP, but I also have the Xbox360controller driver which is a traditional kext, with team ID G947KKM5RL.

The 360 driver is also not installed with an application. It was installed from a pkg installer which you can't even do with system extensions. They need to be bundled with apps. It had its own uninstaller in its System Preferences pane however, that deletes everything for it, and an uninstall script on the GitHub in case the other method fails

Interestingly though, the kext-consent doesn't show SoundFlower, even though it is a currently loaded kext not from Apple (though currently loaded shouldn't matter for kext-consent, just that consent has been given)

That one is also not a system extension, btw, and thus does not show with systemextensionctl list

 

[Unknownnnn]

If you trust the developer and the kernel extension is properly written without any vulnerabilities, it's not dangerous at all.

But the things is, a kernel extension runs in kernel space. The name sort of gives that away, but it's important. Running in kernel space basically means there's nothing it's not allowed to do. Read and write to any and all memory in the system? Sure! Directly write to hardware, no problem. - That is both the power of a kernel extension and the problem. And if a kernel extension crashes, it's not like an app crash. It's a system crash; Whole thing goes down.

That's not to discourage kexts entirely; I run some myself. But it is about the greatest privilege you can give any code. To run as a kernel extension is to have absolute control

Hi casperes1996,

I stumbled upon this thread when googling risks of Kexts. Do you know if they can bypass TCC? For example allowing an app to access Documents folder without asking for permission. How about adding a root certificate?

And would you say if Kext are more dangerous than a Provisioning Profile or not?!

I'm asking this because VirtualBox moved from Kexts in version 6 to utilizing a Provisioning Profile in version 7; and I don't know which one would be less risky to trust. Their team has provided a very brief explanation on why it was done here, but I didn't find it convincing enough, especially since removing their profile wouldn't even allow running a VM in the GUI.

Thank you!

 

[casperes1996]

Hi casperes1996,

I stumbled upon this thread when googling risks of Kexts. Do you know if they can bypass TCC? For example allowing an app to access Documents folder without asking for permission. How about adding a root certificate?

And would you say if Kext are more dangerous than a Provisioning Profile or not?!

I'm asking this because VirtualBox moved from Kexts in version 6 to utilizing a Provisioning Profile in version 7; and I don't know which one would be less risky to trust. Their team has provided a very brief explanation on why it was done here, but I didn't find it convincing enough, especially since removing their profile wouldn't even allow running a VM in the GUI.

Thank you!

Kexts run in kernel space. Effectively the highest permission level possible. They can access anything and do anything pretty much. The only limitations you can really put on a kext are more to try and avoid it accidentally doing something. If it wants to do something it can.

 

[Unknownnnn]

Kexts run in kernel space. Effectively the highest permission level possible. They can access anything and do anything pretty much. The only limitations you can really put on a kext are more to try and avoid it accidentally doing something. If it wants to do something it can.

Thanks. I suppose with a Provisioning Profile, TCC and SIP may be bypassed for the intended developer, but at least, it doesn't increase vulnerability of the kernel to malicious third parties. 🤷‍♂️

 

[casperes1996]

Thanks. I suppose with a Provisioning Profile, TCC and SIP may be bypassed for the intended developer, but at least, it doesn't increase vulnerability of the kernel to malicious third parties. 🤷‍♂️

The profile represents code signing entitlements. Apple signing off on the application developer using certain features. The signature can be revoked by Apple if misused. And sensitive features not explicitly in the profile are not usable

 

[Unknownnnn]

The profile represents code signing entitlements. Apple signing off on the application developer using certain features. The signature can be revoked by Apple if misused. And sensitive features not explicitly in the profile are not usable

The problem is with the transparency loss when trusting a Provisioning Profile. First of all, I can't see what entitlements are in that profile. (Looked everywhere I could think of to no avail.) For example, in the case of VBox, I guess it has an entitlement for full-disk access to make its encrypted VMs work. However, that also means having access to Documents/Desktop/Downloads folders, without it showing in the Privacy panel. (Doesn't show full-disk access there either.) So it probably is no less dangerous than a Kext when it comes to trusting Oracle, but safer than a Kext when it comes to other third parties that may abuse a Kext planted by VBox.

 

[bogdanw]

The problem is with the transparency loss when trusting a Provisioning Profile. First of all, I can't see what entitlements are in that profile.

Here they are:
<key>Entitlements</key>
<dict>

<key>com.apple.vm.networking</key>
<true/>

<key>com.apple.vm.device-access</key>
<true/>

<key>com.apple.vm.hypervisor</key>
<true/>

<key>com.apple.application-identifier</key>
<string>VB5E2TV963.com.oracle.virtualbox.vm1</string>

<key>keychain-access-groups</key>
<array>
<string>VB5E2TV963.*</string>
</array>

<key>com.apple.developer.team-identifier</key>
<string>VB5E2TV963</string>

</dict>

 

[Unknownnnn]

@bogdanw Fantastic. Were you able to extract this on your machine or from their source code? If the former, would love to know how!

Ok, I see that you pasted the entitlements from the embedded.provisionprofile in the main app. Chrome has that file in its bundle as well, but it doesn't show in Preferences/Profiles as in the attached picture. So I'm not sure if this Provisioning Profile is something more than just the embedded.provisionprofile or not.

 

[bogdanw]

Same UUID

security cms -D -i /Applications/VirtualBox.app/Contents/embedded.provisionprofile -o ~/Desktop/embedded.provisionprofile.plist

defaults read ~/Desktop/embedded.provisionprofile.plist UUID

/usr/bin/profiles -cv

TN3125: Inside Code Signing: Provisioning Profiles https://developer.apple.com/documentation/technotes/tn3125-inside-code-signing-provisioning-profiles
Configuration Profile Reference https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf

man -t profiles | open -fa "Preview"

 

[Unknownnnn]

Thank you very much.
The UUID from the command `profiles list -type provisioning` does indeed match the UUID of embedded.provisionprofile in the app's bundle: `grep -A 1 -a UUID /Applications/VirtualBox.app/Contents/embedded.provisionprofile`.
Thanks again.

 

[Unknownnnn]

@bogdanw Just two more questions 🙏
Do you know how to get all the hashes in a Provisioning Profile?
(The hashes of the executables that would benefit from the entitlements in that profile.)

Lastly, would that mean MacOS calculates hash of any executable before running it?!

I'm asking this since I didn't see extended attributes for VBox CLI tools, so I assume they can only rely on a hashing mechanism to be identified.

 

[bogdanw]

TN3126: Inside Code Signing: Hashes
"Look inside a code signature to see how it uses hashes to protect the code’s executable pages, resources, and metadata from tampering."
https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes

As far as I can tell, there are no hashes in the provisionprofile and the decoded DER-Encoded-Profile looks like this

SET               
 SEQUENCE          
  UTF8STRING        :Version
  INTEGER           :01
 SEQUENCE          
  UTF8STRING        :TimeToLive
  INTEGER           :19AA
 SEQUENCE          
  UTF8STRING        :Platform
  SEQUENCE          
   UTF8STRING        :OSX
 SEQUENCE          
  UTF8STRING        :IsXcodeManaged
  BOOLEAN           :0
 SEQUENCE          
  UTF8STRING        :ProvisionsAllDevices
  BOOLEAN           :255
 SEQUENCE          
  UTF8STRING        :AppIDName
  UTF8STRING        :VirtualBox VM1
 SEQUENCE          
  UTF8STRING        :Name
  UTF8STRING        :Oracle VirtualBox VM
 SEQUENCE          
  UTF8STRING        :CreationDate
  UTCTIME           :220524134334Z
 SEQUENCE          
  UTF8STRING        :TeamIdentifier
  SEQUENCE          
   UTF8STRING        :VB5E2TV963
 SEQUENCE          
  UTF8STRING        :ExpirationDate
  UTCTIME           :400519134334Z
 SEQUENCE          
  UTF8STRING        :TeamName
  UTF8STRING        :Oracle America, Inc.
 SEQUENCE          
  UTF8STRING        :ProfileDistributionType
  UTF8STRING        :DIRECT
 SEQUENCE          
  UTF8STRING        :ApplicationIdentifierPrefix
  SEQUENCE          
   UTF8STRING        :VB5E2TV963
 SEQUENCE          
  UTF8STRING        :UUID
  UTF8STRING        :b911524e-b426-4502-b050-8a5bd0bf7ab9
 SEQUENCE          
  UTF8STRING        :DeveloperCertificates
  SEQUENCE          
   OCTET STRING      [HEX DUMP]:31053B63156B75A02C7D80E7943F0517C0C35BCF14B399B646492304AE6CE5CD
 SEQUENCE          
  UTF8STRING        :Entitlements
  appl [ 16 ]       
   INTEGER           :01
   cont [ 16 ]       
    SEQUENCE          
     UTF8STRING        :com.apple.application-identifier
     UTF8STRING        :VB5E2TV963.com.oracle.virtualbox.vm1
    SEQUENCE          
     UTF8STRING        :com.apple.developer.team-identifier
     UTF8STRING        :VB5E2TV963
    SEQUENCE          
     UTF8STRING        :com.apple.vm.device-access
     BOOLEAN           :255
    SEQUENCE          
     UTF8STRING        :com.apple.vm.hypervisor
     BOOLEAN           :255
    SEQUENCE          
     UTF8STRING        :com.apple.vm.networking
     BOOLEAN           :255
    SEQUENCE          
     UTF8STRING        :keychain-access-groups
     SEQUENCE          
      UTF8STRING        :VB5E2TV963.*

 

[Unknownnnn]

Thank you very much.
Then how do you think VBoxManage or VBoxHeadless benefit from that Profile?! (And hopefully not non-Oracle executables.)
`otool -l` doesn't work on them either. 🤔