February 2009 - Wine-Devel - list.winehq.org

Re: Need help on couple of patches

by Jérôme Gardou

Igor Tarasov a écrit : > Hello! > > I've written 2 patches, and I need advice on both of them. > > First one is here: > http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html > > It's a single-line patch that adds forwarding notification that was > omitted in wine code. This fix looks pretty simple, but it included > lots of reading/testing/debugging, and here is what I came with. And > as I told there it fixes one wine bugzilla bug. > > But as I see, it was not comitted, so I am asking for advice: what > could I do in order to make it go through? > > Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 > > The patch adresses 3 problems that all together fix that bug. My > question there was if I should send it in one patch or in several. But > it seems that no one have noticed that post. > > Any help and advice is appreciated. Thanks. > > > > I can't answer your first question, but for the second one : wine developers policy is "one patch per fix". So you should send three patches.

Feb. 18, 2009

Need help on couple of patches

by Igor Tarasov

Hello! I've written 2 patches, and I need advice on both of them. First one is here: http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html It's a single-line patch that adds forwarding notification that was omitted in wine code. This fix looks pretty simple, but it included lots of reading/testing/debugging, and here is what I came with. And as I told there it fixes one wine bugzilla bug. But as I see, it was not comitted, so I am asking for advice: what could I do in order to make it go through? Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 The patch adresses 3 problems that all together fix that bug. My question there was if I should send it in one patch or in several. But it seems that no one have noticed that post. Any help and advice is appreciated. Thanks.

Feb. 18, 2009

Re: Status of USB driver support?

by Alexander Morozov

> Now I kindly ask: is there a simple way to integrate the official branch > with just the USB patches? You can use patches for wine-1.1.15 and git am. > If that USB Key is not of a supportable kind, then I apologize for asking. I think you should try.

Feb. 18, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by David Gerard

2009/2/17 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: > My opinion on this particular issue doesn't matter, but we don't > strictly prevent Windows apps from seeing the underlying Linux > environment. Any app can make linux system calls, access the filename > conversion functions, invoke linux programs, and access the unix > filesystem using a wine-specific shell extension. As I understand it, this isn't possible at present. If I'm wrong, I'd like to know :-) (This is relevant to, e.g. malware analysis using Wine - where Wine-aware malware could easily just use int 0x80 to break out of the Wine environment. Which is one of the hazards of deliberately running toxic waste, and is why Zero Wine runs as a QEMU virtual machine rather than on the box directly, for a bit more safety.) - d.

Feb. 18, 2009

Re: Wine & viruses

by Damjan Jovanovic

On Wed, Feb 18, 2009 at 5:33 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: >> 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: >>> Why not make Wine honor the noexe flag on the mount? >> >> This might not be a bad idea, if it's possible. Make Wine refuse to >> run apps on noexec filesystems. > > This already doesn't work, even though Wine doesn't account for it. > Wine can't mount sections of an exe file with executable permissions > if it's on a noexec filesystem. It crashes trying to branch to the > entry point. > > > It could, for some executables, still work on a noexec filesystem, due to http://wiki.winehq.org/UnalignedMmap copying data instead of mmaping it. Regards Damjan

Feb. 18, 2009

Re: ntdll: Replace malloc() with RtlAllocateHeap()

by Rob Shearman

