Platform: Win98SE/P3733/640M RAM Steps to reproduce: 1) Install 2.0.44 on a Win98SE box 2) Do: Start -> Programs -> Apache HTTP 2.0.44 Server -> Control Apache Server -> Start Apache in Console results: A Modal dialog box is displayed. Details to follow. background: This machine has been running 2.x happily since 2.0.39 I saw the email tonight about the vuln, so I used win98 add/remove programs and uninstalled 2.0.43 and installed 2.0.44. Crashed on first try. I figured, "OK, I'll move httpd.conf outta the way and try installing again". Same thing. I uninstalled 2.0.44 again, deleted the entired apache directory and tried reinstalling. Installation went great, but upon console lauch it crashed with the following error (and yes, I know I should use a *real* OS, but someone has to test this stuff on Win32 :): APACHE caused an invalid page fault in module LIBHTTPD.DLL at 0167:6ff18a08. Registers: EAX=0000a264 CS=0167 EIP=6ff18a08 EFLGS=00010206 EBX=00000004 SS=016f ESP=0057dc24 EBP=005c62bc ECX=6eed5758 DS=016f ESI=0000000a FS=4db7 EDX=0057dc2c ES=016f EDI=00000004 GS=4ed6 Bytes at CS:EIP: 8a 14 81 8d 04 81 8b 4c 24 38 88 11 8a 50 01 41 Stack dump: 00000004 005e2f54 000a6040 0000dba4 00006ff0 000029b9 00000059 00000059 00007b14 0000a264 000163de fffd98ec de36058e 6ff0d84f 0057dc79 4fab6000 Back to 2.0.43 for me, until this works.....
Notes: I installed this from : apache_2.0.44-win32-x86-no_ssl.exe The Win98SE box I am using is pretty "clean", meaning there isn't a lot of extra cruft running on it.
Just re-installed 2.0.43 from local binary and it runs just peachy. JADP.
The address you identified in the log, 6ff18a08, should be the ap_recent_ctime function (in util_time.c). I'll dig into this in the morning. Thanks for the detailed report!
Ok, I see the foobar. Folks are playing games in that fn with data in another module. Apparently libapr was relocated, and data doesn't always survive being relocated. Apparently the address referencing/dereferencing might be causing us problems. Either that, or more likely, tm_wday/tm_mon were not populated correctly, and they are pointing at random memory. Even worse, the exploded_cache_gmt and exploded_cache_localtime seem to never be zeroed out, and perhaps the author has assumed the statics will be zeroed out when the library is loaded. Although I haven't seen this on any NT box (perhaps because NT does so), this behavior may be different on Win9x. If you can get Dr Watson to dump out some more information, that would be very helpful.
No sweat. Happy to serve. If I could code, I'd be dangerous. As it is, I'm just good at breaking things. :)
No Doc Watson on Win98 I know of.... hmmm. Off to google.
Nailed down the bug. FileTimeToLocalFileTime doesn't pay attention to daylight savings time, which was badness. The fix was using SystemTimeToTzSpecificLocalTime() which is only supported under NT (not 9x.) I will be applying conditional logic to use the old code, and post up a patch for Win9x/ME users to replace their libapr.dll. The files in support() might need to be updated; I will take a look to see which (if any) are affected.
Thanks Will. I'll be your guinea pig, if you need it. -jim
Will, Should the release notes for 2.0.44 be updated on the web site to reflect this problem? Or perhaps, even pull .44 off until it's fixed? I know it is a harsh step, but the advisory is specific to Win 9x and ME, and it at least fails to run on Win98. -jim
*** Bug 16281 has been marked as a duplicate of this bug. ***
You can access Dr.Watson through System Information on Windows 98
So what's the scoop Will? We've got a broken build, available for download from everywhere. Is the APR vote holding stuff up? Just curious.... -jim
Created attachment 4508 [details] Replacement libapr.dll, apr/time/win32/time.c reverted to rev 1.40 for 9x/ME only
If some of you poor souls who were clobbered by my patch 10 days ago would grab the attached .zip file and unpack it into your installed Apache 2.0.44 bin directory, replacing the existing libapr.dll, please update this bug with your success or failure at using the server after that update. If this is a confirmed fix, I'll send the file to /dist/httpd/binaries/win32/ for everyone's benefit.
OK. I think you did indeed nail it. I removed 2.0.43 through add/remove, deleted the directory, rebooted and reinstalled 2.0.44 and it ran from console. I *did* however use my httpd.conf file from 2.0.43 simply because it is fairly well hacked. I note that the new file is 35K, as opposed to my 33K file (which worries me a bit), so I guess there is a whole bunch of new stuff, and I'll probably pay for this later. Thanks for the work Will. Marking as verified. (so.... how are you going to get this fix out to the "masses" ?)
First off, the patch file (with .asc sig and .md5 stamp) is up on www.apache.org and now propogating to the mirrors. Second, thanks for testing, Jim. Suggestion to you... you can always go to http://cvs.apache.org/viewcvs/httpd-2.0/docs/conf/httpd-win.conf and compare any two arbitrary versions (find the older version, click 'select for diffs', go to your official release and click 'compare to selected'.) This will give you a hint of what's been introduced to the stock config. Your install also includes httpd.default.conf, feel free to set aside the old one and compare it with the newly installed httpd.default.conf. I'll work with the team to determine how to announce, in the meantime feel free to point people to the URL above. Thanks again for the quick report - made it easier to fix it quickly. The fix will be included in 2.0.45 which won't be far on the heels of 2.0.44.
Again, happy to help. I broke some stuff in 2.0.39 whem I was working at Qualys. I'll keep breaking stuff, have no fear. Besides, it's kinda challenging to make a really good web server run on a really crappy OS. :) cheers, -jim
The patch will take some time to propogate throughout the proxies. Announce to follow in the morning (once folks are able to find the patch.) Feel free to spread the word, and cite this bug entry or this URL.
*** Bug 16909 has been marked as a duplicate of this bug. ***
*** Bug 17133 has been marked as a duplicate of this bug. ***
*** Bug 17333 has been marked as a duplicate of this bug. ***
*** Bug 17988 has been marked as a duplicate of this bug. ***