Hacker News Reader

Comment by fb03 | Hacker News Reader

VcXsrv and a bashrc to set DISPLAY= automatically did it for me

export DISPLAY=$(route -n | grep UG | head -n1 | awk '{print $2}'):0

and on the Windows side, start VcXsrv with the 'Disable Access Control' combo box checked. this will enable X clients from other hosts (WSL is another host, basically) to connect to the server without too much hassle. that's it.

View on HN

> Disable Access Control

This was terrible advice back in the 90s and still is. An attacker anywhere on the network can listen to your input devices, insert fake keypresses, view your screen, etc. Basically a total system compromise.

All without log entries.

The correct way to do this is to use MIT-MAGIC-COOKIE.

One the client host:

    $ xauth -extract - $DISPLAY

Then copy the output. On the host running the X server:

    $ xauth nmerge -

then paste the output copied previously. Press enter and CTRL-D (EOF). If you then check the output of "xhost" on the client, it should only say "Access control enabled."

VcXsrv binds to localhost by default, so unless you already have malware on your system the added risk is quite small I'd say.

What about javascript code on a harmfull website that does requests to localhost?

It used to be possible to easily scan what sites are running locally, even if js code was from a public website. [0]

[0] https://defuse.ca/in-browser-port-scanning.htm

A JS based exploit that hijacks the X Window System Core Protocol running on your localhost to inject key presses into your X server or steal screenshots? I mean it's possible, but it seems quite far-fetched except maybe if someone specifically targets you.

The main impediment is that http request won't look anything like the x window requests, so the x server would likely reject it.

There are actually several (published and non-published) ways to exploit that type of configuration, here is one example:

https://samy.pl/slipstream/

If you're talking about the general concept of using js to spoof another protocol: that exploit involves middleboxes sniffing TCP connections at the packet level, rather than at connection/stream level. It certainly won't work for connections with a TCP server.

If you're talking about using that exploit to allow access to the victim's machine from the internet: that won't work because listening interface for the x11 server is localhost, not the LAN interface.

Thank you for posting this. I tried many times to google how to do this and saw the magic cookie explanation, but never found a good clear description of what was happening. Much appreciated!

Glad to help.

Btw there is a typo, you need to use "nextract", it's too late to edit it now

Instruction unclear: on the host running the X server, I get

  PS C:\Users\user> _

maybe something like...

    (cmd.exe -C xauth -extract - $Display) | xauth nmerge -

first part to run via windows environment, second to pipe that to the wsl environment?

Actual commands probably different, but should be something you could maybe trigger from inside .bashrc file.

You'll want to make sure clipboard sharing is enabled too. This way you can share clipboard data from WSL and Windows.

My VcXsrv config is public on GitHub at: https://github.com/nickjj/dotfiles/blob/master/c/Users/Nick/...

Putting it in that directory sets VcXsrc to start when Windows boots up. You would just replace "Nick" with your Windows user name and put it in that path. Then you never have to worry about starting VcXsrv ever again.

Also if anyone is using both WSL 2 and WSL 1, you need to set different values for DISPLAY depending on which version you use.

My .bashrc handles this at: https://github.com/nickjj/dotfiles/blob/385007837ab787a2be2e...

Yip, been doing it this way for years. Here is guide I originally followed. https://medium.com/@pck/how-to-use-sublime-text-3-from-comma...

We have a guide for it in microsoft/vscode: https://github.com/microsoft/vscode/wiki/Selfhosting-on-Wind...

The first line was enough for me to make it work.Microsoft supports it officially in the latest version I think.

Did you do this for WSL2? I had to do some firewall shenanigans before that worked for me.

And that is slow as hell, laggy scrolling etc. Hope the MS implementation works better.

> And that is slow as hell, laggy scrolling etc.

It's not slow for me. Maybe you have something else running that's interfering with WSL (Defender, etc.)?

I've been using the VcXsrv set up for years (in WSL 1 and now WSL 2). It runs native GUI Linux apps really well. It's how I ran Sublime Text in WSL for a long time before I eventually switched to a different editor. I even ran i3 in it for a bit but gave up on that because it didn't work well with dual monitors. It was smooth as butter tho.

Reply on news.ycombinator.com