October 2002 - Wine-Devel - list.winehq.org

Re: Wine securityflaw.

by Greg Turner

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, such measures will only secure applications which don't specifically check for wine and circumvent its api-level security measures. 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. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Adobe SVG viewer mouse tracing

by Mike Hearn

Hi, I have CrossOver beta 1.3 and have got IE6 installed and version 3 of the Adobe SVG viewer. The installer doesn't work, but I got around that problem, the issue I'm interested in solving now is that mouse interaction is messed up, namely that when the plugin receives a mousemove event, it appears to immediately receive another for 0,0 - this is just a theory I've got however. I'm wondering if there's a way to restrict debug logging to code in a particular file? I'm not interested in any mouse messages except those to the COM object in NPSVG3.dll thanks -mike

Oct. 31, 2002

winapi_check question...

by Greg Turner

winapi_check tells me: ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 documentation: \ /* CLIENT_CALL_RETURN */ rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): no translation defined: PRPC_BINDING_VECTOR rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): no translation defined: PUUID_VECTOR rpc_epmap.c:102: rpcrt4: RPC_STATUS WINAPI RpcEpUnregister(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR): argument 2 type is forbidden: PRPC_BINDING_VECTOR (unknown) how shall I deal with these? -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes

by Lionel Ulmer

> Apologies for needing some more hand-holding: from Alexander's advice I now > have the game linking and beginning to execute. It now gets stuck while > executing this piece of C++: Hmm, according to the backtrace, it is rather crashing when executing 'User_DirectDraw_EnumDisplayModes' (ie something like mp_directDraw->EnumDisplayModes(...)) in the tDirectDrawScreen::setUpWindowedSurfaces method. >From what I see, I wonder if the enum procedure you give to DDraw has the right protoype (ie is it a STDCALL or a CDECL function) ? Moreover, a --debugmsg +ddraw trace would be helpful too with the backtrace + the actual code at Source/tDirectDrawScreen.cpp:852 Lionel -- Lionel Ulmer - http://www.bbrox.org/

Oct. 31, 2002

Re: XBox

by Z_God

Op donderdag 31 oktober 2002 01:04, schreef Chris Thielen: > On Wed, 2002-10-30 at 12:10, Dirk wrote: > > Could someone do something to make the need for this hardware disappear > > and save the world of people who love proprietrary video game consoles? > > > > There is already a tool that converts xpe files into exe. Only the bios > > and the improved DirectX must be re-engineered and the rest will be done > > by a Geforce4 (or 5) and a 2Ghz CPU. > > I'm sure an Xbox emulator will eventually come along, assuming there > aren't a few already in the works; they, however, under Linux at least, > would have to implement DirectX calls; it would be interesting to > frequently contact those developers as they would face many of the same > issues of implementing DirectX as the newly formed Wine DX group will. I > don't know of any emulators that support Xbox architecture, but I don't > think wine should be the project to do so, not unless an Xbox game runs > under (normal) Windows. Xbox apps run on a minimal version of the Windows 2000 kernel.

Oct. 31, 2002

Re: Versions & mass-appeal

by Shachar Shemesh

