Slashdot Mirror
Linux on Windows Exposes a New Attack Surface (eweek.com)
An anonymous Slashdot reader writes:
The Linux in Windows 10 isn't running inside of a hypervisor; it's "running on the raw hardware, getting all the benefits of performance and system access, as well as expanding the potential attack surface." eWeek reports on a new threat discovered by Alex Ionescu, the chief architect at cybersecurity company Crowdstrike, which begins with the fact that "The Windows file system is also mapped to Linux, such that Linux will get access to the same files and directories."
Ionescu says "There are a number of ways that Windows applications could inject code, modify memory and add new threats to a Linux application running on Windows." According to eWeek, "The modified Linux code in turn could then call Windows APIs and get access to system calls to perform malicious actions that might not be mitigated." Ionescu describes it as "a two-headed beast that can do a little Linux and can also be used to attack the Windows side of the system."
Ionescu says "There are a number of ways that Windows applications could inject code, modify memory and add new threats to a Linux application running on Windows." According to eWeek, "The modified Linux code in turn could then call Windows APIs and get access to system calls to perform malicious actions that might not be mitigated." Ionescu describes it as "a two-headed beast that can do a little Linux and can also be used to attack the Windows side of the system."
If the Linux personality has the same level of access to the kernel as the Windows personality, then this is a natural consequence. It's the same as if MS added a dozen new win32/64 APIs that could be exploited by apps with appropriate privileges. New code, new bugs. Total non-story.
Windows Subsystem for Linux processes cannot directly interact with either the win32 subsystem or processes.
Windows Subsystem for Linux Overview [img] :: https://msdnshared.blob.core.windows.net/media/2016/04/LXSS-diagram-1024x472.jpg or WSL System Calls & [img] :: https://msdnshared.blob.core.windows.net/media/2016/06/syscall_graphic.png
This is how UIDs are mapped: Each windows user gets their own copy of Ubuntu installed, located in %LOCALAPPDATA%\lxss. Users exist entirely within the individual Ubuntu installs, so a Windows user can have multiple Linux users within his own virtual Linux filesystem. Files created outside of the Linux environment all have a UID and GID of 0, while the initial default user has a UID and GID of 1000. Only files created within that Windows Users's Ubuntu install have UIDs known to their own Linux install. Of course, this is just how it looks to Linux programs. It is still ultimately limited by the Windows User's own individual permissions throughout the rest of the Windows system.
After googling around a bit. stories about running a bash shell on windows pop up.
It isn't "running Linux" on windows. That would imply that there is a Linux kernel running that actually manages hardware. This impression of "running on hardware" is enhanced by the slashdot summary.
None of this. Windows is simply providing those Linux system calls that allows commandline apps to run. A story then mentioned that servers would not run. That's odd: When "bash" runs and say applications like ping, ssh and telnet, you'd have to go to great lengths to prevent another app like "apache" from running.
But if what I hear is true, this is only useful for the most basic of things, no graphical capabilities. I might be an old fart that uses the commandline a lot, but that becomes useful in combination with a bunch of graphical tools that display what I need to know on a graphical screen.
As to security: the implied trick of running a linux kernel that also has access to the windows block devices is very prone to bugs and security issues. But all that is not the case: It's just another program running in an operating system, using a slightly different set of API calls. If the emulated Linux system calls end up calling windows-internal stuff AFTER the "permissions checking" that normal windows calls would do then you have a problem. It tells a lot about how badly windows is layered.
So is it essentially a new POSIX interface?
No it's not the whole POSIX interface (that used to exist and be called something along the lines like "Unix Services for Windows", but got in practice over taken in popularity by Cygwin - a translation layer between POSIX source code and regular Win32 interface).
WSL implements only a very small subset of Linux kernel's API calls.
Just barely enough to get some Ubuntu user space running, so you can still use Windows to write and test your code before deploying to some Linux cloud.
(instead of using Mac OS X or a real Linux desktop or a VM like everybody else.
There currently nearly no filesystem support (except for the special drivers that Microsoft has written to support passing Windows's local drivers under Linux).
There is very limited network support (you can run apache and even SSH. But forget about NFS)
There's no media at all (no X. no audio. no USBHID/libinput. nowayland/DRM/Mesa hardware/Whatever. no nothing. Its main purpose is to test linux code before deploying to the cluster, so don't expect anything fancy).
No even fabric dummy drivers (that's a bit limiting for the intended purpose...)
Nothing from the Linux kernel internals (no scheduler, etc.)
So maybe with some extensive hacking you could write a zombie node that can take part in some mass spamming or DDOS.
(Basically, anything that you could implement as a not so fancy network daemon under any other OS).
But that's about it. Don't except to circumvent some Windows protection by calling into WSL, it has no access to anything low-level.
(e.g.: Forget about trying to reflash the firmware using some linux sysadmins tools under WSL, or making some advanced stealth keylogger)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]