14

Windows Subsystem for Linux (version 2) is getting more and more traction lately with new features being added such as GUI mode over Wayland (WSLg). It seems to me Microsoft really pushes for WSL usage, however, I am worried about the underlying security.

I have read several articles which put me into panic mode.

Running Sensitive Apps in WSL: (SAFE + SAFE) < SAFE https://www.cyberark.com/resources/threat-research-blog/running-sensitive-apps-in-wsl-safe-safe-safe

Whitepaper by F-Secure https://img.en25.com/Web/FSecure/%7B87c32f0e-962d-4454-b244-1bb8908968d4%7D_WSL-2-RESEARCH.pdf

Some excerpts from the above:

The loopback attack, for the WSL 2 VM, is a Local Privilege Escalation vulnerability that is explicitly enabled by the “Lightweight Utility VM” features of WSL 2. This vulnerability does not exist if an equivalent Linux system is run in a full VM under Windows.

The main security risk identified here is credentials theft or theft of other sensitive data processed by Linux applications running inside WSL.

An additional consideration is the security programs that may be active in the machine. To the best of my knowledge and at the time this blog was published, there is currently no known Windows security program that protects Linux files (inside the WSL file system).

Any security programs that might be implemented inside the WSL VM (e.g., maybe protecting SSH keys) will not be active while the attack is carried out.

The use of Hyper-V no doubt improves the efficiency of the system, however its use of “.vhdx” image files makes behavioral and binary analysis almost impossible. This lack of coverage, short of installing an agent on the virtual machine itself, seriously impacts a hunter’s ability to categorize the presence of such a component.

TLDR - WSL is unusable for any kind of work with sensitive data, that is almost any kind of commercial work, and current antivirus programs aren't able to sufficiently defend against these threats.

I'm not a security expert, so I thought I would ask here. Since WSL undergoes a lot of development and the articles are more than a year old, has any of these issues been adressed by Microsoft as of middle 2021?

Seems strange to me they would focus so much on new features and not fix anything this critical. Or is it just me overreacting and this is not really such a big issue? Should I be worried and avoid using WSL 2 for commercial work?

Improve this question
6
  • 1
    You'll have to come up with a threat model to get any specific answers. If the threat model is that the host is not trusted, the conclusion is of course that the WSL environment can't be trusted either.
    – vidarlo
    Commented Aug 31, 2021 at 16:52
  • Furthermore, commercial doesn't mean sensitive. Me developing an application can be commercial - but if it's only used with test data and credentials with minimal access it's not sensitive by any stretch.
    – vidarlo
    Commented Aug 31, 2021 at 16:55
  • 1
    It's as secure as Windows for commercial use.
    – defalt
    Commented Sep 1, 2021 at 5:09
  • 1
    "commercial work" doesn't really say anything about what risks you are worried about. You say "sensitive data" at one point, and that's better, but you still don't give an indication of the threats you are worried about. If your question is simply about whether those issues you quote have been mitigated, then that's a much easier and more straightforward question to answer.
    – schroeder ♦
    Commented Sep 1, 2021 at 8:31
  • 1
    My apologies, to give a more specific example: in my case sensitive data would be source code but also ssh keys for gitlab, and most importantly, I am using linux to connect to client environments with aws cli or kubectl and obviously I need to secure credentials. But really, I can be writing word documents or a photos editing in photoshop and these might be sensitive too. I understand that if Windows host is compromised, WSL is too. But this is not any different from a regular VM. According to the article I linked, in WSL case you can compromise WSL with user process, unlike in regular VM.
    – Samuel
    Commented Sep 1, 2021 at 12:36

2 Answers 2

Reset to default
15

WSL is as secure as any other program running in your Windows user account. It's not suitable for isolating a Linux VM from your Windows host (in either direction); it is designed to simulate the experience of just running user-mode Linux binaries natively on Windows (which is what WSLv1 does). Don't think of WSL as a VM; while v2 technically is one, it is so deeply integrated into the host OS and user session that it's best to assume there's no meaningful security boundary beyond what already exists between Windows processes. That bold part is important: if you have malicious software running on your Windows session, the entire session including WSLv2 is already compromised. You'll note that all the exploits in the first article either require malicious code running in the Windows session, or in the Linux session.

The main way this confuses people is that WSL has its own Linux-based security model. However, this is completely irrelevant to the actual security of the system. Think of it as a toy, or an advisory thing; it might stop you from making a mistake, but it doesn't actually enforce any actual security controls.

Only the Windows security model matters. Running as root inside WSL doesn't actually give more permissions than running as a standard user; the things that you can do from that perspective are 100% exactly the same (in either case) as the things that the user who ran the Windows wsl.exe program (or other WSL-launching command) could do. Similarly, if WSL was launched as Admin, then code running inside it can do approximately everything, even if it's not root as far as Linux is concerned.

Does this make it insecure? Not at all. You just have to remember that everything that runs in the Windows session (whether or not it's also in a Linux session, and regardless of what Linux user it runs as) has the same access. Don't run malicious code. If you need a VM for a sandbox, use one that's configured for isolation, not for seamless integration.

Improve this answer
14
  • 2
    Thank you for your reply but I still have doubts. What if I use firewall and antivirus on Windows host: these will only protect me against Windows-based threats, wouldn’t they? It’s what both articles mention. Indeed, I pay for Avira and texted their support and they confirmed that they are unable to detect malware in Linux binaries, which is what WSL would run. They don’t have a Linux offering, so can’t detect it. So having protection just on the host would leave WSL open to vulnerabilities and if I want to work commercialy in WSL, I not only need to protect the host but the WSL instance too.
    – Samuel
    Commented Sep 2, 2021 at 13:43
  • 1
    Since non-admin Windows processes have access to WSL data (according to articles above), and they can override anything inside wsl, e.g. replace my awscli or kubectl programs with something that leaks credentials to an attacker, and WSL is able to run non-admin Windows processes without root, it’s precisely this kind of integration that basically allows WSL-aware malware in Linux binaries (ie. untraceable by Windows antivirus) to take control of the WSL instance. Am I wrong here?
    – Samuel
    Commented Sep 2, 2021 at 13:44
  • 5
    You're not wrong, your threat model just doesn't make any sense. If you start with the assumption that malicious code is already running on your machine, you have already failed. WSL isn't a sandbox, and sandboxes are the only place you should make an assumption like that. Also, if you're relying on antivirus for anything, you're making a huge mistake... but for what it's worth, Windows AV software (Defender) can detect Linux "malware" (I've seen it twice, both legit tools I'd intentionally downloaded). If you download the malware within Linux, run your AV there.
    – CBHacking
    Commented Sep 2, 2021 at 15:13
  • 3
    @CBHacking Isn't it safe to assume that without any AV installed into the WSL2 instance, malware downloaded into WSL2 will stay undetected and possible act on behalf of the WSL2 user to attack Windows?
    – Shuzheng
    Commented Nov 5, 2021 at 13:15
  • 1
    @SamHobbs The odds that you managed to pick up WSL 2 malware that specifically targets developers using Visual Studio (rather than doing their dev work in WSL) is... look, I'm not saying that it couldn't happen, but it's so extremely unlikely that I really can't imagine why anybody would bother. You understand that such malware could just take over your entire Windows account, right? Why would it bother with merely tampering with the (very visible) requested permissions on a compiled app? That makes no sense. I refer you to xkcd.com/1180
    – CBHacking
    Commented Dec 11, 2022 at 8:51
3

Updated answer:

In a word: yes and no.

Why?

  1. It can be made more secure to an extent by running as a different user, although this requires some tricky maneuvering..
  • AccountA is administrator-level
  • Login to AccountA
  • Create AccountB as Administrator also
  • Logout of AccountA
  • Login as AccountB
  • Set up the distro on accountB (wsl install -d Ubuntu)
  • logout of AccountB
  • login to AccountA
  • Change AccountB to Standard User
  • Open WSL as AccountB (runas /USER:accountB bash)

As long as Account B cannot bypass traverse checking, or login as another user who can, then WSL is now sandboxed into a Standard User.

You can now do things like host a web server without exposing AccountA's files and/or permissions to WSL, essentially locking it into its own namespace.

There is one small issue however. Performance. Routing WSL through RUNAS is extremely slow compared to running it as the current user.

There are also some graphical issues that can arise from this setup and may require special configuration.

Other than that, it could potentially be used in a production environment if one were so inclined.

Then why no?

Because this setup is a major workaround and is not something you could just embed into an EXE and be able to run Linux programs without having to jump through hoops. So, I would consider it not commercial ready. Also, there is no real isolated context in that you can't have a Linux environment that is 100% isolated -- I.E. any program with Windows level access can just do bash -c "rm -rf *" and wipe out your home directory without even logging in.

Improve this answer
2
  • "So, I would consider it not commercial ready" - and you arrived at this conclusion because it "maybe kinda sort not so much tho" can be made safer and a threat model that requires an already compromised Windows instance. Brilliant.
    – Ed Swangren
    Commented Aug 18 at 2:28
  • This may help. Well...t's a good read at least. The man is a treasure. Maybe security analyst isn't in your wheelhouse. Maybe.
    – Ed Swangren
    Commented Aug 18 at 2:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .