Xref: utzoo comp.lang.c:14331 comp.unix.wizards:12926 Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Message-ID: <8995@smoke.BRL.MIL> Date: 28 Nov 88 11:07:57 GMT References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <644@scotty.UUCP> <288@ispi.UUCP> <2330@cbnews.ATT.COM> <4869@bsu-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 36 In article <4869@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <2330@cbnews.ATT.COM> lvc@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).