Insecure hardware (was Re: gets(3) nonsense)

[Doug Gwyn]

In article <4869 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <2330 at cbnews.ATT.COM> lvc at cbnews.ATT.COM (Lawrence V. Cipriani) writes:
>>Was the one of the reasons the two processor types were attacked
>>because they would allow code to be executed in data space?

I think one of the reasons was that those machines just happened to be
AVAILABLE for compilation of the source to produce the objects that
were shipped around.  However, the particular form that the fingerd
attack took would not work on a system that supported only split-I&D
spaces.

>The fingerd bug was that sending a long line to it via gets() allowed
>you to push anything you wanted on the stack.  Since the stack contains
>both data and return addresses, keeping code space and data space
>separate would probably not have helped.

No, this is wrong.  On a split-I&D machine, return addresses are in
D space but instructions are in I space.  Therefore, the code being
returned to would have had to have been placed in I space, which is
not normally something an unprivileged process can accomplish (other
than by one of a limited class of system calls, e.g. exec on UNIX).

Tags are not required for split-I&D implementations; just consider
the PDP-11 for an example.  Tagged architectures and other uncommon
architectures could also pose barriers, but split-I&D would have
been sufficient to block that particular virus/work attak path.
However, there were (and probably are) still plenty of exploitable
security holes for such viruses to enter.

Note that most common systems that support split I&D spaces do
not REQUIRE their use; the space separation would have to be
ENFORCED to serve as a practical security barrier.  There are
also a lot of subtle details that would have to be gotten right;
I have never in my decades of working with computers seen an
absolutely secure architectural implementation (not even Multics
was 100% secure).