[16145] in Perl-Users-Digest
Perl-Users Digest, Issue: 3557 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 15:52:45 2000
Date: Mon, 10 Jul 2000 12:52:29 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <963258749-v9-i3557@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 10 Jul 2000 Volume: 9 Number: 3557
Today's topics:
CPAN security (Re: PERL scripts (again)) (Nick Kew)
Re: CPAN security (Re: PERL scripts (again)) (Tim Haynes)
Re: CPAN security (Re: PERL scripts (again)) (Abigail)
Re: CPAN security (Re: PERL scripts (again)) <elaine@chaos.wustl.edu>
Re: CPAN security (Re: PERL scripts (again)) (Nick Kew)
Re: CPAN security (Re: PERL scripts (again)) (Nick Kew)
creating files via browser <peter_matulis@hotmail.com>
Re: creating files via browser (Tad McClellan)
Re: creating files via browser <news@fido.workone.com>
Re: creating files via browser (Bart Lateur)
Re: creating files via browser <news@fido.workone.com>
Re: creating files via browser (Bart Lateur)
Crossing server bounderies <lorenzo.gordon@lshtm.ac.uk>
Re: Crossing server bounderies <care227@attglobal.net>
Re: Crossing server bounderies <lorenzo.gordon@lshtm.ac.uk>
Ctrl Chars in $_ <vancef@caligormed.com>
Re: Ctrl Chars in $_ (Villy Kruse)
Re: Ctrl Chars in $_ <gellyfish@gellyfish.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 8 Jul 2000 10:32:25 +0000
From: nick@webthing.com (Nick Kew)
Subject: CPAN security (Re: PERL scripts (again))
Message-Id: <pvv6k8.m9.ln@sleipnir.webthing.com>
[ crossposted from uk.comp.os.linux ]
In article <Pine.LNX.4.10.10007072301530.26342-100000@www.uklinux.net>,
Jason Clifford <jason.clifford@uklinux.net> writes:
> On Fri, 7 Jul 2000, giles wrote:
> > [ want a webpage counter ]
> perl -MCPAN -e shell
[ aside: I'd have thought it a job for a simple script rather than a module,
and would recommend a visit to Randals's webtechniques ]
I have a problem with CPAN on any *x distro I've encountered.
More precisely, I have a problem with running a root process that installs
software over the 'net, without my inspecting it on the way. There are
any number of possible attacks - compromising a CPAN site, or compromising
DNS and substituting a fake CPAN site - that could trash the system.
MD5 checksums don't protect against that, because an attacker could
substitute their own (a PGP/GPG-style signature from a trusted CPAN
librarian could fix this).
My own fix for this is to install the whole of Perl as a non-privileged
user. This is painless, and works fine, and limits the potential damage
any would-be CPAN-trojan can do. I'd suggest Jason and other distro-
packagers should make this standard.
I'd also like to see Perl itself refuse to run as root without explicitly
forcing it (via some commandline flag). But that's another story.
--
Nick Kew
Peninsular Penguin - Linux in the SouthWest
http://www.pen-pen.co.uk/
------------------------------
Date: 08 Jul 2000 21:29:54 +0100
From: piglet@glutinous.custard.org (Tim Haynes)
Subject: Re: CPAN security (Re: PERL scripts (again))
Message-Id: <86puooe56l.fsf@straw.pigsty.org.uk>
nick@webthing.com (Nick Kew) writes:
> I have a problem with CPAN on any *x distro I've encountered.
>
> More precisely, I have a problem with running a root process that
> installs software over the 'net, without my inspecting it on the way.
> There are any number of possible attacks - compromising a CPAN site, or
> compromising DNS and substituting a fake CPAN site - that could trash the
> system. MD5 checksums don't protect against that, because an attacker
> could substitute their own (a PGP/GPG-style signature from a trusted CPAN
> librarian could fix this).
This is true. I've occasionally wondered how long it would take before
someone realised the MD5sums weren't the same as the original source, for
any/all the things one downloads & installs. A bit like the "open-source is
more secure because everyone audits it before installing it" nonsense; we
all know we're lazy twerps (typically)...
> My own fix for this is to install the whole of Perl as a non-privileged
> user. This is painless, and works fine, and limits the potential damage
> any would-be CPAN-trojan can do. I'd suggest Jason and other distro-
> packagers should make this standard.
>
> I'd also like to see Perl itself refuse to run as root without explicitly
> forcing it (via some commandline flag). But that's another story.
Good ideas. Creating a perl user? suidperl? All sorts of fun things could
be done there.
FWIW: I used to use Jason's method above for installing modules from CPAN,
but then I got qualms about running the *whole* thing as root in order to
automate the installation. And by the time I'd worked out how to do it in
two phases, I might as well've done it by hand - so that's what I do! (If I
have to, that is. Debian has a few perl CPAN modules as packages as it is,
eg DBI/DBD, Pg interaction...)
~Tim
--
| Geek Code: GCS dpu s-:+ a-- C++++ UBLUAVHSC++++ P+++ L++ E--- W+++(--) N++
| w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y-
| The sun is melting over the hills, | http://piglet.is.dreaming.org/
| All our roads are waiting / To be revealed | piglet@glutinous.custard.org
------------------------------
Date: 08 Jul 2000 17:05:18 EDT
From: abigail@delanet.com (Abigail)
Subject: Re: CPAN security (Re: PERL scripts (again))
Message-Id: <slrn8mf6u0.t4j.abigail@alexandra.delanet.com>
Tim Haynes (piglet@glutinous.custard.org) wrote on MMDIII September
MCMXCIII in <URL:news:86puooe56l.fsf@straw.pigsty.org.uk>:
'' nick@webthing.com (Nick Kew) writes:
''
'' > My own fix for this is to install the whole of Perl as a non-privileged
'' > user. This is painless, and works fine, and limits the potential damage
'' > any would-be CPAN-trojan can do. I'd suggest Jason and other distro-
'' > packagers should make this standard.
Yes, but CPAN doesn't generally install in the main distribution; things
get typically installed in .../site_perl. You could just make site_perl
owned by some other user, and install modules from CPAN as that other user.
'' FWIW: I used to use Jason's method above for installing modules from CPAN,
'' but then I got qualms about running the *whole* thing as root in order to
'' automate the installation. And by the time I'd worked out how to do it in
'' two phases, I might as well've done it by hand - so that's what I do! (If I
'' have to, that is. Debian has a few perl CPAN modules as packages as it is,
'' eg DBI/DBD, Pg interaction...)
Yet another way is to build everything automatically as some non-root
user, and when it's all build, inspect and run 'make install' by hand.
Of course, the entire point of CPAN.pm is to do everything automatically.
If you don't want to fetch/build/install automatically, the simplest
thing to do is to not do it. The existance of CPAN.pm certainly does
not prevent you from doing it the good old way of ftp, tar -x, perl
Makefile.PL, make, make test, make install.
I never install perl as root. I tend to use a user "camel" for that.
Abigail
--
perl -we 'print split /(?=(.*))/s => "Just another Perl Hacker\n";'
------------------------------
Date: Sat, 08 Jul 2000 23:57:41 GMT
From: Elaine -HFB- Ashton <elaine@chaos.wustl.edu>
Subject: Re: CPAN security (Re: PERL scripts (again))
Message-Id: <3967BFF5.3F6243BF@chaos.wustl.edu>
Tim Haynes wrote:
> > system. MD5 checksums don't protect against that, because an attacker
> > could substitute their own (a PGP/GPG-style signature from a trusted CPAN
> > librarian could fix this).
>
> This is true. I've occasionally wondered how long it would take before
> someone realised the MD5sums weren't the same as the original source, for
> any/all the things one downloads & installs. A bit like the "open-source is
> more secure because everyone audits it before installing it" nonsense; we
> all know we're lazy twerps (typically)...
Noone can guarantee with 100% certainty that anything you download from
the net
is untainted and perfectly secure. If the security of the main archive
is
compromised, bad code could spread like a virus. The checksums help keep
honest
people honest like the locks on your car doors. Making that more secure
though
might not be a terribly bad idea. Hmmm. Each module author signing their modules
and making a public key server available for authors keys might be an
idea to
start with.
Also, as far as installing these modules, etc. You can make a user
called 'pbin'
or somesuch, install perl and chown it to this user. You can thereafter
sudo to
this user and install all modules as pbin either by hand or via CPAN.pm.
Root
isn't really required for 99% of user operations.
e.
------------------------------
Date: Sat, 8 Jul 2000 21:49:59 +0000
From: nick@webthing.com (Nick Kew)
Subject: Re: CPAN security (Re: PERL scripts (again))
Message-Id: <7m78k8.e31.ln@sleipnir.webthing.com>
In article <86puooe56l.fsf@straw.pigsty.org.uk>,
piglet@glutinous.custard.org (Tim Haynes) writes:
>
> A bit like the "open-source is
> more secure because everyone audits it before installing it" nonsense; we
> all know we're lazy twerps (typically)...
We have give-and-take there. I scrutinise some programs with more care
than others, and if I encounter something I'm unhappy about I'll either
work it out in full or post " ... what's this about ... " on some
appropriate newsgroup. And the key to open-source security is that
I know thousands of others will do the same.
A corollary to this is that a hugely popular program, such as Perl,
will get more scrutiny than some specialized application, and can
therefore be somewhat more trusted. But that still doesn't mean giving
it more privileges than it needs.
Of course, a similar argument applies to many other packages.
The extreme case is qmail, with its seven different UIDs and two GIDs!
--
Nick Kew
Peninsular Penguin - Linux in the SouthWest.
http://www.pen-pen.co.uk/>
------------------------------
Date: Sat, 8 Jul 2000 21:39:39 +0000
From: nick@webthing.com (Nick Kew)
Subject: Re: CPAN security (Re: PERL scripts (again))
Message-Id: <r278k8.e31.ln@sleipnir.webthing.com>
In article <slrn8mf6u0.t4j.abigail@alexandra.delanet.com>,
abigail@delanet.com (Abigail) writes:
>
> You could just make site_perl
> owned by some other user, and install modules from CPAN as that other user.
Indeed you could. Perhaps the paranoid approach would be to define two
non-privileged users for perl-core and perl-extra.
> Yet another way is to build everything automatically as some non-root
> user, and when it's all build, inspect and run 'make install' by hand.
I do that for _every_ package - excepting only those that come from an
installation CD or that I wrote myself. Where possible, I also install
non-root - and that includes my own software too ;-)
>
> I never install perl as root. I tend to use a user "camel" for that.
So we have agreement on installing non-root.
My quibble is that this _isn't_ the installation default with any *x
I've encountered. Maybe the likes of bastille-linux or openbsd do this?
--
Nick Kew
Site Valet - the essential service for anyone with a Website.
Now available at <URL:http://valet.webthing.com/>
------------------------------
Date: Mon, 10 Jul 2000 03:47:46 GMT
From: Lord Petrosky <peter_matulis@hotmail.com>
Subject: creating files via browser
Message-Id: <8kbh0u$sf0$1@nnrp1.deja.com>
Is it possible for a user/browser (web server user 'nobody') to create
files on the server? If so, how? I can do so using a part of my script
on the command line (as root) but not from the browser. Not enough
permissions, ok, but is there any way? No, not by recompiling Apache
and using special switch to allow web user to be root.
Take care,
Peter
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 10 Jul 2000 01:48:02 -0400
From: tadmc@metronet.com (Tad McClellan)
Subject: Re: creating files via browser
Message-Id: <slrn8miosi.so6.tadmc@magna.metronet.com>
On Mon, 10 Jul 2000 03:47:46 GMT, Lord Petrosky <peter_matulis@hotmail.com> wrote:
>Is it possible for a user/browser (web server user 'nobody') to create
>files on the server?
user/browser doesn't make any sense.
Only the web server can create files on the web server.
But the web server can be convinced to run programs on
your behalf. I think such programs are called "CGI programs".
There is a newsgroup for CGI questions:
comp.infosystems.www.authoring.cgi
>If so, how?
perldoc -f open
>I can do so using a part of my script
>on the command line
Always a clever first step.
>(as root)
Please stop. You're scaring me.
>but not from the browser. Not enough
>permissions, ok, but is there any way?
Errr, relax the permissions required?
If you have root, then you can change the permissions so
that you do have "enough" permission to create files.
>No, not by recompiling Apache
>and using special switch to allow web user to be root.
Heavens nooooooo!
--
Tad McClellan SGML Consulting
tadmc@metronet.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 10 Jul 2000 10:37:27 +0200
From: Kirill Miazine <news@fido.workone.com>
Subject: Re: creating files via browser
Message-Id: <Pine.LNX.4.21.0007101033590.2142-100000@escamillo.uio.no>
Hi,
There are several easy ways to go:
1) Make the script setuid/setgid (read man setuid)
2) Make one directory worl-writable and let the cgi-scrip write
there. It's however a VERY,VERY,VERY bad idea to do so.
User root??? No way!
On Mon, 10 Jul 2000, Lord Petrosky wrote:
# Is it possible for a user/browser (web server user 'nobody') to create
# files on the server? If so, how? I can do so using a part of my script
# on the command line (as root) but not from the browser. Not enough
# permissions, ok, but is there any way? No, not by recompiling Apache
# and using special switch to allow web user to be root.
#
# Take care,
#
# Peter
#
#
# Sent via Deja.com http://www.deja.com/
# Before you buy.
#
------------------------------
Date: Mon, 10 Jul 2000 11:28:09 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: creating files via browser
Message-Id: <396ab2eb.15521145@news.skynet.be>
Lord Petrosky wrote:
>Is it possible for a user/browser (web server user 'nobody') to create
>files on the server? If so, how? I can do so using a part of my script
>on the command line (as root) but not from the browser. Not enough
>permissions, ok, but is there any way?
Simple. Just set up a directory with appropriate permissions to create
files for any user, i.e. mask 0xx7. You can then create files in that
directory.
--
Bart.
------------------------------
Date: Mon, 10 Jul 2000 14:32:49 +0200
From: Kirill Miazine <news@fido.workone.com>
Subject: Re: creating files via browser
Message-Id: <Pine.LNX.4.21.0007101431170.1913-100000@gilda.uio.no>
On Mon, 10 Jul 2000, Bart Lateur wrote:
# Simple. Just set up a directory with appropriate permissions to create
# files for any user, i.e. mask 0xx7. You can then create files in that
# directory.
And everyone else will also be able to delete your files and to edit them
and to do other things they shouldn't do :)
Use setuid scripts, it works
#
# --
# Bart.
#
------------------------------
Date: Mon, 10 Jul 2000 13:05:17 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: creating files via browser
Message-Id: <3969c9e5.4902715@news.skynet.be>
Kirill Miazine wrote:
>And everyone else will also be able to delete your files and to edit them
>and to do other things they shouldn't do :)
Only if they have access to your server.
--
Bart.
------------------------------
Date: Mon, 10 Jul 2000 10:55:08 GMT
From: Lorenzo Gordon <lorenzo.gordon@lshtm.ac.uk>
Subject: Crossing server bounderies
Message-Id: <8kca28$ddd$1@nnrp1.deja.com>
Hi,
I have the following situation and would massively appreciate any
salvation offered:
I have written a database using Ms Access 97.
I am in the process of setting up a web-site, with which I am trying to
add some'search' facility, using information stored on the Access
Database.
I have written a Perl script which, using the DBI.pm module, can go into
the database and successfully pull out what I need.
But: I work for an acadmic institution which runs the network using an
Apache Server on a Unix Solaris machine.
The web administrator and I are banging our heads against the brick wall
that is the problem of trying to get a Unix machine to read an Access
database. We are unaware of and can find no evidnce of any ODBC-type
driver that might allow the server to recognise the database.
The instution does not have access to any ASP/IIS style technology, nor
does it run any Unix-based database (Access is working off NT), so our
options are extremely limited.
Any ideas?
Any advice/pointers/ODBC-connections offered would help us out.
TIA,
Lorenzo.
--
Lorenzo Gordon
Software Applications Developer
London School Of Hygiene & Tropical Medicine
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 10 Jul 2000 09:44:04 -0400
From: Drew Simonis <care227@attglobal.net>
Subject: Re: Crossing server bounderies
Message-Id: <3969D324.61FEDC8A@attglobal.net>
Lorenzo Gordon wrote:
>
> Any ideas?
>
> Any advice/pointers/ODBC-connections offered would help us out.
Took me all of 3 seconds at CPAN to find:
http://search.cpan.org/search?mode=module&query=ODBC
------------------------------
Date: Mon, 10 Jul 2000 14:58:03 GMT
From: Lorenzo Gordon <lorenzo.gordon@lshtm.ac.uk>
Subject: Re: Crossing server bounderies
Message-Id: <8kco9i$nha$1@nnrp1.deja.com>
Thanks for the tip, I'll check it out.
In article <3969D324.61FEDC8A@attglobal.net>,
Drew Simonis <care227@attglobal.net> wrote:
> Lorenzo Gordon wrote:
> >
> > Any ideas?
> >
> > Any advice/pointers/ODBC-connections offered would help us out.
>
> Took me all of 3 seconds at CPAN to find:
>
> http://search.cpan.org/search?mode=module&query=ODBC
>
--
Lorenzo Gordon
Software Applications Developer
London School Of Hygiene & Tropical Medicine
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 7 Jul 2000 08:58:56 -0400
From: "Vance F" <vancef@caligormed.com>
Subject: Ctrl Chars in $_
Message-Id: <OwluDVB6$GA.328@cpmsnbbsa08>
I am looking to pipe through a perl Socket using <STDIN> and return a
response from a network device.
However the socket needs to accept ctrl chars in STDIN and pass them. This
is where the problem is. It seems that it only passes ASCII characters
stripping ctrl chars. Is there a special input I should be using to
recognize the ctrl chars ???
Thanking you in advance....
--
Vance Forste
Perl Novice....
------------------------------
Date: 7 Jul 2000 15:19:34 GMT
From: vek@pharmnl.ohout.pharmapartners.nl (Villy Kruse)
Subject: Re: Ctrl Chars in $_
Message-Id: <slrn8mbt86.s9u.vek@pharmnl.ohout.pharmapartners.nl>
On Fri, 7 Jul 2000 08:58:56 -0400, Vance F <vancef@caligormed.com> wrote:
>
>I am looking to pipe through a perl Socket using <STDIN> and return a
>response from a network device.
>However the socket needs to accept ctrl chars in STDIN and pass them. This
>is where the problem is. It seems that it only passes ASCII characters
>stripping ctrl chars. Is there a special input I should be using to
>recognize the ctrl chars ???
>
It is not supposed to do that. How do you determine that the control
characters are actually stripped by the perl program?
Villy
------------------------------
Date: 8 Jul 2000 14:28:35 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Ctrl Chars in $_
Message-Id: <8k7aa3$ole$1@orpheus.gellyfish.com>
On Fri, 7 Jul 2000 08:58:56 -0400 Vance F wrote:
>
> I am looking to pipe through a perl Socket using <STDIN> and return a
> response from a network device.
> However the socket needs to accept ctrl chars in STDIN and pass them. This
> is where the problem is. It seems that it only passes ASCII characters
> stripping ctrl chars. Is there a special input I should be using to
> recognize the ctrl chars ???
>
binmode STDIN and binmode your socket ...
/J\
--
yapc::Europe in assocation with the Institute Of Contemporary Arts
<http://www.yapc.org/Europe/> <http://www.ica.org.uk>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V9 Issue 3557
**************************************
