Re^4: Completely removing a perl function.

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.

Comment on Re^4: Completely removing a perl function.

Replies are listed 'Best First'.
Re^5: Completely removing a perl function. by Anonymous Monk on Jun 28, 2006 at 18:29 UTC
For example, there's no way to directly write to a specific memory address in Perl (without using XS). I think you mean to say that there's no supported way to write to a specific memory address in Perl. There are many unsupported methods to do so.	[reply]
Re^6: Completely removing a perl function. by Anonymous Monk on Jun 29, 2006 at 16:04 UTC
Those are bugs in perl. They're not there by design, they're not supposed to be there, and if the implementation was correct, they wouldn't be there.	[reply]
Re^7: Completely removing a perl function. by ikegami (Patriarch) on Jun 29, 2006 at 16:22 UTC
So? Security deals with reality, not theoretical ideals.	[reply]
Re^5: Completely removing a perl function. by Moron (Curate) on Jun 29, 2006 at 09:01 UTC
I already pointed out that C would be used at some point in this escalating battle for control of a Perl implementation. And if C were controlled, the hacker has assembler and then raw machine code waiting in the line-up - there is no answer to that. -M Free your mind	[reply]
Re^6: Completely removing a perl function. by Anonymous Monk on Jun 29, 2006 at 16:01 UTC
I already pointed out that C would be used at some point in this escalating battle for control of a Perl implementation. And if C were controlled, the hacker has assembler and then raw machine code waiting in the line-up - there is no answer to that. The answer is: don't let him do that sort of thing in the first place! Why does some random hacker have access to upload and run assembly language code on your machine, and why doesn't the operating system and/or hardware stop him when he tries to execute instructions for which he has no permissions? If someone only needs to execute perl, then only give him access to upload and run perl. Don't let him run C. code, assembly language code, or any other binary code! Make his nly option to execute perl on any of the files which he has uploaded: and reject any perl script which contains calls to system, backquotes, or XS (preferably, by taking support for those features out of the binary in the first place). Tamper-proof systems are fundamentally possible. Here's a simple example. Suppose I want to prevent hackers from remotely accessing my files. I just ensure that the network cable is unplugged whenever I slot in the flash RAM card that holds my private files is installed, and that I take the memory card out of my computer before I plug the network cable back in. No matter how clever the hacker is, and no matter how much assembly language he knows, he can't defeat physics. He also can't defeat logic. If my operating system always checks the op-codes of all user space programs, and correctly rejects programs that try to read beyond their allocated address space, my program can't access another program's data, whether my program was originally written in perl, C., assembly, or Intercal. The O/S will intercept the attempt, and terminate the program before it can do any harm. If the O/S also zeros out all memory in the data segments allocated to userspace programs, then my program can't read leftover data from old programs, because it simply doesn't exist. The only time a hacker has an opportunity to cause mischief is when the implementor in charge of security screws up; and he can only exploit that mistake to the extent of the screw up. Hackers can't work magic out of thin air, and in absence of mistakes to exploit, they can't do anything.	[reply]
Re^7: Completely removing a perl function. by ikegami (Patriarch) on Jun 29, 2006 at 16:30 UTC
Who said anything about "some random hacker"? Let's find out what the OP really wants.	[reply]
Re^7: Completely removing a perl function. by eric256 (Parson) on Jun 29, 2006 at 22:58 UTC
Not to add flames but.... ;) In your file access argument you claim the hacker couldn't access your files. That isn't deducible from your argument. Say for instance he got a trojan on your system, even when disconnected from the network the virus monitors. Once you then reconnect, off your precious files go over the network. Does this mean you can't make a secure system? Of coures not. Does it mean you can make a secure system?...nope. I would venture to think that computer security is like personal security. How secure you are depends on how many freedoms you want to give up. So you way trade offs, is it worth the trouble of carrying a key to have a lock on your house. What about giving up your freedom to fly without ID? Hopefully people remember this before the current security crazy gets too out of hand. Anyone its the same with computers. Are you willing to give up your internet for security? Are you willing to give up your favorite OS for a better OS that is more secure. Are you willing to enter a password to access any file to secure it? Do you use a more secure but less friendly browser? Do you set windows to always ask some stupid questions to catch those one or two spyware programs it will stop? Do you deal with firewalls? Virus scan? Adware scan? etc. The list is obviously quite large but the point is that you can probably be 100% secure...but then are you still 100% functional? Obviously the answer varies from machine to machine, user to user, circumstance to circumstanc. Just my ramblings! "The only time a hacker has an opportunity to cause mischief is when the implementor in charge of security screws up; and he can only exploit that mistake to the extent of the screw up. Hackers can't work magic out of thin air, and in absence of mistakes to exploit, they can't do anything." Could such a system exist? Probably. Does it? I would venture to bet not. ___________ Eric Hodges	[reply]
Re^7: Completely removing a perl function. by Moron (Curate) on Jun 29, 2006 at 16:42 UTC
The OS already prevents such access violations . But in the given scenario there is no need for the hacker to overcome that -- under the scenario, we are talking about what the hacker can do within the accessible memory of his process. It isn't feasible to write and even less to run a watchdog program as demanding as the one you are talking about. Shutdown/disablement? Yes, technically you are right - but even if you get the authority for such a measure - heads are going to roll and yours will be rather high on the hitlist. -M Free your mind	[reply]


Perl: the Markov chain saw
	PerlMonks