Security issue in Pod::Perldoc #13368
Comments
From @LeontOn Thu, Oct 24, 2013 at 5:31 PM, Leon Timmermans <fawaka@gmail.com> wrote:
Actually, it turns out that any of these module would do the trick: File::Temp Leon |
From @kentfredricOn 25 October 2013 04:31, Leon Timmermans <fawaka@gmail.com> wrote:
Not to mention, it would appear to be an entirely unrequired security hole. It occurs because the code in question modifies @INC blindly to include However, this change is not required to load documentation from the current Attached is a patch which removes modification of @INC, and retains the -- |
From @kentfredricperldoc.patchdiff --git a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm
index 9cdee80..8519680 100644
--- a/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm
+++ b/cpan/Pod-Perldoc/lib/Pod/Perldoc.pm
@@ -441,6 +441,7 @@ sub init {
$self->{'pagers' } = [@Pagers] unless exists $self->{'pagers'};
$self->{'bindir' } = $Bindir unless exists $self->{'bindir'};
$self->{'pod2man'} = $Pod2man unless exists $self->{'pod2man'};
+ $self->{'search_path'} = [ ] unless exists $self->{'search_path'};
push @{ $self->{'formatter_switches'} = [] }, (
# Yeah, we could use a hashref, but maybe there's some class where options
@@ -529,7 +530,7 @@ sub process {
$self->find_good_formatter_class();
$self->formatter_sanity_check();
- $self->maybe_diddle_INC();
+ $self->maybe_extend_searchpath();
# for when we're apparently in a module or extension directory
my @found = $self->grand_search_init(\@pages);
@@ -858,7 +859,7 @@ sub grand_search_init {
# We must look both in @INC for library modules and in $bindir
# for executables, like h2xs or perldoc itself.
- push @searchdirs, ($self->{'bindir'}, @INC);
+ push @searchdirs, ($self->{'bindir'}, @{$self->{search_path}}, @INC);
unless ($self->opt_m) {
if ($self->is_vms) {
my($i,$trn);
@@ -1648,19 +1649,18 @@ sub containspod {
#..........................................................................
-sub maybe_diddle_INC {
+sub maybe_extend_searchpath {
my $self = shift;
# Does this look like a module or extension directory?
if (-f "Makefile.PL" || -f "Build.PL") {
- # Add "." and "lib" to @INC (if they exist)
- eval q{ use lib qw(. lib); 1; } or $self->die;
+ push @{$self->{search_path} }, '.','lib';
# don't add if superuser
if ($< && $> && -d "blib") { # don't be looking too hard now!
- eval q{ use blib; 1 };
+ push @{ $self->{search_path} }, 'blib';
$self->warn( $@ ) if $@ && $self->opt_D;
}
}
|
From @LeontHi all, Perldoc may load File::Temp from lib/ iff Makefile.PL or Build.PL exist in Proof: touch Makefile.PL This is a serious bug, and user-assisted exploits are trivial to write. Leon |
From @tonycozOn Thu Oct 24 13:14:38 2013, LeonT wrote:
This thread ended up as three tickets, which I've merged. Hopefully forwarding to the security list is fixed too, which this reply should test. Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Thu, Oct 24, 2013 at 5:31 PM, Leon Timmermans <fawaka@gmail.com> wrote:
This ticket and it its follow-ups never made it to the Is this issue being handled by the maintainers of the CPAN package? Discuss... -- |
From @iabynOn Wed, Oct 30, 2013 at 11:10:19AM +0000, Dave Mitchell wrote:
This apparently never made it to the list either. Resending as a test. -- |
From @LeontOn Wed, Oct 30, 2013 at 12:10 PM, Dave Mitchell <davem@iabyn.com> wrote:
I think it should be primarily handled by the maintainer, I haven't heard I do think it ought to be backported, but it probably doesn't warrant an I guess it needs a CVE (that bar seems to be set pretty low nowadays), I'm Leon |
From @mrallen1First, I am sorry I was dark - I had a problem in my email filtering rules which didn't surface Second, I just uploaded Pod-Perldoc 3.21_01 to CPAN which incorporates Kent's suggested patch. On confirmation the patch fixes the problem (it appears to on my local machine), I will release 3.21. Thank you for your help in resolving this problem. Mark Allen On Wednesday, November 6, 2013 7:15 AM, Leon Timmermans <fawaka@gmail.com> wrote: On Wed, Oct 30, 2013 at 12:10 PM, Dave Mitchell <davem@iabyn.com> wrote: This ticket and it its follow-ups never made it to the
I think it should be primarily handled by the maintainer, I haven't heard from him at all though. I do think it ought to be backported, but it probably doesn't warrant an immediate maintenance security release. I guess it needs a CVE (that bar seems to be set pretty low nowadays), I'm going to look into that. Leon |
From @iabynOn Tue, Nov 19, 2013 at 09:21:37AM -0800, Mark Allen wrote:
I can confirm it fixes the issue. -- |
From @mrallen1I will prepare a CPAN release in a few days including this patch and a couple others that have come in. Thanks. On Monday, December 30, 2013 5:45 AM, Dave Mitchell <davem@iabyn.com> wrote: On Tue, Nov 19, 2013 at 09:21:37AM -0800, Mark Allen wrote:
I can confirm it fixes the issue. -- |
From @mrallen1Just to close the loop on this - I released Pod-Perldoc 3.21 to CPAN a couple days ago. This is a version I propose Thanks. On Friday, January 3, 2014 10:15 AM, Mark Allen <mrallen1@yahoo.com> wrote: I will prepare a CPAN release in a few days including this patch and a couple others that have come in. Thanks. On Monday, December 30, 2013 5:45 AM, Dave Mitchell <davem@iabyn.com> wrote: On Tue, Nov 19, 2013 at 09:21:37AM -0800, Mark Allen wrote:
I can confirm it fixes the issue. -- |
From @iabynOn Wed, Jan 08, 2014 at 09:55:36AM -0800, Mark Allen wrote:
This version was pulled into blead on monday, so the loop is closed, -- |
From @kentfredricOn 9 January 2014 07:17, Dave Mitchell <davem@iabyn.com> wrote:
Are security fixes usually candidates for stable releases? ie: should this I'm just wondering when we're supposed to advise security people of a -- |
From @LeontOn Mon Jan 13 16:31:11 2014, kentfredric@gmail.com wrote:
And the crickets had the field for a year. It seems this got reported for a second time as #123647. I suspect a CVE is still warranted. Should I do that? The whole process is rather fuzzy to me. |
From @tonycozOn Wed, Jan 28, 2015 at 10:49:54AM -0800, Leon Timmermans via RT wrote:
If the issue isn't public yet, mail any of: - secalert@redhat.com - distros@vs.openwall.org (limited access mailing list, 2 week embargo process) - cve-assign@mitre.org I've used the last before, but that was before the first two were active. If the issue is public: - oss-security@lists.openwall.com (mailing list) See https://github.com/RedHatProductSecurity/CVE-HOWTO for details of what Tony |
From @kentfredricOn 29 January 2015 at 11:46, Tony Cook via RT <
And either do the same here Or once you have draft text for advisory notice let me know and I'll -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @iabynOn Thu, Jan 29, 2015 at 12:44:30PM +1300, Kent Fredric wrote:
This security ticket is still open and un-replied-to for 2+ years. The fix -- |
From @xsawyerxMakes sense. On Thu, Feb 2, 2017 at 1:29 PM, Dave Mitchell <davem@iabyn.com> wrote:
|
|
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#120357 (status was 'resolved')
Searchable as RT120357$
The text was updated successfully, but these errors were encountered: