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!
| [reply] [d/l] [select] |
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). | [reply] |
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.
| [reply] |
|
Did you have a look at Safe.pm http://search.cpan.org/~rgarcia/Safe-2.11/Safe.pm ?
| [reply] |
|
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.
| [reply] |
|
|
|
|
|
Re: Completely removing a perl function.
by ikegami (Patriarch) 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
- identify who/what needs to be protected ("What assets are you trying to protect?"), and to
- 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.
| [reply] |
|
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.
| [reply] |
|
How is this arbitrary perl being submitted? Running the submission through =~ s/shmget/exit;/g would probably do the trick for web forms.
| [reply] [d/l] |
Re: Completely removing a perl function.
by scmason (Monk) on Jun 30, 2006 at 05:14 UTC
|
| [reply] |
|
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.
| [reply] |