[17880] in Perl-Users-Digest
Perl-Users Digest, Issue: 40 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 11 14:10:43 2001
Date: Thu, 11 Jan 2001 11:10:15 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <979240215-v10-i40@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 11 Jan 2001 Volume: 10 Number: 40
Today's topics:
Re: replacing spaces with %20 <fty@mediapulse.com>
Re: replacing spaces with %20 <newsgroups@jhorn.cjb.net>
Re: Security <mischief@velma.motion.net>
SMTP problem. <webmaster@navarone.com>
Re: Stopping users from exploiting Perl 'interpreter' o <russ_jones@rac.ray.com>
strange end-of-line <drkrause@mindspring.com>
Re: strange end-of-line (Anno Siegel)
Re: strange end-of-line <drkrause@mindspring.com>
Re: strange end-of-line (Tad McClellan)
Re: strange end-of-line <drkrause@mindspring.com>
Want to create class/sub-class with no package bpettit@my-deja.com
Re: would a regex be helpful here? (Tad McClellan)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 11 Jan 2001 16:20:02 GMT
From: "Jay Flaherty" <fty@mediapulse.com>
Subject: Re: replacing spaces with %20
Message-Id: <S2l76.215566$DG3.5378827@news2.giganews.com>
"^Jerry" <newsgroups@jhorn.cjb.net> wrote in message
news:93imh0$k1q$1@nnrp1.deja.com...
> how can I replace the name of an image (in $image_name) to something
> like this%20is%20me.jpg ??
use CGI qw(:standard);
$image_name = CGI->escape($image_name);
jay
------------------------------
Date: Thu, 11 Jan 2001 18:04:15 GMT
From: ^Jerry <newsgroups@jhorn.cjb.net>
Subject: Re: replacing spaces with %20
Message-Id: <93ksin$fak$1@nnrp1.deja.com>
I had tried something like this...
$image_name =~ tr/ /%20/;
Dave Brondsema posted this... works great, too.. *Thanks, Dave*
$image_name =~ s/ /\%20/g;
I spent most of last night on the perl.com documentation pages.. I've
installed Active Perl on my computer, too.. helps me figure out what
I've messed up... (I do that a lot.. hehe)
I'm writing (trying to) a script that would kinda simulate the "Who
wants to be a millionaire" game... I had found a cool one (already
written) but it cost $60 for a single domain license... considering
that I don't get payed for the site I wanted the script for, I figured
I'd write my own.. I'll probably make it available under the good 'ole
GNU, or something..
Jerry
http://users.cjb.com
> What did you try?
>
> Greg
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Thu, 11 Jan 2001 17:30:04 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Security
Message-Id: <t5rrcsbugptrf7@corp.supernews.com>
Jerry <jeremy.hutchings@cw.com> wrote:
> Hello everyone,
> I'm trying to understand how to secure a server on which there are many
> users. I understand that being able to link static binaries is a bad thing
> and need to know how we can stop this.
Keeping them from compiling and linking means taking away the compiler
and linker on the server box, which is a good idea. You can move
all the binaries you need compiled for the machine from another
box, but so can the hosting customer.
> "We must prevent users from calling their own binaries from a perl script
> executed by the web server as a .pl CGI script. This is necessary to prevent
> the use of statically linked binaries, that will circumvent disk quota
> control and networking restrictions that prevent hacking, sniffing and
> general buggering around."
Taking away Perl's ability to call other programs is tough. This
requires taking away backticks, system(), and piped opens. You could
still run a binary program without using Perl, though.
I don't know how a user's own binary circumvents his disk quota, unless
the executable itself does something screwy to do so. Perl programs can
make network connections without outside binaries (save, of course, the
Perl interpreter), so keeping people from running programs written in
C/C++, Pascal, Fortran, etc. won't keep them from running a MUD,
a chat server, or a remote shell server.
The only way to make sure that hosting users can't have anything but
Perl programs in their hosting space is to follow these steps, which
are not peculiar to Perl and could be implemented in another language
by your administration team, programmers, or consultants to either:
1) chroot their web server process, so the CGI programs
called cannot call anything above a protected directory
2) Run a scan of all files within the protected directories
searching for anything which has the executable bit set
which isn't a Perl program.
3) Remove or report all files found in step 2 that violate
the requirements.
Step 1 could be tough, unless it is enough to chroot to one
directory for all the hosting clients, then report which of
the subdirectories below that have violated the policy.
Step 2 could be tough, as a user could upload a shell, awk,
or sed script which would also be text. Certain other languages
apply here as well. You can't always trust the shebang for in which
language something is written, either. Take a look at this:
#######################
#!/usr/bin/perl
$shell_script = 'malicious';
$data_file = 'data';
system("/bin/sh $shell_script $data_file");
__END__
#######################
Of course, if you both did a chroot and refused to give a working
copy of a shell or anything similar within the chrooted environment,
then the above is a little more safe.
Step 2 still suffers other difficulties. A Perl program might use
malicious modules, written in C or C++ using XS. They might also
use the Inline.pm module if available. If someone was clever enough
and had enough spare time, they could even write a Perl program to
compile and link an executable for your platform, write it to disk,
call it, then delete it. It would be far easier to place a binary
file in the directory, chmod() it to make it executable, run it, then
chmod() it back. A midway would be to include a base64 encoded or
uuencoded executable in the __DATA__ section of a Perl program,
decode it, write it to disk, chmod() it, run it, and unlink the file.
Step 3 is easy enough once steps 1 and 2 are sucessful.
> I've been through ;
> http://www.perl.com/pub/doc/FAQs/cgi/www-security-faq.html
> but cant seem to find any thing on it.
The reason you have not found anything about it in the CGI
security FAQ would be that the document you are reading is
about writing CGI programs which are secure. It's not about
writing ones that breach security. It does suggest that when
writing a secure CGI that you check your command-line arguments.
This is a good starting point for finding other people's
insecure or malicious code on your server.
Calling code outside a Perl program is not within the scope of
CGI security in Perl. The Perl portion can be made secure based
on the info provided there, and the binary portion is something
else entirely. Anyway, the post I'm responding to doesn't seem
to be about writing secure CGI programs. It is more about finding
other people's programs that are either insecure or malicious.
To learn how to secure against malicious users on your platform,
get a book or five on security. To find additional tricks that
might be used against you, find some things on how to write
malicious programs. 2600 Magazine or http://www.2600.org can be
good for this sometimes, and http://neworder.box.sk can too.
The best way to make sure someone isn't writing malicious code
and running it on your server is to not let them run CGI code
from their home directory at all. Don't give them the rights to
change the mode of files in the FTP session, either. Make them
upload the files they need then contact your administration team
via phone or email. Your admin team can then look at the source
code, compile it if need be (for C/C++, Ada, Pascal, Fortran,
etc.), place it in a CGI directory to which the end user can't
upload, mark it executable, then let them link to it there.
Diligence is the only true means of security, no matter how
much knowledge you may have.
Chris
--
Christopher E. Stith
Parking for people we like only. All other vehicles will be vandalized.
------------------------------
Date: Thu, 11 Jan 2001 08:57:30 -0800
From: "Navarone Webmaster" <webmaster@navarone.com>
Subject: SMTP problem.
Message-Id: <uyl76.195$ioc8.47841792@news.randori.com>
Sending mail to a WINNT mail server (Xtramail) is producing a problem. The
HELO, MAIL, RCPT, DATA, etc. commands all return the proper responses, but
the 'body' of the email does not appear in the resulting email sent to the
RCPT if the RCPT is on the same server (WINNT). But, all the headers (from,
subject, etc.) are correct; only the actual text of the message is missing.
Changing the RCPT to a server that is UNIX based, the body (text)
information appears and is correct.
Initially, I had problems communicating with the mail server because I was
ending the commands (HELO, MAIL, etc.) with only a '\n' instead of a '\r\n'.
I am now also including the '\r\n' in the body as necessary, but still no
go. Here is a portion of the code in question...
#build the actual text for the mail message
$body = ""; #initialize body
foreach $i (0 .. $#in-1) {
$body = $body . $in[$i] . "\r\n"; #build output
}
#Now send it...
#Note...when I change the following RCPT to 'roger@websbyroger.com', the
resulting text is displayed properly when received. websbyroger server is
Apache. Navarone is Xtramail.
$mailTo = 'webmaster@navarone.com'; #RCPT
$mailServer = 'navamail.navarone.com';
$mailFrom = 'webmaster@navarone.com'; #MAIL
$proto = getprotobyname("tcp") || 6;
$port = getservbyname("SMTP", "tcp") || 25;
$serverAddr = (gethostbyname($mailServer))[4];
($name, $alias, $addrtype, $length, @addrs) =
gethostbyname("navamail.navarone.com");
if (! defined($length)) {
die('gethostbyname failed.');
}
socket(SMTP, AF_INET(), SOCK_STREAM(), $proto) or die("socket: $!");
$packFormat = 'S n a4 x8';
connect(SMTP, pack($packFormat, AF_INET(), $port, $serverAddr)) or
die("connect: $!");
select(SMTP); $| = 1; select(STDOUT); #use unbuffered i/o
{
$inpBuf = '';
recv(SMTP, $inpBuf, 200, 0); #returns: 220 XtraMail SMTP-Server (v1.2
58210005712) for Windows NT ready at Thu, 11 Jan 2001 06:46:56 +-800
}
sendSMTP(1, "HELO\r\n"); #returns: 250 navamail.navarone.com Hello
209.249.41.142
sendSMTP(1, "MAIL From: <$mailFrom>\r\n"); #returns: 250 , sender ok
sendSMTP(1, "RCPT To: <$mailTo>\r\n"); #returns: 250 Roger Brown
sendSMTP(1, "DATA\r\n"); #returns: 354 Start mail input, terminate with '.'
send(SMTP, "Subject: $subject\r\n", 0);
send(SMTP, $body, 0);
sendSMTP(1, "\r\n.\r\n"); #returns: 250 162 bytes received in 0,130 seconds;
Message accepted for delivery
sendSMTP(1, "QUIT\r\n"); #returns: 221 209.249.41.142 closing connection
select(SMTP); $| = 1; select(STDOUT); #use unbuffered i/o
{
$inpBuf = '';
recv(SMTP, $inpBuf, 200, 0);
$inpBuf = '';
recv(SMTP, $inpBuf, 200, 0);
}
close(SMTP);
Thanks in advance for your time and comments.
Roger
------------------------------
Date: Thu, 11 Jan 2001 11:54:07 -0600
From: Russ Jones <russ_jones@rac.ray.com>
Subject: Re: Stopping users from exploiting Perl 'interpreter' on NT
Message-Id: <3A5DF33F.56BFCD9A@rac.ray.com>
Jerome O'Neil wrote:
>
> "Clyde Ingram" <cingram-at-pjocs-dot-demon-dot-co-dot-uk> elucidates:
>
> >> Yes. You write policy that says "Thou shalt not ... " and if they do,
> >> you fire them.
> >>
> >> I'm unsure as to why you would hire someone you don't trust in the
> >> first place, but I guess thats your issue.
> >
> > Oops, you miss the point: we do not hire people we do not trust, but we have
> > to secure the system as best we can against unscrupulous employees of our
> > customer. Clearly we cannot control our customer's employment policy: you
> > are wrong to guess that's our issue.
>
> I see. Then you should explain to your customer that they have a personnel
> problem, not a technology problem. It is best solved by enforcing policy
> than trying to simultaneously deny and grant access to a system resource.
>
Even if it's not strictly a technology problem, I think that there's
probably a technology solution. According to the NT guys here where I
work, you should be able to use the windows registry to disallow the
use of any program named "perl" (or whatever) although that might not
stop your users from renaming the perl executable to something else.
I suspect that your issue isn't so much with users that you don't
trust to be honest, that it's more an issue with users that you can't
trust to know what they're doing. While it would be nice to be able to
fire anyone that was a moron, if you did that, then there'd be nobody
to promote to management, would there?
--
Russ Jones - HP OpenView IT/Operatons support
Raytheon Aircraft Company, Wichita KS
russ_jones@rac.ray.com 316-676-0747
Quae narravi, nullo modo negabo. - Catullus
------------------------------
Date: Thu, 11 Jan 2001 11:23:48 -0800
From: Drew Krause <drkrause@mindspring.com>
Subject: strange end-of-line
Message-Id: <3A5E0844.B77A4107@mindspring.com>
Hello, I think this is related to using perl, so I'll ask. I have some
text files that don't copy well into my unix system. They look fine --
no strange characters -- but the spaces and blank lines generate errors
when read.
Here's the strange part: opening a text editor (such as pico) and
deleting / re-inserting the spaces and lines seems to solve the problem
BUT commands such as "sed /^$/d" don't snag the blank lines.
Is there more than one kind of end-of-line in a text file? Has anyone
else heard of this problem?
------------------------------
Date: 11 Jan 2001 17:11:46 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: strange end-of-line
Message-Id: <93kpgi$31n$1@mamenchi.zrz.TU-Berlin.DE>
Drew Krause <drkrause@mindspring.com> wrote in comp.lang.perl.misc:
>Hello, I think this is related to using perl, so I'll ask. I have some
>text files that don't copy well into my unix system.
From what other system, copied by what means? Please be specific.
> They look fine --
>no strange characters -- but the spaces and blank lines generate errors
>when read.
What errors do they generate when read by what program? Please be
specific.
>Here's the strange part: opening a text editor (such as pico) and
>deleting / re-inserting the spaces and lines seems to solve the problem
>BUT commands such as "sed /^$/d" don't snag the blank lines.
>
>Is there more than one kind of end-of-line in a text file? Has anyone
>else heard of this problem?
Yes, there are different kinds of end-of-line markers in use on different
systems. Many people have heard of the problem, most of which actually
got bitten by it.
If you are using an FTP-like program for file transfer, set the mode
to ASCII when appropriate. It will then adjust different line styles
to the system hosting the file.
If necessary, the conversion can also be done in Perl, and isn't hard
to do.
Anno
------------------------------
Date: Thu, 11 Jan 2001 12:51:39 -0800
From: Drew Krause <drkrause@mindspring.com>
Subject: Re: strange end-of-line
Message-Id: <3A5E1CDB.83B70618@mindspring.com>
Anno Siegel wrote:
> Drew Krause <drkrause@mindspring.com> wrote in comp.lang.perl.misc:
> >Hello, I think this is related to using perl, so I'll ask. I have some
> >text files that don't copy well into my unix system.
>
> From what other system, copied by what means? Please be specific.
Copied from CD, which looks like it's meant to be readable on many platforms.
>
>
> > They look fine --
> >no strange characters -- but the spaces and blank lines generate errors
> >when read.
>
> What errors do they generate when read by what program? Please be
> specific.
I get "illegal character" flags from running csound (a sound synthesis
program.
> Yes, there are different kinds of end-of-line markers in use on different
> systems. Many people have heard of the problem, most of which actually
> got bitten by it.
In fact, a "^M" appears at the end of each line when I try "vi -b filename".
>If necessary, the conversion can also be done in Perl, and isn't hard
>to do.
Do tell!
------------------------------
Date: Thu, 11 Jan 2001 11:33:00 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: strange end-of-line
Message-Id: <slrn95ro1s.bug.tadmc@tadmc26.august.net>
Drew Krause <drkrause@mindspring.com> wrote:
>Hello, I think this is related to using perl, so I'll ask.
I don't think it is related to Perl. But you can probably use
Perl to patch up your data files :-)
>I have some
>text files that don't copy well into my unix system.
What do you mean when you say "copy"?
Do you really mean "when I FTP files created on non-Unix system
to my Unix system"?
>They look fine --
>no strange characters -- but the spaces and blank lines generate errors
>when read.
We cannot help you understand error messages if you do not share
the text of the error messages with us.
>Is there more than one kind of end-of-line in a text file?
Yes.
>Has anyone
>else heard of this problem?
Yes.
Unix/DOS/Mac all have different line-ending sequences.
If you use "ASCII" (or "text") mode when transferring via FTP,
it will convert the line endings for you.
Or, write 'dos2unix' in Perl:
perl -p -i.dos -e 'tr/\r//d' filename
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 11 Jan 2001 14:06:58 -0800
From: Drew Krause <drkrause@mindspring.com>
Subject: Re: strange end-of-line
Message-Id: <3A5E2E82.552C91B0@mindspring.com>
BINGO!! Thanks to all who helped!
Tad McClellan wrote:
> Or, write 'dos2unix' in Perl:
>
> perl -p -i.dos -e 'tr/\r//d' filename
------------------------------
Date: Thu, 11 Jan 2001 18:23:47 GMT
From: bpettit@my-deja.com
Subject: Want to create class/sub-class with no package
Message-Id: <93ktn6$gfr$1@nnrp1.deja.com>
Hello,
I'm somewhat new to perl. I want to create a class that has
subclasses. From everything I've read, all classes have to be in a
package file. So, if I wanted something like a class called "Main" and
then a subclass called "Shape" and then a subclass called "Square", I'd
need to have 3 separate package files.
What I want to do is fairly simple.. I don't even need any methods.
I want my own datastructure that I can define to different things. But,
I don't want to have multiple package files. Perhaps this example will
explain what I want to do better (I'm thinking in terms of C++ and
trying to use PERL syntax)
I.E. - newObject = new MyObj()
# This is an object definition
Square {
my ($self) = {};
bless ($self);
$self->{'created'} = 3;
return $self;
}
# This is an object definition
Shape {
my ($self) = {};
bless ($self);
$self->{'created'} = 2;
$self->{'sqr'} = new Square();
return $self;
}
# This is an object definition
MyObj {
my ($self) = {};
$self->{'created'} = 1;
$self->{'shp'} = new Shape();
return $self;
}
#So then, I could do this -
$newObject = new MyObj();
print $newObject->sqr->created
Should give me '3'.
If anyone could point me somewhere I'd really appreciate it. I've been
working with PERL, but I've never created complex data structures. I
know how to do it in C++, but it's getting confusing in PERL.
Any help would be appreciated.
Regards,
Brian Pettit
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Thu, 11 Jan 2001 11:08:55 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: would a regex be helpful here?
Message-Id: <slrn95rmkn.bsl.tadmc@tadmc26.august.net>
webqueen, queen of the web <webqueen@my-deja.com> wrote:
>Thanks for the great replies guys..
Please stop with the upside-down quoting.
Please do not quote an entire article.
>These are some very interesting
>solutions.. I never encountered s/(stuff)/../ or putting a join in a
^^^^^^^
>regex.
^^^^^
You can NOT put a join() in a regex.
You can put a join() in the replacement part though.
s/PATTERN/REPLACEMENT/
The PATTERN is a regex. The REPLACEMENT is not a regex, it is a string.
>New curisoties for me :) Would perdocs have this kind of example
>or is this more like guru-stuff? Are there websites with more examples
>of embedding perlfuncs in regexex's?
All that you need to see (perldoc perlop) is:
s/PATTERN/REPLACEMENT/e
e Evaluate the right side as an expression.
Now the REPLACEMENT is not a string, it is Perl code that returns
a string.
And you realize that you can put any darn code you want in there.
[snip Jeopardy quoted text]
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 V10 Issue 40
*************************************
