Re: Completely removing a perl function.

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

Comment on Re: Completely removing a perl function.

Replies are listed 'Best First'.
Re^2: Completely removing a perl function. by Anonymous Monk on Jun 28, 2006 at 14:18 UTC
Did you have a look at Safe.pm http://search.cpan.org/~rgarcia/Safe-2.11/Safe.pm ?	[reply]
Re^3: Completely removing a perl function. by Moron (Curate) on Jun 28, 2006 at 14:37 UTC
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	[reply]
Re^4: Completely removing a perl function. by Anonymous Monk on Jun 28, 2006 at 18:08 UTC
There are lots of measures which don't allow countermeasures. If there weren't, any attempt to secure a system would be pointless. As the system gets more more complex, it becomes harder, but not impossible, to ensure that there are no countermeasures for any of the features that comprise the system, while still allowing legitimate access to people who need it. Removing a given feature outright is usually not that difficult. For example, removing the feature (shmget), plus all the general system interfaces, ( let's start by eliminating syscall(), system(), backquotes and XS bindings from the secure version of the language), and taking it out of the perl binary itself would be essentially unbreakable. If you can't make a system call, and the system call is the only interface to features protected by the O/S, then you can't tamper with those features, period. You can write all the code you want, but if you can't bypass the control mechanisms, you're out of luck. For example, there's no way to directly write to a specific memory address in Perl (without using XS). So, if a hack relies on tampering with perl source code to access a specific memory address, it will always fail. That's an example of a language specific feature that's not circumventable.	[reply]
Re^5: Completely removing a perl function. by Anonymous Monk on Jun 28, 2006 at 18:29 UTC
Re^6: Completely removing a perl function. by Anonymous Monk on Jun 29, 2006 at 16:04 UTC
Some notes below your chosen depth have not been shown here
Re^5: Completely removing a perl function. by Moron (Curate) on Jun 29, 2006 at 09:01 UTC
Re^6: Completely removing a perl function. by Anonymous Monk on Jun 29, 2006 at 16:01 UTC
Some notes below your chosen depth have not been shown here


Clear questions and runnable code get the best and fastest answer
	PerlMonks