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