Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3DF79250.5000508@apache.org>
Date: Wed, 11 Dec 2002 14:30:24 -0500
From: Greg Ames <gregames@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0/server protocol.c
References: <20021210025627.85090.qmail@icarus.apache.org>
	 <3DF6403F.5020403@apache.org> <1039550284.20962.18.camel@desktop>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brian Pane wrote:
> +1 for the patch in 2.0.44.
> 
> Longer term, a better solution might be able to fix the problem
> closer to its source.  I'm assuming, based on the code, that the
> problem only occurs when the "folding" logic in ap_get_mime_headers_core
> is invoked.  That's the only case I see where the the size of the
> field can grow arbitrarily large.  

OK, I took another look at the dump.  We have 4 saved input buffers.  The oldest 
contains a good request line. The others contain a monster cookie where the 
original buffer lengths are 1460, 1460, and 5840.  So getline gave up when it 
saw the total length was 8720.

But what killed us is that ap_escape_html's input and output strings are 
overlapping, and it is processing its own output as input:

(gdb) fr 0
#0  ap_escape_html (p=0x8152018,
     s=0x8158018 "Cookie: ASPSESSIONIDGQGQGTHO=FDLGHGOBJJJNPCKBHGOGAFFP; 
DTMLASTPOPUP=%7Bts+%272002%2D12%2D02+22%3A39%3A34%27%7D; CFTOKEN=16145632; VJ 
UTrackID=66.200.155.34.14801038898591969; AFFILIATE_SCOPE=N; ASPSES"...) at 
util.c:1703
1703                x[j] = s[i];
(gdb) p x
$10 = 0x8158b80 "Cookie: ASPSESSIONIDGQGQGTHO=FDLGHGOBJJJNPCKBHGOGAFFP; 
DTMLASTPOPUP=%7Bts+%272002%2D12%2D02+22%3A39%3A34%27%7D; CFTOKEN=16145632; VJ 
UTrackID=66.200.155.34.14801038898591969; AFFILIATE_SCOPE=N; ASPSES"...

Notice that the hex addresses of the two variables are only 0xb68 == 2920 bytes 
apart.  That makes some sense; 2920 = 1460+1460.  vi'ing the dump, I can see 
that ap_escape_html tried to escape its own output repeatedly until it seg 
faulted.  The string below appears many times with another "amp;" added each 
iteration as it re-escapes the ampersand:

MC1=V=2&amp;amp;amp;amp;amp;amp;amp;amp;amp;GUID=3
89F8C3Cookie: ASPSESSIONIDG

We know that ap_get_mime_headers thought there was a problem with the length of 
the cookie due to where it called ap_escape_html, even though the length 
returned by getline was only 2920 bytes.  s wasn't null terminated, but my patch 
won't insert a null in an appropriate place as it stands now.  I'll go rework it.

Greg