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

[Wonderly]

>From article <8995 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):
> In article <4869 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
>>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?
> 
> ...
>
> 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 at ihlpb.att.com
It's a direction!                          UUCP:   att!ihlpb!gregg