Re: Re: Dangerous diamonds!

[Juerd]

Sigh. I KNOW THAT.

The problem doesn't like in magic open. The problem lies in assuming world writeable directories are safe.

No.

The problem that I am discussing is that it's using 2-arg open without me knowing it is. Now that I know it does do that, I won't make the mistake of EVER doing any -pe'something' * in something that is automated again. Too bad, since Perl really is nice as a one-liner crafting tool. Or I thought it was.

Consider the following program:

Blah blah. Those two examples are completely unrelated. They only happen to use @ARGV. I was *NOT* discussing the array @ARGV, but the magic filehandle that opens implicitly.

Your examples change the files, which is by definition less secure. My concern is with scripts/one-liners that readline *ARGV without knowing it could be any mode. I'm talking about implicit open, you're talking about explicit open and explicit truncate.

Please step into the real world and realise people make mistakes, and that people sometimes think they know how something works but do not. I thought I knew what magic ARGV did (Note again: @ARGV is not magic. I'm talking about *ARGV{IO} here, and only that.), but apparently did not.

My search on my server, on which multiple people automate tasks using Perl one-liners, proves that I'm not the only one that opened up huge security holes by assuming -n and -p were safe (again assuming no $ARGV, no @ARGV and no $^I or ANYTHING that *changes* files).

It would very insecure to think that using 3-arg open will fix your problems.

Pedant. Let me rephrase: 3-arg open with "<" as its second argument would fix most of the problem that I describe. Possibly still has exploits with nullbytes and such, but at least those are real exploits, and not some stupid Perl bugfeature that can very easily be abused.

To anyone reading my post: I acknowledge that it is a feature (after all, it's documented and sometimes useful) and not a bug. I also agree that you shouldn't assume things. But people do assume a lot and my message serves as a warning for people like me. In some IRC channels some people were quite shocked and started editing their scripts immediately.

Sometimes I wonder why it is that in Perl world you cannot warn people or express your wishes without getting replies about that things are supposed to work the way they do, that any changes would break legacy scripts, that I should have been perfect in the first place and that worse situations are possible too.

So, to avoid further confusion:

• Beware: magic ARGV (implied by -p and -e) uses two-arg open and can open files in a not-read-only mode and can even execute external commands.
• How it works now is a feature, documented in perlop.
• I wish it were different (explicit read-only using three-arg open).
• I'm only talking about the magic ARGV filehandle, not about $ARGV, @ARGV or its elements.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[bart]

To anyone reading my post: I acknowledge that it is a feature (after all, it's documented and sometimes useful) and not a bug.

I disagree. That is like saying that carrying a loaded and unlocked gun with you all the time is sometimes useful. You'll accidently shoot someone that way, likely even yourself while not even handling the gun.

If people want to make use of the effect that this kind of "feature" achieves now, they should program the loop explicitely. How much work is it? Is it really worth the savings?

Again, in summary: <> should only try to open existing files, and for reading only.

[Juerd]

Again, in summary: <> should only try to open existing files, and for reading only.

I agree that it *should* only open files for reading. I was just acknowledging that the current handling of magic ARGV is a feature because it is documented as one.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[mr_mischief]

Please step into the real world and realise people make mistakes, and that people sometimes think they know how something works but do not. I thought I knew what magic ARGV did (Note again: @ARGV is not magic. I'm talking about *ARGV{IO} here, and only that.), but apparently did not.

Please step into the real world, where it is your responsibility to know what you are running when you are logged in as root.

Update: tilly has pointed out to me that the interface is partly to blame whether or not this is documented behavior. I agree that it is _partly_ the blame of the interface. The other part of the blame, I believe, still lies with the user of the interface. The point is to be extremely careful when you do things as root that you do know what is going on.

tye points out that it's nearly impossible to tell if one of some large number of modules uses the diamond operator. It is similarly difficult to tell if some portion of a C library does something stupid. This doesn't mean that C is inherently insecure, nor does it mean that Perl is. The furor has been over one-liners, which are simple enough that you CAN tell everything they are doing. Taint.pm is your friend in either case.

I do agree it's worth fixing. I don't think it's entirely outside the responsibility of the user to be aware of shortcomings before they are fixed, though. End of update

Christopher E. Stith
use coffee;

[tye]

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

[theorbtwo]

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).

[hv]

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.

Hugo

[Juerd]

Please step into the real world, where it is your responsibility to know what you are running when you are logged in as root.

It is indeed. But as I said before, in the post that you quoted, people make mistakes. I believe your mistake was to not read my post or to interpret it the wrong way.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }