Which, by the way, would be a problem with _any_ interpreted programming language that has the equivalent of eval, not just of Perl.

The least you would need would be an externally running program / process that would inspect the Perl program running in memory. Not an easy task, I would think.

Liz

Thank you for thinking about this. This is how it works

1. OK, I've parsed. Now, get my tree.
2. When called, give out my tree MD5, say I keep running as a server process
3. Something else has all the MD5s and "pings" me pretty regularly

Since the inherited PMs, get-my-tree etc are all in the tree, (excepting ///o and others as other submitters have suggested) our MD5 seems to "lock" up everything that matters.

With regards to changing the code on disk, I assume something conventional watches the .pl file and that other security is in place for other compromises. This would help us trust the PERL binary etc.

We then want to prevent foo-root-user being able to fiddle with the executable image in memory. At the PERL level at least.

So, you are right; something has to watch something - it's not "self-auditing" :-).

But is it the case that something could be injected into the memory image which issues fake MD5s for us? How hard is it to fiddle with execution tree in the Perl state machine?

I'll also follow up what other people have posted, thank you.

There must be a routine that returns the MD5. Let's call this "giveMD5" in package Foo. Then the following code will replace that routine by another routine, without the outside world knowing about it.

{
my $giveMD5 = \&Foo::giveMD5;
my %givenMD5;
*Foo::giveMD5 = sub {
    my $md5 = $givenmd5{@_} ||= $giveMD5->( @_ ); # execute old to obt
+ain "real" MD5
# do evil things to op tree for given parameters if first time
    return $md5; # the "right" value
};
}
[download]

Of course, this is more or less pseudo-code to give you the idea.

By the way, this "wrapping" technique is used in all sorts of Perl modules, so disabling this feature in Perl is basically impossible.

Liz

You'll need to keep in mind that some operations cause the optree to alter itself at runtime. First on my mind is the /o regex modifier (and maybe that's it for core perl). Maybe also tricks with B::Generate to alter the optree at "runtime" (considering that BEGIN, CHECK, INIT, runtime, and eval string are all different runtimes).

So far we're using a nastily hacked version of Devel::OpProf.

I take your other suggestions; we'd need to not allow them obviously, along with ``, eval etc and other neat things.
Craig

We wanted to call it SchrCat:: actually!