ionescu007/lxss

Fun with the Windows Subsystem for Linux (WSL/LXSS)

lxss's Issues

Please provide updated WSL video at the next Black Hat conference or stand-alone

@ionescu007

The last video you posted about WSL is from Oct 15, 2016. As I'm sure you know, there have been a huge number of changes to WSL since then, especially between the release of Fall Creator's Update (build 16299) and now (Insider build 17101). Could you provide an updated video that covers the new scope of capabilities and vulnerabilities in a similar fashion to what you did in your video?

Output to non-console handles?

In lxlaunch.cpp:203 it checks whether the output handle is a console handle. I wonder if it's possible to make it supports non-console handles?

Enhancement: KVM support (a simple paint program example)

It would be super cool to have an example where an app on Windows gets some sort of framebuffer resource, and passes that and keyboard/mouse events through to the Linux side, which draws on the framebuffer which is then displayed by the Windows side.

Use case:
The Pharo open-source programming environment runs on the OpenSmalltalk VM. Only recently this has been ported to 64-bits, but only for LP64 programming model, i.e. Linux/OSX. To port VM to LLP64 to have it work on Windows is another big effort. Of course a native port is preferable to support users back to Windows XP, but maybe an interim step could be splitting the app so only the KVM interface runs on the Windows side, and leverage the completed LP64 port running on WSL.

Note that Pharo/Smalltalk is like an operating system and IDE rolled into one. Here SqueakNOS is shown running on bare-metal inside VMWare.

This is neither how the English language works.

annyances
(page 46)

This is not how the English language works.

RegisterAdssBusServer() returning ERROR_NOT_FOUND

I am having a little first-try difficulty with the lxserver sample. (*iLxInstance)->RegisterAdssBusServer() is returning 80070490 (ERROR_NOT_FOUND) after a bit of a wait. The registry key is set, and on the client side I am able to open the /dev/lxss fd as root, but it (naturally) just blocks on ioctl(..., IOCTL_ADSS_BUS_CLIENT_CONNECT_SERVER, ...). This is on 14971. Any ideas?

Support for Windows version greater than RS3 or higher

When I execute the compiled binary it shows the usage. And when I debug the lxlaunch.cpp Visual Studio shows this error at StartDefaultInstance():

Exception thrown at 0x00007FFEB48511F0 (ntdll.dll) in lxlaunch.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

I'm using Windows RS3. Am I doing anything wrong? Or Is this source code not apply for RS3?

Question about lxdrv design

Your lxdrv code appears to "take over" lxcore.sys and calls LxInitialize and VfsInitializeStartupEntries. I am wondering if you could explain the rationale behind this design:

• Was this design your choice or somehow mandated by lxcore.sys?
• Would it not be possible for a driver to register its own VFS device by calling VfsDeviceMinorAllocate and LxpDevMiscRegister and not have to initialize/manage lxcore.sys?

Cygwin alternative

The slides kinda go over my head.

Does this mean this could be used as a cygwin alternative?

Build instructions

As already stated in #3 instructions for compiling the files would be really nice, as I haven't seen a pull request for those which don't use VS. Even with VS I cannot run the lxlauncher because opening the VC++ Project file from lxlauncher opens VS without the lxlauncher.cpp source file.
Compiling the *.cpp file with standard gcc flags results in many missing headers, such as a missing comutil.h or winternl.h.

Question about the original POC

I was thinking about something with the original way you did the POC:

I know that you set up the lxserver to listen on the bus directly, but couldn't you really easily rewrite lxlaunch to do the listening instead? Basically, since lxlaunch takes the stdout of the associated LX process and just dumps it out to a Windows console, couldn't you instead make it so lxlaunch sniffs that output instead of dumping it to screen and grabs it to do an NTCreateProcess()?

Basically instead of using TCP like some of the solutions do, you just have a bridge program on the LX side called, say, lxbridge that opens a unix socket and have lxexec just kick properly formatted stuff into that socket.

So you would do something like CPLXLaunch (CreateProcessLXLaunch), which launches the linux binary lxbridge and then listens back over the attached console. Then just run lxexec yourPE.exe, which just connects by socket to the lxbridge, which then emits some text over stdout back into CPLXLaunch, which then creates the process. Also, since all files on /mnt/c are permission 777, you could have CPLXLaunch load up the lxbridge executable from inside of its own folder.

