[Wine] How can I detect WINE from my program?

[Vincent Povirk]

On Sat, Jun 6, 2009 at 1:13 AM, oiaohm<wineforum-user at winehq.org> wrote:
> Protected loads of dll.so files can also be limited.   You are describing same kinds of exploitation faults these secuirty designers are working against.
>
> System call protection prototypes also prevents from entering libs through non exposed calls.  Ie if the dll.so does not export it there you cannot enter execution there.  The branching attack is included.   From a wine point of view a .dll.so rendered not patch-able would not be a issue.   Wine would work normally.  Only programs doing things they should not be doing would be effected.   Then if program wants to patch dll solution would be to provide a normal dll without syscall usage.

Absolutely. Any particular attack I propose can probably be addressed
by an update, and of course I'm picking the obvious ones. The problem
is that to secure a system in this way, you theoretically have to
think of all of them, and you have to make Wine perfect (in that it
cannot be fooled into doing something it wouldn't normally be able to
coaxed into doing, since it is apparently trusted more than the
program is). By limiting the entry points, you reduce the ways to
interact with system dll's, but the possible interactions are still
quite complicated and effectively impossible to turn into a real
security boundary. I still have the general ability to mess with the
internal data structures of the Wine libraries and to give the
functions unexpected input, potentially bending them to my evil will.

Limiting the entry points must be costly to performance. Each attempt
to execute code on the other side of the boundary must cause an
exception so that it can be validated by the OS (and presumably some
alteration of virtual memory).

Patching system dll's in memory is a perfectly normal thing to do on
Windows, and if Wine cannot allow this then Wine is broken. Yes, it's
bad practice. Yes, it's prone to breakage even under normal (Windows)
circumstances if there is an update. But it is not uncommon on Windows
and so it must work on Wine.

We have a perfectly good security boundary between the process and
everything else. Why try to create another one within the process?

> By the way Vincent Provirk lot of nocd hacks and game cheats trip straight up over Linux secuirty even when it set on low because they try to edit forbin memory sections.

That still makes Wine broken, even if OS limitations make it
unfixable. There are many bugs like that.

> This is why presuming you have a hole in Linux secuirty is bad.  One day it will be taken away from you and your application will snap.    It will produce a nice little secuirty report saying what you tried to do.
>
> You are simply failing to understand you cannot design under Linux and expect to use any form of secuirty hole.   Doing so is asking for your application to fail.

What I'm failing to understand is why you think the ability to see the
host OS from a Windows program running in Wine is anything like a
security hole. If Wine itself can do something, there's no security
reason that a Windows program shouldn't be able to do it.

Yes, trying to use Linux syscalls in a Windows program (as well as
branching to non-entry-points, messing with internal structures,
giving unexpected input, etc.) is evil and prone to breaking. There's
simply no reason to do it when there are better ways. For example, I
can use native Wine API's to convert paths and start, say, /bin/sh.
But this isn't about security. It's about compatibility (these evil
methods make assumptions that may not always be true) and respecting
the user (if the user does choose to not map /, going around the drive
mappings is simply rude).