Xref: utzoo comp.lang.c:14322 comp.unix.wizards:12915 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.lang.c,comp.unix.wizards Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Message-ID: <4869@bsu-cs.UUCP> Date: 26 Nov 88 20:23:42 GMT References: <867@cernvax.UUCP> <645@quintus.UUCP> <339@igor.Rational.COM> <644@scotty.UUCP> <288@ispi.UUCP> <2330@cbnews.ATT.COM> Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 28 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? 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. (I don't know if hardware separation of code and data inhibited the worm but it would still leave the same loophole there for exploitation in some other way.) However, it is rumored that there are machines that maintain a tag value with each word. On such a machine, a return address on the stack would be tagged as a 'code address'. Overwriting it with the data read by gets() would remove the 'code address' tag and replace it with a 'character data' tag, preventing a return to that address. Such a machine would not permit you to change a 'data' tag to a 'code address' tag without either doing a system call or executing a "jump to subroutine" instruction that would automatically push an address with a 'code address' tag on the stack. Unfortunately, this might seriously hinder the assembly-language programmer who wishes to play around with return addresses for code optimization. -- Rahul Dhesi UUCP:!{iuvax,pur-ee}!bsu-cs!dhesi