I know that this would be totally insecure, and it would be obsolete now given that this is going to be officially supported with winrun, but was there a reason why you did it with the original LXServer/LXClient approach (requiring admin on both sides of the bus) in the original POC?

Youtube link is broken

Change the url to https://www.youtube.com/watch?v=_p3RtkwstNk

Lxlaunch crashes on an unhandled exception in the "else" case of the RS2 check

Hiya,

Saw you updated lxlaunch, and I went to go see what the deal was with it. Two weird things:

First, the build-number check seems to be looking for build >=15000 to launch with the new method (comments say that build >= 15000 means the build is at least redstone 2). However, the current latest fast-ring build is 14931, so the conditional fails and we drop into the else half of the conditional. However, as soon as that happens, it crashes. The VS15 debugger claims that this is a result of an unhandled exception:

Exception thrown at 0x00007FF93925BBC0 (ntdll.dll) in lxlaunch.exe: 0xC0000005: Access violation writing location 0x000000000000000B.

The only thing I did that was maybe possibly questionable was building it against the 14392 SDK instead of the 10581 (iirc?) SDK, but I got a similar crash building against that too.

I also tried forcing it to use the new interface by dropping the check (>=15000) to (>=14500), but this gave another crash in basically the same place (inside of the if instead of the else, but right after the line:

hr = ((PLX_INSTANCE_V2)*iLxInstance)->CreateLxProcess with a similar message.

The TTY device and the path of I/O from bash.exe to /bin/bash

Hiya, quick question, wondering since you've done a lot of RE on this already:

So from what I can deduce, bash.exe consists of two distinct parts:

• Something that translates the UTF-8 characters and xterm escape sequences (or whatever you decide to make your terminfo) into/from little-endian UTF-16 and Windows console escape sequences (because conhost)
• A COM client that attaches to the LXSSManager service's COM interface as a console that corresponds to a TTY device in the Linux instance, but also that you could in theory have a TTY on the Linux side that was not started by invoking bash.exe.

So I was wondering how is the kernel sharing the ttys from the Linux instance up into the LXSSManager service (and are the TTYs somehow accessible through LXSSManager's COM interface even if the tty was not spawned by a bash.exe instance). Like, I could imagine that the way you might do it is just have the kernel just have it so the tty driver is just some kind of region of shared memory between the Linux Instance and the LXSSManager, and so basically you are just exporting a bunch of raw text and line data, but maybe this would be stupid and the kernel is sharing memory between the service and the instance on a per-device basis (so the memory regions associated with non-bash.exe tty devices are not mapped into the service's address space.

Or am I entirely wrong and MS is doing it with one of the other million ways to do IPC in Windows?

Also, have you found any checking at the COM interface that only bash.exe is whitelisted to connect and start a new instance and attach itself to a TTY (however they work)?

Or have I got it all wrong?

Thanks for your time and attention.

Binaries/Compilation instructions for the simpleminded?

Any chance you could give those of us who don't use Visual Studio a little readme on how to build, or maybe put up precompiled binaries? Thanks!

Lxdrv POC, limitations?

Hi there, Alex. I haven't seen a proper blogpost or talk by you about LxDrv, and I took a look at the code, but I'm totally clueless about Windows driver development.

Two quick questions:

1.) If I compile the POC driver, won't I have a ton of trouble installing it because it's not signed (do I need to enable test-signing and boot in debug mode or something)?

2.) Also, question about limitations: Is there any reason why the new driver interface couldn't be used to create a shim driver with a custom libgl in lxss and have it send the Windows-compatible ioctls (probably driver-dependent) to the Windows graphics drivers? From what I could glean, the proprietary Linux graphics drivers work by having a user-mode library (nvidia-libgl or fireglrx-libgl) communicate directly by ioctls with a binary blob loaded as a kernel module and exposed by an interface just like this.

Reason why I'm asking is that CUDA is one of the top feature requests on uservoice, as is support for things like ifconfig, both of which would need more device driver exposure. Wondering if you'd be willing to speculate if this kind of thing will be used to implement CUDA on WSL or just be part of their solution for getting ifconfig and networking tools working.