Bug 50450 (CVE-2004-0113)

<!-- SBZ_reproduce  -->
-

Date: Mon, 8 Mar 2004 11:51:01 +0000 (GMT) 
From: Mark J Cox <mjc@redhat.com> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] Some Apache issues 
 
Joe Orton committed the fixes for a couple of known Apache httpd issues 
today.  Vendors might have missed these: 
 
*** CAN-2004-0113: Apache 2/mod_ssl memory leak 
 
A memory leak in mod_ssl in Apache 2 before 2.0.49 allows a remote denial 
of service attack against an SSL-enabled server by sending plain HTTP 
requests to the SSL port. 
 
public: 20040220 
http://marc.theaimsgroup.com/?l=apache-cvs&m=107869699329638 
http://www.apacheweek.com/features/security-20 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27106 
 
*** CAN-2003-0993: Allow/Deny parsing on big-endian 64-bit platforms 
 
A bug in the parsing of Allow/Deny rules using IP addresses without a 
netmask on big-endian 64-bit platforms in Apache 1.3 before 1.3.30 causes 
the rules to fail to match. 
 
public: 20031015 
http://marc.theaimsgroup.com/?l=apache-cvs&m=107869603013722 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23850 
http://www.apacheweek.com/features/security-13 
 
Thanks, Mark 
-- 
Mark J Cox / Red Hat Security Response Team 
 

I'm adding 
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_io.c?r1=1.100.2.11&r2=1.100.2.12
to the apache2 packages.

Andreas, I want to take the opportunity and make another fix available
together with the security update. Apache2 on 9.0 had an internal
default character set of UTF-9, which was the result of a
misunderstanding, see Bug 37427. Can I add it? There is no risk
associated with this change. I'm assigning to you for decision. Please
assign back to me.

go ahead

I have submitted fixed apache2 packages meanwhile.

Sec-Team:
How do we go about the apache1 problem that affects only big-endian 64
bit platforms? Only s390x should be affected, because our PPC products
are sporting 32 bit userland (with few exceptions, but apache is not
among them).

Should we fix it in the general sles7 and sles8 codebase, but ship
updates only to s390x? I don't know if this implies more overhead -- or
less.

s390x has packages here:

sles7-s390x     /work/SRC/old-versions/7.2/arch/sles-s390x/        apache 1.3.19
sles8-s390x     /work/SRC/old-versions/8.1/UL/all/                 apache 1.3.26

And, should we wait for an upcoming fix for mod_digest? (I don't think
so.)

Also, if we want to be super-careful about not breaking something in
sles8 later, we could apply the patch only on s390x. What do you think?

Applying it to s390x only seems more cleaner. 
I think it is no problem even if it shares the same code base as other SLES8 
products. The patch can be made arch-dependent and only s390x can be mentioned 
in the patchinfo... that is the way I would go. :) 
 
I'll attach the patchinfo files ASAP and send around the Laufzettel.... 

Hm, what's about AMD64? 

It's little endian ;)

Created attachment 16519 [details]
patchinfo-box.apache2

Created attachment 16520 [details]
patchinfo.apache1

Please verify the distribution line.

I have just submitted the fixed SLES7-s390x package, which was the last
one missing.

Distribution line looks correct to me. Are you going to submit the
patchinfo files?

A fixed apache package for STABLE is submitted as well now.
apache2 is at 2.0.49-rc2 in STABLE so it is fixed, too.

Can you submit the patchinfos please and after that reassign this bug to me. 
Thanks! 

Patchinfos submitted.

Peter, 
does this fixe the following 2 vulnerabilities too? 
 
SECURITY: 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. 
With Apache 2.x there is no performance concern about enabling the logic for 
platforms which don't need it, so it is enabled everywhere except for Win32. 
[Jeff Trawick] 
 
  
SECURITY: CAN-2003-0020 (cve.mitre.org) Escape arbitrary data before writing 
into the errorlog. Unescaped errorlogs are still possible using the compile 
time switch "-DAP_UNSAFE_ERROR_LOG_UNESCAPED". [Geoffrey Young, André Malo] 

No, both fixes are not yet included in the above packages. 

The first one of these two bugs is also tracked in Bug 51669.

So to summarize it up, the fixes that are still missing in our released
apache2 packages are:

1) Bug 51669 (starvation issue)
2) the abovementioned error_log escaping
3) Bug 51668 (mod_disk_cache issue)

Furthermore, version 1.3 of apache does also not escape stuff which is
written into error_log. (Just noticed the fix in httpd-1.3 cvs.)
Question to security team, do you want updates for that? I suppose no,
since it's not a vulnaribility in apache itself; I suggest we add it
together with the next security fix that pops up. We should add it to
STABLE though.

Created attachment 17068 [details]
proposed patch for 2.0.48 to fix unescaped errorlog problem (backport from 2.0.49)

I'm going to submit packages with fixes for 1) and 2) (refering to
comment #19)

Created attachment 17486 [details]
new patchinfo file for apache2

typo in DESCRIPTION_DE: 
 
auf selten wenig Ports 
 
should read 
 
auf selten benutzte Ports 

Created attachment 17488 [details]
patchinfo for apache1, typo corrected and CVE number added

Both patchinfos have been submitted. Thomas, I assign to you for further
processing.

To comment #24: Thanks, I have corrected it.

*** Bug 51669 has been marked as a duplicate of this bug. ***

almost a month now... how long does it take to get a simple 
patch update out? 
 
 

Dirk, 
how many years does people need to learn to be more gentle and to reallize 
that there are more things out there then just their own concerns. 

apache2 for BOX approved 

apache1 in QA-queue... 

*** This bug has been marked as a duplicate of 55611 ***

CVE-2004-0113: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)