Topic: Linux: is wine a potential threat for our BTCs? (Read 392 times)

I don't use Linux regularly I only use it for tests when it's required. If I did use it instead of Windows I'd say it isn't worth the risk of losing bitcoin to a software so wouldn't use wine on the same computer. If ppl want to run a full node or keep their wallets on a computer it's better if they use software that's essential.

Wine can be very buggy and not all win software will even run properly on linux os.
Few years ago I was experiment with using some adobe software with wine, but I was not happy with results.
I think it would be much better to separate things and keep everything bitcoin related on separate laptop, even better if you can keep it airgapped.

Thank you for all your answers!
It's extremely interesting to read.

I quite agree with NotATether, for a lambda user, some solutions seem too complex to implement (but extremely interesting anyway!).
So, for my friend (who is an advanced user but neither a dev nor a specialist) I imagine that the solution mentioned of using a different user for wine would be the best one:


I'll try to motivate him and help him get it right, and I'll come back to this topic if I have into any problems...

In any case, guys, your answers confirm my initial idea: without knowing exactly what you're doing, it's better to play it safe with software (you'll tell me "as always"  )

Safe assumption: of course! Any software adds a risk. Depending on the risk level, I'd run it in a VM, on a different system, or as a different user. After all, you're using a multi-user system, and there's no need to risk it. Use permissions to keep things apart.

Example:
To run wine as a different user, create a new user "wine". Give user "wine" access to your display:
Then, as user "wine":

Note that I haven't used this for wine, but I did for other programs. If I have to use wine, I run it inside a VM with VPN, because I don't trust the programs I use with it. Or on a spare laptop which is setup to wipe and overwrite in minutes.

True. Maybe I spent too much time on exploring unknown EXE files to notice that. Because in general, if you have some unknown executable, then it is normal to start with "deny by default" approach, and provide all DLLs with empty implementation (or even skip loading them entirely, and replace all calls with NOPs), and then enable features one-by-one, to ensure that we know, how does that unknown program work, and try to write a replacement, without even trying to decompile its code.

What you said is correct. But people who're not familiar with Wine wouldn't know how to secure Wine or even know how insecure is Wine by default. And many people who have some security concern is more likely to choose convenient option such as using VM or running Wine inside Docker.

You are right about the linux privilege system, but you break that system when you install wine because with wine you can run a .exe without being root and install a malware with it, but here comes the deal that DaveF mentioned.


And sadly some kind of attacks would be success, for example. The CryptoWallet Clipper malware could affect the copy/paste on your system making you send the cryptos to the wrong address.
https://www.pcrisk.com/removal-guides/24043-cryptowallet-address-replacing-virus

In 2007 there was a Malware report on the Wine Mailing List:
https://www.winehq.org/pipermail/wine-devel/2007-January/053719.html


And after that the wine wiki update their FAQ with the question: Is Wine malware-compatible?


So, if the wiki suggests using a Virus Scanner, then it's vulnerable.

Of course. But you can configure a lot of things. You can replace any DLL with your own version. You don't want a filesystem access? Just use your own DLL, where all of those WinAPI functions are empty. For example, if you see, that some EXE is using DeleteFileA, and you want to deny access to it, then your own Kernel32.dll with an empty filesystem implementation will do the trick. Because DLLs used in Wine are Open Source, you can just use their code, and disable what you want (or even mark it as "not implemented", as they do for many functions, before implementing them).

You can clearly decide, which user can run Wine. And if you run it as a separate user, created only for that, then user from "/home/wine" cannot access files from "/home/vjudeu".

Maybe you are right. Because when I use Wine, I usually do that to replace Windows applications with some Linux versions. And then, debugging and exploring EXE and DLL files is much easier with Wine, than with virtual machines, or dual boot environments. Why it is easier? Because then you have less black boxes. Then, only your EXE is a black box, everything else is Open Source, so you can build all of that in Debug mode, and know exactly, what is going on.

Please do research before posting.

---

Virtualization? Wine website clearly state it's compatibility later,


Wine does not perform sandbox at all,


Wine doesn't protect you from malware either,

Quite embarrassing for me to forget that but I'll take it.


That is why I wrote, you have to be an expert in Wine to use it in a way that is not a security risk. The average Linux user, though fairly more advanced in knowledge than the average Windows user, is going to experience a lot of trial and error in the process of following these instructions perfectly.

1. By emulation? Wine Is Not Emulator. It is in the name.
2. Not "almost any malware", but only those parts, which are implemented. It is a common thing to encounter "FooBar function is not implemented".
3. Guess what: you can enable and disable things on DLL-level in Wine. Not to mention debugging, which is quite advanced, and even running some executable in console can give you a lot of details.
4. If you install Windows, then you have a lot of black boxes. Windows by itself is a huge black box. If you use Wine, then only your EXE is a black box, everything else is Open Source. Which means, if you want to use MinGW to write a replacement, it is easier to do that, because then you have bare-metal Linux, and simulated Windows, which means, if you port things from Windows to Linux, using Wine is easier than running any VM.
5. If you have fully Open Source machine, including Open Source BIOS, like Libreboot, then installing Windows on bare metal can be hard, because then you have GRUB page after starting your system. Then, there is no longer a classical BIOS boot menu, or anything like that. Booting any closed-source ISO is then much harder, and typical Windows ISO won't even start on such system, unless you specifically enable it (which is quite complicated, because by default, your BIOS can load kernel images, and you cannot get Windows kernel image directly that easily).
6. Installing Windows on bare metal means, that you have to also provide all drivers for Windows. Which means, you will have even more black boxes than in Wine.

Yes.

Don't use WINE, unless you are a Wine expert who knows how to sandbox anything you run in there (and come to think of it, only use it sparingly for a limited number of applications too). It can run almost any malware that is created for Windows, by emulation.

You don't want that anywhere near your Bitcoin devices.

Wine is a safe and open-source virtualization solution that allows to run Windows based applications on Linux and the applications on Wine run in a virtualized environment which won't affect the applications that run on the real Linux host system. I believe windows based malware won't impact the host of the Linux system as Windows malware are built in a way that they can affect Windows based users only.

The files and the whole Kernel module of Windows operating system is changed from Linux and that's another proof that Windows viruses and malware won't be able to penetrate Linux operating system. However, it's always recommended to avoid installing any application on the systems where someone saves his/her Bitcoin. Just don't be paranoid by such thoughts the Linux is a safe operating system and Windows malware can't harm it at all.

No matter what you use, if you have more than one main operating system, then guess what: you will need a way to move files between them. Having Windows partition is good, as long as Windows cannot see the Linux one. External SSD is good, as long as it is attached properly, and if the system will not remove it in the middle of your work, if it was inactive for 5 minutes.

This is one of the reasons, why virtualization is still not good enough. And when it comes to games, it is probably also some GPU, and some additional drivers, probably with closed sources, designed specifically for games, and other closed source software. Guess what: people made emulators first, that's why Wine is called "Wine Is Not Emulator", and not the other way around. VirtualBox is not called "VM Is Not Simulator". The name can tell you, what happened first, and what was created later, as well as explain some reasons, why it is what it is.

So, the whole thing is not only about security. It is also about habits. If someone is used to Wine, where Linux is the main system, and where everything is built around it, and it works, then switching to multi-OS-based environment is hard. Because then, you want to synchronize between different OSes. Switching things then requires rebooting the whole system (which is hard for people who run their machines 24/7 for some reasons, like full node owners). Also note that if something works in Wine, then moving that program into Open Source land, or writing a replacement, is much easier, than if you use VM or dual boot. Also because then you have to make things tick on Linux, even indirectly, for example by configuring PulseAudio properly.

Edit: One more thing: if you have some old software, for example designed for Windows XP or Windows 98, then guess what: using Wine is much easier and safer, than running some VM, or some dual-boot installation. I wonder if you ever tried using dual boot with Windows 98 in 2023. You may be surprised, how hard it is. You would see a lot of strange messages, like "not enough RAM", if you use more than 128 MB RAM, and other very strange things, for example related to MBR vs GPT partitions, not to mention drivers for old systems, and going through the whole installation, without accidentally wiping out your whole disk (and you have to support "large volume" feature, where "large" is greater than "512 MB"). Don't even try to attach it to any network, if you don't know, what is Wireshark.

Edit: I guess in the future, you could even run some apps from a browser, instead of using Wine. Which means, we are more and more away from bare metal installation, and dual boot solutions, or even Virtual Machines. Here is why: https://www.youtube.com/watch?v=urF9SRtrImg

Thank you for all your answers 

---

Yeah I agree, but he is using Wine for software not related to Bitcoin, as BlackHatCoiner guessed.

That's what I feared, but wasn't too sure it was possible.

That makes perfect sense, thank you.
He downloads and installs all sorts of crap on his computer... Genealogy software, games... That's why I've come to wonder whether malware could spread or not.

No matter how hard I try to explain to him that it's not logical, that he could have a Windows partition, a dual boot solution, boot on an external SSD etc..., he keeps telling me that it is safe and that since he checks his computer with clamav. he's not worried. For my part, I'm still just as skeptical after reading everyone's answers here.

That's an excellent idea, thank you. I suggested him to make a dual boot windows/linux but I completely forgot about Virtualbox. However I don't know if his programs would run well with Virtualbox, because I don't know if he'll be able to allocate enough ram / CPU, I'll suggest it to him anyway.

Then still, that game could use Wine, and the Core client could run natively in Linux. Wine Is Not Emulator. It is in the name! But even if it would be, then still, port forwarding from a VM to a native system would solve it. But in Wine, you don't need even that, because Wine is just WinAPI implementation for Linux, so if you open some TCP port, then using Wine-wrapped WinSock is the same as using raw Unix sockets.

Another reason could be that Wine has a nice UI, similar to Windows 98 or systems like that. And some people like that more than Linux GUI. But then, changing UI in native Linux installation is a better option than running everything from Wine.

And if the reason is something else, then I have no idea, what it could be, because those two are probably the most obvious ones. It is definitely not something like "I want to run x86 applications on M1 processor", because Wine is not about that. Which means, x86 is used in both systems, if Wine can run it.

Because virtualization is slow. And if the architecture is the same, then there is no reason to use VM, if it works in Wine. I would understand it in cases, like "I want to run x86 Windows applications on Mac M1 processor", but this is a different story. And even then, if some transcompiler would be available, I would use it instead, to translate x86 instructions into M1 ones, and then execute them natively. Why? Because of performance. And if you talk about games, then this is a place, where performance is important.

Edit: I can add one more thing. Emulators are slow. And I hope, that in the future, they will be much faster than today. How they could do that? For example, by translating binaries, and storing them in native architecture before using. Emulators are great at dynamic analysis: you start from some processor state, execute things instruction by instruction, and then... then, emulators often do a huge mistake: they drop that native instructions, and they are never stored anywhere.

If emulators would perform opcode translation during first execution, and then use native executables in the physical architecture, they would be much faster than today. Then, only the startup would take a lot of time. But if some huge loop would be translated once, for example from x86 into M1, then it could stay in M1, and be executed natively in M1. And that would bring a lot of speedup to the whole emulation.

Also, after initial translation, there should be more phases to do some opcode cleanup, but well, saving executed opcodes is a good start, and I hope emulators will go in that direction. Some of them, like QEMU, can already dump input and output assembly, the only missing piece is capturing all of that, and producing well-structured executables, instead of for example loops expanded into all iterations (which means, emulators could get brilliant performance, but native approach just consumes too much space, because then there are no loops).

Malware targeting Windows doesn't usually work on Wine.  So using Wine to run Windows programs on Linux is less likely to cause issues than using Windows itself.  Still, its not risk-free.   

Why use Wine at all instead of just running Windows virtually? VirtualBox lets you isolate Windows in its own little virtual machine, separated from the rest of your system.  That keeps any Windows malware from affecting your main Debian install.   

It's not about Wine, it's about the programs you want to install. Are they open-source, reputable etc.? Wine is just a compatibility layer that allows you to run Windows applications. In general, no. It can't do great harm if you haven't given the respective privileges as it provides a degree of isolation. But, again, it depends; it absolutely isn't foolproof defense.

Maybe they want to install a Windows application separately, that could be completely irrelevant with Bitcoin (i.e., a game).

Malware or viruses in Windows will not run on Linux, but adding a wine application is a different case why would you use wine? there are many alternative applications, so why put your files at risk?
I have tried wine before and sometimes it will not run smoothly, use opensource alternative software instead, and also always enable your firewall,

Wine is no more or less an attack vector then having your funds on an online HOT wallet.
The windows subsystem is more or less isolated from the linux OS so for an attack to happen
1) Something would have to breach from windows to linux
2) That vulnerability would have to be targeted to get crypto / other data

I would be more worried about other security issues and having funds on a PC without a hardware wallet then something breaching wine.

-Dave