in reply to use Safe ; Any Thwarted Attacks?

Considering the number of holes that have been found in Safe over the years it can hardly be considered... well.. safe in any case.

Replies are listed 'Best First'.
Re: Re: use Safe ; Any Thwarted Attacks?
by Anonymous Monk on Nov 10, 2003 at 16:12 UTC
    Have you got links/examples?
      Have you got links/examples?

      Many :-)

      A quick look at the perl bug site will give you several, including:

      A quick grep through Perl's change files will supply many other instances. For example from Changes5.8.1:

      The CHECKOP macro was not invoked on some newly created ops (to match them against the current opmask.) As a consequence, Safe compartments were unable to trap some ops (pattern match, slices, conditionals.) This fixes the holes.

      So, unless you are running 5.8.2 which has out for less than a week, there are already known exploits in Safe.pm, and goodness knows how many unknown ones.

      (update: of course, Changes5.8.1 refers to the changes made in 5.8.1 - so it's not quite as bad as I originally said. still not good tho')

      This is why I would not rely on Safe.pm for security.

      As a tool to help track down issues it's great - it catches a lot of stuff. However, as the sole line of defence it's history is just too full of security holes for me to have any great faith in it.

      Instead, use alternate tactics:

      • If you need to dump data structures avoid situations where you have to compile arbitrary code (e.g. Use YAML instead of Data::Dumper.)
      • If you need to run code define a "safe" domain specific language and use that (e.g. Template).
      • Authenticate safe code from known sources using public/private keys.
      • etc.
        A quick look at the perl bug site will give you several, including:

        Safe reval bleeds local variable values

        To be fair, I think that problem was both introduced and fixed between 5.8.0 and 5.8.1 and was never a problem in a released version (from memory).