Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

 

 

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


merlyn at stonehenge

Mar 22, 2007, 8:20 PM

Post #1 of 29 (34521 views)
Permalink
MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)

>>>>> "Alex" == Alex Solovey <a.solovey [at] gmail> writes:

Alex> The problem is due to unescaped variable interpolation in regular
Alex> expression $uri =~ /$path_info$/ in sub namespace_from:

I don't want to raise too many alarms, but this means that every MP1 server
has a denial-of-service attack against it now.

Consider a regex that takes 10,000 years to figure out it doesn't match.
Those can be written in under 50 characters. I'm sure the golfers can get
it down to 10.

And path_info is an arbitrary string, aided by having %-escaping before it
gets this far, I presume.

Ick.

"Hello, CERT?"

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


merlyn at stonehenge

Mar 22, 2007, 8:25 PM

Post #2 of 29 (34093 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

>>>>> "Randal" == Randal L Schwartz <merlyn [at] stonehenge> writes:

>>>>> "Alex" == Alex Solovey <a.solovey [at] gmail> writes:
Alex> The problem is due to unescaped variable interpolation in regular
Alex> expression $uri =~ /$path_info$/ in sub namespace_from:

Randal> I don't want to raise too many alarms, but this means that every MP1
Randal> server has a denial-of-service attack against it now.

And MP2 as well, from ModPerl::RegistryCooker:

my $path_info = $self->{REQ}->path_info;
my $script_name = $path_info && $self->{URI} =~ /$path_info$/
? substr($self->{URI}, 0, length($self->{URI}) - length($path_info))
: $self->{URI};

Wonderful. Won't take long until this makes the rounds. Better start
getting the patches out and the press releases.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


fred at redhotpenguin

Mar 22, 2007, 8:49 PM

Post #3 of 29 (34129 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Randal L. Schwartz wrote:
>>>>>> "Randal" == Randal L Schwartz <merlyn [at] stonehenge> writes:
>
>>>>>> "Alex" == Alex Solovey <a.solovey [at] gmail> writes:
> Alex> The problem is due to unescaped variable interpolation in regular
> Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>
> Randal> I don't want to raise too many alarms, but this means that every MP1
> Randal> server has a denial-of-service attack against it now.
>
> And MP2 as well, from ModPerl::RegistryCooker:
>
> my $path_info = $self->{REQ}->path_info;
> my $script_name = $path_info && $self->{URI} =~ /$path_info$/
> ? substr($self->{URI}, 0, length($self->{URI}) - length($path_info))
> : $self->{URI};
>
> Wonderful. Won't take long until this makes the rounds. Better start
> getting the patches out and the press releases.

Ok, help me out here Merlyn. Will this fix it?

phred [at] pook ~/dev/modperl/mod_perl-2.0 $ svn diff
ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
===================================================================
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (revision 508723)
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (working copy)
@@ -337,7 +337,7 @@
my $self = shift;

my $path_info = $self->{REQ}->path_info;
- my $script_name = $path_info && $self->{URI} =~ /$path_info$/
+ my $script_name = $path_info && $self->{URI} =~ /\$path_info$/
? substr($self->{URI}, 0, length($self->{URI}) -
length($path_info))
: $self->{URI};


>


merlyn at stonehenge

Mar 22, 2007, 8:50 PM

Post #4 of 29 (34102 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Fred" == Fred Moyer <fred [at] redhotpenguin> writes:

Fred> Ok, help me out here Merlyn. Will this fix it?

No, you want /\Q$path_info\E$/

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


andy at hexten

Mar 22, 2007, 8:51 PM

Post #5 of 29 (34124 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

On 23 Mar 2007, at 03:49, Fred Moyer wrote:
> Ok, help me out here Merlyn. Will this fix it?

I assume it needs to be quoted like this:

$path_info = quotemeta $path_info;
my $script_name = $path_info && $self->{URI} =~ /$path_info$/


