Segmentation fault on form posting

[Neil Bowers <ne...@bowers.com>]

Hi,

I've got a mod_perl handler which has been working fine for a long time, but just recently two people have managed to trigger a seg fault under specific circumstances.

They are POSTing form data
Only happens over https - doesn't happen via http (ie without SSL)
A certain combination of bytes in the form seems to trigger this. Doesn't appear to be the *number* of bytes, but can't really be sure.
It only happens if the end-user is on 64-bit Windows (Win 7 only so far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix on 64bit, or on any browser on 32-bit Windows.

In my handler, if the first thing I do is print out the POST parameters, then the segfault doesn't happen. So it smells like some kind of memory overwrite.

This happens on combinations of:

CentOS 5.5 and 6.3
openssl 1.0.0d and 1.0.1e
Apache 2.2.22 and 2.2.24
Perl 5.12.3 and 5.16.3
mod_perl 2.0.5, 2.0.7 and 2.0.8

I'll probably try 5.18, though I don't expect any change with that.

So now, some questions:

Anyone seen anything like this, and have an idea where to look?
Any thoughts on where to look / what else to try?
What's the best approach to tracking this down? Valgrind?

I'm going to try attaching a debugger to an httpd process to see if I can see where it's dying, though I suspect the problem may be happening earlier.
I'll have a go with valgrind after that.

Cheers,
Neil

Re: Segmentation fault on form posting

[Jim Schueler <js...@eloquency.com>]

I also encounter this problem occasionally.  So your post is quite 
familiar.

If the first thing you do is print the parameters, what's the second 
thing?  Form posts almost always trigger external processes, databases, 
mail servers, etc.  The external process is more likely to be causing the 
fault than mod_perl.

At its heart, a perl scalar is a pretty complicated data object.  I think 
it's more likely that the scalar gets modified as the result of the print 
operation.  For example:

   sprintf "%d", $cgi{quantity} ;

To my knowledge, this statement modifies the scalar $cgi{quantity} so that 
the next operation views the scalar slightly differently.  I have a 
prototype library that examines the scalar.  If I can find it, I'll 
forward separately.

Finally, there are specific operations for parsing form input.  Are you 
using a package like CGI?  Have you tried an alternative?  It's only a 
couple lines of code to roll your own.

-Jim

On Thu, 23 May 2013, Neil Bowers wrote:

> Hi,
> I've got a mod_perl handler which has been working fine for a long time, but
> just recently two people have managed to trigger a seg fault under specific
> circumstances.
>
>  *  They are POSTing form data
>  *  Only happens over https - doesn't happen via http (ie without SSL)
>  *  A certain combination of bytes in the form seems to trigger this.
>     Doesn't appear to be the *number* of bytes, but can't really be sure.
>  *  It only happens if the end-user is on 64-bit Windows (Win 7 only so
>     far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix
>     on 64bit, or on any browser on 32-bit Windows.
> 
> In my handler, if the first thing I do is print out the POST parameters,
> then the segfault doesn't happen. So it smells like some kind of memory
> overwrite.
> 
> This happens on combinations of:
>
>  *  CentOS 5.5 and 6.3
>  *  openssl 1.0.0d and 1.0.1e
>  *  Apache 2.2.22 and 2.2.24
>  *  Perl 5.12.3 and 5.16.3
>  *  mod_perl 2.0.5, 2.0.7 and 2.0.8
> 
> I'll probably try 5.18, though I don't expect any change with that.
> 
> So now, some questions:
>
>  *  Anyone seen anything like this, and have an idea where to look?
>  *  Any thoughts on where to look / what else to try?
>  *  What's the best approach to tracking this down? Valgrind?
> 
> I'm going to try attaching a debugger to an httpd process to see if I can
> see where it's dying, though I suspect the problem may be happening earlier.
> I'll have a go with valgrind after that.
> 
> Cheers,
> Neil
> 
> 
>

Re: Segmentation fault on form posting

[Jim Schueler <js...@eloquency.com>]

Here's the code I mentioned in my last post.  It's included in my distro
NoSQL::PL2SQL

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include "ppport.h"

SV* typeis ( SV* what ) ;

SV* typeis ( SV* what )
{
 	if ( SvIOK( what ) )
 		return newSVpvs( "integer" ) ;
 	else if ( SvNOK( what ) )
 		return newSVpvs( "double" ) ;
 	else if ( SvPOK( what ) )
 		return newSVpvs( "string" ) ;

 	return newSVpvs( "unknown" ) ;
}


MODULE = NoSQL::PL2SQL		PACKAGE = NoSQL::PL2SQL::Node

PROTOTYPES: ENABLE

SV* 
typeis( what )
 	SV* what



On Thu, 23 May 2013, Neil Bowers wrote:

> Hi,
> I've got a mod_perl handler which has been working fine for a long time, but
> just recently two people have managed to trigger a seg fault under specific
> circumstances.
>
>  *  They are POSTing form data
>  *  Only happens over https - doesn't happen via http (ie without SSL)
>  *  A certain combination of bytes in the form seems to trigger this.
>     Doesn't appear to be the *number* of bytes, but can't really be sure.
>  *  It only happens if the end-user is on 64-bit Windows (Win 7 only so
>     far), on IE9 or Chrome 26 (27 seems to be ok). Doesn't happen on Firefix
>     on 64bit, or on any browser on 32-bit Windows.
> 
> In my handler, if the first thing I do is print out the POST parameters,
> then the segfault doesn't happen. So it smells like some kind of memory
> overwrite.
> 
> This happens on combinations of:
>
>  *  CentOS 5.5 and 6.3
>  *  openssl 1.0.0d and 1.0.1e
>  *  Apache 2.2.22 and 2.2.24
>  *  Perl 5.12.3 and 5.16.3
>  *  mod_perl 2.0.5, 2.0.7 and 2.0.8
> 
> I'll probably try 5.18, though I don't expect any change with that.
> 
> So now, some questions:
>
>  *  Anyone seen anything like this, and have an idea where to look?
>  *  Any thoughts on where to look / what else to try?
>  *  What's the best approach to tracking this down? Valgrind?
> 
> I'm going to try attaching a debugger to an httpd process to see if I can
> see where it's dying, though I suspect the problem may be happening earlier.
> I'll have a go with valgrind after that.
> 
> Cheers,
> Neil
> 
> 
>