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 |                      |
+---------------------------+------------------------+----------------------+