Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!felix!jim
From: jim@felix.UUCP
Newsgroups: comp.os.minix
Subject: 8086/8088 Stack Overwrite Vulnerability
Message-ID: <2252@felix.UUCP>
Date: Mon, 9-Feb-87 13:14:14 EST
Article-I.D.: felix.2252
Posted: Mon Feb  9 13:14:14 1987
Date-Received: Tue, 10-Feb-87 07:12:48 EST
Sender: root@felix.UUCP
Reply-To: jim@felix.UUCP (Jim Gilbert)
Distribution: world
Organization: FileNet Corp., Costa Mesa, CA
Lines: 28

Stuart Lynne has, with some considerable vigor ("RTFM!" several times),
claimed that 8086/8 code emitted by compilers using only intra-segment
calls and returns is not vulnerable to programs overwriting the stack.

So long as you are lucky, he is right.  Suppose, however, that 
we have only intra-segment calls, and the routine called modifies
the saved return address to coincidentally point into the middle of
an instruction, perhaps containing some 16-bit immediate data which
happens to be an inter-segment return op code.  Well, the processor will
cheerfully return to the code segment it came from, pick up the
data thinking its an opcode, interpret it as an intersegment return
and transfer to wherever the other scribbled-over words on the stack point.
I admit that this is a multiple-step process.  But the hole is there unless
Stuart is willing to insist that the compilers never generate intersegment
return opcodes as part of any instruction after the opcode byte, which seems
a bit Draconian.

It is, of course, possible to provide completely safe multi-user programming
environments on such an architecture.  One could implement a type-cheating
proof Pascal, a BASIC dialect without user access to assembly level
features, or so forth.  Most C implementations are, however, vulnerable
to the kinds of shenanigans described.

Jim Gilbert

...hplabs!felix!jim

(Ninety-five per cent of the men who have tried camels prefer women.)