develooper Front page | perl.perl5.porters | Postings from October 2015

Re: Bug#776270: perl: CVE-2012-3878 module loading security weakness

Thread Previous | Thread Next
From:
Reini Urban
Date:
October 1, 2015 12:41
Subject:
Re: Bug#776270: perl: CVE-2012-3878 module loading security weakness
Message ID:
EA028A38-5E8C-49CB-9C4B-E40BECC9A45C@gmail.com

Reini Urban
rurban@cpan.org



> On Sep 24, 2015, at 2:38 PM, Dave Mitchell <davem@iabyn.com> wrote:
> 
> On Sat, Apr 11, 2015 at 04:08:57PM +0100, Dominic Hargreaves wrote:
>> Control: tags -1 -security
>> Control: found -1 5.20.2-3
>> 
>> On Mon, Jan 26, 2015 at 12:20:40PM +0200, Niko Tyni wrote:
>>> On Mon, Jan 26, 2015 at 09:25:33AM +0200, Niko Tyni wrote:
>>>> On Sun, Jan 25, 2015 at 11:00:27PM -0500, Michael Gilbert wrote:
>>>>> package: src:perl
>>>>> severity: normal
>>>>> tags: security
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> There was a CVE assigned to this issue a while ago with strangely
>>>>> enough no real details.  The only non-boilerplate information about it
>>>>> is at osvdb, but they don't provide any details that could be used to
>>>>> fix the issue:
>>>>> http://osvdb.org/show/osvdb/106565
>>>> 
>>>> By that description this seems to be a dup of #588017 
>>>> ("current directory in @INC potentially harmful")?
>>> 
>>> Apparently not, but rather the fact that
>>> perl -e 'require ::foo'
>>> will try to load /foo.pm .
>>> 
>>> Florian Weimer has just asked for CVE-2012-3878 to be rejected
>>> as upstream decided it's not a vulnerability.
>>> 
>>> http://www.openwall.com/lists/oss-security/2015/01/26/3
>>> http://www.nntp.perl.org/group/perl.perl5.porters/2012/07/msg189909.html
>> 
>> Indeed; unsetting the security tag accordingly. I note that this issue,
>> if it is an issue, is still unresolved (the smoke-me/require branch
>> still exists unmerged).
>> 
>> I can't see any upstream bug about this; should there be or do people
>> think it's a complete non-bug?
> 
> Well,
> 
>    bleadperl -e'require ::Foo'
> 
> still ignores @INC and tries to load /foo.pm, so I'd say it's still a bug
> that needs fixing. Some of the commits from Nicholas's smoke-me/require
> branch appear to have made it into blead, but not the one(s) which from
> their description(s), appear to fix this.
> 
> Nicholas, do you know what the status of your branch is?

Some commits are already merged in with different names, and some are not done yet.

of those commits:
$ g topo perl/smoke-me/require |head -n7

* 5d1f12f Validate the module filename created for bareword require.
* 3d83cce Treat require ::foo::bar; the same as require foo::bar;
* 5fc2378 Split the guts of pp_require into S_require_version() and S_require_file().

* 40ba2d7 Eliminate S_path_is_absolute() by inlining it into pp_require.
* a3cf161 In pp_require, call path_is_absolute() once and record the result.
* c1a26e1 Test that when directories in @INC are skipped, coderefs are still called.
* 760d9e8 Avoid reading before the buffer start when generating errors from require.

The first three need to be rebased, and the last 4 are already in.

regarding the 3 commits:

3d83cce Treat require ::foo::bar; the same as require foo::bar;

One could think of treating ::foo::bar as main::foo:bar instead, and main as implicit stash root is 
never looked up on disc. so the alternative variant would be to treat it as syntax error.

5fc2378 Split the guts of pp_require into S_require_version() and S_require_file().

Optional. require is not hot, so why not.

5d1f12f Validate the module filename created for bareword require.

The important missing part.



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About