September 2002 - Wine-Devel

Re: Heap overruns

by Shachar Shemesh

Huw D M Davies wrote: >On Sun, Sep 01, 2002 at 11:33:55PM +0300, Shachar Shemesh wrote: > > >>Marcus Meissner wrote: >> >> >> >>>On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote: >>> >>> >>> >>> >>>>Hi list, >>>> >>>>I am currently having some problems with a change I am working on, that >>>>result in heap corruption as a result of buffer overrun. I was wondering >>>>whether there was any builtin debug options to detect and help fix these >>>>things. >>>> >>>>If there aren't, I am perfectly willing to sidetrack a little and write >>>>them. Please let me know. >>>> >>>> >>>> >>>> >>>If you run with -debugmsg +heap it will check the heaps at every access >>>for corruption. >>> >>>Ciao, Marcus >>> >>> >>> >>> >>Thanks, but this is not what I meant. >> >>Currently, when a buffer overruns, the free pointers right after get >>corrupted, and when the next piece of block is allocated, the machine >>will crash. This will tell me approximetly where the buffer overrun, but >>is, generally speaking, too late. Enabling the debug messages detects >>the error at the same place (i.e. - too late). >> >>What I am talking about is a compile time (or run time, no reason why >>not) option that will add "hot zone" areas before and after each heap >>allocated buffer. These zones should be: >>A. Large enough so that the overrun doesn't reach the heap managment >>structures themselves. This means that the program can keep on running >>despite having the buffer overflow. >>B. Identifiable, so that we know if a buffer has overwritten it. >> >> > >No, as Marcus says, enabling +heap debugging forces the entire heap to >be checked for consistency on every HeapAlloc/Free/ReAlloc . So if >you overwrite a block you'll get an error the next time you call a >heap function (on the same heap) and not only when the system tries >the alloc the next block. So, if you see heap corruption this way, >you can assume that it occured somewhere between this point and the >last time you called a heap function. > >Huw. > > I'm sorry, but my experience is totally different. First, I would like to say that I have found the offending allocation. The problem was with not allocating enough memory (enough for the single width string, not the double width string). Classical mistake. The traces proved useless for several reasons: A. The first place the assertation failed is the same place that wine, without the debug option, would crash. This place is far away from the actual allocation OR freeing of the offending buffer. Having the error point at the actual offending buffer will make life much easier for the debugger (IMHO). B. The current mechanism obviously doesn't work well. By the time the crash/assertion happen, both magic and the value before that seem to be valid for the offending pointer block, but both previous and next pointers were values taken from the middle of my buffer (I could recognize the string). This suggests to me that several alloc/free operations happened before the problem was spotted, migrating the overwritten values to other nodes. The mechanism did not catch that. C. The code I am working with is code I previously removed from Wine, and am now trying to restore. In addition to the serious overrun, it also has an "off by one", where a single NULL is written past the end of the buffer. Running the code with debug +heap does not reveal that. Implementing my suggested system will: A. not hurt the programs operation (despite the overrun), and so the relevant buffer can be found as soon as it is "HeapFree"ed. This means pointing at the actual buffer. B. Even if this is a buffer overrun coupled with a memory leak (HeapFree is NEVER called), we can verify all the hot zones signatures on each heap operation (the same way we do today for the linked list), and give the actual pointer to the offending buffer (which now merely becomes a game of catching who allocated that, almost trivial with +relay) I'm afraid I won't do it now, as I have found my curlpit, and have bigger itches to scratch. I am suspectful of off by ones creeping up. Shachar P.S. Being a security expert as my alter ego, I couldn't help but notice the places where we are vulnerable to integer overflow attacks. For the uninitiated, these are attacks where the attacker minpulates the sizes so that a very big number to be allocated, after being multiplied by the element size, overflows to be a very small number. The attacker can then overrun this small buffer, point the execution path into attacker supplied buffer, and gain control of a program. In order to solve this we need to supply a function to perform the multiplication for us (HeapAllocElement(Heap, flags, num, element_size) sort of thing), which will check against this condition and then call HeapAlloc. Are there any objections? I know Wine is just Alpha, and noone is supposed to trust it, yadda yadda yadda, but I'm thinking "better early than late". Sh.

Sept. 1, 2002

Re: Heap overruns

by Huw D M Davies

On Sun, Sep 01, 2002 at 11:33:55PM +0300, Shachar Shemesh wrote: > Marcus Meissner wrote: > > >On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote: > > > > > >>Hi list, > >> > >>I am currently having some problems with a change I am working on, that > >>result in heap corruption as a result of buffer overrun. I was wondering > >>whether there was any builtin debug options to detect and help fix these > >>things. > >> > >>If there aren't, I am perfectly willing to sidetrack a little and write > >>them. Please let me know. > >> > >> > > > >If you run with -debugmsg +heap it will check the heaps at every access > >for corruption. > > > >Ciao, Marcus > > > > > Thanks, but this is not what I meant. > > Currently, when a buffer overruns, the free pointers right after get > corrupted, and when the next piece of block is allocated, the machine > will crash. This will tell me approximetly where the buffer overrun, but > is, generally speaking, too late. Enabling the debug messages detects > the error at the same place (i.e. - too late). > > What I am talking about is a compile time (or run time, no reason why > not) option that will add "hot zone" areas before and after each heap > allocated buffer. These zones should be: > A. Large enough so that the overrun doesn't reach the heap managment > structures themselves. This means that the program can keep on running > despite having the buffer overflow. > B. Identifiable, so that we know if a buffer has overwritten it. No, as Marcus says, enabling +heap debugging forces the entire heap to be checked for consistency on every HeapAlloc/Free/ReAlloc . So if you overwrite a block you'll get an error the next time you call a heap function (on the same heap) and not only when the system tries the alloc the next block. So, if you see heap corruption this way, you can assume that it occured somewhere between this point and the last time you called a heap function. Huw.

Sept. 1, 2002

Re: Heap overruns

by Shachar Shemesh

Marcus Meissner wrote: >On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote: > > >>Hi list, >> >>I am currently having some problems with a change I am working on, that >>result in heap corruption as a result of buffer overrun. I was wondering >>whether there was any builtin debug options to detect and help fix these >>things. >> >>If there aren't, I am perfectly willing to sidetrack a little and write >>them. Please let me know. >> >> > >If you run with -debugmsg +heap it will check the heaps at every access >for corruption. > >Ciao, Marcus > > Thanks, but this is not what I meant. Currently, when a buffer overruns, the free pointers right after get corrupted, and when the next piece of block is allocated, the machine will crash. This will tell me approximetly where the buffer overrun, but is, generally speaking, too late. Enabling the debug messages detects the error at the same place (i.e. - too late). What I am talking about is a compile time (or run time, no reason why not) option that will add "hot zone" areas before and after each heap allocated buffer. These zones should be: A. Large enough so that the overrun doesn't reach the heap managment structures themselves. This means that the program can keep on running despite having the buffer overflow. B. Identifiable, so that we know if a buffer has overwritten it. Whenever you free a buffer, you check the hot zones. If they have changed, the buffer you are freeing now has been overwritten. This gives an excellent debugging tool, as it points right at the offending code. I am going to try and find my overrun buffer the conventional way. If that doesn't work, I'll implement the system described above. Who knows how many overflows are out there that do not crash the system, and go about undetected? Shachar

Sept. 1, 2002

Re: ALSA 0.9 sound problems

by Eric Pouech

> maybe compare how snd-pcm-oss streams the sound to alsa, with how > winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does > a better job of it =) beware that the APIs (OSS and ALSA) are rather different moreover, ALSA 0.9 driver has a still to be improved dsound interface (which may be the cause of your issues here) A+

Sept. 1, 2002

Re: ALSA 0.9 sound problems

by TJ

I never looked into programming ALSA or WINE I know C, but not much beoynd some GTK can console stuff. (ie will need to learn the APIs involved in this) But I do have a SBLive with fully working MIDI (via ALSA) and i'd love to help testing/feedback (and get FFVII to work which demands MIDI) >not so many people work on Alsa 0.9 these days, so if you want to give >it a shot, be welcome well 0.5 is deprecated and unsuported, afaik all major distros have now switched to 0.9, also ALSA has gone into the Linux kernel. It is more complete then OSS, ie more drivers, midi support etc. (with OSS you need buy the whole opensound system from 4front and I not a fan of semi-free stuff like OSS/free) call on me for help, but I feel if I were try solve it my self I would be playing catch-up with those who understand it better then I. Saying that I will go look at some docs and the source to see what I can see. maybe compare how snd-pcm-oss streams the sound to alsa, with how winealsa.drv streams the sound to alsa. since it seems snd-pcm-oss does a better job of it =) -TJ

Sept. 1, 2002

internet explorer installation

by Franky Van Liedekerke

Hi all, I have a program here that wants to install MDAC 2.6 SP1 first. Now this needs IE 4.0 SP1 or higher installed, so I try to install IE6. Now, when doing that, I get the following error: err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception This is using the latest cvs from wine. Does anybody know how to fix this, or simulate the registry entries so the MDAC install thinks IE is installed? I have to say that *somehow* I managed to get around that error once, but I can't remember what I did (no config changes to wine though, must be something I installed with wine) :( Franky

Sept. 1, 2002

Re: winedbg

by Eric Pouech

