Re: CAN-2002-0392 : what about older versions of Apache?

[Roy T. Fielding]

On Tuesday, June 25, 2002, at 02:05  PM, Arliss, Noah wrote:
> Hopefully this is not a redundant question.. Does this patch cover issues 
> in
> mod_proxy as well, or were the issues introduced in 1.3.23 and later?

They were introduced later.  The patch says that it is not sufficient for
the releases after 1.3.22.

Roy

RE: CAN-2002-0392 : what about older versions of Apache?

[Arliss, Noah]

Hopefully this is not a redundant question.. Does this patch cover issues in
mod_proxy as well, or were the issues introduced in 1.3.23 and later?

-N

-Original Message-
From: Bill Stoddard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 25, 2002 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: CAN-2002-0392 : what about older versions of Apache?



> 
> Some wrote...
>  > ...
> 
> I must say I'm mystified by this discussion.  It seems to be an
> odd argument between this good practice vs that good practice.
> 
> Roy's patch is simple, safe, and reduces the exposure substantially to a
> known threat.  I can't see any reason to defer letting it out;
> particularly now that people have been given a few days to give voice to
> any technical concerns about it.  The worst outcome is that we are
> embaressed - we can handle that.
> 
> Certainly it's a good thing to be careful.  Giving the right folks
> a chance to look over a patch for stuff like this is a good thing.
> Careful is good.  It's a lot easier to be careful before the exploit
> becomes widely known.
> 
> Leaving the users with no option but to stay exposed, write their own
> patch, or upgrade is pretty stern medicine for us to be proscribing.  It
> is very hard for some sites to upgrade.
> 
> Let's put the patch back.  

+1

Bill

Re: CAN-2002-0392 : what about older versions of Apache?

[Pier Fumagalli]

Bill Stoddard <[EMAIL PROTECTED]> wrote:

> 
>> 
>> Some wrote...
>>> ...
>> 
>> I must say I'm mystified by this discussion.  It seems to be an
>> odd argument between this good practice vs that good practice.
>> 
>> Roy's patch is simple, safe, and reduces the exposure substantially to a
>> known threat.  I can't see any reason to defer letting it out;
>> particularly now that people have been given a few days to give voice to
>> any technical concerns about it.  The worst outcome is that we are
>> embaressed - we can handle that.
>> 
>> Certainly it's a good thing to be careful.  Giving the right folks
>> a chance to look over a patch for stuff like this is a good thing.
>> Careful is good.  It's a lot easier to be careful before the exploit
>> becomes widely known.
>> 
>> Leaving the users with no option but to stay exposed, write their own
>> patch, or upgrade is pretty stern medicine for us to be proscribing.  It
>> is very hard for some sites to upgrade.
>> 
>> Let's put the patch back.
> 
> +1

Yes please... As Bill knows we have a problem with the WebSphere module
which is only supposed to run on 1.3.6 (with our version of WebSphere,
anyway)... Given that we're sending that baby in retirement in 2 months, we
didn't renew with IBM, sooo... We're bummed! :) :) :)

Pier (we - my employer and I)

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

Re: CAN-2002-0392 : what about older versions of Apache?

[Bill Stoddard]

> 
> Some wrote...
>  > ...
> 
> I must say I'm mystified by this discussion.  It seems to be an
> odd argument between this good practice vs that good practice.
> 
> Roy's patch is simple, safe, and reduces the exposure substantially to a
> known threat.  I can't see any reason to defer letting it out;
> particularly now that people have been given a few days to give voice to
> any technical concerns about it.  The worst outcome is that we are
> embaressed - we can handle that.
> 
> Certainly it's a good thing to be careful.  Giving the right folks
> a chance to look over a patch for stuff like this is a good thing.
> Careful is good.  It's a lot easier to be careful before the exploit
> becomes widely known.
> 
> Leaving the users with no option but to stay exposed, write their own
> patch, or upgrade is pretty stern medicine for us to be proscribing.  It
> is very hard for some sites to upgrade.
> 
> Let's put the patch back.  

+1

Bill

