Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

use Safe ; Any Thwarted Attacks?

by ptkdb (Monk)
on Nov 10, 2003 at 14:59 UTC ( [id://305881]=perlquestion: print w/replies, xml ) Need Help??

ptkdb has asked for the wisdom of the Perl Monks concerning the following question:

The Safe module was a cool idea to prevent someone from messing with you when you save and restore settings through Data::Dumper.

I'm curious, has anyone ever thwarted an attack using the Safe module?

Replies are listed 'Best First'.
•Re: use Safe ; Any Thwarted Attacks?
by merlyn (Sage) on Nov 10, 2003 at 15:06 UTC
    For safe undumping, see my article on that to parse the dump as text, and Data::Undumper, which puts the eval inside a Safe compartment, just as you propose.

    And, instead of Data-Dumper format, you should strongly consider YAML, which not only dumps and restores faster, it's also cross-platform and much more human editable. For pure Perl dumping, use the now-core Storable module for maximum speed and greatest economy of space.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      And, instead of Data-Dumper format, you should strongly consider YAML,

      Depends on the nature of the data being dumped. If its complex YAML doesnt have a prayer. If its simple config type stuff with minimal self references, and no aliasing then YAML is a suitable choice. And if the intention is for user readability then YAML is not a bad route to go, but then again nor is Config::IniFile

      which not only dumps and restores faster

      Where does this meme come from? All the benchmarks ive seen show YAML gets killed by Data:Dumper. If you stand by this assertion please back it up. I will however grant that YAML is more secure in terms of undumping however.

      For pure Perl dumping, use the now-core Storable module for maximum speed and greatest economy of space.

      And to boot it is the most accurate dumper currently out there (although it makes no claim to dump globs,) and is completely secure (from eval style attacks anyway, I havent reviewed it for other attacks).

      Update: Oh, I should mention that providing an undumper based on the ideas in your column (which you kindly pointed out to me a year ago due to a P::RD node I wrote,) for my new Dumper code (which shall go unnamed for the moment) is on my TODO list. Parsing arbitrary perl may be a near impossible task, but validating that a piece of text was consistant with a Dumper grammar (ie could have been emitted by Dumper) shouldn't be, which then allows Perl to actually handle the conversion without introducing safety problems or requiring things like a Safe container.


        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

Re: use Safe ; Any Thwarted Attacks?
by adrianh (Chancellor) on Nov 10, 2003 at 15:56 UTC

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

      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, 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 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.
Re: use Safe ; Any Thwarted Attacks?
by scrottie (Scribe) on Nov 11, 2003 at 05:29 UTC
    I don't know if anyone has attacked me - attackers are pretty lazy and stupid these days, with so many targets, such easy pickings, and such apathy towards the Web in general - but I trust it in production. Though I could be sealing my fate here. Oh well. I also backup, compartmentalize, and run bounds checking patches.

    Actually, I don't use - I use it's bastard cousin,

    use ops qw(:default entereval sort exit rand ftsize ftfile caller stat +);
    The Internet community at large is allowed to write code to extend TinyWiki. It is useful to understand the way these modules work - for that, read the Opcode manual page. A bitmask is maintained and disallowed ops aren't compiled. Any code compiled before the "use ops" line can do anything it wants, but any code compiled after it - including in evals - cannot compile down to anything that uses any opcode deemed unsafe. This industrial strength approach avoids a lot (most?) of the problems with Safe - but then your module would be dropping permissions permenantly so that unsafe things don't appear in config files. On one hand, drop as much priviledge as early as possible. On the other, don't invite disaster - like me. Use YAML or XML or SGML or ... something.

    I hope this amuses and/or helps.
      You can't really call ops a bastard cousin of Safe - the latter relies on the former. And if you're not using Safe you'll need to duplicate its provisions for additional safety, which is is to isolate compartments from the main script completely by dissociating their namespace from the real %main::. Just using ops does not provide this - which is in fact the whole point of Safe.

      Makeshifts last the longest.

        Question: Do either of these approaches deal with the BEGIN block bug? Which is where, if I'm not mistaken, the code in the BEGIN block is executed before the safe/ops module is loaded, thus rendering the entire thing pointless? Or is this not a bug any more?

        And while I'm pondering, what about keeping the 'unsafe' code seperate from the main code, then run the main code then as a run-time directive 'require' the unsafe code, probably as something like SAFE{ do } or however safe blocks are actually implemented?
        Thanks a lot, Aristotle, for attempting to correct any possibly misleading meanings. and both use Neither nor use either other. As I said and as Artistotle echos here, doesn't compartmentalize - it drops "permissions" completely. Of course, permissions are access to opcodes.

        This is far afield of the original question, and I'm not here for the chatter. The original question was, does thwart attacks? My answer was simply that I do trust to do just that - thwart attacks - and is related to, and the original author should consider another direction entirely for what he is trying to do, dispite this validation.

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://305881]
Front-paged by broquaint
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (4)
As of 2024-05-27 18:56 GMT
Find Nodes?
    Voting Booth?

    No recent polls found