Johan Gill wrote: >On Thu, 31 Oct 2002, Shachar Shemesh wrote: > > > >>The way I see it, no windows installs of wine should have dll load order >>set to "native, builtin" for all DLLs. >> >I'm not sure that we are talking about the same thing here... >Just to be safe, what I mean is that if I want to run an application which >has its own *non-system* dlls I have to tell wine to load them natively, >or they won't get loaded at all. > But if it's a non-system DLL, why should it have a Wine version at all? If it doesn't, then ANY load order that has native somewhere in it will load the DLLs in the system. The only place where that comes into play is when a certain program ships with a new version of MFC42.DLL, for example. That is, at least, my understanding of this issue. > If you meant the same thing as I did, >I need some reading practice. > What makes you think (besides being polite, and I'm not saying there is anything wrong with that) that it isn't me that need writing practice? I will note that, judging from geographical location alone, English is not a mother tongue for either of us. >/Johan Gill, johane(a)lysator.liu.se > Shachar P.S. In case anyone is wondering, I have other indications that English is not a mother tongue for me. There is the fact that I had to look up how to spell "tongue" for one, and that thing that makes sure that you keep knowing something once you knew it once, now how do you call it..... Oh yes, "memory". Sh.

Oct. 31, 2002

Re: Wine securityflaw.

by Raul Dias

My $0.02, I always though of a wine as way to run windows apps better than windows. Better also means "more secure" for me. 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. This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct. As this would be implemented in wine (as opposed in the host OS, e.g. the Linux kernel) a Dialog could pop up telling the user what the app is trying to do and how the user would like to proceed, like: <allow this time>, <allow this session>, <always allow>, <deny this time>, ... and so on. This could be configured in the config as the dll loading is done now in a per app way or generic (all apps) way. Of course, this being implemented in wine as a wrapper to such API calls would slow the performance a little, so wine could be compiled with '--disable-runtime-security' is configure or something like that. This way wine could be compiled just as if this feature did not existed (as it is now). I know this is not a priority to wine project right nowand there is a lot of things to be done to get to wine 0.9 and 1.0. However, I do think that just setting this to a OS problem and that wine should not care about this is wrong. Maybe this is just not the right time to implement this, but this shouldn't be banned. I agree that you shouldn't run any untrusted code as people would not do with Linux/Bsd/..., however there is a strong point here. 99.9999% of win32 applications is closed source. There is no way to trust them. Even common ones like MS Office can be exploited and used to run mallicious code. Codeweavers would need to handle this later on. Internet Explorer can run potencially untrusted/dangerous code with ActiveX from webpages. And its use is already advertised with Codeweavers Xover Office (not supported though). Many programs already install some kind of spyware nowadays, like any p2p as Kazaa, morpheus, edonkey2000, ... Even RealPlay used to send private information thru the net. As Wine gets more and more reliable to run win32 applications and Microsoft change its EULA to not run applciations like Media Player in other OSes that Windows. And this discussion of syscalls that only wine as a linux application could do, could make future versions of MS apps use this to exploit limitations as the wine drivers and wipe everything it has permissions to. And this would be leagal as no one really reads the EULA. Note that I did not get to the merity of Virus that nowadays are the number one reason people are moving to (or willing to) Linux. Wine could implement a clean Security Layer: YES Is this a priority for Wine Project: NO (not yet at least) This kind of stuff is what would make Wine a possibility run run Windows Apps better than Windows. Because of this points, I would like to ask Alexandre to not deny the possibility to a developer to try to implement this kind of layer of security. I agree that this needs to be deeply discussed on how it should be implemented and that after some start to implement this, this could take a long time before being merged in the main tree. However, this is not just a OS problem IMO. Regards, Raul Dias Alexandre Julliard <julliard(a)winehq.com> wrote: >Peter Andersson <kanelballe(a)softhome.net> writes: > >> 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. > >You should. If you run untrusted code under your account it can do >anything that you are allowed to. This is exactly equivalent to >running an untrusted Linux app. From a security standpoint there is >absolutely no difference between a Windows binary running under Wine >and a Linux binary running natively. > >You can use the DOS drive configuration to limit the potential >problems a bug in a Windows app can cause; but it is impossible to >protect against malicious code except by not running it. Wine is not, >and cannot be, a sandbox for running untrusted code. > >> Cant we atleast try implement some protection in wine against these attacks, >> before something really nasty happens. > >No, we can't. > >-- >Alexandre Julliard >julliard(a)winehq.com >

Oct. 31, 2002

Re: RPC test code?

by Greg Turner

On Wednesday 30 October 2002 12:22 pm, Greg Turner wrote: > BTW, this is somewhat off-topic, but sometimes the winsock test hangs > for me after "make testclean"; ctrl-c and re-running "make test" > always works, so I wonder if perhaps there is a race condition > tickled by the make processing? Next time (if there is one) that I > encounter this, I'll attach a debugger and tell you what I see. this happened to turn up last night. first, i was wrong that this was your winsock test, Martin; it's the http test in dlls/wininet/tests (not sure who owns that code?) nevertheless, i attached a debugger, here's a trace: #0 0x4033a0a4 in read () from /lib/libc.so.6 #1 0x40110654 in __JCR_LIST__ () from /var/src/wine/dlls/libntdll.dll.so #2 0x400ccc33 in WaitForMultipleObjectsEx (count=0, handles=0x0, wait_all=0, timeout=100, alertable=0) at ../../scheduler/synchro.c:265 #3 0x400cc989 in Sleep (timeout=100) at ../../scheduler/synchro.c:186 #4 0x40234a43 in winapi_test (flags=268435456) at http.c:139 #5 0x40234f8c in func_http () at http.c:211 #6 0x402354ee in run_test (name=0xbffff7c5 "http.c") at ../../../include/wine/test.h:283 #7 0x402356f4 in main (argc=2, argv=0xbffff638) at ../../../include/wine/test.h:322 #8 0x40234040 in __wine_exe_main () at wininet_test.exe.spec.c:133 #9 0x400c80aa in start_process () at ../../scheduler/process.c:564 #10 0x400ccfa5 in call_on_thread_stack (func=0x400c7dde) at ../../scheduler/sysdeps.c:112 (gdb) after this, as predicted above, "killall wine; killall wineserver; make test" succeeded. "rm dlls/wininet/tests/http.ok; make test" also succeeds. As soon as I do "make testclean && make test," it hangs again. To whomever wants to tackle this, let me know if there's more info I should give; the behvior is more-or-less repeatable on my box. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

SIGSEGV in IDirectDrawImpl_EnumDisplayModes

by Matthew Bloch

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

Oct. 31, 2002

Re: Versions & mass-appeal

by Johan Gill

On Thu, 31 Oct 2002, Shachar Shemesh wrote: > The way I see it, no windows installs of wine should have dll load order > set to "native, builtin" for all DLLs. > > The rational is that, as no DLL originally came from a native windows > environment, all dlls present in the system are from various installs. > It was therefor the application's install decision to override the dll > available at the time of install with a new version. For that to > properly work, it must be possible to query the builtin DLLs version > with the APIs available to standard installers, and have the version > reported for our DLLs be comparable to DLLs of same functionality > available on Windows. I am not sure where that stands at the moment, > however. > Shachar I'm not sure that we are talking about the same thing here... Just to be safe, what I mean is that if I want to run an application which has its own *non-system* dlls I have to tell wine to load them natively, or they won't get loaded at all. If you meant the same thing as I did, I need some reading practice. /Johan Gill, johane(a)lysator.liu.se

Oct. 31, 2002