Hacker News Reader

Comment by morsch | Hacker News Reader

A separate Linux user would go a long way. You'd have to be very unlucky to get hit by a RCE in a game that's simultaneously targeted at Proton users.

View on HN

With PC gaming it's more of an issue of having to install all sorts of various software, including game mods, or the ever popular "hey try out my game" scams through discord. A popular one is distributing malicious unity assets. We don't realize that most of this stuff has little to no security, simply put just nobody exploits it. Dark souls series all had an online RCE and the game servers have been down for a while. I do not trust any of that near my dev environment. I've found a great separation is a PC with dual boot and a laptop with only Linux.

A RCE in Windows software running on WINE wouldn’t have much benefit on Linux unless the attacker specifically knew said software was running in WINE.

1. WINE et al run in a sandboxed environment. You cannot execute other Linux software without then also finding an RCE in WINE. So that’s multiple RCEs needed in multiple points of the stack and the attacker needs to be aware that you’re running the uncommon set up of that Windows software running in WINE.

2. The amount of Windows software installed in WINE is limited. So you don’t have a large attack surface of Windows software. That not only limits the amount an attacker can do in the sandbox but also limits the surface area that further RCEs might exist

3. Even if you could escape WINE you’re then stuck with the problem that you don’t know what the host OS is. So you’re stuck with generalised POSIX or GNU. Which might still be common but far far less common than going after Windows users.

> 1. WINE et al run in a sandboxed environment. You cannot execute other Linux software without then also finding an RCE in WINE. So that’s multiple RCEs needed in multiple points of the stack and the attacker needs to be aware that you’re running the uncommon set up of that Windows software running in WINE.

Are you sure about this? I was the impression that there's nothing preventing an .exe running under Wine from just issuing Linux syscalls, eg. execve.

EDIT: I just tested this, and indeed there doesn't seem to be any sandboxing:

cursed.c: https://gist.github.com/q3k/e5952111283ea59ee78a7699919a055b

cursed.exe (built in msys2): https://object.ceph-eu.hswaw.net/q3k-personal/b8159d43e0698d...

  $ wine cursed.exe
  hello from win32
  hello from linux
  hello from execve

I stand corrected. Thanks for that detailed test too. I learned a lot from it

Not only there isn't any sandboxing, the lack of it is how WINE works - wine's low-level dlls (kernel32.dll for example) just call out to linux libs, or syscall directly.

Keep in mind that the Souls RCE exploit was unknown for many years, and the modding community rallied to get it to FromSoft's attention.

The modding community maintains its own 'anti-cheat' system called Blue Sentinel, which was updated day-of to block the RCE exploit. At least, the same day the warning was made in the Discord servers I'm still in.

Not really because it requires very esoteric configurations to avoid other users reading important files of yours. Unless you're willing to modify your default SSH (and other, apache, etc.) configurations out-of-the-box setup will leave all your data readable by other users.

In the linux world it's standard operating procedure to make a separate user/group for every service and ensure the file system is cognizant of that. And the default in ubuntu runs mysql with mysql user and nginx / apache with www-data as a user.

That's correct, but if you want to keep any files that services like that access, such as SSH keys/authorized_keys you need to give them access to your directories. Because of this you can't make your home directory only readable by your user, since then sshd cannot access `~/.ssh` to check your authorized_keys file. The same is true for running a web server in `~/public_html` and anything else.

The agreed upon solution to this is to make the home directory readable, then split the files into a `~/public` and `~/private` directory, which is well accepted in the server space but completely non-adopted and not straightforward in the desktop space. It's technically possible to modify your $XDG_DATA_DIR and other similar configurations, but many programs and tools still don't care and will only look for and operate on configuration files in `~/.config` or `~/.local` or worse yet just `~/.foo`.

Reply on news.ycombinator.com