Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Completely removing a perl function.

by BUU (Prior)
on Jun 28, 2006 at 08:12 UTC ( #557963=perlquestion: print w/ replies, xml ) Need Help??
BUU has asked for the wisdom of the Perl Monks concerning the following question:

I've been playing around with trying to completely remove the ability to call a specific perl function (shmget if you care). I've tried the usual tricks like:
BEGIN{*CORE::GLOBAL::shmget=sub{die}}
And so on, but they can all be trivially circumvented by this code: BEGIN{ undef *CORE::GLOBAL::shmget }. Simply add that code after any attempts to remove shmget and shmget magically springs back to life. So now I ask you: anyone have a better idea for removing it? I'll cheerfully take XS and B:: evilness.

Comment on Completely removing a perl function.
Select or Download Code
Re: Completely removing a perl function.
by rblasch (Monk) on Jun 28, 2006 at 08:27 UTC
    Not sure if that's exactly what you are looking for, but check out Safe (and Opcode).
Re: Completely removing a perl function.
by Sidhekin (Priest) on Jun 28, 2006 at 08:37 UTC

    You may use the ops pragma, as it "currently has an irreversible global effect":

    sidhekin@blackbox:~$ perl -le 'no ops "shmget"; shmget 5, 4, 3' 'shmget' trapped by operation mask at -e line 1. sidhekin@blackbox:~$

    print "Just another Perl ${\(trickster and hacker)},"
    The Sidhekin proves Sidhe did it!

Re: Completely removing a perl function.
by Moron (Curate) on Jun 28, 2006 at 09:20 UTC
    If you mean an unbreakable solution, then I would say that there is no such thing as 100% security. For every measure you apply, there are an infinite no. of ways to get around it just waiting for a creative hacker to find. Each time you find one you'll implement a new measure for which there will also be an antidote.

    For example, suppose you replace /usr/bin/perl with a wrapper that disables the function in the perl command options. So your hacker needs only to find out where you put the original program and shebang that instead. So then you are at stage 2 of the battle and have to make the original program no-execute and make your wrapper call setruid before running the original interpreter with your enforced options. Hacker counters by making a copy of your wrapper and editing it with the right I/O options to preserve its sticky bit on close. So at stage 3 you rewrite in C to counter again. Hacker is still not prevented - he writes his own wrapper to patch yours in memory - and so on ad infinitum. It's called 'core wars' by some of those who do it for fun.

    -M

    Free your mind

      Did you have a look at Safe.pm http://search.cpan.org/~rgarcia/Safe-2.11/Safe.pm ?
        I can't prove my theory that to every measure there exists a countermeasure - it would be an infite proof. But I am sure the same principles of non-100% security will apply to Safe - it is a matter of creative thinking. The first two ideas that come to mind (that a hacker might try to compromise Safe.pm):

        - download and modify the source and use a modified version of Safe.pm

        - change its code or access to it in a BEGIN block

        I am sure others can think up more.

        -M

        Free your mind

Re: Completely removing a perl function.
by ikegami (Pope) on Jun 29, 2006 at 16:12 UTC

    What are you really trying to do? Who are you trying to prevent from accessing this function? As you can see from other posts, this is a security issue. Security problems have solutions, but we need to identify the problem before we can find the solution. Identifying the problem requires us to

    1. identify who/what needs to be protected ("What assets are you trying to protect?"), and to
    2. identify from whom/what it needs to be protected ("What are the risks to the assets?").

    Could you elaborate on these topics. We can't develop you devise a means of protection without clear information on them. What you told us to be protected sounds too specific, and we have no information on that from which it should be protected.

      Honestly that was what I was trying to accomplish. I execute arbitrary perl and the only minor security hole is that shmget allows people to allocate shared memory that never goes away, which apparently has a negative effect when other processes later want shared memory.
        How is this arbitrary perl being submitted? Running the submission through =~ s/shmget/exit;/g would probably do the trick for web forms.
Re: Completely removing a perl function.
by scmason (Monk) on Jun 30, 2006 at 05:14 UTC
    The best way to do this would be to hack into the Perl internals and remove the functions visibility and then recompile. Should not be too difficult and would be bulletproof.

    "Never take yourself too seriously, because everyone knows that fat birds dont fly" -FLC
      Heh, I've actually considered this, but it's a huge pain for a large number of reasons, so I was hoping to avoid it. Maybe I can hack up something scary involving XS.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://557963]
Approved by GrandFather
Front-paged by bart
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (7)
As of 2014-12-20 16:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (96 votes), past polls