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.
What kind of "new threat" is this? All he's saying is that running code on a machine can have affect its state.
The Server Application in Windows 10 isn't running inside of a hypervisor; it's "running on the OS, 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 the Server Application, such that the Server Application will get access to [...] files and directories."
Ionescu says "There are a number of ways that Windows applications could inject code, modify memory and add new threats to the Server Application running on Windows." According to eWeek, "The modified Server Application code in turn could then call Windows APIs and get access to system calls to perform malicious actions that might not be mitigated."
I'll Tell you what else increase your attack surface: Turning the computer on.
Didn't RTFA (naturally!), but the summary fails to convince me that this is more than incrementally worse than running...well...MOST applications that do anything useful on Windows.
a two-headed beast that can do a little Linux and can also be used to attack the Linux side of the system.
FTFY
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
This is just crazy talk. If I'm running Windows I obviously don't care about security.
I'm an American. I love this country and the freedoms that we used to have.
Just like Linux you need to have special privileges to change anything important with the ACL lists of NTFS just like ext3.
I highly doubt malware will target this. I mean besides those using SQL insertion exploits for server databases no one targets Linux on the desktop. No one is going to be running a server with this anyway.
http://saveie6.com/
touch: cannot touch ‘./test’: Permission denied
Doesn't seem to be a problem from that angle at least. Sounds like FUD.
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
You're a regular user and don't have write access to the Windows directory - I don't think that's the problem.
More likely problems are:
- What is "root" mapped to? In windows, an Administrator account does not have full privileges - you need a local or remote system account for that.
- How about setuid and setgid executables? setgid in particular can be problematic, given that Windows doesn't have a concept of both a user owner and a group owner - there's just an owner, and any number of acls.
- Are setfattr and similar commands supported? Windows and Linux stores special privileges as file attributes, and if you can set them, you might open up for gratuitous privilege escalation of the "other" side.
- Are chattr and similar commands supported, and obeyed on the Windows side too? If I "chattr +i file", can I still modify it on the Windows side? Will chattr +d prevent backup?
- Are hardlinks and/or bind mounts now supported? That can give continued access to files or directories after an admin or the system has revoked access to a parent directory.
- What about loop mounts? If supported, I could see vectors of attack, especially through autoplay.
- What about the Windows reserved names, like CON, PRN, NUL, COM1 and such? Linux has no problem with those names.
There's just a lot of stuff to think through, from both a Windows angle and a Unix-like angle. Hopefully, Microsoft has managed to make it safe, two-ways, and let caution prevail over convenience.
But I wouldn't bet my house on it.
Very few people (except developers) will have WSL running on their machines. WSL is isolated from Win32 except via FS access. Just based on it's current state, WSL is practically impossible to exploit thansk to it's limitations. Alex Ionescu is (was?) a ReactOS 'developer'. He has a beef against Microsoft. Disclaimer, in a past life, I was a ReactOS core developer for a certain period of time in the late 90s to early 2000s.
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.
Linux is a kernel. The Linux kernel is not used in this emulation layer, instead it emulates Linux system calls on the Windows kernel. So, there is very little if any Linux in this scheme. Its not Linux.
I don't think this is a wise use of Canonical's resources, a better use would have been greatly enhancing and accelerating Wine development with a goal of getting it to 99% app compatability within 2 years and as well funding a project to provide a driver compatability layer to allow Windows drivers to run on Linux. This would make it easier for people to make a complete move to Linux and to bring their apps and hardware with them, rather than creating a reason for people to stay on Windows.
So, a self-contained system inside a larger system isn't a subsystem?
Implementing such a thing in userland is, in fact, a valid way to make a subsystem. Linux's own dynamic loader is a userspace program (the Linux kernel doesn't know how to load dynamic shared objects); and some systems (e.g. Minix, L4) implement their entire native execution environments and even hardware drivers in userspace.
Besides that,
The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys) that are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces. On native Linux, when a syscall is made from a user mode executable it is handled by the Linux kernel. On WSL, when a syscall is made from the same executable the Windows NT kernel forwards the request to lxcore.sys. Where possible, lxcore.sys translates the Linux syscall to the equivalent Windows NT call which in turn does the heavy lifting. Where there is no reasonable mapping the Windows kernel mode driver must service the request directly.
WSL uses a kernel-level interface to perform the actions required to satisfy POSIX and Linux system behaviors. This includes everything from procfs to execve() calls. File system permissions management is handled by kernel-level decisions on whether or not a program's effective permissions and capabilities mesh with the file system ACL (which is stored as extended NTFS attributes).
WSL doesn't use a kernel-level dynamic loader, and neither does Linux; as you pointed out, it loads ELF programs by using a PE executable process to bring the file into memory appropriately, like Wine. It's only necessary to have one type of kernel-level executable; all others can use a userspace loader, which is why Linux proper only supports static-linked executables and calls ld-linux.so to perform dynamic linking.
You appear to have made yet another post full of wrong information just to be aggressive and mean to other people. It's like your whole day revolves around finding ways to be an asshole to everyone else.
Support my political activism on Patreon.
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 ]