in reply to Re: Re: Re: Locking PERL code another way
in thread Locking PERL code another way

Thanks Liz,
I was pretty sure there'd be something like that possible, but do you know how your example could be executed so that it affects my program _while its running_?

I assume I am protected by *NIX protected memory... but I wonder if there is some debug mode for Perl that lets one inspect running code...or poke at a Perl process...? Cheers,
Craig.
PS My idea is getting some function creep, or worse, creep creep. However, to compromise the running process would require your hack above being able to affect my running process. I hope you haven't lost patience with this idea. The question then becomes "does this fangled idea really add any more security than tripwire etc?"
  • Comment on Re: Re: Re: Re: Locking PERL code another way

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Locking PERL code another way
by liz (Monsignor) on Sep 26, 2003 at 09:31 UTC
    You need to watch out for string eval's during execution. Now you might say, I'm not doing any string eval's. That may be true, but the modules that you've used at compile time, may do require at run-time. Many times this is done to reduce the memory footprint of the module and/or to reduce startup time.

    This is also the mechanism that AutoLoader type modules use.

    So you need to make sure that the files that are being required, can not be changed to include trojan horses. One way of doing that is with tripwire.

    Then there is also the possibility of programs changing @INC and/or @ISA of a module. That would also offer ways of introducing executable code.

    So basically, I think that if all of your explicit string eval's are covered, and you are sure that the modules that you use do not contain backdoors that would allow a string eval, and you're monitoring the files with tripwire, then maybe your idea makes sense as the final check on everything else. With a high chance on false positives, as Perl does its rearranging and changing of optrees with runtime requires anyway.

    I don't think it is worth the trouble given all the other security features that Perl has. But please don't take my word for it, as I am not a security professional, just someone with some experience.

    Liz