[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 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:


Please don't keep it more public than it is already until there's a good fix.


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

Search Discussions

  • Andreas J. Koenig at Sep 29, 2008 at 10:10 pm

    On Tue, 23 Sep 2008 11:40:09 +0200, "Jos I. Boumans" <kane@cpan.org> said:
    And so I have implemented it now. If it breaks too much in too short
    time, we could probably revert it, but first I'd like to see how bad
    we really do.
    I agree to this (first) solution; this will give us a good idea about
    scope of the problem.
    I have watched the indexer for a week now. The scope is more than two
    uploads per day. These uploads got an email about world writable files
    or directories. I looked up their CPAN directories right now and based
    on the findings I have added the third column.

    23-Sep SEMUELF/Data-ParseBinary-0.07.tar.gz fixed
    26-Sep GFUJI/warnings-unused-0.02.tar.gz not fixed
    26-Sep STEFFENW/DBD-PO-0.10.tar.gz not fixed
    26-Sep STEFFENW/Bundle-DBD-PO-0.10.tar.gz not fixed
    26-Sep AJDIXON/daemonise-1.0.tar.gz not fixed
    26-Sep RPHANEY/openStatisticalServices-0.015.tar.gz fixed
    26-Sep RPHANEY/openStatisticalServices-0.018.tar.gz fixed
    27-Sep COSIMO/Imager-SkinDetector-0.01.tar.gz fixed
    27-Sep FAYLAND/Pod-From-GoogleWiki-0.06.tar.gz fixed
    28-Sep DANNY/Rose-DBx-Object-Renderer-0.34.tar.gz not fixed
    28-Sep MTHURN/WWW-Search-Ebay-2.244.tar.gz fixed
    28-Sep JSTROM/Tk-TextVi-0.014.tar.gz not fixed
    28-Sep JSTROM/Tk-TextVi-0.0141.tar.gz not fixed
    29-Sep MATTN/Net-Kotonoha-0.07.tar.gz fixed
    29-Sep MTHURN/WWW-Search-Ebay-Europe-2.002.tar.gz fixed
    29-Sep ANGERSTEI/Net-Ping-Network-1.57.tar.gz not fixed
    29-Sep RPHANEY/openStatisticalServices-0.019.tar.gz fixed

    Congratulations to all authors who managed to fix their distros.
    I *you* are among them, please spread the word how you did it.

    I expect that the third column is already wrong when you read this.

    Good night,

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
postedSep 22, '08 at 8:00p
activeSep 29, '08 at 10:10p

2 users in discussion

Andreas J. Koenig: 1 post David Golden: 1 post



site design / logo © 2021 Grokbase