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

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

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.

Replies are listed 'Best First'.
Re^4: perl pre-execution hook
by logix (Initiate) on Jan 04, 2011 at 20:35 UTC
    Yes..But
    $ perl /tmp/foo
    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 ;) )

      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 "$@"
Re^4: perl pre-execution hook
by Anonyrnous Monk (Hermit) on Jan 04, 2011 at 20:24 UTC

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

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

    yes, but you can always say

    $ /usr/bin/perl foo

    (which would run without problem)

      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.

        But can the attacker?

        Why not?  If the attacker can run ./foo, s/he can almost certainly also run /usr/bin/perl /tmp/foo.  Actually, it's more than likely that someone uploading something to /tmp (which can be expected to be mounted noexec) would try this in the first place...