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 _______________________________________________ wine-users mailing list wine-users@winehq.com http://www.winehq.com/mailman/listinfo/wine-users
