Wine securityflaw.

[David Fraser]

Geoff Thorpe wrote:

>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
>  
>
I think this is missing the point.
The way to make something secure isn't to make big software companies 
worry about
anti-trust, or virus writers worry they might get sued for writing a 
virus. Big companies
aren't likely to write wine-specific special workarounds that do nasty 
things, and virus
writers couldn't care less.
Any security improvements should be normal UNIX ideas like letting a 
wineserver
do certain priviledged tasks running as a special user, while standard 
wine programs
run as a different, non-priviledged user. In other words, the kernel 
layer in Windows
should have higher priveledges than standard user processes, but not run 
as root.

David