January 2008 - Wine-Bugs - list.winehq.org

[Bug 11421] Wine makes possible for windows virus to work?

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11421 James Hawkins <truiken(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from James Hawkins <truiken(a)gmail.com> 2008-01-31 15:43:58 --- Um, closing again. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11421] Wine makes possible for windows virus to work?

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11421 Roderick Colenbrander <thunderbird2k(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED --- Comment #3 from Roderick Colenbrander <thunderbird2k(a)gmx.net> 2008-01-31 15:41:23 --- There is nothing around that prevents windows viruses from working on wine. We try to be like windows in every regard. In a few ways we are more safe as windows viruses can't gain root permissions and perform more nasty things. Second if you are worried you can remove the z: link, so that viruses won't see all of the system and only the wine c: drive. You can run anti-spyware tools or even a virus scanner on wine (some work). Sorry but there is nothing which we can do about. Further some people are planning to add a way to edit run/runonce settings without having to resort to regedit. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11421] Wine makes possible for windows virus to work?

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11421 James Hawkins <truiken(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #2 from James Hawkins <truiken(a)gmail.com> 2008-01-31 15:40:28 --- Closing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11421] Wine makes possible for windows virus to work?

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11421 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger(a)gmx.at Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #1 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2008-01-31 15:38:01 --- You're right on all points. Even more than that, a windows virus can do any Linux syscall via INT 0x80. So even without the Z:\ drive a Windows Virus running in Wine can do everything a Linux application running on the same account can do. This is not a bug though. This is a consequence of how Wine works. Wine is not a security sandbox. If you want to protect yourself against Windows viruses use any Linux or Windows based security software. For example, run Windows apps as a normal user, not root, and your Linux system can't be hurt. Run Windows apps in a chroot environment and they won't be able to access your data. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11421] New: Wine makes possible for windows virus to work?

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11421 Summary: Wine makes possible for windows virus to work? Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: tsalacinski(a)gmail.com I know that it's too early to say this, but when Wine started to support Run and RunOnce registry entries, I have few Windows worms on my computer (I've been using ies4linux). Is this possible, that when for example virus developer will think about supporting Linux he will steal data? I think, yes. As we know, wine have access to the whole drive (most users have / configured as Z:\). If we have a virus installed in Run in the registry, and the virus will look for every drive in the system (especially for Z:\) it can try to detect if there is any Z:\home\[user] directory and it can steal data from it. Virus devs can even try to compile their viruses with libwine to check if they will work on Linux. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11251] Photoshop CS2 update process funky

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11251 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kopseng(a)stud.ntnu.no --- Comment #1 from Dan Kegel <dank(a)kegel.com> 2008-01-31 14:40:47 --- *** Bug 11377 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11377] Photoshop CS2: Detailed update view disappears on click

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11377 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Dan Kegel <dank(a)kegel.com> 2008-01-31 14:40:47 --- Yep! I filed that earlier as bug 11251, but thanks for the screenshots. *** This bug has been marked as a duplicate of bug 11251 *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11420] New: service control manager API problem: name of named objects might differ (client vs. service process)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11420 Summary: service control manager API problem: name of named objects might differ (client vs. service process) Product: Wine Version: 0.9.54. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=10552) --> (http://bugs.winehq.org/attachment.cgi?id=10552) patch which fixes client vs. service SCM API when using named objects Hello, there seems to be a misconception in usage of names for named objects in service control manager API. Some people might have experienced such situation: wine hangs for several seconds on startup (when starting services). I usually disabled autostart type services (except for builtin ones) and the problems went away. Lately while fixing Microsoft Visual Studio .NET installers (2002/2003/2005) this problem became more and more annoying because the installers and VS.NET depend on some services, namely "debug manager" (service has to be running). Consider the following snippet with "service_get_event_handle" trace message added by me to highlight the problem: 0x9: client (net.exe) 0x11: service process (mdm.exe) 0x12: dispatcher thread --- snip trace --- .. 0009:trace:advapi:OpenSCManagerW ((null),(null),0x000f003f) 0009:trace:advapi:sc_handle_alloc sc_handle type=0 -> 0x121450 0009:trace:advapi:OpenSCManagerW returning 0x121450 (access : 0x000f003f) 0009:trace:advapi:OpenServiceA 0x121450 "mdm" 983103 0009:trace:advapi:OpenServiceW 0x121450 L"mdm" 983103 0009:trace:advapi:sc_handle_alloc sc_handle type=1 -> 0x121488 0009:trace:advapi:OpenServiceW returning 0x121488 0009:trace:advapi:GetServiceDisplayNameA 0x121450 "mdm" 0x34ee48 0x34fe48 0009:trace:advapi:GetServiceDisplayNameW 0x121450 L"mdm" 0x1214b8 0x34ee08 The Machine Debug Manager service is starting. 0009:trace:advapi:StartServiceA (0x121488,0,(nil)) 0009:trace:advapi:StartServiceW 0x121488 0 (nil) 0009:trace:advapi:LockServiceDatabase 0x121450 0009:trace:advapi:LockServiceDatabase returning 0x3c 0009:trace:advapi:service_start_process service_get_event_handle(L"mdm"): 0x40 0011:trace:advapi:LookupPrivilegeValueW L"",L"SeDebugPrivilege",0x34fc80 0011:trace:advapi:LookupPrivilegeValueW L"" -> 00000000-00000014 0011:trace:advapi:AdjustTokenPrivileges 0011:trace:advapi:StartServiceCtrlDispatcherA 0x34fc9c 0011:trace:advapi:service_run_threads Starting 1 pipe listener threads. Services running as process 16 0012:trace:advapi:service_control_dispatcher 0x121ea8 L"Machine Debug Manager" 0012:trace:advapi:service_control_dispatcher service_get_event_handle(L"Machine Debug Manager"): 0x48 0009:trace:advapi:UnlockServiceDatabase 0x3c 0009:trace:advapi:StartServiceW returning 0 The Machine Debug Manager service failed to start. 0009:trace:advapi:CloseServiceHandle 0x121488 0009:trace:advapi:sc_handle_destroy_service destroying service 0x121488 0009:trace:advapi:CloseServiceHandle 0x121450 0009:trace:advapi:sc_handle_destroy_manager destroying SC Manager 0x121450 000d:trace:advapi:service_run_threads last user process exited, shutting down 0011:trace:advapi:service_run_threads last user process exited, shutting down --- snip trace --- When a service is started, named objects are created to internally communicate data/events from the service process (dispatcher) to client side SCM API and vice versa. Unfortunately there exist service proccesses which pass service names to dispatcher table (StartServiceCtrlDispatcher) not matching the service name on the client side (registry "Services" key). --- snip dlls/advapi32/service.c --- static DWORD WINAPI service_control_dispatcher(LPVOID arg) { service_data *service = arg; LPWSTR name; HANDLE pipe, event; TRACE("%p %s\n", service, debugstr_w(service->name)); /* create a pipe to talk to the rest of the world with */ name = service_get_pipe_name(service->name); <--------- *problem*! pipe = CreateNamedPipeW(name, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, 1, 256, 256, 10000, NULL ); if (pipe==INVALID_HANDLE_VALUE) ERR("failed to create pipe for %s, error = %d\n", debugstr_w(service->name), GetLastError()); HeapFree(GetProcessHeap(), 0, name); /* let the process who started us know we've tried to create a pipe */ event = service_get_event_handle(service->name); <--------- *problem*! SetEvent(event); CloseHandle(event); .. --- snip dlls/advapi32/service.c --- As result, different named objects are created and signaled so the client side can't communicate with the service side using named pipe and events. This leads to infamous timeout problem (30 sec) and service startup failing. In case of Microsoft Debug Manager the service is called "mdm" (registry). The service process itself passes "Microsoft Debug Manager" as name to dispatch table (see first trace). Problem: how can both sides communicate a "common" name for named objects? The service dispatcher part on the service side has only dispatch table data available which doesn't help much. I thought about this problem and found a feasible solution ... well call it "hack" whatever. If the client side API passes the service name in one of the process startup parameter members before process creation, the service process' dispatcher routine is able to access this data and create the named objects used for communication. I (ab)used startupinfo "title" member because only wine itself make exclusive use of most service process startup parameters. If not considered safe, use reserved/undoc fields... With that patch applied the services in question start fine and can be controlled using "net" commands. No more hangs ;-) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11419] Installation of Intel Indeo Video freezes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11419 Lei Zhang <thestig(a)google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ole |-unknown Keywords| |Installer --- Comment #1 from Lei Zhang <thestig(a)google.com> 2008-01-31 14:06:52 --- Can you provide a download link? Please attach the console output, if any. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008

[Bug 11418] Traffic giant does not start with CD in drive

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11418 --- Comment #1 from Lei Zhang <thestig(a)google.com> 2008-01-31 14:04:38 --- save the full output from the crash and attach it to this bug report. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Jan. 31, 2008