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

[Rahul Dhesi]

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?

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:  <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi