Rafaël Garcia-Suarez

Safe.pm, originally released with perl 5.002, has been an experiment to bring compile-time safety to perl. It allows to compile a (usually user-provided) snippet of perl code and execute it, while forbidding a configurable list of operations -- for example, all perl built-ins that would require disk or operating system access. Moreover, Safe "chroots" perl's main:: namespace, so the real program's variables can't be overwritten by the ones created by the code executed from Safe.

It's pretty clear that Safe does not provide absolute safety. For once, even overly restricted, it can be abused to execute code that allocates gigabytes of RAM, or goes into an infinite loop. Also, Safe is forced to share a small list of variables and functions with the main program; $_ is an obvious example, being the default topic for a lot of built-ins; functions from the UNIVERSAL:: and utf8:: namespaces also come to mind.

Another security risk is to let code compiled inside Safe be run outside -- for example, via coderefs it might return; because those coderefs will not be run in the chrooted namespace, so they can access the host program's namespace; and if they want to compile some other code in turn, that compilation will occur outside of Safe, permitting the full range of perl's operations.

That's why Tim Bunce recently added the function wrap_code_ref() to Safe, which, as the docs say, returns a reference to an anonymous subroutine that, when executed, will call the coderef with the Safe compartment 'in effect'.

The latest release of Safe (2.25, on a CPAN mirror near you) also strenghtens the security of Safe by removing all automagic methods that a Safe might have been created in the chrooted namespace; that is, destructors, AUTOLOAD, and overloading operators. It appeared that those could be abused to inject malicious code in any application that uses Safe and allows a pretty basic set of operations.

In other words, if you're using Safe, you really want to upgrade to 2.25.