>
> phred [at] pook ~/dev/modperl/mod_perl-2.0 $ svn diff ModPerl-Registry/
> lib/ModPerl/RegistryCooker.pm
> Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
> ===================================================================
> --- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (revision
> 508723)
> +++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (working copy)
> @@ -337,7 +337,7 @@
> my $self = shift;
>
> my $path_info = $self->{REQ}->path_info;
> - my $script_name = $path_info && $self->{URI} =~ /$path_info$/
> + my $script_name = $path_info && $self->{URI} =~ /\$path_info$/
> ? substr($self->{URI}, 0, length($self->{URI}) - length
> ($path_info))
> : $self->{URI};
>
>
>

--
Andy Armstrong, hexten.net


pharkins at gmail

Mar 22, 2007, 8:55 PM

Post #6 of 29 (34112 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

On 3/22/07, Andy Armstrong <andy [at] hexten> wrote:
> $path_info = quotemeta $path_info;
> my $script_name = $path_info && $self->{URI} =~ /$path_info$/

You can in-line that to avoid clobbering the original:
my $script_name = $path_info && $self->{URI} =~ /\Q$path_info\E$/

- Perrin


pgollucci at p6m7g8

Mar 22, 2007, 8:59 PM

Post #7 of 29 (34136 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Perrin Harkins wrote:
> On 3/22/07, Andy Armstrong <andy [at] hexten> wrote:
>> $path_info = quotemeta $path_info;
>> my $script_name = $path_info && $self->{URI} =~ /$path_info$/
>
> You can in-line that to avoid clobbering the original:
> my $script_name = $path_info && $self->{URI} =~ /\Q$path_info\E$/
+1 from me.

I guess we should start planning for a 1.30 and 2.0.4 once this is
agreed and committed ?

--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci [at] p6m7g8) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF

Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.


fred at redhotpenguin

Mar 22, 2007, 9:22 PM

Post #8 of 29 (34121 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Philip M. Gollucci wrote:
> Perrin Harkins wrote:
>> On 3/22/07, Andy Armstrong <andy [at] hexten> wrote:
>>> $path_info = quotemeta $path_info;
>>> my $script_name = $path_info && $self->{URI} =~ /$path_info$/
>>
>> You can in-line that to avoid clobbering the original:
>> my $script_name = $path_info && $self->{URI} =~ /\Q$path_info\E$/
> +1 from me.
>
> I guess we should start planning for a 1.30 and 2.0.4 once this is
> agreed and committed ?

The changes are ready for review on the dev list. I can dig up some
tuits to help with the release if needed, and I think we are pretty set
there patch wise for anyone who needs something right away.

Now I guess we just need that press release... Randal maybe you can get
this all out on Perlcast? :)


merlyn at stonehenge

Mar 22, 2007, 9:23 PM

Post #9 of 29 (34138 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Fred" == Fred Moyer <fred [at] redhotpenguin> writes:

Fred> The changes are ready for review on the dev list. I can dig up some
Fred> tuits to help with the release if needed, and I think we are pretty set
Fred> there patch wise for anyone who needs something right away.

Release*s* you mean?

Fred> Now I guess we just need that press release... Randal maybe you can get
Fred> this all out on Perlcast? :)

At the delay at which I usually record them, that won't be very fast. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


geoff at modperlcookbook

Mar 23, 2007, 5:04 AM

Post #10 of 29 (34118 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Randal L. Schwartz wrote:
>>>>>>"Randal" == Randal L Schwartz <merlyn [at] stonehenge> writes:
>
>
>>>>>>"Alex" == Alex Solovey <a.solovey [at] gmail> writes:
>
> Alex> The problem is due to unescaped variable interpolation in regular
> Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>
> Randal> I don't want to raise too many alarms, but this means that every MP1
> Randal> server has a denial-of-service attack against it now.
>
> And MP2 as well, from ModPerl::RegistryCooker:
>
> my $path_info = $self->{REQ}->path_info;
> my $script_name = $path_info && $self->{URI} =~ /$path_info$/
> ? substr($self->{URI}, 0, length($self->{URI}) - length($path_info))
> : $self->{URI};
>
> Wonderful. Won't take long until this makes the rounds. Better start
> getting the patches out and the press releases.

