[Copying Andreas, Jos, Schwern and the Module::Build list]
Well, I'm not sure that escalating to Securiteam at this point was
necessary given the low overall risk of the threat, but let's set that
aside and find some agreement on closing the hole. Here are my
thoughts on some of the problems/options:
Problem 1: race condition between unarchiving and execution if
Makefile.PL or Build.PL is world writable (ditto test files as well)
(a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in
question is world writable.
(b) Have CPAN and CPANPLUS not preserve mode permissions even for
root; that's "--no-same-permissions") for tar or $Archive::Tar::CHMOD
= 0 for Archive::Tar. I presume there's a comparable thing for zip
archives. That leaves it up to the users umask setting.
(c) Both
(d) Something else
(e) Ignore it
Personally, I lean towards (b) as that seems relatively sane and
minimally disruptive.
For (a), I worry about edge cases for operating systems that don't
have unixish permissions. E.g. on Win32, an administrative always has
write-permission, even on files set to be read-only. A less
aggressive option than (a) is just to issue warnings about
world-writable files.
For completeness, there's a possible problem 2: An insecure umask can
lead to world-writable files, including not only the unarchived files,
but also Makefile (or Build) and some files in blib [1]:
(a) Ignore this -- insecure umask isn't Perl's problem to worry about
(b) Set an appropriate umask before generating Makefile, Build or
copying things to blib.
For this one, I lean towards (a).
-- David
[1] EU::MM and M::B have a race condition when then copy files to blib
before calling chmod. Also, shebang fixes seem to undo the chmod and
leave script files with the default permissions from the umask
On Mon, Sep 22, 2008 at 1:37 PM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> Note to "Securiteam": there's a link to the possible security problem report
> at the bottom.
>
> On Monday 22 September 2008, chromatic wrote:
>> On Monday 22 September 2008 08:41:31 Michael G Schwern wrote:
>> > Shlomi Fish wrote:
>> > > Let's suppose Makefile.PL is world-writable. While the distro is being
>> > > unpacked, a malicious user writes something like:
>> > >
>> > > {{{
>> > > system('rm -fr $HOME');
>> > > }}}
>> > >
>> > > to it, and after you come to the "perl Makefile.PL" stage - you lose
>> > > your home-directory. ;-)
>> >
>> > Run that by me again how the Makefile.PL being world-writable has any
>> > effect on that? If a Makefile.PL does an "rm -rf $HOME" and you run it,
>> > it doesn't matter what permission flags are on the file. Your home
>> > directory is gone.
>>
>> There's a race condition attack between the time the CPAN client *writes*
>> the world-writeable file and the time the CPAN client *executes* the
>> world-writeable file. During that time, anyone on the system can write
>> anything to the file, replacing its legitimate and safe contents with
>> malicious contents.
>>
>> That's completely orthogonal to the problem of the Build.PL/Makefile.PL
>> containing malicious code.
>>
>
> Right. I decided that it was a major problem with how CPANPLUS handles such
> situations (regardless to whether we are smoking or just installing) and
> reported it here:
>
> http://rt.cpan.org/Ticket/Display.html?id=39516
>
> Please don't keep it more public than it is already until there's a good fix.
>
> Regards,
>
> Shlomi Fish
>
> -----------------------------------------------------------------
> Shlomi Fish http://www.shlomifish.org/
> My Aphorisms - http://www.shlomifish.org/humour.html
>
> Shlomi, so what are you working on? Working on a new wiki about unit testing
> fortunes in freecell? -- Ran Eilam
>
