in reply to Re: perl pre-execution hook
in thread perl pre-execution hook

s/ect/etc/g. *typo*.

No-execute wont make a difference, since what is executed is /usr/bin/perl which then reads a file (script) from /tmp/.

The wrapper script idea would certainly work. But its really simple to circumvent. I know theres no fool-proof way, but i was kinda hoping for something that would be more, errhh... "Hardcoded".. The problem with the wrapper script is, that to be able to execute a SCRIPT, you need read access to it. Execute-only is not enough. So basically you can just cat the script and see where the real perl is located.

Still, its the best option so far.

Now the PERL5OPT might be interresting.. Especially if there is some way to make the env-var read only to PHP.. Ill look into that.

Isnt there some sort of "autoloading" directory, where i can drop a file, a module, a .so file or somthing and have perl automagically load this on startup?

Ive already tried making a patch to perl that simply rejects running scripts from /tmp/, but its hacky to have to recompile perl on every server.

Replies are listed 'Best First'.
Re^3: perl pre-execution hook
by ikegami (Patriarch) on Jan 04, 2011 at 20:16 UTC

    No-execute wont make a difference, since what is executed is /usr/bin/perl which then reads a file (script) from /tmp/.

    Depends on if the script itself gets executed (in which case it would help) or on if the script is passed to perl (in which case it won't). 

    $ ls -l /tmp/ikegami/foo
-rwx------ 1 ikegami pg1404028 30 2011-01-04 12:23 /tmp/ikegami/foo*

$ cat /tmp/ikegami/foo
#!/usr/bin/perl
print "bad\n";

$ /tmp/ikegami/foo
-bash: /tmp/ikegami/foo: /usr/bin/perl: bad interpreter: Permission de
+nied

$ /usr/bin/perl /tmp/ikegami/foo
bad

    [download]

    But its really simple to circumvent.

    No, it's not. You seem to have forgotten the threat against you which you wish to defend. The attacker either relies on the web server knowing where to find perl or on him knowing where to find perl.

    Isnt there some sort of "autoloading" directory

    No. Besides, this would at least as easy to circumvent as replacing perl itself.

    Update: Elaborated on first point.

[reply]
[d/l]
[select]
      Yes..But 
      $ perl /tmp/foo

      [download]
      would still work. (And many hacks actually execute like that).

      I agree that trying to stop every scenario is hard, but replacing perl will only foil an automated attack, not the manual hacker.. Which may be a good start, but there ARE manual hackers out there :)

      Autoloading would be way easier to make secure. The only way to circumvent it, would be to upload your own perl. And even then, which wouldnt work as easy, since no-exec is set on /tmp, so you'd have to find a 777 directory somewhere to dump your binary.

      PHP for example, can be told to load .so "extension", which are initialized before the actual PHP code.. It seems strange that perl doesnt have something like it (though PHP is, of course, not the best example of anything ;) )

[reply]
[d/l]

        It seems strange that perl doesnt have something like it

        Not at all. Noone spent the time, possibly because it's much easier writing the following wrapper: 

        #!/bin/sh
/usr/bin/perl.shadow -MFoo "$@"

        [download]
[reply]
[d/l]

      (note: the original post was changed significantly after my reply) 

      $ foo
-bash: ./foo: /usr/bin/perl: bad interpreter: Permission denied

      [download]

      yes, but you can always say 

      $ /usr/bin/perl foo

      [download]

      (which would run without problem)

[reply]
[d/l]
[select]

        Yeah, I've elaborated on that point while you were posting.

        yes, but you can always say

        But can the attacker? Again, it comes down to the threat model.

[reply]

In Section Seekers of Perl Wisdom