this sensationalism was just flat-out irresponsible. I don't doubt that
it's true, but not giving us dev folks time to address the issue with a
security release is going to cause more headaches than it otherwise
would have.

in the future, if anyone has a security issue with any apache product,
the proper path to follow is to send a brief email to
security [at] apache those guys will make sure it gets routed to the
appropriate place (the mod_perl pmc and core development team in this
case) and we'll work with you to get it clarified and resolved.

--Geoff


mpeters at plusthree

Mar 23, 2007, 6:06 AM

Post #11 of 29 (34133 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Randal L. Schwartz wrote:
>>>>>> "Alex" == Alex Solovey <a.solovey [at] gmail> writes:
>
> Alex> The problem is due to unescaped variable interpolation in regular
> Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>
> I don't want to raise too many alarms, but this means that every MP1 server
> has a denial-of-service attack against it now.

Not quite. It only affects people running PerlRun. Not insignificant, but
definitely not everyone.

--
Michael Peters
Developer
Plus Three, LP


geoff at modperlcookbook

Mar 23, 2007, 6:57 AM

Post #12 of 29 (34140 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Michael Peters wrote:
> Randal L. Schwartz wrote:
>
>>>>>>>"Alex" == Alex Solovey <a.solovey [at] gmail> writes:
>>
>>Alex> The problem is due to unescaped variable interpolation in regular
>>Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>>
>>I don't want to raise too many alarms, but this means that every MP1 server
>>has a denial-of-service attack against it now.
>
>
> Not quite. It only affects people running PerlRun. Not insignificant, but
> definitely not everyone.

fwiw, I am unable to reproduce this in either mp1 or mp2 using what I
consider a basic setup.

this does not mean that I don't agree with the assessments thus far.
but one thing it does mean, though, is that we can't be sure we have a
fix in place if we are unable to verify before and after scenarios.

so, I could use some help here. if anyone is able to reproduce it
please email me PRIVATELY with

o relevant httpd.conf
o sample script

again, watch your reply-all button - no need to expose things to the
world and forever in google at the moment :)

alternatively, anyone with an interest can join #mp-security on
irc.pobox.com (irc.perl.org) so we can get this resolved quickly.

--Geoff


kjetilk at opera

Mar 23, 2007, 7:30 AM

Post #13 of 29 (34124 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

On Friday 23 March 2007 14:57, Geoffrey Young wrote:
> fwiw, I am unable to reproduce this in either mp1 or mp2 using what I
> consider a basic setup.

I have also failed to reproduce the problem on 2.0.3 with my setup.
Also, we are very liberal on what kind of usernames, and thus what
special characters can enter the URI, and in some cases they go through
a registry script, and we have not observed any crashes due to this.

Best,

Kjetil
--
Kjetil Kjernsmo
Information Systems Developer
Opera Software ASA


geoff at modperlcookbook

Mar 23, 2007, 7:54 AM

Post #14 of 29 (34114 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

Kjetil Kjernsmo wrote:
> On Friday 23 March 2007 14:57, Geoffrey Young wrote:
>
>>fwiw, I am unable to reproduce this in either mp1 or mp2 using what I
>>consider a basic setup.
>
>
> I have also failed to reproduce the problem on 2.0.3 with my setup.
> Also, we are very liberal on what kind of usernames, and thus what
> special characters can enter the URI, and in some cases they go through
> a registry script, and we have not observed any crashes due to this.

I was able to reproduce this in mp1.

for the interested, a fix has been put in place in svn for mod_perl 1.0,
which you can grab from here:

https://svn.apache.org/repos/asf/perl/modperl/branches/1.x/

furthermore, as michael pointed out, the problem is isolated to
Apache::PerlRun - Apache::Registry has had a similar fix in it since
mid-2000 and Apache::RegistryNG is filename based, not url based.

--Geoff


merlyn at stonehenge

Mar 23, 2007, 7:57 AM

Post #15 of 29 (34119 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Geoffrey" == Geoffrey Young <geoff [at] modperlcookbook> writes:

Geoffrey> this sensationalism was just flat-out irresponsible. I don't doubt
Geoffrey> that it's true, but not giving us dev folks time to address the
Geoffrey> issue with a security release is going to cause more headaches than
Geoffrey> it otherwise would have.

Geoffrey> in the future, if anyone has a security issue with any apache
Geoffrey> product, the proper path to follow is to send a brief email to
Geoffrey> security [at] apache those guys will make sure it gets routed to
Geoffrey> the appropriate place (the mod_perl pmc and core development team in
Geoffrey> this case) and we'll work with you to get it clarified and resolved.

I get around. I read various mailing lists. I'm not a dumb guy about
Perl stuff. And by the way, I've already been yelled at. :)

But this thing about "security [at] apache" is something that I wouldn't have
thought to look for. And even if I had thought to look for it, what web site
describes it? A quick google for "security mod_perl" doesn't point it out in
the first ten hits or so, and searching literally for it links it far more
with the Apache server itself, not mod_perl, and mostly historical links.

So please don't tell me that I should have known about a secret mailing list.
That's being a bit presumptive. I thought I *was* notifying the most
appropriate list (the mod_perl developers). Perhaps your job for the *next*
breakage is to make sure your secret mailing list is a bit more public, if you
want security reports to go there instead of here.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


merlyn at stonehenge

Mar 23, 2007, 8:00 AM

Post #16 of 29 (34145 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Michael" == Michael Peters <mpeters [at] plusthree> writes:

Michael> Randal L. Schwartz wrote:
>>>>>>> "Alex" == Alex Solovey <a.solovey [at] gmail> writes:
>>
Alex> The problem is due to unescaped variable interpolation in regular
Alex> expression $uri =~ /$path_info$/ in sub namespace_from:
>>
>> I don't want to raise too many alarms, but this means that every MP1 server
>> has a denial-of-service attack against it now.

Michael> Not quite. It only affects people running PerlRun. Not insignificant,
Michael> but definitely not everyone.

No, it affects users of all script-like things, both mod_perl1 (users of
Apache::Registry, Apache::PerlRun), and mod_perl2 (users of ModPerl::PerlRun,
ModPerl::PerlRunPrefork, ModPerl::Registry, ModPerl::RegistryBB,
ModPerl::RegistryPrefork). They've all copied the same common code.

And yes, not everyone. Anyone who has actual "handlers", instead of just
using mod_perl to "speed up content delivery by migrating legacy Perl CGI",
won't be affected by this. But for the vast public out there, these
"superfast scripts" are what mod_perl is.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


geoff at modperlcookbook

Mar 23, 2007, 8:01 AM

Post #17 of 29 (34092 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

> I was able to reproduce this in mp1.
>
> for the interested, a fix has been put in place in svn for mod_perl 1.0,
> which you can grab from here:
>
> https://svn.apache.org/repos/asf/perl/modperl/branches/1.x/
>
> furthermore, as michael pointed out, the problem is isolated to
> Apache::PerlRun - Apache::Registry has had a similar fix in it since
> mid-2000 and Apache::RegistryNG is filename based, not url based.

as for mp2, nothing in the current distribution is affected -
ModPerl::Registry and ModPerl::PerlRun are both filesystem based and not
uri based. however, if you use RegistryCooker to roll your own
non-standard Registry handler and are using the non-standard uri-based
methods then you will want to examine your code.

--Geoff


geoff at modperlcookbook

Mar 23, 2007, 8:02 AM

Post #18 of 29 (34128 views)
Permalink
Re: MP1 Security issue [In reply to]

> Michael> Not quite. It only affects people running PerlRun. Not insignificant,
> Michael> but definitely not everyone.
>
> No, it affects users of all script-like things, both mod_perl1 (users of
> Apache::Registry, Apache::PerlRun), and mod_perl2 (users of ModPerl::PerlRun,
> ModPerl::PerlRunPrefork, ModPerl::Registry, ModPerl::RegistryBB,
> ModPerl::RegistryPrefork). They've all copied the same common code.

