httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Vanasco <>
Subject corrupt cookie kills mod-perl / apreq
Date Wed, 15 Feb 2006 00:45:37 GMT
[note: x-posted to modperl]
[note: i sent this earlier from an unsubscribed address.  that  
shouldn't go through.  if it does, apologies in advance ]

I wrote a web services module to incorporate the TrackBack protocol  
into my mod_perl application

I started testing it using WordPress - the php blog software

It seems to have set a cookie (see details below) , that causes an  
automatic error in modperl

The error in the logs is :"Expected token not present"

It was touched briefly in :
	[mp2] "Expected token not present" error in logs
	Date: Sun, 8 Jan 2006 11:18:10 -0500

The extent to which it was discussed was:

Joe Schaefer
	It probably means that the request's Cookie: header was missing an  
"=" sign.
Philip M. Gollucci
	joes: any possibility of improving that error message in 2.07-dev ?

And then the conversation died.

The issue seems to be definitively caused by an issue in the way that  
wordpress encodes the cookie and safari sends it

 From the headers_in , it seems that WordPress includes raw-php code  
(instead of executing it), and either wordpress or safari doesn't  
properly escape the = sign in the cookies.

In production I see little chance this will affect me or any other  
user -- the invalid cookie isn't going to be sent to the box.

BUT it brings up this issue - a corrupt cookie of this sort seems to  
call a die() in modperl  once libapreq attempts to parse it.  i'd say  
50% of the dies are met with a segfault.  i don't know why its not a  
1:1 ratio.

I couldn't seem to find any way to provide a defense against this.   
Just calling cookiejar->cookie() will cause the error.
	my $cookiejar 	= Apache2::Cookie::Jar->new( $self->{'apr'} );
	my @names 		= $cookiejar->cookies();

the segfault, natually, occurs whether or not the code is wrapped in  
an eval block.  an eval block didn't seem to catch the other  error  
either (sorry, but i can't discern what it is)

Can someone suggest an approach?  Maybe some sort of validation regex  
needs to be in/updated on the cookie parsing code?  I'm a little  
uneasy with the idea that sending a bad cookie gives a 50% chance to  
segfault a server.

I've enclosed a Data::Dumper representation of the the APR::Table  
headers_in atfer the cookie info.  I'll be happy to pull it into any  
other format if instructed how.

To recreate this, you can use:
	wordpress-2.0.1 (current)
	mac osx 10.4 + safari 2.0.3
	libapreq 2.07
	httpd 2.055

$headers_in = bless( {
                        'Accept' => '*/*',
                        'Accept-Language' => 'en',
                        'Accept-Encoding' => 'gzip, deflate',
                        'Cookie' =>  
2f9db49; rs_session=59ae9b8b503e3af7d17b97e7f77f7ea5; dbx- 
                        'User-Agent' => 'Mozilla/5.0 (Macintosh; U;  
PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8',
                        'Connection' => 'keep-alive',
                        'Host' => 'g5.local:8082'
                      }, 'APR::Table' );

View raw message