New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security: It's possible to debug elevated (UAC Win32 perms) WSL processes from non elevated ones. #626

Closed
xilun opened this Issue Jul 3, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@xilun

xilun commented Jul 3, 2016

Example:

  1. Start an elevated bash.exe, check you can see admin only stuff e.g. ls /mnt/c/Windows/System32/sru
  2. Start a second bash.exe, this time non-elevated, so be sad when ls /mnt/c/Windows/System32/sru yields "Permission denied".
  3. From the non-elevated bash, gdb the elevated bash process.
  4. It works! Hack the planet!
  5. Profit :)
@fpqc

This comment has been minimized.

fpqc commented Jul 4, 2016

Wow, great catch! I bet you could turn this into an exploit pretty easily!

@zhykzhykzhyk

This comment has been minimized.

zhykzhykzhyk commented Jul 5, 2016

If both elevated user and restricted user are using the same linux user account, the attack may be trivial by using something like .bashrc, and almost unavoidable.

@zhykzhykzhyk

This comment has been minimized.

zhykzhykzhyk commented Jul 5, 2016

I think root as elevated and #285 may be a good idea to solve the security issue although many one against it.

@fpqc

This comment has been minimized.

fpqc commented Jul 5, 2016

@zhykzhykzhyk Well, maybe if they decide to do that, they can also make a proper sudo/elevate for powershell that doesn't require launching a new terminal window.

@xilun

This comment has been minimized.

xilun commented Jul 5, 2016

@zhykzhykzhyk you're right, I did not think about that. There are probably many way to use an elevated bash to perform uac bypass, and the only sane way to close all the hole seems to be more mapping between Wsl and regular Win security. However simply mapping root to admin is problematic because of the usage model: non-admin users would not be able to administer their wsl instance.

So I guess running bash as elevated should always be considering as a risk of allowing UAC bypass, and the users should be at least warned about that.

@xilun

This comment has been minimized.

xilun commented Jul 5, 2016

Maybe a mitigation would be to only allow effective usage of the admin right, if present, by root. This way with a strong enough password, this seems to restore more security (probably not perfect). This is a little complicated, though.

@stehufntdev

This comment has been minimized.

Collaborator

stehufntdev commented Jul 5, 2016

Thanks for reporting the issue! We will take a look.

@benhillis

This comment has been minimized.

Member

benhillis commented Feb 3, 2017

We have resolved this in recent Insider builds by only allowing processes of one NT integrity level in WSL instances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment