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

Liz, a late reply here after some meditation. Your code snippet to steal the getMD5 routine would itself become part of the syntax tree for the program. This changes the MD5, even before you get to it. Anything calling us for the MD5 will get a bad MD5. This is, unless you can call getMD5 before the Perl code fully parses.

Another way would be to somehow obtain the MD5 from our live script by copying the script elsewhere and executing it under debug. Presumably we can then observe the variable that handles the MD5 and grab it on its way through without modifying the syntax tree for the script. With the MD5, we can pretend to be the script.

I know little about Debug. Does debug modify the syntax tree for a script by, say, instrumenting the code (the way some profilers do at run time?) if so, Debug could not help an attacker. Also, we could peek the memory for the data segment used by the script/Perl and try to find the MD5. However, with protected memory we would presumably be somewhat prevented from doing this.

Presumably Perl has some Debug/Devel feature that lets one "watch" the state machine and so obtain the values of of any SV at any time? Or does it have security to prevent this?

I think my idea is doomed, however. Trust requires secrets. If my script can be read, I have naught that can't be copied and used to pretend to be me to a remote entity. The Devel::opprof idea just attempts to prove all's well on-the-fly with a schroedinger's cat and a remote entity watching the door on the cat's box.

This doesn't prevent someone from copying the cat/box and then putting up a picture of the cat/box for the remote observer.

Cheers
Craig.
  • Comment on Re: Re: Re: Re: Locking PERL code another way