Xref: utzoo comp.lang.c:14354 comp.unix.wizards:12958
Path: utzoo!utgpu!watmath!clyde!att!ihlpb!gregg
From: gregg@ihlpb.ATT.COM (Wonderly)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Insecure hardware (was Re: gets(3) nonsense)
Message-ID: <9119@ihlpb.ATT.COM>
Date: 29 Nov 88 03:15:49 GMT
References: <8995@smoke.BRL.MIL>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 47

From article <8995@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ):
> In article <4869@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>>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?
> 
> ...
>
> However, there were (and probably are) still plenty of exploitable
> security holes for such viruses to enter.

Just to demonstrate how vunerable we can make ourselves,

Consider my naive implementation of fingerd which, on most architectures
with a decending address, local variable stack allocation stratedgy
can be compromised, after a little investigation.

main ()
{
	char vec[10];
	int vecp = 1;
	char buf[512];

	vec[0] = "/usr/ucb/finger";
	if (gets(buf) != NULL)
		vec[vecp++] = buf;

	vec[vecp++] = NULL

	execvp (vec[0], vec);
	perror (vec[0]);
}

One only needs to write the appropriate strings, a value for vecp,
and a value for vec[0-?] to the programs standard input to force
execution of your choice of programs.  Naturally, there is less
freedom (actually none) of the values one might write into the 
array of pointers, but all it takes is the source and a wee bit of
knowledge about the STANDARD environment that sooooo many turnkey
UN*X boxes have these days, and you are in.

This is just one method of many...


-- 
It isn't the DREAM that NASA's missing...  DOMAIN: gregg@ihlpb.att.com
It's a direction!                          UUCP:   att!ihlpb!gregg