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.

In reply to Re^6: Completely removing a perl function. by Anonymous Monk
in thread Completely removing a perl function. by BUU

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.