Use interop to dump /etc/shadow

[fpqc]

Inside of bash, run:

/mnt/c/Windows/System32/cmd.exe /c type "C:\Users\fpqc\AppData\Local\lxss\rootfs\etc\shadow"

I don't know how complete/robust you're going to make the WSL security model, but with this first release of interop, you can easily jack your shadow file.

One way to do this is to maybe require root permissions to even do interop at all, but that seems restrictive and maybe you can try to figure out a way to be a bit less restrictive.

This obviously won't get you escalation of privileges at the Windows level, but it's something to think about.

[fpqc]

Granted, if someone malicious got a hold of a shell before you could do interop, they could probably have owned the user's account by wgetting a malicious file to %appdata%\Microsoft\Windows\Start Menu\Programs\Startup

Maybe an answer is to have a whitelist of areas that you can access on the DriveFS mounts. One way to implement this in Windows would be to make it so the Linux instance runs with a low-privilege user token, and you can whitelist a folder by sharing with the low-privilege user?

Or (not to cast aspersions), you could just do the MS thing and say that WSL root is not going to be a security boundary, which is a perfectly reasonable answer. Maybe set the DriveFS mounts to only be accessible and executable by users in a specific group (this is something that ntfs-3g can do on Linux). Without some kind of serious effort possibly beyond the scope of the project, I doubt that you will be able to seriously distinguish (in security terms) between any user with DriveFS access and root, since DriveFS access with or without ability to execute Windows programs as the User will always enable you to trivially get root by editing /etc/shadow or dropping something in the startup folder.

Potentially you could make things a bit more fine-grained, like selective driveFS mounts and requiring sudo for execution of Windows .exe files, and that could be pretty easy. Once you let any WSL user execute cmd.exe though, it's game over without reflecting something nontrivial in the Windows-side ACLs.

[rodrymbo]

%LOCALAPPDATA%\lxss is pretty well restricted to the user's account, at least it is as long as Windows hasn't already been corrupted, or as long as the user or an administrator doesn't make a change herself. Considering that someone with access to the user's account can use lxrun to switch the defaultuser to root, then log in to WSL's root without a password, where she could do anything to /etc/shadow (except for rare times when the file is locked by another process), being able to do it from outside the WSL environment with the user's Windows account is not a huge additional risk.

Accessing one user's %LOCALAPPDATA%\lxss from a different account, without the owner or an administrator giving access, implies that a non-trusted (or non-trustworthy) person has access to the whole machine, so the game is already over.

Replacing the hash in /etc/shadow might be possible from outside the WSL environment, if one can get the file's extended attributes right, but since one can do it from within WSL anyway (by logging in as root), there's not a huge additional risk.

If the password hash in /etc/shadow is something that can be broken easily, it might reveal the user's Windows login password (if they are the same). I'd guess the hash is not that easy to break, at least this week, and the risk could be mitigated by not using the same password.

If someone without access to the user account has ill-gotten credentials (or a privilege escalation, or physical access) to give herself access to that user's %LOCALAPPDATA%\lxss, the game is already over and nothing on the machine can be trusted.

The main problem might be from an untrustworthy application running in WSL, unprivileged. The user might expect that the application would have no access to things like /etc/shadow, and might be surprised if the program gives itself access via the CMD /c trick. But there are already lots of programs that the user can run that do nasty things on her computer.

I can see a (user experience) problem with a user snooping around on her own machine and saying "I wonder what would happen if ..."

Still, you raise some good points.

[fpqc]

@rodrymbo I mean, here is the situation I was imagining:

I decide to run sshd on my machine, and I give my buddy a shell account with an unprivileged user and non-sudoer.

