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