Portcullis Labs » Linux https://labs.portcullis.co.uk Research and Development en-US hourly 1 http://wordpress.org/?v=3.8.5 Exploring Windows Subsystem for Linux https://labs.portcullis.co.uk/blog/exploring-windows-subsystem-for-linux/ https://labs.portcullis.co.uk/blog/exploring-windows-subsystem-for-linux/#comments Thu, 27 Jul 2017 09:00:04 +0000 https://labs.portcullis.co.uk/?p=5869 Whilst there has been quite a lot of analysis of Microsoft’s new Windows Subsystem for Linux (aka WSL or Bash on Ubuntu on Windows) and how it functions (particularly from Alex Ionescu), most of this has focused on how it affects the Windows security model. Being a keen UNIX focused researcher, I decided to take […]

The post Exploring Windows Subsystem for Linux appeared first on Portcullis Labs.

]]> Whilst there has been quite a lot of analysis of Microsoft’s new Windows Subsystem for Linux (aka WSL or Bash on Ubuntu on Windows) and how it functions (particularly from Alex Ionescu), most of this has focused on how it affects the Windows security model. Being a keen UNIX focused researcher, I decided to take it for a spin.

The first thing I did once I had it installed was look at how the Windows process tree had changed. Running it results in two new branches to your process tree. The first contains the Windows bash.exe instance which hosts your new terminal:

  • explorer.exe (runs as your user):
    • bash.exe (runs as your user):
      • conhost.exe (runs as your user)

Whilst the second contains the Linux process tree:

  • svchost.exe (runs as SYSTEM):
    • init (runs as your user, no disabled privileges, locked into a job):
      • bash (runs as your user, disabled privileges, locked into a job, break away set to true)

As you might expect, new code compiled to support this is well hardened and uses Windows 10′s advanced mitigations. Specifically, bash.exe has the following mitigations enabled:

  • DEP enabled
  • ASLR high entropy, bottom up
  • CFG enabled

Digging a little further, the same can’t be said for init, bash and other parts of the Linux process tree. Whilst DEP is enabled, ASLR and CFG are not. In fairness, this shouldn’t come as any great surprise – they’re Ubuntu packaged binaries however it does start to show show how introducing WSL to your system can change the systems posture.

The kernel

So what does the “kernel” version look like. Well, at the point I examined it:

x@DESKTOP-L4857K3:~$ uname -a
Linux DESKTOP-L4857K3 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

This version of the Linux kernel should be vulnerable to dirty cow, so what of it? It doesn’t work which again isn’t a huge surprise. As Alex has alluded to there is a quite a substantial amount of mapping going on to implement the Linux system calls on Windows and whilst they should be API compatible, the implementations between a real Linux kernel and what WSL gives up may be quite different.

This does however bring up the first critical point: There is no relationship between the patches supplied as part of Windows Update and what goes on with WSL. If you don’t patch regularly you’ll still be vulnerable to a whole plethora of Ubuntu (userland) vulnerabilities.

Memory corruption mitigations

Some Linux mitigations are in play however (as they would be on any real Ubuntu system) as can be seen with checksec.sh:

  • System-wide ASLR (kernel.randomize_va_space): On (Setting: 2)
  • Does the CPU support NX: Yes

And of course binaries are compiled with whatever Ubuntu hardening is currently supported:

	COMMAND    PID RELRO             STACK CANARY           NX/PaX        PIE
	  init      1 Full RELRO        Canary found           NX enabled    Dynamic Shared Object
	  sudo     14 Partial RELRO     Canary found           NX enabled    Dynamic Shared Object
	    su     15 Partial RELRO     Canary found           NX enabled    No PIE
	  bash     16 Partial RELRO     Canary found           NX enabled    No PIE
	  bash      2 Partial RELRO     Canary found           NX enabled    No PIE

Shared memory

So what does WSL look like more generally. Well, since I’ve had some fun with shared memory, I wondered how this was implemented. Well, it turns out that it’s not:

root@DESKTOP-L4857K3:~# ipcs

kernel not configured for shared memory

kernel not configured for semaphores

kernel not configured for message queues

Whether this will have any security implications, it’s difficult to say but at the very least it may stop certain applications from working. Other applications may revert to using other less well tested IPC mechanisms which may expose security issues along the way.

Debugging

Moving on, how about debugging something. A simple tool which exercises the ptrace() system call is strace. Here’s what happens when strace is run on a normal process:

root@DESKTOP-L4857K3:/sys# strace -f printf "test" 2>&1 | head -n 5
execve("/usr/bin/printf", ["printf", "test"], [/* 15 vars */]) = 0
brk(0)                                  = 0xa9d000
...

However you can’t strace PID 1 (as would have been possible on real Linux), instead ptrace() returns an error: “Operation not permitted”.

File systems

Whilst /mnt doesn’t show up as a different file system, /mnt/c is actually used to map the underlying Windows system disk. This is immediately peculiar since it is mapped with permissions of 0777 (world readable, world writable amongst others). Moreover any files created under it are created with an owner of root. You’d think this might be a problem but from what I’ve seen so far, assuming the Windows file permissions are set right then (because everything (even setUID processes) runs as you from Windows’ perspective) you won’t be able to access anything inappropriate (think SAM etc). It. Just. Looks. Weird.

