You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Randal L. Schwartz" <me...@stonehenge.com> on 2007/03/23 04:20:48 UTC
MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
>>>>> "Alex" == Alex Solovey <a....@gmail.com> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
Posted by Alex Solovey <a....@gmail.com>.
On 3/23/07, Geoffrey Young <ge...@modperlcookbook.org> 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
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
Posted by Kjetil Kjernsmo <kj...@opera.com>.
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
Re: MP1 Security issue
Posted by Alex Solovey <a....@gmail.com>.
On 3/23/07, Randal L. Schwartz <me...@stonehenge.com> 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
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Randal" == Randal L Schwartz <me...@stonehenge.com> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Geoffrey" == Geoffrey Young <ge...@modperlcookbook.org> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Michael" == Michael Peters <mp...@plusthree.com> writes:
Michael> Randal L. Schwartz wrote:
>>>>>>> "Alex" == Alex Solovey <a....@gmail.com> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Michael Peters wrote:
> Randal L. Schwartz wrote:
>
>>>>>>>"Alex" == Alex Solovey <a....@gmail.com> 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
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Michael Peters <mp...@plusthree.com>.
Randal L. Schwartz wrote:
>>>>>> "Alex" == Alex Solovey <a....@gmail.com> 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
Re: MP1 Security issue
Posted by geronimo <ge...@clerkin.co.uk>.
----- Original Message -----
From: "Chris Shiflett" <sh...@php.net>
To: "Randal L. Schwartz" <me...@stonehenge.com>
Cc: "Geoffrey Young" <ge...@modperlcookbook.org>; "Alex Solovey"
<a....@gmail.com>; <mo...@perl.apache.org>
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@apache.org" 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@perl.apache.org.)
>
> 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
Re: MP1 Security issue
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Randal L. Schwartz wrote:
>>>>>>"Jonathan" == Jonathan Vanasco <jv...@2xlp.com> writes:
>
>
> Jonathan> Randal didn't raise an report an new security threat -- he re-
> Jonathan> categorized an active bug discussion as a security threat.
>
> Just for the record, I'm now clear (thanks to new information) that I handled
> this poorly, and will handle it differently the next time.
in all fairness, I do appreciate you paying attention and speaking up.
if the security implications had not been brought up there's always the
possibility that Evil Guy would have seen the exploit, that the
developers wouldn't have patched things fast enough, and that much chaos
would have been the result.
I just wish we hadn't given the bad guys such a clear roadmap to the
chaos :)
> I apologize for
> any stress or grief, or even break-in, that may have resulted from my actions.
thankfully, I don't think the risk is as great as anybody thought at
first. but just to put things in perspective, the top two mod_perl
shops transact _billions_ of dollars through mod_perl servers, so a more
serious security threat... well, I think that could have had an
incredible impact on all of us who work in open source, not just our
little corner of it.
>
> Jonathan> People have commented "This isn't the proper way to report a
> Jonathan> security threat." Well, right now ModPerl doesn't have a published
> Jonathan> protocol for dealing with security threats.
>
> I *do* strongly support this statement though. Even after having been LARTed,
> googling for "security mod_perl" didn't reveal anything in the first ten hits
> that would be remotely useful here.
>
> This *can* be fixed for the future. (Nudge to the developers.)
I had actually started patching the documentation before jonathan said
anything, so expect something soonish. still, short of an official
channel to report security issues, it's always probably safe to say
"hey, I think this poses a security issue. what's the best way to
handle things?" no matter which mailing list you're on :)
--Geoff
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Jonathan" == Jonathan Vanasco <jv...@2xlp.com> writes:
Jonathan> Randal didn't raise an report an new security threat -- he re-
Jonathan> categorized an active bug discussion as a security threat.
Just for the record, I'm now clear (thanks to new information) that I handled
this poorly, and will handle it differently the next time. I apologize for
any stress or grief, or even break-in, that may have resulted from my actions.
Jonathan> People have commented "This isn't the proper way to report a
Jonathan> security threat." Well, right now ModPerl doesn't have a published
Jonathan> protocol for dealing with security threats.
I *do* strongly support this statement though. Even after having been LARTed,
googling for "security mod_perl" didn't reveal anything in the first ten hits
that would be remotely useful here.
This *can* be fixed for the future. (Nudge to the developers.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <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!
Re: MP1 Security issue
Posted by Jonathan Vanasco <jv...@2xlp.com>.
On Mar 26, 2007, at 12:25 PM, Perrin Harkins wrote:
> That's easy to say in this specific case, since the actual threat is
> so tiny that it didn't make much difference. You guys probably
> wouldn't think it was such a good idea if it had been a more serious
> exploit and someone had used it to compromise your servers before a
> fix was available.
Keep in mind -- in this specific case the discussion was such ( the
first 3 emails ):
From: a.solovey@gmail.com
Date: March 22, 2007 11:57:41 AM EDT
Subject: [mp1] PerlRun fails if path_info contains special symbols
From: pharkins@gmail.com
Date: March 22, 2007 11:04:37 PM EDT
Subject: Re: [mp1] PerlRun fails if path_info contains special symbols
From: merlyn@stonehenge.com
Date: March 22, 2007 11:20:48 PM EDT
Subject: MP1 Security issue (was Re: [mp1] PerlRun fails if
path_info contains special symbols)
It's not the case that Randal found an exploit and said "Hey
developers ! there's a security breach I found" -- which a lot of
these postings insinuate.
Alex found the issue, and reported it as a bug.
Perrin asked, 'do you think you can patch it?'
Randal replied "wait - this isn't a bug, its a security issue. this
needs faster attention"
Randal didn't raise an report an new security threat -- he re-
categorized an active bug discussion as a security threat.
People have commented "This isn't the proper way to report a security
threat." Well, right now ModPerl doesn't have a published protocol
for dealing with security threats.
In fact, there's no security policy *at all* on the mod perl
website. There also aren't any listings or contact addresses for
project maintainers -- the closest thing available is a current +
historical intermingled list of people who have contributed. All the
"Repot a bug" information make it very clear that everything should
be posted to the mailing list for discussion, and there is no mention
of "if you believe this could have security implications, please do
not post it publicly".
That said, I think the suggestion to email "info , support ,
security" as a first step is ridiculous -- they're not addresses
universally used across projects , and shouldn't be expected to work
as such. There's about as much rationale to crossing your fingers
and hoping someone sees those messages as writing to
"SantaClausPleaseFixMyBugsForChrismas@perl.apache.org" .
I suggest the core developers devise some protocol + notification
scheme / contact addresses they feel comfortable with, and publish it
on these pages:
Reporting bugs
http://perl.apache.org/bugs/index.html
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
Getting Help
http://perl.apache.org/help/index.html
It could be as simple as:
"If you think you have found a security threat, please email _______
and give us 7 days to respond and work out a disclosure scheme with
you."
We're all fortunate that this discussion happened around a trivial
threat in a largely insignificant/unused feature -- but there should
be a system or directions in place for the unlikely event that
someone else finds a serious bug and follows every piece of
information on the website that says "just post it to the mailing list".
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
Re: MP1 Security issue
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/26/07, Robert Landrum <rl...@aol.net> wrote:
> 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.
That's easy to say in this specific case, since the actual threat is
so tiny that it didn't make much difference. You guys probably
wouldn't think it was such a good idea if it had been a more serious
exploit and someone had used it to compromise your servers before a
fix was available.
- Perrin
Re: MP1 Security issue
Posted by Robert Landrum <rl...@aol.net>.
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
Re: MP1 Security issue
Posted by Chris Shiflett <sh...@php.net>.
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@apache.org" 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@perl.apache.org.)
Chris
--
Chris Shiflett
http://shiflett.org/
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Geoffrey" == Geoffrey Young <ge...@modperlcookbook.org> 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@apache.org. 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@apache.org" 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Randal L. Schwartz wrote:
>>>>>>"Randal" == Randal L Schwartz <me...@stonehenge.com> writes:
>
>
>>>>>>"Alex" == Alex Solovey <a....@gmail.com> 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@apache.org. 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
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Fred" == Fred Moyer <fr...@redhotpenguin.com> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Philip M. Gollucci wrote:
> Perrin Harkins wrote:
>> On 3/22/07, Andy Armstrong <an...@hexten.net> 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? :)
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Perrin Harkins wrote:
> On 3/22/07, Andy Armstrong <an...@hexten.net> 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@p6m7g8.com) 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.
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
Posted by Perrin Harkins <ph...@gmail.com>.
On 3/22/07, Andy Armstrong <an...@hexten.net> 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
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
Posted by Andy Armstrong <an...@hexten.net>.
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@pooky ~/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
Re: MP1 Security issue
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Fred" == Fred Moyer <fr...@redhotpenguin.com> 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
<me...@stonehenge.com> <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!
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info
contains special symbols)
Posted by Fred Moyer <fr...@redhotpenguin.com>.
Randal L. Schwartz wrote:
>>>>>> "Randal" == Randal L Schwartz <me...@stonehenge.com> writes:
>
>>>>>> "Alex" == Alex Solovey <a....@gmail.com> 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@pooky ~/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};
>
Re: MP1 Security issue (was Re: [mp1] PerlRun fails if path_info contains special symbols)
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Randal" == Randal L Schwartz <me...@stonehenge.com> writes:
>>>>> "Alex" == Alex Solovey <a....@gmail.com> 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
<me...@stonehenge.com> <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!