Wine securityflaw.

[Geoff Thorpe]

On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote:
> On Thursday 31 October 2002 08:10 am, Raul Dias wrote:
> > My $0.02,
> >
> > A way to make it more secure is to catch key API calls and decide if
> > the application is allowed to run it or not.
>
> not a bad idea.
>
> > Wine could implement a clean Security Layer: YES
>
> Clean, perhaps, but secure?  That depends on what you are trying to
> achieve: since the unix API is available to apps running under wine,

This subject interests me a great deal so please humour me as I try to
wrap my head around the wine-specifics well enough to get an
accurate(ish) picture of this. I'm a security person, but no win32
expert and even less of a PE/ELF hacker...

First I can understand the point made that, at the end of the day, the
only *actual* security you can force on a wine-loaded application is
whatever security the operating system forces on *all* applications
(wine-loaded or otherwise) running as the same user. Ie. even if a win32
application loaded under wine couldn't directly call ioctl(), unlink(),
or fopen(), the binary code could still *reimplement* those functions in
assembly. I also realise that other assembly hacks (or just
trail-and-error "luck" virii) could scan the process's memory space
looking for likely function pointers, file-descriptors, etc and start
meddling with them directly to bypass the wine-implemented win32 API.
Does that seem a reasonable understanding of the situation?

My next question is this: why is the unix API available to
wine-loaded PE apps/libs? I can't see a single compelling reason for
this, though I'm prepared to be illuminated otherwise. If we discard
memory-scanning and other assembly tricks for a moment and consider just
the case of PE apps/libs generated from "clean C" (and "clean
compilers"); then preventing any direct binding of any wine-loaded PE
images to native ELF images, *except* those implemented by wine,
immediately raises the bar. Of course, I'm assuming this is *possible*
with the PE (and ELF) format(s)?

My problem with discarding the "clean" security layer because it isn't
perfectly impenetrable in a technical sense, is that it is purely an
abstract technical-only view of things, and Wine's role (and
threat-model for its future success) is anything but purely technical.
Jeremy, I'd be particularly interested if you have any thoughts on this.
AFAICS, this idea is not just a question of security by obscurity -
there are technical and "political" issues involved too.

First, not linking PE images to non-wine ELF images allows one to define
a security policy in wine for win32/PE executable code akin to a "rules
for Win32 programs" config. One possibility here is the kind of thing
Raul was discussing. Buggy programs aren't programs that try to detect
if they're running in wine and if so do damage - buggy programs are
programs using the win32 API written by careless win32 bunnies. *Those*
programs could be subject to a policy configuration that would allow you
to selectively restrict things in a way that will *always* be better
than what MS-windows provides - whether the programs are horribly buggy
or really solid. In other words, a configurable real-world
control/protection against potentially buggy win32 code (that would be
equally buggy on MS-windows and Wine after all).

Second, if the PE loader doesn't blindly link PE apps/libs to native
libraries, then bypassing the wine-implemented win32 API (and thus the
policy configuration) would require an *explicit* workaround on the part
of the programmer. Putting in assembly code to prime registers and fire
interrupts that (a) on linux would getenv("HOME") and unlink() the
result, and (b) on windows would probably just crash with a BSOD is what
the security community call a "virus". :-) It doesn't have to be
difficult for the programmer to do it, it just has to require him/her to
be malicious and unambiguously *intend* to do it. Writing and
distributing one of these things opens you up to criminal prosecution in
many jurisdictions, and also allows McAfee and friends to assign a
signature to corresponding binaries and get them classified as a virus
(and their authors classified as bad people).

Or put another way - as Wine converges on "beta" or "release" level and
Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a
competitor to MS-windows, but in fact offers considerable advantages,
where then will the *threats* to wine lie?? I would certainly like to
(a) see the flexibility of being able to apply a "soft" security policy
for win32 applications in the wine-implemented win32 API, (b) force
win32 developers who are "anti-wine" and "pro-monopoly" to have to
expose themselves to criminal possibilites if they want to bypass
wine-based execution configuration and controls (or worse, if they want
to package anti-wine trojans).

> So, for example, this could be used to protect a system against
> security flaws in Internet Exploder or Outlook... but a malicious virus
> writer could work around winapi-based security provisions, as discussed
> earlier in this thread.

Yes, and I think the point that's worth making is that writing a
malicious virus against wine is not only a crime in the sense that
normal virus-writing is a crime, but also has
anti-trust/anti-competition overtones ... when you try to imagine which
companies would most like their win32-based applications to *NOT* run on
wine (and perhaps even hurt wine users), you might understand where I'm
coming from.

In lieu of "pure" security enforcements (which would require
virtualisation anyway which Wine is not in the business of), I think a
"win32-API-based" security approach is worthwhile. If I can write win32
apps that link directly to libc, I could elect to replace the
file-management subsystem of my app with a POSIXy layer that is only
used on wine "for performance reasons only, honest!". This would mean
(a) Wine's file-system configuration can be bypassed, and (b) I could
(perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem
but have my win32 subsystem very stable. This program would just be
"unstable on wine" but not "anti-competitive" nor "criminal". But if you
don't let applications do this in wine's PE-loader (or at least let it
be controllable in the config) then acheiving the same result would
require me to write a genuine virus instead (and so open myself to
anti-trust/criminal accusations).

Thoughts?

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/