Bugzilla – Bug 55611
VUL-0: CVE-2004-0174: apache-1.3 security issues (fixes from 1.3.31)
Last modified: 2021-10-11 13:57:46 UTC
apache 1.3.31 brings three new security fixes that we don't have yet: 1) CAN-2003-0987 (cve.mitre.org) In mod_digest, verify whether the nonce returned in the client response is one we issued ourselves. This problem does not affect mod_auth_digest. 2) CAN-2003-0020 (cve.mitre.org) Escape arbitrary data before writing into the errorlog. 3) CAN-2004-0174 (cve.mitre.org) Fix starvation issue on listening sockets where a short-lived connection on a rarely-accessed listening socket will cause a child to hold the accept mutex and block out new connections until another connection arrives on that rarely-accessed listening socket. 4) CAN-2003-0993 (cve.mitre.org) Fix parsing of Allow/Deny rules using IP addresses without a netmask; issue is only known to affect big-endian 64-bit platforms The latter, 4), we have already fixed recently. The others I am going to backport.
<!-- SBZ_reproduce --> http://www.apache.org/dist/httpd/Announcement.html
Do you have an estimate on this? And, more important: Will it be fixed in SLES9?
IMO, backporting the fix for CAN-2003-0020 to apache < 1.3.25 is not worth the time, because - the escaping of the error-log which was added with 1.3.31 is based on escaping functions used with the access-log which were added with 1.3.25, and it wouldn't work without the latter being backported too - we didn't to backport the access log escaping since two years - it is not fixing a security vulnerability in apache itself. It is only guarding against possible vulnerabilities in terminal emulators that are used when viewing apache error logs - only SLES7 has a version < 1.3.25 and would need this extra work. I'm not sure how much longer they are going to be maintained? Security team, what do you think?
[okay, here's my comment again. mid-air collision seems to break the HTML form...] IMO, backporting the fix for CAN-2003-0020 to apache < 1.3.25 is not worth the time, because - the escaping of the error-log which was added with 1.3.31 is based on escaping functions used with the access-log which were added with 1.3.25, and it wouldn't work without the latter being backported too - we didn't to backport the access log escaping since two years - it is not fixing a security vulnerability in apache itself. It is only guarding against possible vulnerabilities in terminal emulators that are used when viewing apache error logs - only SLES7 has a version < 1.3.25 and would need this extra work. I'm not sure how much longer they are going to be maintained? Security team, what do you think?
ad comment #2: I have already submitted a fixed package for SLES9 earlier, and I'll finish the rest today.
Hhm, the changes that came with 1.3.25 do not just escape stuff before it is written to the log files, but actually hook in earlier: they add checks to the request line syntax. ...This is what I find when digging in the CVS about the required change: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/include/httpd.h?r1=1.360&r2=1.361 http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/gen_test_char.c?r1=1.7&r2=1.8 http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_protocol.c?r1=1.314&r2=1.315 http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/util.c?r1=1.203&r2=1.205 http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/modules/standard/mod_log_config.c?r1=1.87&r2=1.88 I'll have a further look.
With those, a backport seems feasible.
Okay, apart from backporting the mod_digest fix for 1.3.19 (sles7) I'm done. I'm working on that.
I now submitted the following fixed packages: .../7.2/all/apache -> /work/src/done/SLES7 .../7.2/arch/sles-i386/apache -> /work/src/done/SLES7/sles-i386 .../7.2/arch/sles-s390x/apache -> /work/src/done/SLES7-S390X .../7.3/all/apache -> /work/src/done/SLES7-PPC .../8.0/all/apache -> /work/src/done/8.0 .../8.1/UL/all/apache -> /work/src/done/8.1 .../8.2/all/apache -> /work/src/done/8.2 .../9.0/all/apache -> /work/src/done/9.0
Thank you! I'll reassign it to us... (or is something missing?)
If you want to go ahead with the patchinfos: you're welcome :) Two things to remember: - Bug 54600, where previous updates are missing for SLES8. The patchinfo files should probably mention what was fixed in the past - patchinfo for the box needs to include 9.1. A fixed 9.1 package was also submitted, as mentioned above. It's also still waiting to be checked in under /work/src/done. That's it I think.
*** Bug 50450 has been marked as a duplicate of this bug. ***
Peter, this update replaces bug 50450, right? Old package gots rejected: Date: Fri, 14 May 2004 15:10:52 +0200 (CEST) From: patch_system@suse.de Reply-To: patch-management@suse.de To: patch-management@suse.de, poeml@suse.de Subject: [pm] [patchinfo] ID 61cfb952b4858a2d106efe4c17a6fb3a has been rejected I'll make a dup resolv on the old one.
Exactly, that's the one that was supposed to fix CAN-2003-0993 and was rejected since it's obsoleted now.
Peter, you said a backport of the access-log code was doable, so was it submitted too? I'll attach the patchinfo files ASAP. Peter, do you have a list of old bugs that I can add to the sles8 patchinfo?
This one is already fixed: 3) CAN-2004-0174 (cve.mitre.org) Fix starvation issue on listening sockets where a short-lived connection on a rarely-accessed listening socket will cause a child to hold the accept mutex and block out new connections until another connection arrives on that rarely-accessed listening socket.
ad comment #15: yes, I backported that, it is added as an additional patch to apache 1.3.19-1.3.24 (which corresponds to the SLES7 and 8.0 packages). Thus, all four issues are fixed. +- for the CAN-2003-0020 fix, add apache-1.3.24-escape_requests.dif (backport + from 1.3.25): stricter check to the request line syntax ad comment #16: the starvation issue had been fixed for apache2 only, so far.
about the missing fix in SLES8, see Bug 54600, I just updated it. Hm, I didn't check the maintenance web for completeness of SLES7 updates yet.
Created attachment 19816 [details] patchinfo.apache.sles8.s390x
Created attachment 19817 [details] patchinfo.apache.sles8.s390x
Created attachment 19818 [details] patchinfo.apache.sles7
Created attachment 19819 [details] patchinfo.apache.sles7.s390x
Comment on attachment 11816 [details] Patch to change ext2/3 deafults will be replaced
Comment on attachment 11817 [details] crashing diagram will be replaced
Comment on attachment 11819 [details] new patch using right diff will be replaced
Created attachment 19822 [details] patchinfo.apache.sles8
Created attachment 19823 [details] patchinfo.apache.sles7.s390x (new)
Created attachment 19824 [details] patchinfo.apache.sles8.s390x (new)
Created attachment 19825 [details] patchinfo-box.apache.8.0
Created attachment 19826 [details] patchinfo-box.apache
Ok, this update is a little patchinfo nightmare. :) Please check each file before submitting it.
Checking... slight misunderstanding: CAN-2003-0020 (the escaping business) is fixed in _all_ packages, not only 8.0 and older. The latter just needed another fix to make it possible (no CVE number was ever assigned to that one afaik) I'll fix the patchinfos...
Created attachment 19841 [details] new patchinfo for all box products
The SLES7 maintenance web seems to miss the same update as SLES8 (Bug 54600). I think I can make one patchinfo for them all...
Created attachment 19844 [details] new patchinfo for all maintained products
Should have done 'mv patchinfo.apache.sles8 patchinfo.apache' before attaching the last file... I have now submitted those two patchinfo files.
removed them again, since another patch was added, see Bug 55603
Correction: bug 55791 is the one that I intended to refer to in my last comment
Created attachment 19905 [details] new patchinfo with mod_ssl fix added (box)
Created attachment 19906 [details] new patchinfo with mod_ssl fix added
submitted to /work/src/done/PATCHINFO I re-assign to security-team for further processing then.
Thanks!
Approved packages. have been annoucned in section 2 of last advisory.
CVE-2004-0174: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)