Re: CAN-2002-0392 : what about older versions of Apache?

[dirkx]

On Mon, 24 Jun 2002, Ben Hyde wrote:

> Some wrote...
>  > ...
...
> Roy's patch is simple, safe, and reduces the exposure substantially to a
> known threat.  I can't see any reason to defer letting it out;
> particularly now that people have been given a few days to give voice to
> any technical concerns about it.  The worst outcome is that we are
> embaressed - we can handle that.
...
> Leaving the users with no option but to stay exposed, write their own
> patch, or upgrade is pretty stern medicine for us to be proscribing.  It
> is very hard for some sites to upgrade.
>
> Let's put the patch back.

+1 - And let us not forget that you can always patch the patch - when we
find a better and more holistic solution. Patches are not the same as
corrective braces.

Dw

Re: CAN-2002-0392 : what about older versions of Apache?

[Aaron Bannert]

On Mon, Jun 24, 2002 at 10:44:54PM -0400, Ben Hyde wrote:
> Let's put the patch back.  

I believe the patch is out there and has been out there since yesterday,
my mirror picked it up last night.

FWIW, as far as I can tell the patch fixes all potential sign-bit
overflows of the chunk-extention handling. Here's my +1

I think our best bet at this point would be to reevaluate all uses
of memcpy() and make sure that we aren't passing in any negative
offsets.

-aaron

Re: CAN-2002-0392 : what about older versions of Apache?

[Ben Hyde]

Some wrote...
 > ...

I must say I'm mystified by this discussion.  It seems to be an
odd argument between this good practice vs that good practice.

Roy's patch is simple, safe, and reduces the exposure substantially to a
known threat.  I can't see any reason to defer letting it out;
particularly now that people have been given a few days to give voice to
any technical concerns about it.  The worst outcome is that we are
embaressed - we can handle that.

Certainly it's a good thing to be careful.  Giving the right folks
a chance to look over a patch for stuff like this is a good thing.
Careful is good.  It's a lot easier to be careful before the exploit
becomes widely known.

Leaving the users with no option but to stay exposed, write their own
patch, or upgrade is pretty stern medicine for us to be proscribing.  It
is very hard for some sites to upgrade.

Let's put the patch back.  

 - ben

Re: CAN-2002-0392 : what about older versions of Apache?

[Roy T. Fielding]

> I did not remove your patch, I am merely looking for some other opinions.

So am I.  Where are they?

> Have you so soon forgotten that this bug has been in the codebase for
> over 4 years? Common sense tells us that this big of a fuckup needs to
> be thoroughly reviewed, and by someone other than the original author.

What kind of nonsense is that?  The fuckup is obvious once someone says
"hey, it's not protecting against overflow into the signed bit."  The
fix for that is trivial.  The hard part was seeing the tree within the
forest, and then figuring out how they used it to create an exploit.
But that must not prevent us from plugging the hole once it is pointed out.

I know exactly how the hole in the code was introduced -- I remember when
it happened and why there wasn't enough review of the code.  I also know
that I reviewed that code dozens of times since then and never saw this
particular condition.  Shit happens.  Nevertheless, I also know when to
put aside ego and let the bugs be fixed as soon as possible.  Our rule
is that if an exploit script is published, then nothing else is more
important than getting a patch up that plugs the exploit on all releases.

>> My patch does fix the problem, certainly far better than no patch at all.
>> If you disagree, then tell me why it doesn't fix the problem.  If all you
>> are going to do is pontificate about the subject without taking the five
>> minutes necessary to review the change
>
> There's no way that I would be comfortable with a patch to fix a problem
> of this magnitude after only 5 minutes, especially after spending so
> many hours trying to understand the ramifications of the gobbles exploit.

How can you not feel comfortable about it after 5 minutes?  The 
ramifications
of the gobbles exploit are completely irrelevant to stopping the gobbles
exploit.  The ramifications were already published.  Stopping the exploit
only requires one conditional pre-1.3.24.  Even if, by some strange freak
of nature, there exists some other exploit of a related nature, it is still
absolutely necessary that we provide a patch that allows our users to stop
the script kiddies from using the gobbles exploit ASAP.  That was done for
the current version of httpd (a much harder task) and would have been done
for all Apache httpd as of Friday if some idiot hadn't removed my patch
without telling me.