2009/2/17 Andrew Talbot <andrew.talbot(a)talbotville.com>: > Changelog: > ntdll: Replace malloc() with RtlAllocateHeap(). > > diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c > index 145540f..0cade3f 100644 > --- a/dlls/ntdll/server.c > +++ b/dlls/ntdll/server.c > @@ -743,13 +743,13 @@ static void setup_config_dir(void) > struct stat st; > char *tmp_dir; > > - if (!(tmp_dir = malloc( p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > + if (!(tmp_dir = RtlAllocateHeap( GetProcessHeap(), 0, p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > memcpy( tmp_dir, config_dir, p - config_dir ); > tmp_dir[p - config_dir] = 0; > if (!stat( tmp_dir, &st ) && st.st_uid != getuid()) > fatal_error( "'%s' is not owned by you, refusing to create a configuration directory there\n", > tmp_dir ); > - free( tmp_dir ); > + RtlFreeHeap( GetProcessHeap(), 0, tmp_dir ); > } I'd be surprised if this worked, since setup_config_dir is called very early in the ntdll execution sequence, and RtlAllocateHeap itself will depend on server calls (NtAllocateVirtualMemory, NtCreateMutex, etc.) that depend on the server having started (i.e. after this function having already executed). -- Rob Shearman

Feb. 18, 2009

Re: Wine & viruses

by Vincent Povirk

> Wine can't mount sections of an exe file with executable permissions > if it's on a noexec filesystem. Err, sorry, meant to say "map", not "mount".

Feb. 18, 2009

Re: Wine & viruses

by Vincent Povirk

> 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: >> Why not make Wine honor the noexe flag on the mount? > > This might not be a bad idea, if it's possible. Make Wine refuse to > run apps on noexec filesystems. This already doesn't work, even though Wine doesn't account for it. Wine can't mount sections of an exe file with executable permissions if it's on a noexec filesystem. It crashes trying to branch to the entry point.

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Steven Edwards

On Wed, Feb 18, 2009 at 5:20 AM, Francois Gouget <fgouget(a)free.fr> wrote: > My remark was not so much about including windows.h rather than > winfoo.h, but about including it in winetest.h when the parent C file > has already included the winxxx.h files it needs. That is, in Wine it > seems we have a policy to put include statements primarily in the C > files, rather than in private header files. > > Also: > * I don't see what depends on windows.h in winietest.h (besides my > newly added annotations). > * if I remember correctly, removing this include did not cause any > warning or compilation error (even with my newly added annotations). > But maybe it's different if you compile with MinGW or MSVC (in which > case Wine's headers should be fixed). Right, I don't disagree with the change, I was more just thinking out loud. I agree it does not need to be in that header, I just think we should not avoid using windows.h in the programs. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 18, 2009

Re: Wine & viruses

by Mihai Donțu

On Wednesday 18 February 2009, Ben Klein wrote: > 2009/2/18 Martin Hinner <martin(a)hinner.info>: > > Hi, > > > > I will start one more hot discussion. Sorry if it was discussed > > earlier, I am not regular reader of this mailing-list. I tried to > > search google, found several discussions, but no real result: > > It won't be very hot. > > > http://www.linux.com/feature/42031 > > http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus > > https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 > > wine-devel mailing list google results > > > > The problem is that some (almost all?) distributions simply execute > > .exe file when you click on it. I was amazed when testing JTAGTest on > > Linux! This is in my opinion quite big issue as ordinary users do not > > have problem clicking on "New folder.exe" on their flashdisk etc. > > Well, that's a problem with, at most, the distribution or, at least, > the user being silly. > > > It's good that wine is so compatible that it runs even viruses, but I > > think there should be some (optional) protection. The biggest > > problem seem to be removable media, in many distributions mounted > > under /mnt or /media. > > Removable media can be mounted literally anywhere. It'd be easier to > find it with HAL, but it's not something suitable for Wine. > > > Please think about this twice before writing "problem is in > > Microsoft not in Wine", "it's not a bug but feature", etc. It's too > > childish IMO. > > Hmmm, let me think about this ... and again ... it's not a bug, it's a > feature. There is no 100% fool-proof way to determine whether the user > is about to run some malware or some legitimate application. > > > - What about creating a configurable list of directories, where wine > > would first ask if you really want to execute the program? It would be > > up to distribution what is set-up by default. > > Again, this is not something suitable for Wine. Perhaps getting the > distributions to mount removable media with the noexec option would > help. Of course, this wouldn't help if .exe files were associated with > Wine via the file managers, but maybe you think that should stop too. > > > - It's long time I have been interested in viruses, but I think that > > 90% of most common virus infected/trojan .exe files can be pretty > > easily identified. Almost every modern virus is trying to connect to > > the internet either by opening socket or using few standard DLL > > functions. > > Gee, this sounds like ever other networking application. Why? Because > GOOD viruses, trojans, worms etc. are suitably disguised as genuine > applications. > > > What about adding some checks to Wine that would check the > > calling function code sample against some small database to see if > > this is a virus and ask user? Or adding some "API" functions to allow > > someone to write such program? > > What you're suggesting is to include a standard virus scanner in Wine. > Not going to happen. Use clamav instead. It's opensource and has > *nix-native versionns. > > > I have done quite a lot of work with PE loading and code > > modification and I think it could be moved to level when it works > > without crashing anything. > > > > I understand, that none of this is system solution. But are > > anti-viruses system solution? They solve real world problem. > > "System solution"? Anti-viruses are the only reasonable solution. > History of computer science has shown us that the harder you try to > prevent something the harder other people try to do it. Anti-virus > programs mitigate some of that, detecting known viruses and > quarantining or deleting them. They're not perfect, but they're a lot > better than what other options we have. > > A new version of Wine is released every 2 weeks. This is too long to > keep a virus database up-to-date, and a lot of people don't upgrade as > soon as the release comes out any way. > > > Regarding API I have mentioned above I mean some hookdll() function > > that would re-direct GetProcAddress() or PE loader for defined > > functions, i.e.: > > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 > > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 > > Redirecting GetProcAddress() sounds more like a security hazard than a > security feature to me. Someone correct me if I'm wrong. > > > Obviously this would have to be global for wine (libwine.so?), not as > > a PE exported API function. Pre-loaded "antivirus" would be able to > > hook Winsock functions + some other important stuff and then check if > > the binary code is not on the list. > > Check out clamav and other *nix-native virus scanners. They're much > more suited for this task than adding a full-blown virus scanner to > Wine as standard. Who wants to maintain something like that? > > 2009/2/18 Mihai Donțu <mihai.dontu(a)gmail.com>: > > I think that soon there will no longer be a need to hack wine in order to > > prevent the spread of malware. There is already work in progress on an > > API (a derivative of dazuko) that will allow for antivirus scanners to > > intercept all filesystem accesses and scan for, well, viruses. It seems > > to me that this is the right way to go. > > Wine is not intended to prevent the spread of malware. It is assumed > that the user is careful and sensible, just like it is assumed on > Windows. While I'm with you on this one, this method is yet to be widely adopted among desktop users. > What you mention here sounds like an API to allow > Windows-based virus scanners to run, checking both loaded apps and > scanning hardisk when changes occur, but there are better solutions > for virus scanning on *nix systems. I keep mentioning clamav. I was actually referring to this[1], which started when people wanted to create malware-free file servers in an easy way (without proprietary modules, Samba VFS, proxies etc.) and as with all good designs, it covers a wide range of cases, including this one. [1] http://marc.info/?l=linux-kernel&m=123368869002717&w=2 -- Mihai Donțu

Feb. 18, 2009