child pid 28464 exit signal Segmentation fault (11)

[Cyril SCETBON]

Hi people,

I get this error message int error.log when I try to access a perl 
script which exists or not.


I've turned on trace messages in mod_perl and here is my error.log :

[Sun Oct 08 17:19:39 2006] [notice] Apache/2.0.55 (Ubuntu) 
mod_ssl/2.0.55 OpenSSL/0.9.8a mod_perl/2.0.2 Perl/v5.8.7 configured -- 
resuming normal operations
modperl_filter_add_connection: no InputFilter handlers configured 
(connection)


modperl_filter_add_connection: no OutputFilter handlers configured 
(connection)


modperl_callback_run_handlers: no PerlPreConnectionHandler handlers 
configured ()


modperl_callback_run_handlers: no PerlProcessConnectionHandler handlers 
configured ()


modperl_config_req_new: 0x8168440

modperl_callback_run_handlers: no PerlPostReadRequestHandler handlers 
configured (/tmp/test.pl)


modperl_config_dir_new: new dcfg: 0x8172388

modperl_config_dir_merge: basev==0x81a44a8, addv==0x8150380, mrg==0x8172388

modperl_callback_run_handlers: no PerlTransHandler handlers configured 
(/tmp/test.pl)


modperl_callback_run_handlers: no PerlMapToStorageHandler handlers 
configured (/tmp/test.pl)


modperl_config_dir_new: new dcfg: 0x81732f0

modperl_config_dir_merge: basev==0x81a44a8, addv==0x8150380, mrg==0x81732f0

modperl_callback_run_handlers: no PerlHeaderParserHandler handlers 
configured (/tmp/test.pl)


modperl_callback_run_handlers: no PerlAccessHandler handlers configured 
(/tmp/test.pl)


modperl_callback_run_handlers: no PerlTypeHandler handlers configured 
(/tmp/test.pl)


modperl_callback_run_handlers: no PerlFixupHandler handlers configured 
(/tmp/test.pl)


modperl_filter_add_request: no OutputFilter handlers configured 
(/tmp/test.pl)


modperl_filter_add_request: no InputFilter handlers configured 
(/tmp/test.pl)


modperl_interp_select: scope is per-request

modperl_tipool_pop: about to lock tipool in thread 0xb77f3bb0

modperl_tipool_pop: acquired tipool lock

modperl_tipool_pop: about to unlock tipool in thread 0xb77f3bb0

modperl_tipool_pop: released tipool lock

modperl_interp_get: head == 0x84770a0, parent == 0x82287b0

modperl_interp_get: selected 0x8253fe0 (perl==0x822a4b8)

modperl_interp_get: thread == 0xb77f3bb0

modperl_interp_select: set interp 0x8253fe0 in request_rec pool 
0x81677c8 (main request for /tmp/test.pl)


modperl_env_request_populate:
[28464/3078568880/0x822a4b8/localhost.localdomain:80/tmp/test.pl]
@ENV{keys r->subprocess_env} = values r->subprocess_env;
modperl_env_table_populate: $ENV{HTTP_HOST} = "127.0.0.1";
modperl_env_table_populate: $ENV{HTTP_ACCEPT} = "text/html, text/plain, 
application/x-java-jnlp-file, application/vnd.sun.xml.calc, 
application/vnd.sun.xml.calc.template, application/vnd.sun.xml.draw, 
application/vnd.sun.xml.draw.template, application/vnd.sun.xml.impress, 
application/vnd.sun.xml.impress.template, 
application/vnd.sun.xml.writer, application/vnd.sun.xml.writer.global, 
application/vnd.sun.xml.writer.template, application/pdf, 
application/postscript, application/x-bzip, 
application/x-bzip-compressed-tar, application/x-compress, 
application/x-compressed-tar, application/x-gzip, 
application/x-java-archive, application/x-stuffit, application/x-tar, 
application/zip, text/xml, application/x-troff-man, image/avs, 
image/bie, image/x-ms-bmp, image/cmyk, image/dcx, image/eps, image/fax, 
image/fits, image/gif, image/gray, image/jpeg, image/pjpeg, image/miff, 
image/mono, image/mtv, image/x-portable-bitmap, image/pcd, image/pcx, 
image/pdf, image/x-portable-graymap, image/pict, image/png, 
image/x-portable-anymap, image/x-portable-pixmap, image/ps, image/rad, 
image/x-rgb, image/rgba, image/rla, image/rle, image/sgi, 
image/sun-raster, image/targa, image/tiff, image/uyvy, image/vid, 
image/viff, image/x-xbitmap, image/x-xpixmap, image/x-xwindowdump, 
image/x-icon, image/yuv, application/vnd.oasis.opendocument.database, 
application/vnd.oasis.opendocument.spreadsheet, 
application/vnd.oasis.opendocument.spreadsheet-template, 
application/vnd.oasis.opendocument.chart, 
application/vnd.stardivision.calc, application/vnd.stardivision.chart, 
application/vnd.oasis.opendocument.graphics, 
application/vnd.oasis.opendocument.graphics-template, 
application/vnd.stardivision.draw, 
application/vnd.oasis.opendocument.presentation, 
application/vnd.oasis.opendocument.presentation-template, 
application/vnd.stardivision.impress, 
application/vnd.oasis.opendocument.formula, 
application/vnd.stardivision.math, 
application/vnd.oasis.opendocument.text, 
application/vnd.oasis.opendocument.text-template, 
application/vnd.oasis.opendocument.text-web, 
application/vnd.oasis.opendocument.text-master, 
application/vnd.stardivision.writer-global, 
application/vnd.stardivision.writer, application/x-ogg, application/ogg, 
audio/x-mp3, audio/x-scpls, audio/x-mpeg, audio/mpeg, audio/x-mpegurl, 
application/x-flac, application/x-gtar, audio/mpegurl, audio/x-ogg, 
application/msexcel, application/vnd.ms-excel, application/x-msexcel, 
application/m

Re: Fwd: XSS evasion

[mock]

On Fri, Oct 06, 2006 at 07:25:06PM +0200, Clinton Gormley wrote:
> On Fri, 2006-10-06 at 18:48 +0200, Hendrik Van Belleghem wrote:
> > "mock" talked about XSS at this years YAPC::Europe in Birmingham a few
> > weeks ago. He had quite a few examples. His slides are at
> > http://sketchfactory.com/static/mvc.pdf (More Vulnerable Code).
> > It goes without saying that it would be a bit unwise to test the URLs
> > mentioned in the talk.
> 
> He briefly mentions HTML::Scrubber in there. I am using
> HTML::Stripscripts::Parser, which also makes sure that tags are nested
> properly.
> 
> Anybody have any view on these (or other) modules?
> 
> Clint
> 

HTML::Scrubber is not really broken.  The problem is that the
documentation leads the user to do broken things, as was shown with
Planet Plagger.  It is possible to make a secure HTML::Scrubber config,
but you need to default deny everything and then only allow a select
list of tags and attributes - and you need to really think about that
list.  The underlying problem, which I suspect HTML::Stripscripts shares
is that HTML::Parser thinks that the attribute "foo=bar" is different
than the attribute "foo.=bar" (RSnake covers this kind of evasion in his
document fairly well) and your browser thinks that everthing non
alphanumeric before the equals sign is junk.  So without actually
sitting down and auditing HTML::Stripscripts I'd say it probably _can_
be used safely, but odds are most people won't.

As an aside, I'm not sure that it's completely public knowledge outside
people who read my site and people who saw my talk, but CSRF can be
performed from feeds (RSS, Atom).  So you need to defang any feeds that
will be shown to a logged in user otherwise there's the possibility of
doing various bad things(tm).  There's also the obvious problem with
javascript in feeds as well...

Finally, if you're near Tokyo this November, Martin Johns is going to be
presenting what looks like a really good talk on CSRF, with some new
mitigation techniques and a fair bit of new work on the problem at
PacSec (http://pacsec.jp/speakers.html).

mock

Re: Fwd: XSS evasion

[Clinton Gormley]

> HTML::Scrubber is not really broken.  The problem is that the
> documentation leads the user to do broken things, as was shown with
> Planet Plagger.  It is possible to make a secure HTML::Scrubber config,
> but you need to default deny everything and then only allow a select
> list of tags and attributes - and you need to really think about that
> list.  The underlying problem, which I suspect HTML::Stripscripts shares
> is that HTML::Parser thinks that the attribute "foo=bar" is different
> than the attribute "foo.=bar" (RSnake covers this kind of evasion in his
> document fairly well) and your browser thinks that everthing non
> alphanumeric before the equals sign is junk.  

HTML::StripScripts::Parser has a default deny everything approach, and
reconstructs the HTML fed to it, so unless it makes sense as html, it
doesn't get passed through and reconstructed.

I tried out loads of different forms of XSS attacks from RSnake's site,
and they were all neutered by StripScripts, including the 'foo.=' form.

> So without actually 
> sitting down and auditing HTML::Stripscripts I'd say it probably _can_
> be used safely, but odds are most people won't.

Again, without actually auditing it but based on my experience of
configuring and using it, I would say that with the default settings of
HTML::StripScripts::Parser, you'd be pretty safe, but that you could
configure it so that it would NOT be safe.

Clint