Furthermore, the way that WSL implements umasks too is an oddity. umask doesn’t work on all file system types and in particular the aforementioned /mnt/c. Observe the following:

root@DESKTOP-L4857K3:/# umask 666
root@DESKTOP-L4857K3:/# touch foo
root@DESKTOP-L4857K3:/# ls -la foo
---------- 1 root root 0 Mar 28 23:10 foo
root@DESKTOP-L4857K3:~# rm foo
root@DESKTOP-L4857K3:~# cd /mnt/c/Users/x/
root@DESKTOP-L4857K3:/mnt/c/Users/x# touch foo
root@DESKTOP-L4857K3:/mnt/c/Users/x# ls -la foo
-rwxrwxrwx 1 root root 0 Mar 28 23:10 foo

Umask is honoured in the first location but not the second (a umask of 0666 should mean that files are created with no permissions). Whilst there’s a fundamental Windows reason why this is the case, there is nothing to indicate this to the Ubuntu instance’s userland and thus files created within your home directory might be created with undesirable permissions. Microsoft are tracking this in the GitHub as issue 352.

Authentication

Unlike on a real Ununtu there’s no terminal level authentication (whilst user accounts within the Ubuntu instance do have passwords, they’re not needed unless you want to access the system remotely or gain root privileges via sudo). Moreover, from Windows’ perspective there is no difference between UID 0 and UID 1000. You can start a terminal and then use sudo to elevate your privileges and Windows will be none the wiser (Linux capabilities aren’t mapped into Windows user rights or special tokens). That might mean that users won’t care too much about their Ubuntu instance’s passwords but as you can imagine with no password policy enforcement, users might be tempted to reuse their Windows passwords.

I should also note that whilst sudo prompts for a password on each new instance of bash.exe/conhost.exe pair hosting a terminal however if you authenticate to sudo, close the terminal and then reopen it, then your sudo ticket may still be valid – this requires exact co-ordination as sudo sessions are tracked by PID, however the first terminal opened will always have a Linux bash process with a PID of 2 which may well be blessed from a previous sudo session.

Privileges

Finally, as per issue issue 561, because everything runs as you from Windows’ perspective, the only way to successfully execute ping (which requires an ICMP raw socket on Linux) is to run bash.exe in elevated mode (as Administrator). This, despite the fact that a non-elevated user can quite happily execute ping on the Windows host. WSL doesn’t even implement concept of root in any real sense, let along implement the necessary Linux syscalls to support capabilities in any useful fashion. This in turn means that everything else spawned from the elevated shell also runs with Windows administrative privileges. For comparison, here’s what the new branches of your process tree will look like:

  • wininit.exe.exe (runs as SYSTEM):
    • services.exe (runs as SYSTEM):
      • svchost.exe (runs as SYSTEM):
        • RuntimeBroker.exe (runs as your user, disabled privileges, not elevated):
          • bash.exe (runs as your user, disabled privileges, elevated):
            • conhost.exe (runs as your user, disabled privileges, elevated)

The first contains the Windows bash.exe instance which hosts your new terminal, whilst the second contains the Linux process tree:

  • svchost.exe (runs as SYSTEM):
    • init (runs as your user, no disabled privileges, locked into a job, elevated):
      • bash (runs as your user, disabled privileges, locked into a job, break away set to true, elevated):
        • sudo (runs as your user, disabled privileges, locked into a job, break away set to true, elevated):
          • ping (runs as your user, disabled privileges, locked into a job, break away set to true, elevated)

Microsoft’s stock answer is that the Ubuntu instance (or rather the bash.exe instance hosting the terminal and accompanying lxss.sys kernel implementation) is locked down, effectively sandboxed by a combination of Windows DACLs, the concept of jobs (touched upon at the start and akin to Linux cgroups) and syscall mapping that effectively uses lxss.sys to proxy most syscalls onto their corresponding NT kernel implementation.

Conclusion

The design of WSL seems to be relatively robust if slightly odd, however time will tell, particularly if offensive teams pick up the whiff of a new opportunity. If nothing else, take this article as a reminder that WSL should not be considered a security boundary and that it will remain unmanaged irrespective of how you administer your Windows hosts.

The post Exploring Windows Subsystem for Linux appeared first on Portcullis Labs.

]]> https://labs.portcullis.co.uk/blog/exploring-windows-subsystem-for-linux/feed/ 0 UNIX and Linux setUID advice and guidance https://labs.portcullis.co.uk/blog/unix-and-linux-setuid-advice-and-guidance/ https://labs.portcullis.co.uk/blog/unix-and-linux-setuid-advice-and-guidance/#comments Fri, 16 Jun 2017 14:41:53 +0000 https://labs.portcullis.co.uk/?p=5793 It is a topic that often comes up on client engagements, usually when running structured build reviews of Linux “gold builds”, but occasionally when trying to explain in detail how we used a Linux system to pivot internally. SetUID and setGID files are inevitably a risk, potentially allowing attackers to elevate privileges to root from […]

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

]]> It is a topic that often comes up on client engagements, usually when running structured build reviews of Linux “gold builds”, but occasionally when trying to explain in detail how we used a Linux system to pivot internally.

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

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

]]> https://labs.portcullis.co.uk/blog/unix-and-linux-setuid-advice-and-guidance/feed/ 0