WINE is not safe to run malware in, it’s not a secure sandbox. AFAIK, anything expecting it can do anything a Linux binary can. (Also, not an emulator, it’s in the original name - WINE Is Not an Emulator)
I know what WINE is and the gist of “Wine is not an emulator”. I have used it extensively and for a while it even contained some of my code (not sure if it still does). But it is still emulating but not in the way people think. WINE is not emulating the operating system but it is emulating the interface that an executable interacts with Windows, aka the Win32 APIs and other DLLs.
They even touch on this in their FAQ - *That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode. *
As far as a potentially malicious executable is concerned, you can create a throwaway wine folder to run the thing and delete it as soon as it is done, e.g.
e.g.
export WINEPREFIX=~/tmpwin
winecfg
# disable wininet from libraries tab, remove Z:, unlink all desktop integration folders
wine keygen.exe
# when done...rm -rf tmpwin
It doesn’t matter if keygen.exe is evil because it can write anything it likes to the fake C: and the fake registry and it’s blown away. As a precaution disable networking so it can’t reach out either. In the extremely unlikely event that keygen.exe had code to detect it was running under WINE, it would still be subject to the permissions of the uid you had run it as, so you could take even more precautions if you felt so inclined. You could even use a dockerized WINE if you felt like it.
On the topic of whether or not it’s an emulator, sounds like semantics in the end - fair enough, I disagree but you make a fair point.
That said, in terms of security I think it’s very important to point it out that it isn’t any more secure than running a random Linux executable. In my view, the original comment is advocating for running unknown executables under wine as a security measure, and the further argument is that it’s more secure because most attacks don’t target that.
Sounds like if people rely on that for security, malware will just start targeting that after people get used to assuming it’s safe.
I doubt many people are ever going to do what I suggested so the effort / payoff for malware writers makes it very unlikely they’d bother. They’ll just assume 99.999% of people running the binary are doing so on Windows and code accordingly. Of course anything is theoretically possible.
![ATTENTION: 1337X IS NO LONGER SAFE [Reposted from Reddit]](https://lm.madiator.cloud/pictrs/image/46fa2d88-10a1-4ec6-81ee-c487321a15e1.jpeg){kind=link}
WINE is not safe to run malware in, it’s not a secure sandbox. AFAIK, anything expecting it can do anything a Linux binary can. (Also, not an emulator, it’s in the original name - WINE Is Not an Emulator)
I know what WINE is and the gist of “Wine is not an emulator”. I have used it extensively and for a while it even contained some of my code (not sure if it still does). But it is still emulating but not in the way people think. WINE is not emulating the operating system but it is emulating the interface that an executable interacts with Windows, aka the Win32 APIs and other DLLs.
They even touch on this in their FAQ - *That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode. *
As far as a potentially malicious executable is concerned, you can create a throwaway wine folder to run the thing and delete it as soon as it is done, e.g.
e.g.
export WINEPREFIX=~/tmpwin winecfg # disable wininet from libraries tab, remove Z:, unlink all desktop integration folders wine keygen.exe # when done... rm -rf tmpwinIt doesn’t matter if keygen.exe is evil because it can write anything it likes to the fake C: and the fake registry and it’s blown away. As a precaution disable networking so it can’t reach out either. In the extremely unlikely event that keygen.exe had code to detect it was running under WINE, it would still be subject to the permissions of the uid you had run it as, so you could take even more precautions if you felt so inclined. You could even use a dockerized WINE if you felt like it.
On the topic of whether or not it’s an emulator, sounds like semantics in the end - fair enough, I disagree but you make a fair point.
That said, in terms of security I think it’s very important to point it out that it isn’t any more secure than running a random Linux executable. In my view, the original comment is advocating for running unknown executables under wine as a security measure, and the further argument is that it’s more secure because most attacks don’t target that.
Sounds like if people rely on that for security, malware will just start targeting that after people get used to assuming it’s safe.
I doubt many people are ever going to do what I suggested so the effort / payoff for malware writers makes it very unlikely they’d bother. They’ll just assume 99.999% of people running the binary are doing so on Windows and code accordingly. Of course anything is theoretically possible.