Re: Wine securityflaw.
On Sunday 27 October 2002 22.19, Francois Gouget wrote: > On Sun, 27 Oct 2002, Peter Andersson wrote: > > What is it with you people? > > I was just trying to make a point about the security risks about using > > wine at present. And you start flameing me? > > We're not flaming you. We're just see big flaws with your proposal. We > also proposed alternatives that seem to make more sense to us. > > Why don't you study how chroot or jail could be used in combination with > Wine to build a sandbox? As far as I know no-one has tried that and it > is possible that some changes in Wine could make things simpler to set > up. Of course, we won't know until someone actually tries this. Finally someone that takes my concerns serriously, thank you! I agree. Using chroot could offer the functionality Im looking for. I will try the chroot model for now, I have a feeling that this wont be enough though, but we will see. Something in the chroot manside got me puzzled: ... ... ... Only the super-user may change the root directory. Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'. ... ... ... I will have to figure out the consequences of this odd behaviour, it certainly dont sound very safe at first look. Maybe jail is much better, but it seems to require porting as you said. //Peter
Re: Wine securityflaw.
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? Instead of continuing this flame war I will try to express myself more clearly. Before I go into details of my idea, lets make a few things clear... I agree that focus of the Wines project, should be more towards running windows applications than on extreme security. I also agree that securing an environment usually means reducing the freedom and flexibility to do things. My intention was that some security should be offered in wine regarding the attacks. This would not neccesary need to be a mandatory solution, it should IMHO be an easily configured on/off option feature. My idea is to use ptrace in a supervisor process to trap all syscalls from the wine process, and use some kind of sanity checks for some of the syscalls. Watching the fork,exec,open,write and unlink syscalls and doing sanity checks could offer atleast some security. Could this work? Do you see this as a useful option? //Peter On Sunday 27 October 2002 03.06, Francois Gouget wrote: > On Sun, 27 Oct 2002, Peter Andersson wrote: > [...] > > > I believe most wine users trust wine not to touch anything outside of > > its configured drive space. Malicious Linux/Unix syscalls could be > > embedded in windows apps and if executed do a great deal of damage. > > 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. > > > > 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? > > 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. > > [...more snipped...] > > Certainly I would be surprised to see a Wine-aware virus tomorrow. In > that sense I certainly would not expect this sort of thing to happen > tomorrow. But you seem to be confused about the goal of Wine. > > The goal of Wine is to run Windows applications on Unix. Windows > applications run through Wine should be able to do no more and no less > than any other Linux application. Thus Wine is not more of a security > risk than any other piece of (somewhat alpha) software. > > But the goal of Wine is *not* to build a sandbox or a virtual machine in > which you can safely run malicious code. If that is what you want, then > you should look at chroot, jail, User Mode Linux, VMWare or Plex86. You > can even combine them with Wine to build sandboxes. For instance you > could run Wine in a 'jail' environment and then a Wine-aware would be > confined to that environment. > > > That being said, yes it is possible to configure Wine such that Windows > applications are confined to a small portion of your disk. It is a > useful feature and, as far as I know, it should work against all current > Windows viruses. Of course, when configured this way Wine is not very > useable. You would not be able to use Word to edit your documents for > instance... that is unless you menually copy the document to the Wine > environment where any Windows virus will be able to munge it. You simply > cannot have it both ways.
Wine securityflaw.
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. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. 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. 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? 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. 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. 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. 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
Re: How is Win/Dos syscalls implemented in Wine?
On Saturday 26 October 2002 21.32, Eric Pouech wrote: > > You never know that the future holds. I can think of atleast one > > big company that want the death to Linux and Wine, its located > > in Redmond somewhere :-) > > they'd better fix their own security holes ;-) > > > I was told direct syscalls were only made through lovest level dlls, > > like ntdll,and from whithin dos/16 bit system. > > Whats this? > > we're still speaking from two different levels: > - on windows, all the windows-syscalls are made from ntdll > - on wine, no real windows-syscalls are made. However, every (native > wine) DLL is able to link against libc and thus make linux-syscalls > hence the difference > OK, I didnt realise this before (lack of wine knowledge). This means the linux sycall can possibly come from every wine-native dll. I agree, tracing syscalls will be very hard indeed. > > > 2/ allow disallow the traps you want > > > > Why disallow interupt traps? > > (here read linux-syscalls) > > > I must admit I dont have a percent of your knowledge about the Wine > > and Windows architectures, so I have a hard time understanding why > > this is needed, and if therfore if its because of the way Wine is > > currently working or the way Windows calling is made. > > > > Imagine you write and ownership protect the trusted low level dlls > > (the ones that are supposed to be allowed syscalls). > > Would it not be possible to trace every Wine process for interupts and > > check if its originates from the lowlevel dlls? Checking the adress where > > interupt was is in the memory range of the loaded ntdll, to allow or > > disallow the call. Wouldnt that work? > > it depends what you want to achieve, but it won't be sufficient. > examine the following code: > > trusted dll: > a) setup regs for syscall > b) int 80h > > malicious non trusted dll: > 1) setup malicious regs (like erase file...) > 2) jump at the address of the int 80h above > 3) > (of course you won't be able to go back to 3), but this would still > allow you to make a valid syscall > looking at all trusted dlls you might even find some code where you get > something like (in trusted dll) > a) setup regs for syscall > b) int 80h > c) ret > and in that case, jsr address of b from untrusted code would circumvent > your scheme > > once again, since: > - wine is just seen from the linux kernel as a standard process > - wine core DLLs and the loaded code live in the same address space > it would be extremely difficult to implement this type of protection on > wine (as it is today) > it might possible using some kind of code control tools. the new skins > on valgrind would help here, but that would be done in a completly > different manner > > A+ You are right, and as Sylvain Petreolle wrote it might even be possible to push the (iret) adress and jump to an int 80h instruction. But its still a fact that the supervisor process would trap the syscall, wouldnt it? It could still do a sanity check of the sycall. I know its hard but a few worst case scenario, like the removed home directory, could be catched. Some protection is better than no protection. //Peter
Re: How is Win/Dos syscalls implemented in Wine?
On Saturday 26 October 2002 18.01, Eric Pouech wrote: > > Well for now there are not much Linux viruses around. It is possible to > > write an antivirus program (I have not heard of any yet) for Linux/Unix. > > if antivirus check for a signature, it should find it. it would be more > difficult for polyforms virii of course. > As of today, I don't think that people willing to write virii for > (against) Linux would use wine as their insertion media > You never know that the future holds. I can think of atleast one big company that want the death to Linux and Wine, its located in Redmond somewhere :-) > > And > > there are antivirus programs for Windows. But how do you check for > > viruses that directly affects the Linux/Unix environment embedded > > within a Windows app? I believe running windows apps in wine should be > > trusted the same way as enabling java in a web browser. > > there are some validity checks against the PE (file format). however, > wine > doesn't provide a sandbox. intercepting linux syscalls isn't enough > you need also to prevent : > 1/ read/write to wine memory (which would trigger some other nice side > effects) > 2/ read/write of local files (which isn't allowed for java in web > browser by default...) > 3/ know if a requested operation (syscall, win32 api call) is malicious > or not > > so wine will not protect users from windows programs > > the best thing to do (see some recent discussion on wine-devel on this > topic) is to limit the part of the disk wine will be allowed to > read/write to > > > Has an int 0x80 any purpose in Windows environment? > > under dos it sure has (don't have Ralf Brown list handy) > > > > > Cant you fix this with ptrace? > > > > Are you really sure? > > you will need to: > 1/ know which part of memory is calling (wine DLLs vs program exec vs > loaded DLLs) [regular windows API must be allowed to call linux > syscalls] I was told direct syscalls were only made through lovest level dlls, like ntdll,and from whithin dos/16 bit system. Whats this? > 2/ allow disallow the traps you want Why disallow interupt traps? > 3/ and because of the point 1 above, this will not be of any protection. > > for example, look at the following scheme: > 1/ get the address of the implementation of an API in wine > 2/ call Win32 API to allow write access to this part of memory > 3/ modify the code the make the linux syscall you want > 4/ call in this API. > > of course, you could in the ptrace code check for CRC of memory (or > calling page), but I wouldn't dare to use the final performance of such > a beast > > if you have enough time to loose on this, feel free to do it > > A+ I must admit I dont have a percent of your knowledge about the Wine and Windows architectures, so I have a hard time understanding why this is needed, and if therfore if its because of the way Wine is currently working or the way Windows calling is made. Imagine you write and ownership protect the trusted low level dlls (the ones that are supposed to be allowed syscalls). Would it not be possible to trace every Wine process for interupts and check if its originates from the lowlevel dlls? Checking the adress where interupt was is in the memory range of the loaded ntdll, to allow or disallow the call. Wouldnt that work? //Peter
Re: How is Win/Dos syscalls implemented in Wine?
On Saturday 26 October 2002 14.13, Eric Pouech wrote: > > Conclusion: > > The ntdll is for wine apps what libc is for Linux/Unix. > > Syscalls is made from ntdll and the native version is never > > run. > > mostly (libc contains much more than ntdll does). A closer (yet > incomplete) answer would be libc = ntdll + kernel32 + msvcrt > (most of the win32 apps don't call ntdll in, they call kernel32 or > msvcrt in) > > > You are right about the syscalls in Linux, too bad > > theres no protection for it though. It should be, otherwise > > there could appear wine_linux viruses. > > well, there could, as well, be pure linux viruses. and, I don't see why > wine should be more protective than the linux kernel is. > Well for now there are not much Linux viruses around. It is possible to write an antivirus program (I have not heard of any yet) for Linux/Unix. And there are antivirus programs for Windows. But how do you check for viruses that directly affects the Linux/Unix environment embedded within a Windows app? I believe running windows apps in wine should be trusted the same way as enabling java in a web browser. Has an int 0x80 any purpose in Windows environment? What does it do? > > Cant you fix this with ptrace? > > no. > > A+ Are you really sure? Here is a cut of the Linux man side: ... ... ... PTRACE_SYSCALL, PTRACE_SINGLESTEP Restarts the stopped child as for PTRACE_CONT, but arranges for the child to be stopped at the next entry to or exit from a system call, or after exe- cution of a single instruction, respectively. (The child will also, as usual, be stopped upon receipt of a signal.) From the parent's perspective, the child will appear to have been stopped by receipt of a SIGTRAP. So, for PTRACE_SYSCALL, for example, the idea is to inspect the arguments to the system call at the first stop, then do another PTRACE_SYSCALL and inspect the return value of the system call at the second stop. (addr is ignored.) ... ... ... Cant you use this to trap the call and kill the process before it enters the kernel or maybe if its a 0x80 intreupt check the params for the call and do some protective actions if the call is not supported by wine? //Peter
Re: How is Win/Dos syscalls implemented in Wine?
Thanks for putting my thinking on the right track again... Conclusion: The ntdll is for wine apps what libc is for Linux/Unix. Syscalls is made from ntdll and the native version is never run. You are right about the syscalls in Linux, too bad theres no protection for it though. It should be, otherwise there could appear wine_linux viruses. Cant you fix this with ptrace? Thanks for your help! //Peter On Friday 25 October 2002 17.26, Ove Kaaven wrote: > On Fri, 25 Oct 2002, Peter Andersson wrote: > > Hello! > > Perhaps someone can give me a good answer to this question. > > Please give me a direct answer, I have allready been trouh the wine > > FAQ:s , docs, code, etc. > > > > I know DOS syscalls is made using interupts (int instruction) but, > > is Windows/NT syscalls made the same way. > > What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they > just call the system DLLs (which is just shared libraries). Wine > implements those DLLs in its own way. > > > How does wine stop these instructions from reaching the unix kernel? > > If you're talking about interrupts, the ones that DOS/Windows app may use > aren't accepted by Linux, so a segmentation fault happens when an app > tries to issue such an interrupt. Wine can catch that segmentation fault > by installing a SIGSEGV signal handler. If you're talking about the Win32 > API, then Wine just links the app to its own version of that API, so it > calls into the Wine-implemented DLLs.
Loading program icon
Hi, How do you read the icon of a windows application? Please tell me how to do it inside wine/windows-environment, and possibly independent of wine/win (the raw way). Can someone give me a hint? //Peter
Re: How is Win/Dos syscalls implemented in Wine?
Hi, Ok, I think I get it (never been much into Windoze codeing)... Windows "syscalls" is also actually done by requesting a dll mapping and calling the system_function inside processed mapped memory. Am I right so far? Is the dll mapping event, itself raised by some kind of SIGSEGV signal? About the DOS/Windows interrupts: Is it really sure that trusting SIGSEGV is safe? What happens for instance in this case: EAX (ackumulator register)= (char *) "$HOME" and an instruction interupt 10h (Linux unlink syscall)? This is a fully correct Linux syscall, wich would remove the users homedirectory if called, and would not raise a SIGSEGV signal. How would Wine stop this? I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also? //Peter On Friday 25 October 2002 17.26, you wrote: > On Fri, 25 Oct 2002, Peter Andersson wrote: > > Hello! > > Perhaps someone can give me a good answer to this question. > > Please give me a direct answer, I have allready been trouh the wine > > FAQ:s , docs, code, etc. > > > > I know DOS syscalls is made using interupts (int instruction) but, > > is Windows/NT syscalls made the same way. > > What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they > just call the system DLLs (which is just shared libraries). Wine > implements those DLLs in its own way. > > > How does wine stop these instructions from reaching the unix kernel? > > If you're talking about interrupts, the ones that DOS/Windows app may use > aren't accepted by Linux, so a segmentation fault happens when an app > tries to issue such an interrupt. Wine can catch that segmentation fault > by installing a SIGSEGV signal handler. If you're talking about the Win32 > API, then Wine just links the app to its own version of that API, so it > calls into the Wine-implemented DLLs.
How is Win/Dos syscalls implemented in Wine?
Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc. I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?
