http://www.perlmonks.org?node_id=971884


in reply to Re^2: Bug in perl command line processing?
in thread Bug in perl command line processing?

The -e1 is unnecessary.

That seems to be because perl sees the 'e' in 'foo e eval...' as an -e command line switch. Change it to something else besides 'e' and the behavior changes.

It sort of feels like the same sort of exploit one should worry about when using the two-arg open unsafely, passing user data to a database without placeholders, or instantiating user data as variable names.


Dave

Replies are listed 'Best First'.
Re^4: Bug in perl command line processing?
by demerphq (Chancellor) on May 22, 2012 at 21:41 UTC

    Yes, but to me that is THE bug.

    ---
    $world=~s/war/peace/g

      Absolutely.

      BTW: It doesn't seem to propagate into full-fledged scripts like this:

      #!/usr/bin/perl -i'foo e eval "warn q[bar]" ' 1;

      From what I can tell, -i has to actually appear on the command-line, which hopefully self-limits its significance as a tool for exploit.


      Dave

        From what I can tell, -i has to actually appear on the command-line

        Yup,

        $ cat uhoh #!/usr/bin/perl -i.bak e die(666) 1; $ perl uhoh Can't emulate -e on #! line at uhoh line 1.

        which hopefully self-limits its significance as a tool for exploit.

        Hmm, the only exploit situation i an envision is someone naively automating perl, for example from perl

        system $^X, "-i$bak", ...

        which doesn't seem unreasonable. I suppose given that -e commandline documents

        $ perl -e warn(1); -e die(2); 1 at -e line 1. 2 at -e line 2.

        folks might be scared away from automating perl this way, but then again whitespace in paths is not unheard of