I don't mind that some people here don't have enough experience with
Apache 1.2.x and 1.3.x to feel comfortable about preparing such a patch.
I wouldn't feel comfortable preparing one for 2.0.x filters.
What I do mind is some people feeling that I should sit on my thumb and
wait for them to decide, if they ever find the time to get around to it,
whether or not I know enough about C programming and http_protocol.c
to provide an adequate patch.  I've earned the right to be given the
benefit of the doubt, just as you have earned the right to veto the
patch based on TECHNICAL reasons after you've taken the time to review it
and supplied an alternative.

Roy

Re: CAN-2002-0392 : what about older versions of Apache?

[Aaron Bannert]

On Sun, Jun 23, 2002 at 08:20:23PM -0700, Roy Fielding wrote:
> >I don't remember seeing any +1's for this patch on the list.
> 
> I don't remember needing any.  There were no -1 with explanations.
> There certainly hasn't been any effort spent, aside from my own, to
> address the needs of those who cannot upgrade.  You guys punted, so
> I picked up the ball and finished the task.  Somebody has to do it.
> I refuse to consider votes based on "I haven't looked at it yet."

I did not remove your patch, I am merely looking for some other opinions.

Have you so soon forgotten that this bug has been in the codebase for
over 4 years? Common sense tells us that this big of a fuckup needs to
be thoroughly reviewed, and by someone other than the original author.

> My patch does fix the problem, certainly far better than no patch at all.
> If you disagree, then tell me why it doesn't fix the problem.  If all you
> are going to do is pontificate about the subject without taking the five
> minutes necessary to review the change

There's no way that I would be comfortable with a patch to fix a problem
of this magnitude after only 5 minutes, especially after spending so
many hours trying to understand the ramifications of the gobbles exploit.

> , then piss off.

Turning this personal doesn't make your code any better.

-aaron

Re: CAN-2002-0392 : what about older versions of Apache?

[Roy T. Fielding]

> I don't remember seeing any +1's for this patch on the list.

I don't remember needing any.  There were no -1 with explanations.
There certainly hasn't been any effort spent, aside from my own, to
address the needs of those who cannot upgrade.  You guys punted, so
I picked up the ball and finished the task.  Somebody has to do it.
I refuse to consider votes based on "I haven't looked at it yet."

> Please remove this patch until one can be made that addresses the same
> issues with the proxy code (which also uses get_chunk_size()).

No.  Aaron, use your brain.  First, the proxy code that implemented chunked
reading was introduced after 1.3.22 (hence my NUMEROUS comments to the 
effect
that it wasn't applicable).  Second, the bogus type casts were not present
until after 1.3.22.  Third, the pointless ap_strtol addition was only done
because someone wanted to check the errno field, which is totally
irrelevant to the security hole itself.

My patch does fix the problem, certainly far better than no patch at all.
If you disagree, then tell me why it doesn't fix the problem.  If all you
are going to do is pontificate about the subject without taking the five
minutes necessary to review the change, then piss off.

Roy

RE: CAN-2002-0392 : what about older versions of Apache?

[Ryan Bloom]

> From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> 
> On Sun, Jun 23, 2002 at 05:09:05PM -0700, Roy Fielding wrote:
> > I have re-uploaded a patch to fix the problem on all versions of
> > httpd 1.2.0 through 1.3.22.  This time I added the four lines that
> > check for a negative return value from atol, even though there has
> > been no evidence of any such error in the standard C libraries.
> >
> > To the person who deleted my prior patch: You just wasted
> > my Sunday afternoon.  Even if the patch didn't, by some stretch of
> > your imagination, suffice for the broken atol case, you prevented
> > people from protecting themselves against a published exploit script
> > that doesn't even use content-length as an attack.  Do not remove
> > my patch unless you replace it with a better fix that is known to
> > apply for that version and compile on all platforms.
> >
> > -1 to any additions of ap_strtol to prior versions of Apache.
> > That introduced more problems than it fixed.  There is no reason
> > to work around the operating system when a simple fix to our own
> > code is necessary and sufficient to solve the problem.
> 
> 
> I don't remember seeing any +1's for this patch on the list.
> 
> Please remove this patch until one can be made that addresses the same
> issues with the proxy code (which also uses get_chunk_size()).

The proxy didn't use that code until it supported HTTP 1.1, which didn't
happen until 1.3.24.  Roy is right, removing this patch is completely
bogus.

Ryan

Re: CAN-2002-0392 : what about older versions of Apache?

[Aaron Bannert]

On Sun, Jun 23, 2002 at 05:09:05PM -0700, Roy Fielding wrote:
> I have re-uploaded a patch to fix the problem on all versions of
> httpd 1.2.0 through 1.3.22.  This time I added the four lines that
> check for a negative return value from atol, even though there has
> been no evidence of any such error in the standard C libraries.
> 
> To the person who deleted my prior patch: You just wasted
> my Sunday afternoon.  Even if the patch didn't, by some stretch of
> your imagination, suffice for the broken atol case, you prevented
> people from protecting themselves against a published exploit script
> that doesn't even use content-length as an attack.  Do not remove
> my patch unless you replace it with a better fix that is known to
> apply for that version and compile on all platforms.
> 
> -1 to any additions of ap_strtol to prior versions of Apache.
> That introduced more problems than it fixed.  There is no reason
> to work around the operating system when a simple fix to our own
> code is necessary and sufficient to solve the problem.


I don't remember seeing any +1's for this patch on the list.

Please remove this patch until one can be made that addresses the same
issues with the proxy code (which also uses get_chunk_size()).

-aaron

Re: CAN-2002-0392 : what about older versions of Apache?

[Roy T. Fielding]

I have re-uploaded a patch to fix the problem on all versions of
httpd 1.2.0 through 1.3.22.  This time I added the four lines that
check for a negative return value from atol, even though there has
been no evidence of any such error in the standard C libraries.

To the person who deleted my prior patch: You just wasted
my Sunday afternoon.  Even if the patch didn't, by some stretch of
your imagination, suffice for the broken atol case, you prevented
people from protecting themselves against a published exploit script
that doesn't even use content-length as an attack.  Do not remove
my patch unless you replace it with a better fix that is known to
apply for that version and compile on all platforms.

-1 to any additions of ap_strtol to prior versions of Apache.
That introduced more problems than it fixed.  There is no reason
to work around the operating system when a simple fix to our own
code is necessary and sufficient to solve the problem.


Roy T. Fielding, Chairman, The Apache Software Foundation
  ([EMAIL PROTECTED])  



Please see 

This patch fixes the known vulnerability of chunk size reads,
and a potential vulnerability for content-length reads on systems
with a broken atol() implementation, for all versions of
Apache httpd 1.2.0 through 1.3.22.

Apache httpd 1.3.23 through 1.3.25 require a more extensive patch
and should upgrade to the latest version of Apache httpd.

All Apache users are encouraged to upgrade to httpd 1.3.26 (or later)
or httpd 2.0.39 (or later).  This patch is for those people who cannot
upgrade for reasons beyond their control.


--- apache_1.3.22/src/main/http_protocol_orig.c Fri Jun 22 05:43:54 2001
+++ apache_1.3.22/src/main/http_protocol.c  Sun Jun 23 15:56:34 2002
@@ -1913,6 +1913,9 @@
 }
 
 r->remaining = atol(lenp);
+if (r->remaining < 0) {
+return HTTP_BAD_REQUEST;
+}
 }
 
 if ((r->read_body == REQUEST_NO_BODY) &&
@@ -2049,6 +2052,10 @@
 }
 
 len_to_read = get_chunk_size(buffer);
+if (len_to_read < 0) {
+r->connection->keepalive = -1;
+return -1;
+}
 
 if (len_to_read == 0) { /* Last chunk indicated, get footers */
 if (r->read_body == REQUEST_CHUNKED_DECHUNK) {