Wine securityflaw.

[Vincent Béron]

Peter Andersson a écrit:
> Hello again,
> 
> (FYI, I took the liberty to change the topic since I started the 
> former thread "How is Win/Dos syscalls implemented in Wine?" 
> which I feel has gone a little bit off-topic)
> 
> 
> I had some more thoughts on the issue...
> 
> I believe most wine users trust wine not to touch anything outside of 
> its configured drive space.

"Trust" might be a bit too heavy. "Believe" would be more appropriate. 
Running Wine is (and has always been) a bit of a security risk, the same 
way (although to a lesser extent) than say SUID libsvga apps. That's 
why, if you think the risks exceed what you are ready to bear, then 
don't use it on your systems.

> Malicious Linux/Unix syscalls could be embedded
> in windows apps and if executed  do a great deal of damage.

The same way they can be embedded in any Linux native trojan.

> After all checking
> your app is run whithin Wine is not that hard (reading registry settings for
> instance). Lets call such an malicious app a wine-virus from  now on. 
> At present a wine-virus would even be allowed to fork itself, leaving the wine
> environment and continue to run even after you shutdown the wineserver,  and
> in some cases even after the user logs out. The virus would now have full 
> access to the system whithin the users permission, doing much greater
> damage than you expected.

It doesn't have any more permission than any other closed-source app you 
run on your system. Are you that sure that, let's say, UT2K3 (or any 
other closed-source or even open-sourec native Linux app) won't try to 
do that, either maliciously or by accident?

> 
> The question is...Would you expect that damage from running a windows app
> in wine, when you know it could be safely run in Windows?

How do you know it _is_ safe to run in Windows? Because you never had a 
problem running it? Hardly a proof, no?

> In just a few embedded bytes in the code it could remove your home directory 
> in a single syscall. Would you expect that? - I wouldnt.

No need for convulated interrupt calling. Just call (through system()) 
something along the lines of "/bin/sh -c /bin/rm -rf /" (beware, don't 
actually *do* that!) to get that effect. Since the deletion is done 
through /bin/rm rather than a Wine (or your app) libc call, then 
anything you add to protect from this in Wine won't help.

"Then don't allow Win32 apps to run Unix apps."

Ok. Then include a Winelib app which will call that Unix app. You *do* 
want us to allow the calling of Winelib apps, don't you? Else, you 
wouldn't be able to run notepad.exe.so from an installer to see the 
release notes.

And since a Winelib app is a native Unix app, adding something to Wine 
wouldn't help.

> 
> I really love the idea of Wine, and the fact that its working  good and rather 
> stable now does mean its gaining popularity and a broader user base,
> which further IMHO accelerates the wine movement. 
> If wine users were aware of the risks of using wine at present, I believe wine 
> would be used more cautiously.

It should already be used cautiously.

> 
> Cant we atleast try implement some protection in wine against these attacks,
> before something really nasty happens. I do think company policy decissions
> againt using wine, will do just as much damage to the wine movement as too
> the free software movement at large. 

If you want to implement some of those protections, they should belong 
at another level, in which case not only Wine would benefit from them.

And don't forget that if you try to build a wall in an open field, there 
will probably be some gaping holes around, over or under it. Beginning 
to erect that wall would (IMHO) just entice some people to try to 
circumvent it.

Use the LSM patches for Linux if you want to monitor certain system calls.
Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you 
want to protect your current $HOME.

>  
> I would, despite my current lack of knowledge, gladly offer my help. But I 
> hope someone more experienced would take the lead.
> 
> Best Regards,
> 
> Peter Andersson

Vincent