Hacker News Reader

Comment by throwaway290 | Hacker News Reader

Installing a kext is a password prompt away, I believe, so all that's needed technically seems to be "install something not reviewed by Apple, fill in a genuine OS password prompt when asked, and run it" which strikes me as a very common scenario.

View on HN

Enabling 3rd-party extensions is much more involved on AS Macs: https://support.apple.com/guide/mac-help/change-security-set...

Then the extension needs to be allowed in System Preferences > Security (this step has been required on Intel Macs too)

Additionally, if can find a way to trick a user into installing a malicious kext, why even bother with PACMAN? You already have arbitrary kernel code execution!

Perhaps the kext with the overflow may not necessarily look malicious? It can serve as an actually useful kext and pass review.

yeah but if you can trick the user to do that, you can already trick him to do more

These days all kexts look malicious.

Yeah. The bundled ones in the main OS image are the worst. Who the hell knows what nefarious acts lie behind IOPCIFamily.kext?!

/s, though not entirely, moving more stuff to unprivileged contexts would be nice

First you need to trick Apple into signing that kext (which is getting more difficult by the day even for legitimate uses), or get the user to disable SIP first.

Didn't many tools require disabling SIP, like Homebrew? Is this no longer true?

This hasn't been true for at least 2 major macOS releases.

But yes, there was a time when editing even /etc/sudoers required disabling SIP. That time is long gone.

Reply on news.ycombinator.com