4 ms·

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 th

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.

laumars 5y ago
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.
- q3k 5y ago
  > 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 https://gist.github.com/q3k/e5952111283ea59ee78a7699919a055b cursed.exe (built in msys2): https://object.ceph-eu.hswaw.net/q3k-personal/b8159d43e0698d27379c537a3cddc85f6df622329af9399e7caee3fc1d3a922d.exe https://object.ceph-eu.hswaw.net/q3k-personal/b8159d43e0698d... $ wine cursed.exe hello from win32 hello from linux hello from execve
  - laumars 5y ago
    I stand corrected. Thanks for that detailed test too. I learned a lot from it
- implr 5y ago
  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.
gigaflop 5y ago
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.

laumars 5y ago

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.

q3k 5y ago
> 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 https://gist.github.com/q3k/e5952111283ea59ee78a7699919a055b cursed.exe (built in msys2): https://object.ceph-eu.hswaw.net/q3k-personal/b8159d43e0698d27379c537a3cddc85f6df622329af9399e7caee3fc1d3a922d.exe https://object.ceph-eu.hswaw.net/q3k-personal/b8159d43e0698d... $ wine cursed.exe hello from win32 hello from linux hello from execve
- laumars 5y ago
  I stand corrected. Thanks for that detailed test too. I learned a lot from it
implr 5y ago
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.

gigaflop 5y ago

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.