admiral coeyman a écrit : > > Eric Pouech, > > > > what do you mean here ? you can (as of today) choose any fixed font > > (that fits in the screen) for displaying in the wineconsole. Those > > settings are saved in the registry. > > I agree that the current way of choosing a default font is not optimal, > > but you can always pick up another one if you don't like it > > > The last time I tried using winedbg, the entire text was in a small square at > the top of my screen. It looked like about 1/10 of the screen. Other people > mentioned this so I was asking if there was somebody else working on that. > This is not my strong suit, if I even have one, and I was hoping that somebody > more qualified than I am was going to work on this. as of today, right click in the console window, and choose the default item in the popup menu that comes up a dialog box will appear. Choose the Fonts sheet and pick up any font (& size) you want. this will become the default for any subsequent console sessions A+

Sept. 1, 2002

current wine status pr-1

by tom

Hello, I would like to thank everyone who has re-plied so far about the current wine status. I have a pre-1 hacked together and request any feed back that you can give. My main goal is the info I put up be as accurate as possiable . And since i'm not a Developer I have to bug/spam you guy's for the info :) So please bear with me .......... Known ToDo's will be next on my list after ** WE ** get this up to date.. Tom Wine status changes from 9-29-01 untill 9-01-02 pre-1 reply to : twickline2(a)triad.rr.com ( Aspect or Component ) Wine's fundamental architecture Documentation = workers = Alexandre Julliard % = 85% Process/Address Space model Documentation = workers = Alexandre Julliard % = 100% Threading model Documentation = workers = Alexandre Julliard % = 100% Scheduling and synchronization Documentation = workers = Alexandre Julliard % = 100% Supervisory process (wineserver) Documentation = workers = Alexandre Julliard % = 90% Windows binary loader Documentation = workers = Alexandre Julliard % = 100% Memory management Documentation = workers = Alexandre Julliard % = 90% Wine DLL infrastructure Documentation = workers = Alexandre Julliard % = 95% Need to ADD --- DLL separation Documentation = workers = AJ % = 75% Message passing/queues Documentation = workers = Alexandre Julliard % = 95% Window management Documentation = workers = ? % = 95% Disk drive emulation Documentation = workers = ? % = 100% CD-ROM emulation Documentation = workers = Eric Pouech eric.pouech(a)wanadoo.fr % 90% Native DLL overrides Documentation = workers = ? % = 95% X11 display/window driver Documentation = workers = ? % = 90% X11 font mapper Documentation = workers = ? % = 70% Registry handling Documentation = workers = ? % = 90% Clipboard handling Documentation = workers = ? % = 90% File I/O Documentation = workers = Mike McCormack % = 100% TrueType support Documentation = workers = Huw D M Davies % = 80% National Language Support (NLS) Documentation = Dmitry Timoshkov, Alexandre Julliard workers = % = 90% Unicode support Documentation = workers = Dmitry Timoshkov, Alexandre Julliard % = 80% Dynamic Data Exchange (DDE) Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 80% Standard Windows Controls Documentation = workers = ? % = 95% Serial/parallel ports 16-bit 95% 32-bit 90% Documentation = workers = Mike McCormack I/O port access Documentation = workers = ? % = 100% VxDs Documentation = workers = ? % = 5% General printer setup Documentation = workers = Huw D M Davies % = 70% Internal PostScript printer driver Documentation = workers = Huw D M Davies, Ian Pilcher % = 60% Native Windows printer drivers 16-bit 50% 32-bit 0% Documentation = workers = ? Win32 Console Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 75% DOS application support Documentation = workers = Ove Kåven, Alexandre Julliard % = 60% CPU emulation Documentation = workers = ? % = 5% Multi-user support Documentation = workers = ? % = 20% ( DLLs ) crtdll&msvcrt: Standard C runtime library Documentation = workers = CodeWeavers % = 60% comctl32: Common Controls Documentation = workers = CodeWeavers % = 95% Note-- Is Macadamian still working on Wine ??? comdlg32: Common Dialogs Documentation = workers = ? % = 75% riched32: Rich Text Control Documentation = workers = ? % = 20% shell32: Shell interface Documentation = workers = CodeWeavers % = 80% tapi32: Telephony API (TAPI) Documentation = workers = ? % = 0% rasapi32: Dial-Up Networking (DUN) and Remote Access Service (RAS) Documentation = workers = ? % = 0% wsock32: Windows Sockets (WinSock) 1.1 Documentation = workers = Macadamian ???????? % = 90% ws2_32: WinSock 2 Documentation = workers = Macadamian ???????? % = 20% wininet: Internet application protocols Documentation = workers = CodeWeavers % = 50% winmm: Multimedia architecture Documentation = workers = Eric Pouech eric.pouech(a)wanadoo.fr % = 80% ( Eric has this changed ??? ) Multimedia wave audio Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 100% for OSS Multimedia MIDI audio Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 100% for OSS **Preliminary ALSA support 10% Multimedia joystick driver Documentation = workers = Eric Pouech eric.pouech(a)wanadoo.fr % = 80% ( Eric has this changed ??? ) Multimedia CD audio Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 100% MCI (Media Control Interface) drivers Documentation = workers = Eric Pouech eric.pouech(a)wanadoo.fr % = 60% ( Eric has this changed ??? ) msacm32: Audio Compression Manager (ACM) Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 60% msvfw32: Video for Windows (VFW) Documentation = workers =Eric Pouech eric.pouech(a)wanadoo.fr % = 30% ddraw: DirectDraw Documentation = workers = TransGaming % = 85% Direct3D Documentation = workers = TransGaming % = 30% dinput: DirectInput Documentation = workers = TransGaming % = 40% dplayx: DirectPlay Documentation = workers = Peter Hunnisett % = 25% dsound: DirectSound Documentation = workers = TransGaming % = 80% quartz: DirectShow core Documentation = workers = In TransGaming cvs ?? % = 0% wing: WinG 16-bit game library Documentation = workers = ? % = 50% rpcrt4: RPC/DCOM subsystem Documentation = workers = ? % = 0% ole32: OLE/COM core Documentation = workers = CodeWeavers % = 60% oleaut32: OLE Automation core Documentation = workers = CodeWeavers % = 60% olecli32: OLE client library Documentation = workers = ? % = 5% olesvr32: OLE server library Documentation = workers = ? % = 5% oledlg: OLE user interface Documentation = workers = ? % = 5% opengl32: OpenGL interface Documentation = workers = Lionel Ulmer, TransGaming % = 90% odbc32: ODBC Database Manager Documentation = workers = Corel % = 100% wnaspi32: Advanced SCSI Peripheral Interface Documentation = workers = ? % = 85% ( Tools ) Wine Resource Compiler Documentation = workers = Bertho Stultiens ??? % = 95% Wine Message Compiler Documentation = workers = Bertho Stultiens ??? % = 75% Wine Debugger Documentation = workers = Eric Pouech eric.pouech(a)wanadoo.fr % = 85% Wine Porting Tool (winemaker) Documentation = workers = CodeWeavers % = 70% Wine Installer (wineinstall) Documentation = workers = Andreas Mohr % = 90% Wine Installation Checker (winecheck) Documentation = workers = Andreas Mohr % = 30% Wine Setup Tool (winesetuptk) Documentation = workers = CodeWeavers % = 50% Wine Launcher Documentation = workers = CodeWeavers % = 60% Wine Regression Test Suite Documentation = workers = CodeWeavers % = 10% ( No-Windows installation issues ) Initial registry contents Documentation = workers = ? % = 25% Initial directory structure Documentation = workers = ? % = 90% Initial INI files Documentation = workers = ? % = 40% DLL placeholder files Documentation = workers = CodeWeavers % = 100% ( Instructions ) How to install Wine Documentation = workers = Andreas Mohr % = 90% How to debug Documentation = workers = Andreas Mohr % = 80% How to create a useful bug report Documentation = workers = Andreas Mohr % = 80% How to become a Wine developer Documentation = workers = Andreas Mohr % = 80% How to use Winelib Documentation = workers = Andreas Mohr % = 90% How to compile MFC with Winelib Documentation = workers = Andreas Mohr % = 80% ( Miscellaneous ) Wine 1.0 Release Plan Both link's are dead !! I did find this link: http://www.winehq.com/news/?view=118#Road%20to%200.9 Ove- do you plan to do a updated Road to 1.0 ? The History of the Wine Project MS has got nervous and released junk API's What a MS breakup might mean to Wine ? Remove as there not going to get BROKE -UP!!!! ): ??? WineHQ and Corel relationship CodeWeavers is the host of WineHQ now ? ----------------- Need to ADD BiDi Documentation = workers = Shachar Shemesh contact = wine-devel(a)sun.consumer.org.il % = 5% individual control status Documentation = workers = Dimitrie O.Paun contact = dimi(a)bigfoot.com % = ?%

Sept. 1, 2002

Re: Heap overruns

by Marcus Meissner

On Sun, Sep 01, 2002 at 12:17:38PM +0300, Shachar Shemesh wrote: > Hi list, > > I am currently having some problems with a change I am working on, that > result in heap corruption as a result of buffer overrun. I was wondering > whether there was any builtin debug options to detect and help fix these > things. > > If there aren't, I am perfectly willing to sidetrack a little and write > them. Please let me know. If you run with -debugmsg +heap it will check the heaps at every access for corruption. Ciao, Marcus

Sept. 1, 2002

Heap overruns

by Shachar Shemesh

Hi list, I am currently having some problems with a change I am working on, that result in heap corruption as a result of buffer overrun. I was wondering whether there was any builtin debug options to detect and help fix these things. If there aren't, I am perfectly willing to sidetrack a little and write them. Please let me know. Shachar

Sept. 1, 2002