2008/9/30 Andreas J. Koenig <[EMAIL PROTECTED]>:
>> On Tue, 23 Sep 2008 11:40:09 +0200, "Jos I. Boumans" <[EMAIL PROTECTED]>
>> 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
> >
> On Tue, 23 Sep 2008 11:40:09 +0200, "Jos I. Boumans" <[EMAIL PROTECTED]>
> 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; thi
On Tue, Sep 23, 2008 at 06:30:31AM +0200, Andreas J. Koenig wrote:
> 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 knew this would happen :-)
> From: Shmuel Fomberg <[EMAIL PROTECTED]>
On Sep 23, 2008, at 6:30 AM, Andreas J. Koenig wrote:
On Mon, 22 Sep 2008 22:37:55 +0200, andreas.koenig.
[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
Ovid writes:
> --- On Tue, 23/9/08, Shlomi Fish <[EMAIL PROTECTED]> wrote:
>
> > The default Mandriva umask appears to be 0002 .
>
> That surprised me
In general 0002 (aka u=rwx,g=rwx,o=rx) is the right choice of umask on a
sytem where each user has their own group -- that is, where the user
o
> 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
On Tuesday 23 September 2008, Eric Wilhelm wrote:
> # from Ovid
>
> # on Tuesday 23 September 2008 00:54:
> >Of course, even as Eric pointed out, a umask of 0002 still masks the
> > world writeable permissions, so I still don't see how you're getting
> > there and if you've configured your system
On Tuesday 23 September 2008, Ovid wrote:
> --- On Tue, 23/9/08, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> > The default Mandriva umask appears to be 0002 .
>
> That surprised me, so I googled "default mandriva umask". All the
> references I found say the default umask is 0022 ... unless ...
>
> Ma
> 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 probab
# from Ovid
# on Tuesday 23 September 2008 00:54:
>Of course, even as Eric pointed out, a umask of 0002 still masks the
> world writeable permissions, so I still don't see how you're getting
> there and if you've configured your system to give *you* a umask of
> 0022, then you still shouldn't be
--- On Tue, 23/9/08, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> The default Mandriva umask appears to be 0002 .
That surprised me, so I googled "default mandriva umask". All the references I
found say the default umask is 0022 ... unless ...
Mandriva offers a tool to control security settings.
On Tuesday 23 September 2008, Eric Wilhelm wrote:
> # from Shlomi Fish
>
> # on Monday 22 September 2008 23:55:
> >> There would be no "mechanism" because tar respects the umask by
> >> default when invoked as a non-root user. Thus, there are no
> >> world-writable files being unpacked from CPAN d
# from Shlomi Fish
# on Monday 22 September 2008 23:55:
>> There would be no "mechanism" because tar respects the umask by
>> default when invoked as a non-root user. Thus, there are no
>> world-writable files being unpacked from CPAN dists on my machine.
>>
>> Is a umask of 022 not the default s
On Tuesday 23 September 2008, Eric Wilhelm wrote:
> # from chromatic
>
> # on Monday 22 September 2008 17:37:
> >> 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?
> >
> >If I were so incl
# from David Golden
# on Monday 22 September 2008 19:56:
>On Mon, Sep 22, 2008 at 6:23 PM, Eric Wilhelm 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 (s
# from chromatic
# on Monday 22 September 2008 17:37:
>> 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?
>
>If I were so inclined and had access to your machine, I could do a lot
> of damage
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
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 try
On Monday 22 September 2008 15:23:44 Eric Wilhelm 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?
If I were so inclined and had access to your machine, I could do a lot of
damage th
* Eric Wilhelm <[EMAIL PROTECTED]> [2008-09-23 00:30]:
> 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?
Note that while running CPAN as non-root is a good idea because
it reduces the surface area o
# 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
--- On Mon, 22/9/08, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> 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.
Why not? I am completely at a loss here.
You have not addressed the fundamental issue. If a malicio
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
[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/opti
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 di
Michael Peters wrote:
> You're right. If they are a malicious user then they will find a way to
> screw you. I'm just saying that since we know about this path, let's
> eliminate it, or at least make it public and known.
I agree with that. The part I object to in the OP is the part where CPAN
Tes
On Mon, Sep 22, 2008 at 04:24:27PM +0300, Shlomi Fish wrote:
> World-writable files are a security risk and the CPAN shell should refuse to
> test the distribution if they exist. A security conscious admin won't install
> such modules if they generate world-writable files. As such, one should no
On Mon, Sep 22, 2008 at 03:40:17PM +0300, Shlomi Fish wrote:
> My suggestion for resolving this is to modify the smoking modules so, after
> the archive is unpacked (with a proper umask and arguments to tar), they will
> traverse the directory tree and look for any world-writable files. If any a
Ovid wrote:
Correct me if I've misunderstood something, but if you have a malicious user on your box, I would assume that them trying to attack a CPAN install process is the least of your worries.
You're right. If they are a malicious user then they will find a way to screw you. I'm just sayin
--- On Mon, 22/9/08, Michael Peters <[EMAIL PROTECTED]> wrote:
> Say I'm using a CPAN module that I've vetted before
> and know the code is not going to do something
> malicious. If I don't know that world writeable files
> are a problem or that this module contains
> them (because there aren't
Michael G Schwern wrote:
Some malicious user, who has somehow gotten an account on your machine, and
can see inside your .cpanplus build directory (which he shouldn't because it
should only be readable by you), might at just the right exact moment when
you're about to run THE ALREADY UNTRUSTED C
Michael G Schwern wrote:
> Shlomi Fish wrote:
>>> * What is the problem with world writeable files in a distro?
>> 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
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
Shlomi Fish wrote:
>> * What is the problem with world writeable files in a distro?
>
> 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 Ma
On Mon, Sep 22, 2008 at 9:24 AM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> Well, it does. However, hardly anyone pays any attention to CPANTS, and it's
> out there in the background, and hardly influences the general perception of
> the module.
As an aside, if the core Kwalitee metrics are sufficie
On Monday 22 September 2008, David Golden wrote:
> On Mon, Sep 22, 2008 at 8:40 AM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> > My suggestion for resolving this is to modify the smoking modules so,
> > after the archive is unpacked (with a proper umask and arguments to tar),
> > they will traverse t
On Mon, Sep 22, 2008 at 8:40 AM, Shlomi Fish <[EMAIL PROTECTED]> wrote:
> My suggestion for resolving this is to modify the smoking modules so, after
> the archive is unpacked (with a proper umask and arguments to tar), they will
> traverse the directory tree and look for any world-writable files.
Hi all.
Today, after I invoked my CPAN smoker for a while, I received another msec
(Mandriva Security) report with many world-writable files in the CPAN
distributions that were left unpacked under /home/cpan/.cpanplus . Among the
gems there are:
/home/cpan/.cpanplus/5.10.0/build/Data-Dump
38 matches
Mail list logo
