"WSL is a supplemental feature that runs a Linux image in a near-native environment on Windows, allowing for functionality like command line tools from Linux without the over-head of a virtual machine."
But since WSL 2 it does use a VM. According to wikipedia:
"a real Linux kernel,[4] through a subset of Hyper-V features.""with a Linux kernel running in a lightweight virtual machine environment."
edit: unless they mean user overhead of getting it to work. I kind of read it as performance overhead.
As a related sidenote: Try doing an apt install metasploit inside a "VM" while an antivirus is running on the host.
You'll soon realize that the "VM" will be bricked by quarantine actions on the NTFS based filesystem, which kind of defeats the reason of the V in VM.
I fear once more people realize this, there'll be NTFS stream based "hidden" malware and other filesystem rights abusing tools everywhere all over again.
That’s because the VM has hooks into the host filesystem though, isn’t it? Does it still happen if the VM is fully isolated from host resources (files, ports, devices)?
I didn't test whether or not LUKS or similar filesystem level encryptions are transparently mapped to the Windows kernel.
Might be a good way to avoid this behavior. The default (from the Windows Store) Ubuntu based VM however doesn't use filesystem level encryption, and every folder or file inside the "VM" is available somewhere buried in the Roaming folders.
Yeah, you'd have to install LUKS or eCryptfs or something, but I think it would be worth a try. I expect Windows would only see the encrypted files then.
When installing WSL you can still choose if you want to use WLS 1 or WSL 2, and you can switch between them. If you keep your files not in the WSL filesystem, WSL 1 is still the recommended choice because of the lower overhead for file access.
Plus WLS 1 is marginally easier to install because you don't have to enable Hyper-V
Is WSL still opt-in? Something to be aware of for power users, but most Windows users are never going to know about or figure out how to turn on WSL (at least as of the last time I tried it).
The install process for WSL is still fairly complex for mainline Windows builds. However, in the preview channel, it's mostly just "wsl.exe --install". And that wsl.exe ships with the preview builds. I can see this being a bigger target once that feature is pushed down to the mainline windows builds. It does still require admin rights.
Most Windows users are also never going to know how to get Microsoft Office on their Computer when it doesn't come preinstalled. Usually people have other people who do things like this for them
In all fairness, things were a lot easier back then. Installers all had the same UI and you knew where to find them afterwards. Now the UI is different for all of them and you have no idea where the program went when it finished installing.
It was possible to download an installer from Microsoft 15 years ago (except MSDN)? For most people getting Office meant trip to the store and getting a box with physical CD.
A link to download an Office Trial, which at the time was just the full version of office which worked without a key for a trial period.
I seem to recall there was an online store for Office to purchase a key.
Though, I suspect you're right, most people probably bought a box back then. These days, I'd expect the average consumer to use the preloaded Office stubs on new PCs.
This seems like a symptom of forgetting 2006 was 15 years ago. I did the math this time but if someone off hand mentions 20 years ago I still think of the 90s.
Ha, you're right, I might have overshot my time period a little. I was thinking Windows 7 era, plus some late Vista/XP. Wikipedia tells me Windows 7 was released in 2009, so my statement would probably hold better if I'd said "around 10 years ago". But on the whole I think it's close enough :)
Really? I think they will just Google "buy Microsoft office" and follow the instructions on the first link that pops up. Or buy it from the Windows store app.
Yes, and I believe enabling it requires administrative rights so the risk to a lot of organizations with locked down Windows installs is minimal unless they’ve enabled WSL intentionally
That's interesting. The mainline builds seem to require running dism.exe with admin rights, and the preview builds require running "wsl.exe --install" with admin rights. Curious how you got around that.
Pretty much all government contractors use windows for bureaucratic and spying purposes. Good luck convincing your security-minded boss to let you have a linux playground when it increases attack surface area.
Interesting, though it doesn't explain how it's invoking WSL. As far as I know, you would need a second part of the payload that invokes WSL and runs the ELF binaries.
I think the idea is that the user would run these malicious binaries in WSL themselves, thinking it's a safe environment for testing. But actually, anything run in WSL will have the same privileges as the user who started the session, due to the interop features (even if it's not running as root in WSL).
from what i read, it just sounds like the issue is that windows virus scanners haven't been updated to check hashes for elf binaries. wsl added a new executable type to windows and the virus scanners haven't caught up, so now you can have these malicious elf binaries laying around that a user could run and the virus scanner will ignore them.
the nature of the ones they found sound simplistic. just python scripts in one of those self extract and run bundled python interpreter and included script single file executable archive things.
It sort of hints that you could coax LxssManager.dll into running an elf binary without WSL itself really running. Though you would need to do some things to make lxss happy, so it's not trivial.
But there's no advantage to starting with a Windows binary and executing a Linux binary just to have it execute a Windows binary again. You may as well just start with the final payload if you are already able to run code in Windows, there's no point invoking WSL in that scenario at all. I am pretty sure the attack scenario imagined here is regarding Linux binaries executed in WSL by the user or other software inside WSL, not code which was already running under Windows.
How about this.
May be this is a bad idea too.
Can we have like WSL3, where highly optimised Linux kernel runs on hypervisor. And Ubuntu/arch share the kernel using containerised approach.
And individual apps too can run using the same workflow?
That way we have benefits wrt overhead.
Something like electron but they all use the same ringtone instead of a new instance.
Again it may be a bad idea, just curious of the benefits.
I'm having issues parsing your comment, but WSL2 is already a single Linux VM with containers for each "distribution". That's how the /mnt/wsl/ thing works — it's just a mount mapped into your container. Also, all distributions share a network namespace.
Oh, I thought each instance of the os has its own VM upto now.
Still, I wish it would be more native experience rather than depending on docket desktop, if it makes sense.
If you install separate WSL2 images for each app it does. If you go the container route with Docker (or your container orchestrator of choice) naturally they'll be shared.
But since WSL 2 it does use a VM. According to wikipedia:
"a real Linux kernel,[4] through a subset of Hyper-V features." "with a Linux kernel running in a lightweight virtual machine environment."
edit: unless they mean user overhead of getting it to work. I kind of read it as performance overhead.