[32610] in Perl-Users-Digest
Perl-Users Digest, Issue: 3883 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 20 09:09:22 2013
Date: Wed, 20 Feb 2013 06:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 20 Feb 2013 Volume: 11 Number: 3883
Today's topics:
Re: Apache 2.2 & Perl CGI::Simple running under separat <vilain@NOspamcop.net>
Re: Apache 2.2 & Perl CGI::Simple running under separat <hjp-usenet2@hjp.at>
Re: Apache 2.2 & Perl CGI::Simple running under separat <hjp-usenet2@hjp.at>
Re: assignments of arrays <toralf.foerster@gmx.de>
Re: help with regexp <marc.girod@gmail.com>
Re: Is there a shorter, more elegant way to write this (Seymour J.)
Re: Is there a shorter, more elegant way to write this <ben@morrow.me.uk>
Re: Is there a shorter, more elegant way to write this <derykus@gmail.com>
regular expresion, search replace ask8y@yahoo.com
Re: regular expresion, search replace <jurgenex@hotmail.com>
Re: selenium with www::mechanize <vsakthivel.cs@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 17 Feb 2013 20:56:48 -0800
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <vilain-E95992.20564817022013@news.individual.net>
In article <hcb7v9-u711.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> > On 2013-02-17 04:33, Ben Morrow <ben@morrow.me.uk> wrote:
> > > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> > >>
> > >> 'Changing the UID' is a single system call. This is trivial.
> > >
> > > Go and read a few CVEs until you begin to get an idea of some of the
> > > ways uncontrolled execution environments can cause security problems.
> > >
> > > If there was no risk here, you might as well just go ahead and make the
> > > individual CGIs setuid. (If they're in Perl you'll have to disable the
> > > kernel's no-setid-scripts feature, but never mind, there's no risk,
> > > right?)
> >
> > ... I think this is rhetorical hyperbole and would like to get back to a
> > rational assessment of risks here:
>
> OK :).
>
> > A setuid wrapper for CGI scripts like suexec or (presumably) cgiwrap
> > does not run in an uncontrolled execution environment. It is designed to
> > be called with a strictly defined environment from a web server, and it
> > can (and usually does) take steps to ensure that this is the case.
> >
> > Furthermore, such wrappers can (and do) sanitize the environment for the
> > scripts they call.
>
> It may not be *designed to* run in an uncontrolled environment; that
> does not imply it *does not*.
>
> The piece of cgiwrap documentation I originally quoted said
>
> chmod 1755 cgiwrap
>
> cgiwrap makes a token attempt to clean a few environment variables but
> doesn't clear the environment completely (and allows the program it
> execs to inherit its environment). That means that any user can set
> PERL5LIB to something appropriate and execute arbitrary code as any
> other user with a Perl cgi accessible to cgiwrap.
>
> I realise this is just a bug in cgiwrap, but this sort of mistake is
> incredibly easy to make. Operating systems and applications keep adding
> new and exciting ways for the environment (and I don't just mean
> environ(7), I mean the whole execution environment) to affect the way a
> program behaves, so any program which starts setuid root and then tries
> to clean things up ends up playing a dangerous game of catch-up.
>
> > An external server is also not risk-free. For example, if it listens on
> > a Unix socket, who can access that socket and feed it malformed
> > requests? Even worse if it listens on a network socket.
>
> This is of course true, and very important. However backend protocols
> like this usually have to pass some sort of authentication (permissions
> on a Unix socket, SSL or Kerberos or something over the network) before
> the server even starts trying to interpret the protocol data. This makes
> it a good deal harder to mount an attack (unless you attack the
> authentication protocol, of course, but that should be a trusted
> implementation of a standard protocol).
>
> Ben
If you look at how CGIWrap works, it looks at the UID environment. If
it's not the web user, it exits. Then it checks to see if the user in
the path that the script is supposed to run under is allowed to run CGI
scripts, then exists.
There are a number checks in the CGI environment under which the script
won't run the code. It not just blithely executing the script passed to
it as the root user. It does the checks, logs the results, then
chroot() to the requested UID and directory, then runs the script as
that user. If it's a perl script, it's running under the effective UID
of requested user. Can perl call it's own version of chroot to change
into some other UID? I thought you had to be root to do that.
This seems like a tempest in a teapot.
Ultimately, the OP will have to decide if this is secure enough or if
they'll have to go with a full server running the UID they want and the
perl code running as the web server connecting to it locally through
sockets. Your call on if that's worth the time and effort to develop.
And the management headache of monitoring, debugging, etc.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Sun, 17 Feb 2013 20:47:35 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <slrnki2cun.lcu.hjp-usenet2@hrunkner.hjp.at>
On 2013-02-17 14:17, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> This kind of
>
> [...]
>
> An addition that: This was a totally useless text because "conjectures
> about you I can come up with based on posting you wrote I've read"
> rest on at least as shaky foundations as "conjectures about me you can
> come up with based on ..." and - even assuming some or all of them
> were true - neither of both matter because of their content and
> they're certainly unrelated to both the topic of the thread and the
> newsgroup.
Thanks.
(This may sound sarcastic, but I sincerely mean it)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 17 Feb 2013 21:57:50 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Apache 2.2 & Perl CGI::Simple running under separate uid's: SCGI? FCGI? PSGI?
Message-Id: <slrnki2h2e.lcu.hjp-usenet2@hrunkner.hjp.at>
On 2013-02-17 15:59, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2013-02-17 04:33, Ben Morrow <ben@morrow.me.uk> wrote:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> >>
>> >> 'Changing the UID' is a single system call. This is trivial.
>> >
>> > Go and read a few CVEs until you begin to get an idea of some of the
>> > ways uncontrolled execution environments can cause security problems.
>> >
>> > If there was no risk here, you might as well just go ahead and make the
>> > individual CGIs setuid. (If they're in Perl you'll have to disable the
>> > kernel's no-setid-scripts feature, but never mind, there's no risk,
>> > right?)
>>
>> ... I think this is rhetorical hyperbole and would like to get back to a
>> rational assessment of risks here:
>
> OK :).
>
>> A setuid wrapper for CGI scripts like suexec or (presumably) cgiwrap
>> does not run in an uncontrolled execution environment. It is designed to
>> be called with a strictly defined environment from a web server, and it
>> can (and usually does) take steps to ensure that this is the case.
>>
>> Furthermore, such wrappers can (and do) sanitize the environment for the
>> scripts they call.
>
> It may not be *designed to* run in an uncontrolled environment; that
> does not imply it *does not*.
>
> The piece of cgiwrap documentation I originally quoted said
>
> chmod 1755 cgiwrap
>
> cgiwrap makes a token attempt to clean a few environment variables but
> doesn't clear the environment completely (and allows the program it
> execs to inherit its environment). That means that any user can set
> PERL5LIB to something appropriate and execute arbitrary code as any
> other user with a Perl cgi accessible to cgiwrap.
Yup. That's why I wrote:
>> A well-designed general purpose wrapper has to do a lot more than that
>> and that extra complexity may make the wrapper itself exploitable (lack
>> of that complexity may make it easy to trick the wrapper into executing
>> an arbitrary program and/or attack the CGI program).
(and I realize now that this doesn't exactly say what I wanted it to
say).
Writing a wrapper is not trivial. Even experienced, security-conscious
programmers make stupid mistakes (I certainly have). I think this is a
good example. The programmer apparently didn't think (enough) about
restricting the execution environment. Just a few ideas what could have
been done (obviously incomplete, I'm not trying to design a secure
wrapper in a usenet posting):
* Restrict possible user transitions:
* A very simple (probably too simple in most cases) is to
chmod 1550 the wrapper and use an appropriate group
* Another possibility is to check source and target uid in the
wrapper (from a config file).
* Use a whitelist instead of a blacklist for environment variables to
pass through. Let the wrapper set additional environment variables
(like PERL5LIB in this example) only under the control of the
target user (actually: Under the control of the owner of the target
environmend - ideally that should be a different uid).
I think that writing a wrapper that is secure if it is correctly used
and configured is possible. I wouldn't trust that any random wrapper
downloaded from the web (cgiwrap doesn't seem to be distributed with
either Debian or Redhat - there may be a reason for that).
> I realise this is just a bug in cgiwrap, but this sort of mistake is
> incredibly easy to make. Operating systems and applications keep adding
> new and exciting ways for the environment (and I don't just mean
> environ(7), I mean the whole execution environment) to affect the way a
> program behaves, so any program which starts setuid root and then tries
> to clean things up ends up playing a dangerous game of catch-up.
True, although I think that following a whitelist approach
(forbid/remove everything which isn't explicitely allowed) vastly
reduces the risk that a future addition to the execution environment
adds a new exploit (obviously it is still non-zero, because my code may
not be able to remove the dangerous future feature).
>> An external server is also not risk-free. For example, if it listens on
>> a Unix socket, who can access that socket and feed it malformed
>> requests? Even worse if it listens on a network socket.
>
> This is of course true, and very important. However backend protocols
> like this usually have to pass some sort of authentication (permissions
> on a Unix socket, SSL or Kerberos or something over the network) before
> the server even starts trying to interpret the protocol data.
Unfortunately very often it's just "whoever can connect to port 8080".
However, that's at least partially the responsibility of the sysadmin.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 17 Feb 2013 18:52:46 +0100
From: =?UTF-8?B?VG9yYWxmIEbDtnJzdGVy?= <toralf.foerster@gmx.de>
Subject: Re: assignments of arrays
Message-Id: <kfr5br$ipc$1@dont-email.me>
On 02/17/2013 03:41 PM, Peter J. Holzer wrote:
>What creates the *illusion* that Perl function calls are by value is the
>convention to immediately assign parameters to local variables. So you
>would normally write foo as
...
> Here the assignments in the second line alter only the local variable
> (@p or $p2, respectively), not the parameters. But it's the assignment
> in the first line which causes the values to be copied, not the function
> call.
>
> hp
ah - now I did understood it much better
Thx for this answer
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
------------------------------
Date: Tue, 19 Feb 2013 02:11:37 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: help with regexp
Message-Id: <de381c75-9ae4-4bc3-8dda-526b04b6ab9d@e10g2000vbv.googlegroups.com>
On Feb 8, 7:46=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Oh, well, that's much easier then:
Right you are (with label types matching [\w-]+).
Thanks.
Marc
------------------------------
Date: Tue, 19 Feb 2013 07:12:45 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Is there a shorter, more elegant way to write this deep hash lookup statement
Message-Id: <51236c3d$17$fuzhry+tra$mr2ice@news.patriot.net>
In <3pl5v9-nik.ln1@anubis.morrow.me.uk>, on 02/17/2013
at 12:44 AM, Ben Morrow <ben@morrow.me.uk> said:
> $is_freight = 1 if $r && $r eq 'Freight';
By the time you get there you've dealt with the autovivification
issue. Why can't you do a simple
$is_freight = 1 if $r eq 'Freight';
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 19 Feb 2013 15:27:01 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Is there a shorter, more elegant way to write this deep hash lookup statement
Message-Id: <57icv9-n7j2.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <3pl5v9-nik.ln1@anubis.morrow.me.uk>, on 02/17/2013
> at 12:44 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> > $is_freight = 1 if $r && $r eq 'Freight';
>
> By the time you get there you've dealt with the autovivification
> issue. Why can't you do a simple
>
> $is_freight = 1 if $r eq 'Freight';
Only because of unininitialisized value warnings. I usually just turn
them off; I don't find them useful under most circumstances.
Ben
------------------------------
Date: Tue, 19 Feb 2013 11:40:02 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Is there a shorter, more elegant way to write this deep hash lookup statement
Message-Id: <42d3692c-38a8-4ca3-a49d-e6bdfdfd0e0a@googlegroups.com>
On Saturday, February 16, 2013 4:16:33 PM UTC-8, Ignoramus329 wrote:
> As I always say 'use strict; use warnings', I have this statement in my program:
>
>
>
> $is_freight = 1
>
> if $ebay_record
>
> && $ebay_record->{ShippingDetails}
>
> && $ebay_record->{ShippingDetails}->{ShippingServiceOptions}
>
> && $ebay_record->{ShippingDetails}->{ShippingServiceOptions}->{ShippingService}
>
> && $ebay_record->{ShippingDetails}->{ShippingServiceOptions}->{ShippingService} eq 'Freight';
>
>
>
> This is a correct statement and it does not give errors or warnings,
>
> however, I would like to know if I can write it in a shorter way.
>
>
>
> Any suggestions?
>
>
I haven't used it but there's a module providing a
a pragma to lexically disable autovivifying:
http://search.cpan.org/~vpit/autovivification-0.11/lib/autovivification.pm
so, untested, you could do something like this:
no autovivification;
$is_freight = 1
if ebay_record->...->{ShippingService} eq 'Freight';
and $is_freight would remain undefined unless all levels
existed.
Needs a careful read for default behavior and
CAVEATS section.
--
Charles DeRykus
------------------------------
Date: Mon, 18 Feb 2013 19:23:34 -0800 (PST)
From: ask8y@yahoo.com
Subject: regular expresion, search replace
Message-Id: <b1163ba7-076b-40da-9dd2-1d6fa6461e59@googlegroups.com>
I would search a variable in a script, and change the value. For example for following line
export NAME=FOO_1 #something
Change it to
export NAME=BAR_1 #something
I have following two rules. I expect 1) work. But 1) did not yield a match. 2) did. Can some one explain?
1) s/NAME=[a-zA-Z]\w*$/NAME=BAR_1/
2) s/NAME=[a-zA-Z]\w*/NAME=BAR_1/
Thanks in advance,
------------------------------
Date: Mon, 18 Feb 2013 20:06:24 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: regular expresion, search replace
Message-Id: <n7u5i89fuqjc9m4v5v6vrovvh6vsuiq9s3@4ax.com>
ask8y@yahoo.com wrote:
>I would search a variable in a script, and change the value. For example for following line
>
>export NAME=FOO_1 #something
>
>Change it to
>
>export NAME=BAR_1 #something
>
>I have following two rules. I expect 1) work. But 1) did not yield a match. 2) did. Can some one explain?
Lert's translate them into plain English
>1) s/NAME=[a-zA-Z]\w*$/NAME=BAR_1/
"NAME="
followed by any single letter ==> "F"
followed by any number of "word characters" ==> "OO_1"
followed by the end of the line ==> cannot match because there is more
text between the current position and the end of the line
>2) s/NAME=[a-zA-Z]\w*/NAME=BAR_1/
"NAME="
followed by any single letter ==> "F"
followed by any number of "word characters" ==> "OO_1"
No other requirements, so this obviously matches.
jue
------------------------------
Date: Mon, 18 Feb 2013 05:24:48 -0800 (PST)
From: Sakthivel Vengatachalam <vsakthivel.cs@gmail.com>
Subject: Re: selenium with www::mechanize
Message-Id: <84003b91-aff7-49a1-aa68-ab12a05ae0d6@googlegroups.com>
On Tuesday, September 12, 2006 4:22:46 PM UTC+5:30, Nospam wrote:
> Does anyone have a sample script of the use of selenium with www::mechanize
> to handle javascript buttons?
I have a similar problem, i want to execute selenium code (which is recorded from browser) from a perl script in linux.
I am looking at the best methods to handle this.
Any help appreciated!
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3883
***************************************
