Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Microsoft Operating Systems Security Ubuntu Windows Linux

Linux on Windows Exposes a New Attack Surface (eweek.com) 228

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."
This discussion has been archived. No new comments can be posted.

Linux on Windows Exposes a New Attack Surface

Comments Filter:
  • by Dog-Cow ( 21281 ) on Sunday August 07, 2016 @11:50PM (#52662729)

    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.

    • I'm glad you beat me to typing "NO SHIT".

      Next story we're gonna get is, "If you install a database or 3rd party program, the attack vector gets larger!"
      • by Anonymous Coward on Monday August 08, 2016 @03:28AM (#52663257)

        It's not fucking Linux unless it runs the Linux kernel.

        • by Vitus Wagner ( 5911 ) <vitus@wagner.pp.ru> on Monday August 08, 2016 @07:03AM (#52663749) Homepage Journal

          It is really a GNU subsystem for Windows.

          • Re: (Score:3, Insightful)

            by Anonymous Coward

            it's really just another attempt by microsoft to sour the reputation of linux.

          • by Junta ( 36770 ) on Monday August 08, 2016 @09:36AM (#52664273)

            Actually, it's not GNU either. It's an implementation of Linux kernel system calls. It only becomes GNU-ish after installation of Ubuntu libraries.

            It's not a Linux kernel, it's not an emulator, it's an alternative implementation of Linux system calls.

            • So is it essentially a new POSIX interface? Why don't they just call it that?
              • by danbob999 ( 2490674 ) on Monday August 08, 2016 @10:17AM (#52664495)

                it's not a POSIX interface, it runs native Linux (not BSD, not OS X, not other POSIX OS) AMD64 binaries

              • Not the whole POSIX. (Score:5, Informative)

                by DrYak ( 748999 ) on Monday August 08, 2016 @04:10PM (#52667217) Homepage

                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)

      • ANY program you install that even remotely thinks about accepting input in any way is a potential attack vector. Why do you think anyone who has even a passing interest in his computer's security is up in arms about all the "free" crapware programs delivered with a new laptop?

    • It's not even that. You are NOT running linux under windows. There is no such thing. Even Canonical admits that. It's just parts of the Ubuntu user space [ubuntu.com]. No linux kernel. No vm. No container. Nada. Think of wine in reverse.

      Linus (or rather, the linux foundation) should sue for slander for anyone calling it "linux under windows."

      • by retchdog ( 1319261 ) on Monday August 08, 2016 @02:48AM (#52663189) Journal

        I'd just like to interject for moment. What you're referring to as Linux, is in fact, GNU/Windows, or as I've recently taken to calling it, GNU plus Windows. Linux is not an operating system unto itself, but rather another possible alternative for a fully functioning system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as (sort of) defined by POSIX. This so-called Linux distribution is really a distribution of GNU/Windows!

        • by Dr.Dubious DDQ ( 11968 ) on Monday August 08, 2016 @06:51AM (#52663713) Homepage
          The kernel is actually "NT", I believe.

          Therefore, it really ought to be "GNU/NT" (pronounced "guh-nunt", because that amuses me for some reason.)

        • Only freetards insist on calling it GNU/anything. Bet you won't be calling it Oracle/Gnu/Linux if it has mysql or openoffice or Java installed. Same as you won't call it Adobe/windows if it has photoshop installed.
          • Only freetards insist on calling it GNU/anything. Bet you won't be calling it Oracle/Gnu/Linux if it has mysql or openoffice or Java installed. Same as you won't call it Adobe/windows if it has photoshop installed.

            So, isn't OS X/macOS much closer to a "Linux hybrid" than this is? I know that macOS is not built on a Linux Kernel; but as far as being something other than just the smoke-and-mirrors thing that this appears to be, isn't macOS MUCH closer to the "heart of Linux" than this "Inverse WINE" clusterfuck?

          • by sjames ( 1099 )

            That's because you have a usable system without a database or image editor. A kernel with no userspace isn't useful.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        Anyone who wants to learn more about this can read up on the Windows Subsystem for Linux [microsoft.com]. Quoting from the linked overview:

        WSL executes unmodified Linux ELF64 binaries by virtualizing a Linux kernel interface on top of the Windows NT kernel. [...] 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.

        -PCP

      • But if it has things like hardware access, ain't that like how FreeBSD supports Linux jails? Allow them direct hardware access, while doing API level translation of Linux to BSD system calls? How exactly is this different, or worse? And does Microsoft translate Linux API to win64, or just let it run raw on the hardware?
        • Think of it as a shim. The binary makes the call to the shim, the shim calls windows code.
          • That's not really a good way of thinking about it. A syscall layer translates from some public API into a set of internal calls used by the kernel. Windows provides a few syscall layers already (32- and 64-bit versions of the Windows system call layers, at the very least and others depending on the version of Windows that you're using). This provides another that translates from the Linux system calls.
        • It's exactly the same as FreeBSD's Linux syscall layer (and Linux's various SysV and so on syscall layers). Win64 is a higher-level set of APIs (the Windows syscall interfaces are not very documented and you're strongly discouraged from using them), this is not translating them into Win64, it's using the same kernel services that it uses to implement the syscall interfaces used by kernel32.dll to implement the Linux syscalls. Oh, and there's also an ELF loader.
      • Linus (or rather, the linux foundation) should sue for slander for anyone calling it "linux under windows."

        Maybe we should call it NotGnuDows ?

    • Non-story?
      It somewhat endangers straight-up Linux users. Exploitation of software flaws in Ubuntu LTS will be more sought after by hackers and criminals, as that allows to reach a population of Windows "power users" who might or might not be careless (gamers who started with Windows 95 or XP and think they have computer skills because they buy expensive hardware and plug it together. But well, no reason more knowledgeable users can't get owned)

    • by gweihir ( 88907 )

      Indeed. And what is even more, having Linux user-space components running on top of a translation layer is not new either. Cygwin has been doing it for ages.

      • by Anonymous Coward on Monday August 08, 2016 @05:11AM (#52663489)

        Ummm no, this is explicitly /not/ what Cygwin does. Cygwin provides a Unix-style /API/, not a Linux /ABI/. You can't run an unmodified Linux binary under Cygwin, you get to recompile your source.

        • by gweihir ( 88907 )

          And that matters why? You have the same translation layer, just in a slightly different place vertically.

      • by DrXym ( 126579 )
        A bad example since Cygwin is basically a kludge DLL with Posix functions and path mapping that allows recompiled binaries to think they're running against some kind of *nix environment.

        A GOOD example would be coLinux which came out years ago and genuinely allowed a Linux dist like Debian to run in Windows at full speed. It wasn't a VM but used a modified kernel that ran over a low level driver. As far as the dist was concerned it was Linux but it was running over Windows.

  • This seems circular:

    Windows applications could inject code, modify memory and add new threats to a Linux application running on Windows.

    Is this some privilege escalation scenario for the original "Windows applications" against its own system via Linux subsystem?

    Isn't that a bigger problem with the subsystem implementation?

    • by mysidia ( 191772 )

      This seems circular:

      It's totally circular..... you compromise the windows bits, then use the compromised Windows bits to compromise the Linux bits, then use the compromised Linux bits to compromise the Windows bits.

      Why wouldn't you just use the initially-compromised Windows bits to wreak your evil and be done with it, then?

      Unless your evil is corrupting the Linux-based application and making the Linux application serve bad data..... but that's not

      sir[rosomg eother/ riw jbiw///

      • If you're running code locally, why is it even a compromise? Isn't it allowed to delete your stuff, if that is what it does?

        • If you're running code locally, why is it even a compromise? Isn't it allowed to delete your stuff, if that is what it does?

          I would think the danger is privilege escalation: since Windows now includes some basic sandboxing and system protection from apps in user space, if such an app were able to use the Linux-y part of Windows to run code with system access, then hilarity would ensue.

    • mzzt@TEMPE:/mnt/c/Windows$ touch ./test
      touch: cannot touch ‘./test’: Permission denied

      Doesn't seem to be a problem from that angle at least. Sounds like FUD.

      • by arth1 ( 260657 )

        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

    • Re: (Score:2, Redundant)

      Repeat after me - there is NO linux subsystem. You're just running some ubuntu user space code the same way that linux can run windows code - think "wine".
      • 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 syst

        • No, because in this case there is no linux kernel code in it. Drivers are not kernel code - that's why the whole fuss about free/open and proprietary drivers, and how the linux devs refuse to look at bugs that the dump reveals are using a tainted kernel - one that is running on a system with proprietary drivers. You would know that if you had a clue, instead of being determined to be an ass.
  • Clickbait (Score:4, Insightful)

    by real gumby ( 11516 ) on Sunday August 07, 2016 @11:50PM (#52662735)

    What kind of "new threat" is this? All he's saying is that running code on a machine can have affect its state.

  • *yawn* (Score:5, Insightful)

    by jargonburn ( 1950578 ) on Sunday August 07, 2016 @11:55PM (#52662755)

    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.

    • 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.

      True enough; but there "Increments" come in all sizes, shapes and forms.

      If history has anything to inform us with here, it is that Microsoft is REALLY bad at securing inter-process communication. (e.g. Windows Shatter Attack?). And this looks to be one HONKIN' huge inter-process conduit...

  • by Hylandr ( 813770 ) on Monday August 08, 2016 @12:01AM (#52662777)

    a two-headed beast that can do a little Linux and can also be used to attack the Linux side of the system.

    FTFY

    • a two-headed beast that can do a little Linux and can also be used to attack the Linux side of the system.

      Privilege escalation is not a new thing. If you trust any Microsoft container solution to be unbreakable, you deserve exactly what you get.

  • Crazy Talk (Score:3, Funny)

    by frovingslosh ( 582462 ) on Monday August 08, 2016 @12:04AM (#52662793)
    This is just crazy talk. If I'm running Windows I obviously don't care about security.
  • Don't run root (Score:4, Interesting)

    by Billly Gates ( 198444 ) on Monday August 08, 2016 @12:06AM (#52662805) Journal

    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.

    • by Hylandr ( 813770 )

      And now someone is going to do it just because you said nobody would. It's the Linux way.

    • What they can, and will, target is privileged credentials in the user's home directory. Linux users, for example, sometimes keep SSH private keys or GPG keys in their home directory. Those now become vulnerable to Windows tools that are poorly secured and allow filesystem access to well defined home directory locations.

      Conversely, many careless Windows users run their personal user account with Administrator privileges on their Windows machine, to make certain types of work easier. This makes Linux hosted a

      • Linux users, for example, sometimes keep SSH private keys or GPG keys in their home directory. Those now become vulnerable to Windows tools that are poorly secured and allow filesystem access to well defined home directory locations

        How is this different from any other secure file you might have on your computer? If the malware has file system access and permission to read the files that you have access to, then it has access to the files....

        I have private keys in the form of PuTTY .ppk files on my Windows box. I also have private keys in the form of id_rsa on my Linux boxen. Those files exist in places that I have access to... so would malware, if it got installed.

        I am trying to understand why this is somehow more of a security risk (

    • by dominux ( 731134 )

      I wouldn't be too sure about not running servers on this. Plenty of places really really want to have a standard build of windows on all their servers without exception. Plenty of developers want their stuff to run on a well understood LAMP stack that isn't a complete and utter pain in the arse to install and update. WSL lets everyone be happy - not sure it can run background services properly yet, but there is certainly a use-case for it running servers. Now whether such a machine is vulnerable to this kin

      • Plenty of places really really want to have a standard build of windows on all their servers without exception.

        Oh, I am SURE the Computer Priesthood will absolutely LOVE this! All the insecurity of Windows with all the Obscurity of Linux, rolled into one hard-to-troubleshoot package; yay!!!!

    • I highly doubt malware will target this.

      Funniest thing I've read all day!

  • We've pretty much written Windows off years ago.

    Windows applications could inject code, modify memory and add new threats to a Linux application running on Windows.

    Windows has been able to do that to itself for years. No Linux needed.

  • I'm not sure if many people will install this functionality to begin with aside from developers, the target may be too small to justify

    • THIS. The linux-compatible subsystem is NOT installed by default, and a user has to go through a lot of non-easy hoops to get it installed. That is, it's not simply a matter of opening the Windows Store and clicking on a colorful icon of a skimpy-dressed female holding cash in one hand and a machine-gun in the other. There are a plurality of steps [howtogeek.com], all boring, any one of which would likely cause your typical sucker-user to lose interest.

      However vulnerable this turns out to be ("hey, handsome, are you MAN

  • by CrashNBrn ( 1143981 ) on Monday August 08, 2016 @12:52AM (#52662923)

    Windows Subsystem for Linux processes cannot directly interact with either the win32 subsystem or processes.

    Windows Subsystem for Linux Overview [microsoft.com] [img] :: https://msdnshared.blob.core.windows.net/media/2016/04/LXSS-diagram-1024x472.jpg [windows.net] or WSL System Calls [microsoft.com] & [img] :: https://msdnshared.blob.core.windows.net/media/2016/06/syscall_graphic.png [windows.net]

  • So, basically what he is saying is that if you can run software on a machine then you'll also be able to run software on that machine.

    Or am I missing something?
  • Captain Obvious award for Alex Ionescu, the chief architect at cybersecurity company Crowdstrike. Congratulations!

  • Shill (Score:4, Insightful)

    by eWarz ( 610883 ) on Monday August 08, 2016 @01:28AM (#52662989)
    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.
    • by truedfx ( 802492 )

      except via FS access

      Network access too, right? It wouldn't surprise me if there are default Windows network services that allow the Linux subsystem to effectively execute Win32 programs this way.

    • Alex Ionescu is (was?) a ReactOS 'developer'. He has a beef against Microsoft.

      Every sane person on the planet has at least one major, legitimate beef against Microsoft. If you don't, you're either very young, idiotic, or both.

    • Alex is a great guy and pretty brilliant; he's slightly-wrong in this case, as Linux binaries can't call Windows system functions (no Win32 API). The attack surface does include accessing the Windows file system, but not triggering Windows programs.

      He's not the kind of raging psycho typified by RMS or Theo de Raadt, at least.

  • by rew ( 6140 ) <r.e.wolff@BitWizard.nl> on Monday August 08, 2016 @02:29AM (#52663149) Homepage

    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.

    • Here's how server applications aren't supported: they use system calls or variants of system calls that aren't implemented. Microsoft have made sure that bash, git and nodejs all work fine. But they haven't implemented all the APIs that, for example, Oracle or Docker use. I found I could run xterm no problem but not Haskell's ghc or stack. They will probably add more features over time but it's hard to say how far they'll get or when. The project originated in the Astoria Android emulator, so the APIs that

    • GUI is not supported. However you can run an x-window emulator on windows then in the ubuntu sub-system redirect the display to localmachine, meaning windows, and that will work.
    • But if what I hear is true, this is only useful for the most basic of things, no graphical capabilities

      I know someone else has already said it differently, but X is a networked display protocol, so I assume any X server for Windows could work.

  • That's Ok I have my windows 10 running in a sandboxed virtual machine under debian.

  • Both Linux and Windows accessing hardware directly so that Linux performs well.

    What's the logical next step?

  • That should make porting WINE easy!

    Seriously speaking, it seems the short of it is that WSL should be disabled if AppLocker is desired. I suspect that wouldn't upset too many folks, as I imagine the intersection of audience that uses AppLocker and the audience that would use WSL is non-existent. AppLocker is a pretty extreme lockdown to inflict on your users, and I can't imagine those admins wanting to use Linux applications.

    WSL can be disabled, so I don't think this is as large a deal as the article want

  • by Eravnrekaree ( 467752 ) on Monday August 08, 2016 @10:32AM (#52664571)

    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.

  • Okay, I can see running Windows under Linux, but why run Linux under Windows? It seems like that's the worst of both worlds.

  • I only bothered upgrading my HP workstations to Windows 10 (for free) is so that I can install windows 10 on a hard drive and run Ubuntu GNU/Windows.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...