Apache Chunking Exploit

For those of you working to patch your production Apache installations.

I have tested and verified Cris Bailiff's interim fix. (see
http://online.securityfocus.com/archive/1/278281/2002-06-21/ 2002-06-27/0).

Now I am re-building and testing my Apache/mod-ssl systems and all of my 3rd
party vendor modules. My plan is to replace the interim fix with the real
one, but I had too many combinations of Apache/mod_ssl and 3rd party modules
to do so, quickly.

For me, Cris Bailiff's patch was just in-time.

David Marshall
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Apache Chunking Exploit

On Tue, 25 Jun 2002, David Marshall wrote:

> For those of you working to patch your production Apache installations.
> I have tested and verified Cris Bailiff's interim fix. (see
> http://online.securityfocus.com/archive/1/278281/2002-06-21/ 2002-06-27/0).

That's way overkill. Please see

http://www.apache.org/dist/httpd/patches/apply_to_1.3.22/SEC URITY_chunk_size_patch.txt

for a patch that should fix all versions of Apache up to 1.3.22 (you may
or may not have to apply it to earlier versions by hand, but the logic
should suffice). For versions 1.3.23-1.3.25, the best fix is to upgrade
to 1.3.26 because the proxy was vulnerable in those versions as well as
the core.

Note: this patch is only a bandaid -- you should still upgrade ASAP.

--Cliff

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Apache Chunking Exploit

On Tue, 25 Jun 2002, Cliff Woolley wrote:

> On Tue, 25 Jun 2002, David Marshall wrote:
>
> > For those of you working to patch your production Apache installations.
> > I have tested and verified Cris Bailiff's interim fix. (see
> > http://online.securityfocus.com/archive/1/278281/2002-06-21/ 2002-06-27/0).
>
> That's way overkill. Please see
>
> http://www.apache.org/dist/httpd/patches/apply_to_1.3.22/SEC URITY_chunk_size_patch.txt
>
> for a patch that should fix all versions of Apache up to 1.3.22 (you may
> or may not have to apply it to earlier versions by hand, but the logic
> should suffice). For versions 1.3.23-1.3.25, the best fix is to upgrade
> to 1.3.26 because the proxy was vulnerable in those versions as well as
> the core.
>
> Note: this patch is only a bandaid -- you should still upgrade ASAP.


The problem has been that walking through the steps to upgrade
apache/mod-ssl in the older versions of apache has always been quite
complicated, and taken sometime to grab up apache, ssl, mm, and all that,
let alone configure it all together. We've watched in the lists over the
years how often there are cries for help, and how often those cries are
spewed from those just to lazy to read the docs, though even some that do
take time to read get confused. Thus the release of apache 2 was
welcomed, since the complications were dramatically reduced. Still , some
of us run older kernels that apache 2 fails under, and until apache 2
works under those older systems, these patches, especially the module
patch, might well be functionable and useful in those implimentations. I
don't think just blowing them off as overkill is a feasible suggestion in
these circumstances, unless there are issues with the patches put forth.

Certainly no offense is meant here, these are simply my observations and
opinions.


Thanks,

Ron DuFresne
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com

"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart

testing, only testing, and damn good at it too!



____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

Re: Apache Chunking Exploit

Ron and David have understood the real utility of mod_blowchunks:

On Tue, 25 Jun 2002, Cliff Woolley wrote:
> On Tue, 25 Jun 2002, David Marshall wrote:
> > For those of you working to patch your production Apache installations.
> > I have tested and verified Cris Bailiff's interim fix. (see
> > http://online.securityfocus.com/archive/1/278281/2002-06-21/ 2002-06-27/
> >0).
>
> That's way overkill. Please see
>
> http://www.apache.org/dist/httpd/patches/apply_to_1.3.22/SEC URITY_chunk_s
>ize_patch.txt

Cliff, If you actually read the text of

http://online.securityfocus.com/archive/1/278281/2002-06-21/ 2002-06-27/

you'll see that I agree with you - upgrade your apache as soon as you can, or
if you can at least re-compile, add the ASF patch!

In the meantime, mod_blowchunks.c/BlowChunks.pl is designed to be a simple to
install tweak to your current version, because upgrading and testing all 21+
million apache sites is a non-atomic operation.

In many large organisations, with mission-critical apps, BlowChunks.pl (or
even mod_blowchunks.c) could be in place in minutes as a minor (reversible)
config change, rather than leaving systems vulnerable during an (expedited)
2-3 week change management process (or longer!).

On Wed, 26 Jun 2002 15:14, R. DuFresne wrote:
> The problem has been that walking through the steps to upgrade
> apache/mod-ssl in the older versions of apache has always been quite
> complicated, and taken sometime to grab up apache, ssl, mm, and all that,
> let alone configure it all together.

Precisely, and that's if it's a binary you built yourself in the first place.

I've had many thank-you's from people with IBM HTTP Server, ensim, cobalt,
Windows users (who often only have binaries and no compiler), etc. who have
gained breathing room. (I've also had replies from many people using it in
addition to the upgrade, just to log potential attacks :-) )

Of course, YMMV ;-)

Cris Bailiff
c.bailiff+blowchunks@devsecure.com - http://www.awayweb.com





____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org

RE: Apache Chunking Exploit

I'd like to calrify, my point

I have binary DSO modules from 3rd party companies. I have several
non-source Binary Apache versions from Sun, IBM, Stronghold and Oracle
deployed. Mod_blowchunks has closed the door while I get updates from my
vendors and test them with all the other software that Apache integrates
with.

I might also add that I was on a tight schedule for another project. I would
not have been able to meet my schedule commitments and install/deploy/test
new Apache versions with my 3rd party DSO's.

I will be upgrading ASAP. However, I find that I cannot migrate to Apache
2.0.x yet due to 3rd party dependencies. To make a long story short. We have
to stay on Apache 1.3.x until we can migrate to BEA Weblogic 6.1 or 7.x, but
to do so requires us to migrate our portal infrastructure from Weblogic
Commerce Server 3.2 to Weblogic portal 4.0. Due to numerous API changes by
BEA, this project turned into a re-coding of our portal. This project did
not get funded this year.

I decided to notify the list, because I can't imagine that I'm the only one
with such constraints.

BlowChunks.pl took a day to implement, test and deploy onto 15 systems. I
implemented it as an include file so I can easily remove it. Now my company
is not exposed to what Chunking attacks are looming and I can complete the
current project and then begin the multiple week install/test/deploy cycle
of the updated Apache(s) without being vunerable.

So thanks again Cris!
David
____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org