3 ms·

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

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.

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.