sektioneins / SUIDGuard

SUIDGuard - a TrustedBSD Kernel Extension that adds mitigations to protect SUID/SGID processes a bit more
390 stars 52 forks source link

How to uninstall? #6

Open ZappoB opened 9 years ago

ZappoB commented 9 years ago

How can I see, if the package is loaded after reboot? And how can it be uninstalled, if Apple fixes the security hole themselves?

guillaumemaka commented 9 years ago

To see if the kernel is loaded you can use kextstat

$ kextstat -l | grep SUIDGuardNG

You should get a result that look like that:

74    0 0xffffff7f80a3e000 0x3000     0x3000     com.sektioneins.driver.SUIDGuardNG (1.0.5) <7 4 3 2 1>

and to unload I think (not sure is the right way) you can use kextunload

$ kextunload -b com.sektioneins.driver.SUIDGuardNG

But again not sure, I found these commands by googling «mac unload/list kext»

ZappoB commented 9 years ago

Many thanks for your reply, I could verify the loaded kext, but it would be great to now, how this installation could be undone correctly.

guillaumemaka commented 9 years ago

I think to remove it completely you can unloaded first then:

rm -r /Library/Extensions/SUIDGuardNG.kext

or backup it

mv /Library/Extensions/SUIDGuardNG.kext /somewhere/bacjup
Marqin commented 9 years ago

But would that also remove autoloader for that extension that's provided with NG or it will just autoload any extension that someone would later put in /Library/Extensions/SUIDGuardNG.kext ?

guillaumemaka commented 9 years ago

Yes removing the kext will rebuild the cache (see issue #5) and for the second part of the question: Yes if it conform to a valid signing kernel extension.

stefanesser commented 9 years ago

I guess the question Marqin has if we added a magic autoloader that will load whatever extension is installed in /Library/Extensions/SUIDGuardNG.kext <-- the later is not the case. Extensions autoload under certain conditions, e.g. when they are designed to do it by using IOKit. This is what we did in the binary package (make it look like an IOKit driver) and that is also the technique LittleSnitch uses (???).

So we did not install some magic autoloader when you install the extension. It is just that the extension itself was changed a bit from the public source code to make it autoload by default.

ZappoB commented 9 years ago

Thank you all very much for all these explanations! I've now uninstalled it as described above, as Apple has fix this issue with OS X 10.10.5.

guillaumemaka commented 9 years ago

From APPLE-SA-2015-08-13-2 OS X Yosemite v10.10.5 and Security Update 2015-006

dyld Available for: OS X Yosemite v10.10 to v10.10.4 Impact: A local user may be able to execute arbitrary code with system privileges Description: A path validation issue existed in dyld. This was addressed through improved environment sanitization. CVE-ID CVE-2015-3760 : beist of grayhash, Stefan Esser

stefanesser commented 9 years ago

There is this misinformation spread that SUIDGuard is just a fix for DYLD_PRINT_TO_FILE. SUIDGuard is a mitigation that stops a class of vulnerabilities (and soon more). If you uninstall SUIDGuard because you upgraded to 10.10.5 you are still vulnerable to other exploits people know and that Apple was informed about as far as I know and that are not fixed in 10.10.5 or in 10.11.

ZappoB commented 9 years ago

Again many thanks for all the help! Yes, this was a real misunderstatement and thank you for clearing it up.

I reinstalled it now.

aanno commented 9 years ago

It's a little off-topic but I have just found out the phantomjs is blocked by SUIDguard, i.e. if I remove SUIDguard as described above, I could use phantomjs again. Is this a security flaw in phantomjs? Or perhaps in nodejs?

stefanesser commented 9 years ago

Do you see any message from SUIDGuard in your /var/log/system.log when you try to use phantomjs ?

lostthetrail commented 9 years ago

@stefanesser Yes, I do.

kernel[0]: SUIDGuard: disallowed execution of binary without a __PAGEZERO segment