https://bugs.winehq.org/show_bug.cgi?id=49024
Bug ID: 49024 Summary: Malicious software able to alter, infect and/or destroy personal files Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: youtube@marcus-s.de Distribution: ---
Hello,
I might have discovered an issue with the current state of Wine execution of Windows programs. While Wine does run pretty well for what I need it, I have been pointed in the direction that it is also possible to execute malicious software to the same effect it has on Windows.
Namely did I perform a test with the "WannaCry" ransomware on a non-live test bed - and have found that not only does it encrypt and destroy files in one's home folder (if standard Wine symlinks are kept in place), but also I found that files that lie outside of the Wine prefix are affected. For me, files in /tmp and a complete custom folder residing on the root level were also affected.
I find this to be quite a security issue when Wine is also able to perform destructive code without any limitations.
Steps to reproduce:
- Install current version of Wine - Acquire a WannaCry (or other Virus) binary - Execute the binary - Observe results
Expected result:
- Security measure that prevents access to files and folders outside the Wine prefix unless specifically specified by user through Winecfg.
Thanks, Marcus
https://bugs.winehq.org/show_bug.cgi?id=49024
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- Wine is not a sandbox. Security is handled by the host system. https://wiki.winehq.org/FAQ#How_good_is_Wine_at_sandboxing_Windows_apps.3F
https://bugs.winehq.org/show_bug.cgi?id=49024
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
https://bugs.winehq.org/show_bug.cgi?id=49024
--- Comment #2 from marcus-s youtube@marcus-s.de --- In my opinion, a Linux system is responsible for the security of the underlying Linux components and the system. Separate software such as Wine, should implement independent security measures for such a scenario.
https://bugs.winehq.org/show_bug.cgi?id=49024
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #3 from Paul Gofman gofmanp@gmail.com --- As Rosanne said in comment #1, Wine is absolutely not a sandbox and is not pretending to be one. As a very rough analogy, python is capable of running python scripts, but do you expect it to protect you from some unwanted things that scripts can do?
Probably the easiest and most lightweight thing you can do to limit the potential impact of unwanted Windows programs under Wine is to run it under separate user which does not have any excessive rights and does not have access to any personal files or write access to anything besides its own files. Then (unless the malware is specifically designed for Wine and will exploit host security somehow) no software run in the prefix will be able to do what your describe. There are other limitations which can be imposed, like disabling access to network through iptables. Of course, this is still not a perfect sandbox which might be not very easy to do right, but it will avoid many of practical threats and won’t impose any performance penalty.
https://bugs.winehq.org/show_bug.cgi?id=49024
--- Comment #4 from marcus-s youtube@marcus-s.de ---
... but do you expect it to protect you from some unwanted things that scripts can do?
Frankly speaking, that is something pretty fundamental - I would like to see such an ability or mechanism in professional grade software. Windows, ironically, does have at least an attempt of such a mechanism that warns users when critical access happens or when system files are changed. In the very least, Wine should have some kind of protection or warning mechanism when a program attempts to access something outside the Wine prefix.
... then (unless the malware is specifically designed for Wine and will exploit host security somehow) no software run in the prefix will be able to do what your describe.
As I said, in performed a test myself on a real machine with a malware specifically designed to target Windows machines. At first, I could not believe this to be the case - but it is true. This is documented and shown in my own video (I speak German though):
https://www.youtube.com/watch?v=37BUwFH_yKI
In another video, the same ability under Wine is demonstrated:
https://www.youtube.com/watch?v=7cUL1HKfTK0
And another one for good measure:
https://www.youtube.com/watch?v=TErrIvyj_lU
https://bugs.winehq.org/show_bug.cgi?id=49024
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- There is some misconception here. Windows program running under Wine is a native host system process, not more and not less. You should treat it as such. The concerns you raise should be raised against Linux or Mac user process security model, it has nothing to do with Wine.
https://bugs.winehq.org/show_bug.cgi?id=49024
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
same procedure as every year? We already had such requests in the past. They have been discussed extensively and shot down for good reasons. You want to repeat that again here?
* bug 11421 ("Wine makes possible for windows virus to work?") * bug 25537 ("Wine allows access to / regardless configured ~/.wine/dosdevices") * bug 31114 ("Wine is too insecure.") * bug 33587 ("Should Wine create symbolic links to ~ directories?") * bug 42591 ("Do not auto symlink devices to dos device except for c:") * bug 45419 ("Consider adding 'read-only' option for virtual drives for better security ("read-only file system")") * bug 46525 ("Wine allows access to / regardless of configured ~/.wine/dosdevices")
Use Linux/distro provided security measures and sandboxing technologies if you need a bit more "security". Remember, there is no such thing as 100% security - even with Linux.
BTW, I've tested the compatibility of "WannaCry" with Wine in 2017 when it was a hot topic. I used a Docker container at that time because I knew what would happen. It worked as designed and encrypted everything user-writable on the exposed filesystem(s). You figured that out again - great. If "WannyCry" wouldn't have worked due to some Wine bug/API insufficiency it would have been fixed a long time ago. It's still a Windows application in the end. Same with other malware.
Regards
https://bugs.winehq.org/show_bug.cgi?id=49024
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #7 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Wine has access to the same files as any other native program run by the same user. If you're worrying that Wine has access to your personal files, then you should worry that your native web browser, file manager and standard text editor do.
Wine's goal is to run windows application on the host system as transparently as possible. Security concerns are outside the scope of Wine.
There are already plenty of external security solutions to preserve data integrity and availability that are available elsewhere.
Bugzilla is not the place to discuss design decisions, so if anyone still have objections after all that has been said, please go to the developer channels.
Marking INVALID.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49024
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=49024
--- Comment #9 from marcus-s youtube@marcus-s.de --- If nothing else, the replies have been... insightful.