On Friday 01 Nov 2002 11:51 am, Vincent Béron wrote:
Le ven 01/11/2002 à 11:27, Geoff Thorpe a écrit :
Hi there,
[snip]
What do you mean? No PE apps can link straight to glibc. Only Unix-implemented DLLs (like the Wine ones) can link to it. The problem
Ah, this had been my question. It seemed otherwise from the earlier post I had seen. I'm glad this is the case - you need to use virus-style hacks if you want your PE app to bypass (or corrupt) the interfaces provided by Wine libraries.
No. Just launch a Winelib app from the PE (it must be permissible to do so), and that Winelib app then has access to glibc and friends, and can act as a gateway between the main app and the outside (the sandbox) world. That app could be meant as an "enhancement" or "workaround" when running under Wine (thus not affecting normal Windows operation), but still have a "bug" which can do nasty things.
In what way is that different from what I said? It's a wine-specific work-around - the winelib app you invoke is either wine-provided (ie. not a problem) or a wine-specific payload your application is carrying. This is equivalent to embedding assembly hacks (after all, your assembly hacks could be a complete winelib app image that you save to a file and execute).
I don't see the issue of executing winelib apps as a fundamental security problem as such - for example, what if your policy says not to load executables or libraries from "C:\" unless they're PE format? Likewise, what is to stop you defining a policy that wineserver-managed applications can't execute winelib apps unless they're (a) provided by wine (/usr/lib/wine/... and not C:\...), or (b) you've specifically granted them rights to do so.
The point remains that to do damage, applications have to implement very deliberate wine-targetted workaround measures if they don't want to be subject to policies configured by the user (and enforced by wineserver). By "deliberate", I mean they have to detect the wine environment (memory scanning, "signature" characteristics of unimplemented or buggy win32 API functions, etc) before then delivering their "special" payload. Ie. they have to write anti-wine viruses. Moreover, jailing the non-wineserver processes (if possible) to a "nobody" user makes it *possible* to provide some actual protection against such untrusted PE win32 apps. Not that *possible* means *default* of course :-)
OTOH: If an application is written to have wine-specific functionality and you want to accept it, that's something you could support. Kind of like turning MS's "embrace and extend" policy against themselves - allow applications to support Wine-specific enhancements that can't be used in MS windows. But in this situation, you're trusting and accepting both win32 *AND* native code - and you're not any more exposed than if you were just trusting a native application.
My point against anti-wine measures, I think, remains. If you are forced to run untrusted (ie. potentially anti-wine) binaries, there seems to be a lot that can be done on two levels; first, forcing anti-wine measures to be explicit payload-bearing virii and not just annoying "features". Second, jailing PE-loaded code with user privileges so that only the wineserver has all the native (unix) permissions of your regular user account. The first is a criminal (and complexity) deterrent. The second is an actual hardening of wine's security model.
So essentially I guess we could specify, for example, that no wine-loaded application has access to "F:" unless it is enabled in the wine command-line arguments? Eg.
wine --config-section=enable-F-home C:\\...where 'enable-F-home' could be a section in the config file specifying to map F: to $HOME?
Remember (from the thread on 0.8.0 feature list) that the config file should be merged completely in the registry, with a control-panel like app to aaply changes. So at least that app will need to be able to access it read/write.
Doesn't the wineserver process handle all registry manipulation? If so, the wineserver doesn't even have to let the applications get file-access to the registry - but either way, if it's the wineserver, you can implement a policy however you like without worrying about nasty workarounds embedded in the PE images. That policy could be an "override the registry settings in situation XXX" type of thing, or simply built in to the registry configuration model (the wineserver would just have to refuse to manipulate those entries if asked to by (untrusted) applications). You could even write a win32 configuration GUI that would manipulate these entries, then set your policy to allow *only* that application to touch them.
Is it even possible to switch to the nobody user without having higher priviledges beforehand? I thought you needed to be launched by root (or SUID root, etc.) to switch to nobody, since it can't login (su, ssh, etc.)
There is always a way :-) You could chmod 4755 the wine binary and wine itself could setuid back down to the "regular" user when initialising the wineserver and could setuid down to "nobody" when initialising the PE-loader. By the way, processes started as root that drop use privileges (on most posixy systems) become very hard to run memory scanning attacks and a variety of other things an anti-wine virus writer would find useful (it's also harder to attach a debugger to). If the wineserver needs to be able to create extra "nobody" processes later then there's probably a different way of doing this - eg. make the PE-loader be a chmod 4755 binary so it can start as root and fold down to "nobody" - then it can be invoked by the "normal" user, including the wineserver process(es).
Just my 0.02 $ (yes, $ after. Do you say "dollar 3.56"? Neither do we in French :)
moi non-plus en anglais - mais c'est surement "0,02 $", non? :-)
Cheers, Geoff