Xref: utzoo comp.lang.c:14336 comp.unix.wizards:12931 Path: utzoo!attcan!uunet!husc6!mailrus!eecae!cps3xx!rang From: rang@cpsin3.cps.msu.edu (Anton Rang) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Summary: Don't blame the VAX, blame U**X Message-ID: <1189@cps3xx.UUCP> Date: 28 Nov 88 15:30:11 GMT References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <4869@bsu-cs.UUCP> <14733@mimsy.UUCP> Sender: usenet@cps3xx.UUCP Reply-To: rang@cpswh.cps.msu.edu (Anton Rang) Organization: Michigan State University, Computer Science Dept. Lines: 25 In-reply-to: chris@mimsy.UUCP's message of 28 Nov 88 03:53:46 GMT One quick note here... Chris Torek (chris@mimsy.UUCP), in article 14733@mimsy.UUCP, writes: >>In article <2330@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) >>asks: >>>Was the one of the reasons the two processor types were attacked >>>because they would allow code to be executed in data space? >(It is worth noting that the fingerd attack was applied only to VAXen.) > [ stuff deleted ] >Now, if the VAX hardware had refused to execute data pages---perhaps >by refusing to execute any pages with user-write permission enabled--- >the worm could not have run code off the stack. VAX processors do have separate bits for read, write, and execute on each page (I seem to vaguely recall one more). The problem lies with the implementation of BSD and Ultrix, which leave the stack executable; I can't see any reason for this offhand. +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+