Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
> On Mon, 22 Sep 2008 22:37:55 +0200, [EMAIL PROTECTED] (Andreas J. Koenig) > said: >> (d) Something else > I lean toward PAUSE not indexing them thus pulling the plug as early > as possible. 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. -- andreas
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Mon, Sep 22, 2008 at 6:23 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > Yes. Would someone please explain to me how this issue is not already > made a mostly non-issue by having a proper umask and running CPAN as > non-root? Someone in the thread (sorry, forget who and I'm not going to search for it) gave the example that access to Makefile.PL allows arbitrary additions to the Makefile install target that a non-root user might well run with "sudo make install" -- thus a Makefile.PL compromise could be used to execute arbitrary code as root. I'm not saying it's a big threat. Risk level is the combination of likelihood of an event and the severity of the event and the first is low. Nevertheless, stopping archive extraction from creating world-readable files is probably a good idea. -- David
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Mon, Sep 22, 2008 at 5:23 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > > Would that "tracks-covering chmod" not require *ownership* of the file? According to the man page for chmod(1), yes, but on Win32 doesn't a world-writable file mean it's world-replaceable too? In any case, I was also trying to point out that if the top-level directory is expanded as world-writable, then any file therein (e.g. Build.PL) is world-replaceable. So that's just another thing to check for. -Ken
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
# from Ken Williams # on Monday 22 September 2008 13:45: >> (a) Have CPAN and CPANPLUS refuse to run 'perl *.PL' if the PL in >> question is world writable. > >That wouldn't completely solve the problem, since someone could >quickly rewrite *.PL and change it to non-writable status. Note that >a world-writable top-level directory also has the same problem (or in >some cases, only one or the other situation has the problem). Would that "tracks-covering chmod" not require *ownership* of the file? # from David Golden on Monday 22 September 2008 13:00: >>(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. Yes. Would someone please explain to me how this issue is not already made a mostly non-issue by having a proper umask and running CPAN as non-root? Thanks, Eric -- "Time flies like an arrow, but fruit flies like a banana." --Groucho Marx --- http://scratchcomputing.com ---
Re: pre-release test runs
Here are the results. Of the 2700+ dists in Eric's list, about 20 had
different results. Unfortunately, I didn't think to stop my mirror from
replicating and some of these are from a new version of Moose with
incompatible changes. In any case, nothing went from "pass" to "unknown"
which would be indicative of a Build.PL failure. And some "unknown" grades
became "pass" which is good. ("discard" means the report didn't get
generated, mostly likely due to prereq failures).
So I think that 0.30 can set sail!
-- David
0.2808_01 0.2808_05 Distribution
unknown pass ABI-1.0
discard fail Agent-TCLI-0.032
discard fail Agent-TCLI-0.02
fail pass Business-LCCN-0.12
passdiscard Carp-Clan-Share-0.012
passdiscard Catalyst-Plugin-UserAgent-0.01
passdiscard DBIx-Class-WebForm-0.02
passdiscard DBIx-Connect-FromConfig-0.04
unknown pass DBIx-DataModel-0.35
pass fail File-Stat-Moose-0.02
discard pass HTML-GenToc-3.00
discard pass khatgallery-0.03
unknown pass HTML-LinkList-0.1501
passdiscard IO-Moose-0.05
pass fail MooseX-Params-Validate-0.05
discard fail SQLite-Work-0.1001
unknown pass Text-NeatTemplate-0.08
fail pass WWW-Shorten-2.01
discard pass WWW-Shorten-Smallr-0.01
On Mon, Sep 22, 2008 at 12:30 AM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> # from David Golden
> # on Sunday 21 September 2008 19:58:
>
>>Not sure if you want to wait or not, but there was a request for
>>something a bit more structured and I wanted to let you know that it's
>>in progress.
>
> I can wait. Thank you.
>
> --Eric
> --
> But you can never get 3n from n, ever, and if you think you can, please
> email me the stock ticker of your company so I can short it.
> --Joel Spolsky
> ---
>http://scratchcomputing.com
> ---
>
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
> On Mon, 22 Sep 2008 16:00:41 -0400, "David Golden" <[EMAIL PROTECTED]> > said: > 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. What you say below. > (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. I have no experience how much it would break. > (c) Both > (d) Something else I lean toward PAUSE not indexing them thus pulling the plug as early as possible. > (e) Ignore it Even if the communitiy tends to believe this to be irrelevant, I'd say Shlomi is right. There's nothing that allows us to ignore security relevant issues. We have to be paranoid, period. > 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. Sounds good. > 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). So do I. Apart from that, I wonder if and how 'make dist' could let world readable files escape. Or were they built without 'make dist'? There was umask setting code in MakeMaker since the early days. If it isn't anymore, this should be fixed, and if you agree with me, it must be fixed RSN, given PAUSE would refuse to index distros with world readable files. -- andreas
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
On Mon, Sep 22, 2008 at 3:00 PM, David Golden <[EMAIL PROTECTED]> wrote: > 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. That wouldn't completely solve the problem, since someone could quickly rewrite *.PL and change it to non-writable status. Note that a world-writable top-level directory also has the same problem (or in some cases, only one or the other situation has the problem). -Ken
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
[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
>
Re: Is that possible?
Torsten Foertsch wrote:
> I understand the argument why MakeMaker is bad. But it has worked for
> many years now. How do you expect to build a greater user base if it's
> so complicated to do simple things in M::B?
Now, before we drift off into "MakeMaker did it better" land, let me remind
you that MakeMaker has *no* facilities to write README files for you and the
process of hooking into the build or distdir steps is so difficult and
capricious I'm not even sure how to do it, much less do it safely.
> By the way, you haven't answered my initial question. What is
> the "right" way to do that in M::B?
In Module::Build, you override ACTION_code() or ACTION_distdir() or
ACTION_distmeta() to add in whatever you want.
sub ACTION_distmeta {
my $self = shift;
$self->SUPER::ACTION_distmeta(@_);
...do your own README generation...
}
It's that simple. The docs might not always make it look that simple, which
is unfortunate and patchable, but it is that simple.
As for publicizing private methods, I'd rather see customization done like the
above then for Module::Build to try to handle all the TMTOWTDI ways authors
want to get their stuff done. That way lies insanity, maintenance hassles and
bloated, bloated code.
For example, there's a small pile of code in MakeMaker dealing with
automagically committing your files... TO RCS! There's others for making
.shar and uuencoded distributions.
That said, having the create_* parameters take a subroutine reference for
customization seems like a clever idea.
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
Re: Is that possible?
On Mon, Sep 22, 2008 at 5:09 AM, Torsten Foertsch <[EMAIL PROTECTED]> wrote: > By the way, you haven't answered my initial question. What is > the "right" way to do that in M::B? This is Perl, so TIMTOWTDI. Personally, I generally only override ACTION_ subroutines. If I need code from a private subroutine, I cut/paste it. That insulates me from future M::B changes to internal functions. I have dozens of modules that generate external .pod files from simpler markup in the .pm files. If you look at http://search.cpan.org/dist/Pod-WikiDoc/ and read the Pod::WikiDoc::Cookbook file, you'll see an example of a Build.PL that creates a subclass to do this. However, rather than do that in Build.PL itself, I now usually create the subclass in inc/Module/Build/WikiDoc.pm and just load that from Build.PL. That keeps my Build.PL uncluttered. You can see an example of how I do that in http://search.cpan.org/dist/CPAN-Mini-Devel/ -- David
Re: Is that possible?
On Mon 22 Sep 2008, Ken Williams wrote: > >> Override create_readme() I think. > > > > That was actually do_create_readme. However, in my case it was > > easier to override _main_docfile. > > But _main_docfile() is a private undocumented method, which can (and > very very likely will) change or disappear in future releases of > M::B. It's fine with me if you override it, but be aware that you're > way into unsupported-land. Well, my initial goal was quite trivial. I have a script that creates a README that is called during "make dist". My first thought was surely the author of M::B would have thought of that and implemented it so that one can pass a boolean flag as argument to create_readme or a subroutine that will be called in due course. That is how I would have done it. Then I found out somehow that I can subclass M::B and override ACTION_distdir. Michael suggested it would be better to override create_readme. Now I had to look at the code. create_readme is documented as "autogenerated accessor" whatever that means. There I found that it's not create_readme what he meant to override but do_create_readme, a function that is also not documented. How do you distinguish between private and public method? Is every undocumented method private or every method the name of which starts with an underscore? I understand the argument why MakeMaker is bad. But it has worked for many years now. How do you expect to build a greater user base if it's so complicated to do simple things in M::B? As a module author I want to concentrate on the module not on some Build.PL or Makefile.PL. That should just work. M::B may be much better than MM but it has a steep learning curve if one wants to do something just slightly off the road. By the way, you haven't answered my initial question. What is the "right" way to do that in M::B? On Fri 19 Sep 2008, Torsten Foertsch wrote: > * use gzip -9f instead of simple gzip > * create a README file during ./Build dist using the mk_README.sh > script and > * add the equivalent of a make target to create an RPM So I am with David here. If a private method is useful for the public make it a public one. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