this is fud. please stop. please read my recent emails, or take the
time to examine the code in detail.

--Geoff


merlyn at stonehenge

Mar 23, 2007, 8:09 AM

Post #19 of 29 (34107 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Geoffrey" == Geoffrey Young <geoff [at] modperlcookbook> writes:

Michael> Not quite. It only affects people running PerlRun. Not insignificant,
Michael> but definitely not everyone.
>>
>> No, it affects users of all script-like things, both mod_perl1 (users of
>> Apache::Registry, Apache::PerlRun), and mod_perl2 (users of ModPerl::PerlRun,
>> ModPerl::PerlRunPrefork, ModPerl::Registry, ModPerl::RegistryBB,
>> ModPerl::RegistryPrefork). They've all copied the same common code.

Geoffrey> this is fud. please stop. please read my recent emails, or take the
Geoffrey> time to examine the code in detail.

You're correct. It has been fixed in Apache::Registry for MP1. I'm sorry I
overlooked that last night. For mp1, it affects only users of
Apache::PerlRun.

However, for mp2, since the listed modules all use ModPerl::RegistryCooker,
and the problem is in there, my list is still accurate.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


a.solovey at gmail

Mar 23, 2007, 8:09 AM

Post #20 of 29 (34125 views)
Permalink
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols) [In reply to]

On 3/23/07, Geoffrey Young <geoff [at] modperlcookbook> wrote:
> as for mp2, nothing in the current distribution is affected -
> ModPerl::Registry and ModPerl::PerlRun are both filesystem based and not
> uri based. however, if you use RegistryCooker to roll your own
> non-standard Registry handler and are using the non-standard uri-based
> methods then you will want to examine your code.

Indeed, default mp2 setup is not affected. One cannot reproduce this
problem unless something like
*ModPerl::MyRegistry::namespace_from =
\&ModPerl::RegistryCooker::namespace_from_uri;
is done.

-- Alex


a.solovey at gmail

Mar 23, 2007, 8:16 AM

Post #21 of 29 (34105 views)
Permalink
Re: MP1 Security issue [In reply to]

On 3/23/07, Randal L. Schwartz <merlyn [at] stonehenge> wrote:
> You're correct. It has been fixed in Apache::Registry for MP1. I'm sorry I
> overlooked that last night. For mp1, it affects only users of
> Apache::PerlRun.
>
> However, for mp2, since the listed modules all use ModPerl::RegistryCooker,
> and the problem is in there, my list is still accurate.

Not quite. In mp2, the problem is in RegistryCooker.pm, sub
namespace_from_uri which is not called from anywhere in default setup,
including PerlRun and Registry _unless_ default behaviour is overriden
but something like

*ModPerl::MyRegistry::namespace_from =
\&ModPerl::RegistryCooker::namespace_from_uri;

This may be present in some users code though, especially if it is
migrated to mp2 from mp1 where uri-based namespaces were default, but
I do not think it is common.

-- Alex


merlyn at stonehenge

Mar 23, 2007, 8:18 AM

Post #22 of 29 (34144 views)
Permalink
Re: MP1 Security issue [In reply to]

>>>>> "Randal" == Randal L Schwartz <merlyn [at] stonehenge> writes:

Randal> However, for mp2, since the listed modules all use
Randal> ModPerl::RegistryCooker, and the problem is in there, my list is still
Randal> accurate.

Ugh. Yes, I see it now. While ModPerl::RegistryCooker has the problem, some
of the modules (like ModPerl::Registry) don't use the affected code. So the
problem would be more accurately stated as a bug in RegistryCooker, that
affects users of *that* module's namespace_from_uri routine. And you've
determined that none of the shipped end-user modules use that? That's good,
as it will narrow the damage.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn [at] stonehenge> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


shiflett at php

Mar 25, 2007, 8:39 AM

Post #23 of 29 (34106 views)
Permalink
Re: MP1 Security issue [In reply to]

Randal L. Schwartz wrote:
> I get around. I read various mailing lists. I'm not a dumb guy about
> Perl stuff. And by the way, I've already been yelled at. :)
>
> But this thing about "security [at] apache" is something that I
> wouldn't have thought to look for.

That's a weak defense. If you're a proponent of full disclosure, say so,
but don't use ignorance as your defense in the same email where you
claim to not be a "dumb guy."

You were probably yelled at for these reasons:

1. You thought you had discovered a serious security vulnerability.

2. You first mentioned it on a public mailing list.

Even if I knew nothing about responsibly reporting security
vulnerabilities, my email to this list would have been something like this:

"I believe I've discovered a security vulnerability in mod_perl. To whom
should I address my concerns?"

In the future, I highly suggest trying security@, support@, and info@
before disclosing a vulnerability, or ask this list for guidance.

(It might be worth making sure at least one of these works with the
perl.apache.org domain, e.g., security [at] perl)

Chris

--
Chris Shiflett
http://shiflett.org/


gerard at clerkin

Mar 25, 2007, 4:19 PM

Post #24 of 29 (34097 views)
Permalink
Re: MP1 Security issue [In reply to]

----- Original Message -----
From: "Chris Shiflett" <shiflett [at] php>
To: "Randal L. Schwartz" <merlyn [at] stonehenge>
Cc: "Geoffrey Young" <geoff [at] modperlcookbook>; "Alex Solovey"
<a.solovey [at] gmail>; <modperl [at] perl>
Sent: Sunday, March 25, 2007 4:39 PM
Subject: Re: MP1 Security issue


> Randal L. Schwartz wrote:
>> I get around. I read various mailing lists. I'm not a dumb guy about
>> Perl stuff. And by the way, I've already been yelled at. :)
>>
>> But this thing about "security [at] apache" is something that I
>> wouldn't have thought to look for.
>
> That's a weak defense. If you're a proponent of full disclosure, say so,
> but don't use ignorance as your defense in the same email where you
> claim to not be a "dumb guy."
>
> You were probably yelled at for these reasons:
>
> 1. You thought you had discovered a serious security vulnerability.
>
> 2. You first mentioned it on a public mailing list.
>
> Even if I knew nothing about responsibly reporting security
> vulnerabilities, my email to this list would have been something like
> this:
>
> "I believe I've discovered a security vulnerability in mod_perl. To whom
> should I address my concerns?"
>
> In the future, I highly suggest trying security@, support@, and info@
> before disclosing a vulnerability, or ask this list for guidance.
>
> (It might be worth making sure at least one of these works with the
> perl.apache.org domain, e.g., security [at] perl)
>
> Chris
>
> --
> Chris Shiflett
> http://shiflett.org/
>

I saw my teenage daughter yesterday and finally succeeded in engaging her
attention on the subject of Perl, which lasted as long as it took me to
explain that I was subscribed to a mailing list concerning a very
specialized technology that I was only on the fringes of, but that in the
last few days there had been some rapid-fire back and fourth on some hot
security issue that was being fixed right before my eyes and that it was the
most excitement I had ever seen on a mailing list ever! Well, she was
genuinely interested from start to finish. What are the odds of the modperl
mailing list being the inspiration for a breakthrough father-daughter moment
like that? Pretty astronomical. Thanks you guys. Randal in particular. As
ever, the beating heart of Perl.

Best,
Gerard Clerkin


rlandrum at aol

Mar 26, 2007, 8:52 AM

Post #25 of 29 (34102 views)
Permalink
Re: MP1 Security issue [In reply to]

Chris Shiflett wrote:
> That's a weak defense. If you're a proponent of full disclosure, say so,
> but don't use ignorance as your defense in the same email where you
> claim to not be a "dumb guy."
>

I am a dumb guy, and I would have done the exact same thing Randal did.
I just don't think about security in terms of secrecy. It's not a
full disclosure thing at all, at least for me.

Despite the (perceived) violation of protocol, Randal's message did
light a fire under the asses of a lot of mod_perl developers, and made
known a potential security issue. I'd say that's mission accomplished.

Rob

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.