Bug 42822 (CVE-2003-0192)

<!-- SBZ_reproduce  -->
-

short summary:
  Security [VU#379828]: Prevent the server from crashing when entering
    infinite loops. The new LimitInternalRecursion directive
    configures limits of subsequent internal redirects and nested
    subrequests, after which the request will be aborted.  PR 19753+


To update or not to update? (the old question)

I have built apache 2.0.47 packages and tested them on 8.1 and 8.2.
They run fine. And they pass all tests in my testsuite. 

2.0.47 contains 3 further security fixes:

  Security [CAN-2003-0192]: Fixed a bug whereby certain sequences
    of per-directory renegotiations and the SSLCipherSuite
    directive being used to upgrade from a weak ciphersuite to a
    strong one could result in the weak ciphersuite being used in
    place of the strong one.
  Security [CAN-2003-0253]: Fixed a bug in prefork MPM causing
    temporary denial of service when accept() on a rarely accessed
    port returns certain errors.
  Security [CAN-2003-0254]: Fixed a bug in ftp proxy causing denial
    of service when target host is IPv6 but proxy server can't
    create IPv6 socket.  Fixed by the reporter.

Other changes in 2.0.47 are bugfixes, with one eception:

  core:
    core_output_filter: don't split the brigade after a FLUSH
    bucket if it's the last bucket.  This prevents creating
    unneccessary empty brigades which may not be destroyed until
    the end of a keepalive connection.
  mod_cgid:
    Eliminate a double-close of a socket.  This resolves various
    operational problems in a threaded MPM, since on the second
    attempt to close the socket, the same descriptor was often
    already in use by another thread for another purpose.
  mod_negotiation:
    Introduce "prefer-language" environment variable, which allows
    to influence the negotiation process on request basis to prefer
    a certain language.
  mod_expire:
    Make ExpiresByType directive work properly, including for
    dynamically-generated documents.
  apr bugfixes

I suggest that we update 8.1 and 8.2, which currently have 2.0.46, to
2.0.47.

Ok, I think so too. 

A decision is needed. I reassign to Chris.

Reasons to do a version upgrade:

- the license does not allow to modify the sources, except "official"
  patches or configuration changes. There are no official patches for
  the 4 security problems in < 2.0.47 (and there won't be any, since
  that's what the 2.0.47 release is for). In the case of distributors
  like us adding patches, they closed both eyes so far, but we must be
  extra careful to not break stuff which the apache developers get
  accused for.

- 2.0.47 contains a few additional (non-critical) bugfixes
  http://www.apache.org/dist/httpd/Announcement2.html

- 2.0.47 is tested by the apache software foundation. 2.0.46 plus patches is not

- 2.0.47 is a pure bugfix release, and apache developers haven efficient
  peer review system and a reputation of not breaking stuff (other than
  with the kernel ;)

- users appreciate it

- only 8.1 and 8.2 is concerned. No maintained product

- less work (and less work in the future when the package needs to
  be touched again)

- subversion HEAD requires apache (apr) 2.0.47


Reasons to not do a version upgrade:

- against our policy

- requires a decision

- customers get used to it

8.1 and SLES8 share the same source code. An update would trigger a larger scale testing 
since all modules would require a re-test. Unless the diff between the released version and 
their new fixed version is just the security problem, I see little chance to do a version update. 
For 8.2 we might be able to do it, but for 8.1 Ralf has approve it first. 

How is your feeling if I ask to spool this for the next service pack (SP3 in fall)? 
We currently have ZERO test resources and just claiming the apache people 
have tested their stuff is not enough, as this says nothing about apache related 
packages (mod_php4, tomcat, etc)  
 
Several questions to Peter: 
1: Is the diff so small that we can REALLY be sure it is bugfixes only and 
their are all obviously safe? 
 
2. And how about the (version) dependencies? 
 
3. Autobuild will trigger a rebuild of mod_php4 and all that stuff, right? 
 
4. Could we JUST release apache, I mean would the new apache work 
with the old mod_php4 or would that cause dependency problems? 
 

Chris wrote:
> 8.1 and SLES8 share the same source code. An update would trigger a larger scale testing
> since all modules would require a re-test. Unless the diff between the released version and

The rebuild that would be triggered in the 8.1/SLES8 code base would not
affect SLES8 packages. (The only affected package in fact is subversion.)  

> their new fixed version is just the security problem, I see little chance to do a version update.
> For 8.2 we might be able to do it, but for 8.1 Ralf has approve it first.

We did a much bigger version update just a few weeks ago. This one is
really small compared to it. There were no problems with the last
update.

Ralf wrote:
> How is your feeling if I ask to spool this for the next service pack (SP3 in fall)?

See above, I don't see that these issues are related.

> We currently have ZERO test resources and just claiming the apache people

We can safely ignore this point since it is basically me (and our
customers) who does serious testing of apache and its modules. You can
neglect our QA department, here.

> have tested their stuff is not enough, as this says nothing about apache related
> packages (mod_php4, tomcat, etc)

I have run my tests. 

> Several questions to Peter:
> 1: Is the diff so small that we can REALLY be sure it is bugfixes only and
> their are all obviously safe?

The diff can be stripped down to 160 KB which I wouldn't exactly call
"small", but it fixes the problems that are mentioned in the ChangeLog.

> 2. And how about the (version) dependencies?

No problem, version dependencies are determined by a magic number that
is increased any time the API changes and modules would need to be
rewritten or rebuilt. My packages automatically reflect these
dependencies in RPM dependencies. (It is a mechanism that I also
retrofitted for all our 70 apache1 & module packages once, sorting out
all our previous dependency problems. Ask Roman about it.) The last time
that this dependency changed for apache2 was 20020903. The last time it
changed for apache1 was 19990320. This effectively means that you can
use your '99 module, that you built for apache-1.3.5-dev, with 1.3.28
which gets released tomorrow (provided you used the same compiler ;)

> 3. Autobuild will trigger a rebuild of mod_php4 and all that stuff, right?

Not in 8.1. I created the apache2-mod_php4 subpackage for 8.2.

In 8.2, a few packages will be rebuilt (apache2-mod_perl, mod_php4,
subversion, flood) but there is no need to care about it.

> 4. Could we JUST release apache, I mean would the new apache work
> with the old mod_php4 or would that cause dependency problems?

Yes! That's what I'm suggesting.
Yes it would work, and no, it would not cause dependency problems. 
It worked in the past, and it will work this time, too. We will spend
less time porting and testing and our customers will be more satisfied.

reassigned to Ralf

Ralf, could I answer your questions?

Since Ralf doesn't seem to be available, I reassign back to Chris.

apache2 is not part of UL nor SLES, so only cs has 
to decide. 

Ok, then go ahead with a 8.1 and 8.2 update of apache2. 

Ping?

I think we do not insist on any update any more this time for this package, since
it is a local DOS only.

Please note that it won't help in the future to simply not respond to bugs any
more. :-)

Closing.
Roman.

Please note that the first 4 weeks were consumed by the decision making
process. Doing the update itself is only a small step. But after 4 weeks
it probably isn't too urgent anymore, so needing 4 more weeks for it
is probably not critical. I would have had more time before the load
peak of the 9.0 development started. 

I have seen zero requests from customers for an "official" update.

I don't know which kind of response you were expecting. "Pong"? ;)

Now after more security relevant bugs have been fixed with 2.0.48, we
will issue updates, see Bug 47756.

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