Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^4: Dangerous diamonds! (s/real/perfect/ world)

by tye (Sage)
on May 19, 2003 at 20:15 UTC ( #259280=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Re: Dangerous diamonds!
in thread Dangerous diamonds!

Have you ever run a Perl script as root? If so, did you read the entire source tree of modules that get included by that script to make sure not a single one of them did:

my $data= do { local(*ARGV); @ARGV= $filename; <> };
It is a very broken tool that takes the contents of file names and lets it leak into the execution stream. Perl usually does a better job of avoiding such stupidity than many Unix tools and so I've often replaced non-Perl tools with Perl tools thinking I was improving security.

But now I have to add Perl to my list of things to "never trust". Why? Because it isn't reasonable for me to constantly keep track of exactly which modules might have been updated and might have decided to start using <>. Yes, in the real world, you have to make assumptions based on imperfect information and so you have to sometimes put your trust into things that you haven't recently disassembled and digested completely.

The phrase

know what you are running when you are logged in as root
is good advice but is very black-and-white and very much "in a perfect world" thinking when used to disregard a serious flaw in software. "In a perfect world, you can know exactly what you are running when you are root." In the real world, you are reasonably cautious.

Now this <> brokenness means that I can't trust the most basic of Perl code. This is not how it should be. And it is easy to fix.

Juerd may be complaining about not having realized that <> will pass file names to the shell. I'm not. I don't care whether some people think I should have realized this or not. It is just plain stupid and broken as a design and should be changed, regardless of the existence of so-called documentation of this mis-feature.

I'm not even convinced of the validity of the "it is documented" argument. All of the documentation I recall on the subject was sufficiently vague. For example:

is equivalent to the following Perl-like pseudo code:     ....
except that it isn't so cumbersome to say, and will actually work. It really does shift the @ARGV array and put the current filename into the $ARGV variable. [....]

You can modify @ARGV before the first <> as long as the array ends up containing the list of filenames you really want.

So I find it perfectly reasonable to interpret that as "very much like this code" except it expects the names of files that will be read (hence them being called "filenames" repeatedly) instead of arguments to be interpretted by open as perhaps filenames, perhaps filenames w/ open modes prepended, perhaps commands to be run, etc. since doing so would mean that the code actually works. Especially since it doesn't make any sense to have "> file" nor "| command" be interpretted by <>. You can come up with unusual situations where you want to be able to put "command |" into @ARGV, but you should have to specify your intentions.

                - tye

Replies are listed 'Best First'.
Re^5: Dangerous diamonds! (Let's fix it)
by theorbtwo (Prior) on May 19, 2003 at 20:53 UTC

    I think it's time to actualy fix this thing. I propose a new $^H (or %^H) hint that selects if ARGV magic open uses two-arg or three-arg open. What would matter is the value in effect at the moment of the open. I propose a pragmata to select it, and an additional "lock" feature, which would not allow changing the value after that point (in execution order, allowing it to be a feature of the module code, not the core).

    IOW: use magic::ARGV qw(safe lock); allows you to trust all code from that point on. (use magic::ARGV qw(safe); wouldn't lock it in, so it could be explicitly overruled, use magic::ARGV qw(more-magic); would give back the old behaviour. All that's left is to get better names, perhaps change the default from more-magic to safe, and actualy code the thing.

    Agree, disagree? Think I should be saying this on p5p already?

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      As I said, I've already started down that road. I've made similar changes and know what code is needed. However, I won't waste my time finishing it until someone can convince p5p to accept it. The amount of work is not trivial due to some accumulation of hacks in how 2-arg vs. 3-arg open are handled. And I'm convinced p5p won't accept such a patch anyway.

      I also refuse to try to convince p5p. I don't find them to be very susceptible to (my) logic. q-: (or, if you prefer, because it wouldn't work anyway -- someone else would have better luck convincing p5p)

      See my p5p submission for more details.

                      - tye
Re: Re^4: Dangerous diamonds! (s/real/perfect/ world)
by hv (Parson) on May 20, 2003 at 04:02 UTC

    Without regard to the question of whether this particular feature is desirable, I think the maxim of 'know what you are running when you are logged in as root' remains important and relevant.

    In that regard, the fact that a perl installation may regularly change as new modules are installed from CPAN should be seen as an issue to be addressed - CPAN modules do not get anything like the same level of checking as the core perl installation.

    Perhaps, then, it would be advisable to install a version of perl specifically for the use of trusted scripts, with its own library path, and require a higher level of validation before any changes to that installation.

    On my local system, I have a statically-linked perl in /sbin primarily so that scripts involved in startup/shutdown of the system can have a binary to use that doesn't need any other filesystems to have been mounted. I could certainly imagine orienting a security strategy for perl-as-root code around that installation.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://259280]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (2)
As of 2017-03-26 06:53 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (313 votes). Check out past polls.