Buddy is using the shell for whatever people like to use shells, and then he realizes he can own my user account by executing windows applications with cmd (or before that, dropping it into my user's startup folder).

So at this point he's elevated permissions from an unprivileged shell account to root, and now if I'm running idk a webserver or service or whatever, he's got control.

I think that a reasonable and simple way to have some security is to mount DriveFS restricted to a certain user group.

[goreliu]

Enable or disable interop according to different users and chroot may solve this problem.

[fpqc]

@goreliu Yeah, I would protect interop with a usergroup and make it 770

[rodrymbo]

@fpqc I'd call that untrustworthy behavior. WSL is specifically not designed to be a multiuser-safe environment, or at least that was my interpretation of the way it is implemented. So if you give someone access to a user account that way, it's with the understanding that they are making changes to (parts of) your (Windows) machine with your (Windows) credentials, even if they restrict themselves to playing by the rules.

Not sure how the devs would respond to the suggestion that interop be restricted to a group or to certain users, but they'd need to implement such a change; whereas the /proc/sys/fs/binfmt_misc/WSLInterop lets one disable interop for everyone for one session.

[goreliu]

@fpqc Just chmod or chown /dev/lxssclient after starting bash.exe works for you.

$ ll /dev/lxssclient
crw-rw-rw- 1 root root 10, 51 2016-10-24 08:52 /dev/lxssclient
$ /init cmd /C echo aa
aa
$ sudo chmod 660 /dev/lxssclient
$ /init cmd /C echo aa
Failed to open /dev/lxssclient: Permission denied
$ id
uid=1000(goreliu) gid=1000(goreliu) groups=1000(goreliu),10(wheel)

[fpqc]

@goreliu Yeah, even still, would gate off the whole /mnt/c as .

[goreliu]

@fpqc You can use chroot.

[root@my-pc ~]# pwd
/root
[root@my-pc ~]# mkdir new_rootfs
[root@my-pc ~]# mount -o bind / new_rootfs
[root@my-pc ~]# mount -o bind /dev new_rootfs/dev
[root@my-pc ~]# exec chroot --userspec=goreliu:goreliu new_rootfs /bin/zsh
my-pc% ls /mnt
my-pc%

Then this goreliu can't access any files in /mnt/c. You can also start a sshd after chroot new_rootfs /bin/zsh.

[shawnz]

It seems like allowing any kind of interop is equivalent to giving root access. So why not just require root?

[fpqc]

@shawnz idk, because you shouldn't be running a production server on WSL atm lol, and it would be inconvenient to require root now. If WSL does ever make it into the server platform, they probably will do something like that.

[shawnz]

Can this issue be revisited, now that WSL is available on Windows Server?

[therealkenc]

Oddly I think this one is pretty much addressed since 17063. In some alternate universe where you wanted to allow untrusted users to ssh into your WSL instance, assign those users to a guest group and mount your DrvFS drives without global read permission.

In any case, the FAQ still stands on this, so there isn't much to revisit.

Also, even though you will be able to run many popular server applications (e.g. Redis), we do not recommend WSL for server scenarios – Microsoft offers a variety of solutions for running production Ubuntu workloads in Azure, Hyper-V, and Docker.

[fpqc]

Yep!

[shawnz]

In some alternate universe where you wanted to allow untrusted users to ssh into your WSL instance [...]

By the same logic, it should be no problem to run every service as root on Linux as long as they don't give shell access. But obviously that's not an acceptable practice for many reasons.

[fpqc]

@shawnz If you allow someone to have interop, he can mess with your %localappdata%. The answer is to restrict interop to trusted users. Interop access is equivalent to root access.

[therealkenc]

By the same logic, it should be no problem to run every service as root on Linux as long as they don't give shell access

I said you can give them shell access in this alternative universe where it is a supported scenario. Your shell users can't use interop because they do not have read access to /etc/shadow, or anything else. Or clarify what it is you would like revisited.

[shawnz]

My apologies @therealkenc, I did misread your post.

The point I was trying to make is that this vulnerability is not just applicable in situations where you are giving people shell access to your WSL environment. It is applicable in any case where you are dealing with untrusted software or data.

For example: consider I'm running a network service in my WSL instance that turns out to be vulnerable to a remote code execution attack. Unless I specifically disallow every WSL network service's access to drivefs (which is a rather complicated configuration) then such an attack could easily lead to privilege escalation also.

Furthermore, let's say i am running some untrusted code in my WSL instance such as a shell script I downloaded from the internet. This is not such an uncommon circumstance (e.g: build scripts for a source code package). I wouldn't run with 'sudo' because it's untrusted, but due to this vulnerability, having drivefs access is equivalent to having root. That is very atypical and i imagine most users would not realize that they ought to be running such untrusted code in a seperate user with no drivefs access.

I think at the very least that this caveat should be documented in a visible place.

[therealkenc]

We'll skip the "if I was vulnerable I'd be vulnerable" scenario. I'm too old for that. Yes.

Your script scenario, okay. There is merit to that, in the sense that usually in a VM type environment (but not Cygwin), when you're sharing a drive with windows, you (a) have to make an active decision to do so (which is self documenting), and you (b) get to chose a directory tree. That's #2778, and I hope we see this implemented (in my own alternate universe of my own we'd have bindfs).

But even here, if you are worried about this scenario, you're already terrified of running Visual Studio with source/scripts you've downloaded from the Interwebs. And, well, I don't think you are. But on the chance you are, then you're just saying you don't want to give yourself interop privileges. And you can do that: require sudo winusr (alias winrun) to give yourself access to the DrvFS mounts. Bearing in mind you haven't given yourself Windows User admin privileges (right), so you can't scribble all over C:/ to begin with, naturally 😉.

[shawnz]

We'll skip the "if I was vulnerable I'd be vulnerable" scenario. I'm too old for that. Yes.

But it is a scenario that is accounted for in the Linux security model. This is what I meant to say with my earlier post -- just because a service does not explicitly provide shell access to its users, doesn't mean that it is safe to run that service as root. Similarly on Windows, we have privilege separation for network services because this is a reasonable and genuine concern.

you're already terrified of running Visual Studio with source/scripts you've downloaded from the Interwebs.

No, because I have UAC enabled on my workstation which offers the same kind of security that 'sudo' does on Linux. The appearance of a UAC dialog clearly indicates that something is attempting to use administrative privileges, in the same way that the sudo password prompt clearly indicates that something is attempting to use root privileges. However, by using this attack, the sudo password prompt would never be displayed and so there would be no indication that system files might be modified.

Your suggestion of creating a separate user with no drivefs access does mitigate the problem, but my concern is that that configuration should be the default if you want to be consistent with the actual security model of Linux. Otherwise, why not just use the root user all the time in WSL? Why even create a non-root user at all? You could just let users create their own non-root user if they care about privilege separation. That would surely be the most convenient solution, but obviously that's not acceptable. Similarly I don't think it is acceptable for drivefs to be available to non-root users in the default configuration.

[therealkenc]

...just because a service does not explicitly provide shell access to its users, doesn't mean that it is safe to run that service as root.

See, I learned something today after all. 👍

...that configuration should be the default if you want to be consistent with the actual security model of Linux. Otherwise, why not just use the root user all the time in WSL? Why even create a non-root user at all?

Okay to me. Sounds like you should probably run as root until the default is changed. If I follow your reasoning correctly. Bonne chance.

[shawnz]

Why the sarcasm? I'm not trying to create a problem for you. I use WSL every day and think it is a fantastic system. However I think this is a serious and non-obvious security concern which is being brushed away without even any documentation. This behaviour will only be harder to change/mitigate in the future when other software has come to rely on it.

[therealkenc]

Apologies. The non-sequitur was one bridge too far. With the metadata mount option, a normal WSL user cannot read /etc/shadow. That the default is not -o metadata does not make all users the same as root. Nothing has been brushed away; your hypothetical has to reach into /mnt/c/.../Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState and that has to happen deliberately not by accident. And if you are worried about that, then you should be more worried about said script dropping a replacement wget into ~/.local/bin, which is sitting right at the front of your $PATH (ditto Real Linux). That isn't obvious either, but understanding the nonobvious is why they pay us developers the big bucks. Furthermore, in a development environment, it is not quoth "very atypical" to have write access to C:\. There is no uid:gid on NTFS and "root" has no meaning there. That's the whole reason #1854 was brought up. It was wide open from the get-go (before the metadata on DrvFS) because there is 20 years of precedent for writing there; nevermind an imagined future where WSL somehow changes programming practice for the worse. If you disagree with any of this, I can respect that. In that case Docker might be a better fit for you.