Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!umn-d-ub!nic.MR.NET!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <14462@mimsy.UUCP>
Date: 10 Nov 88 11:37:53 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <1031@cps3xx.UUCP> <2044@cbnews.ATT.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 29

In article <2044@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence
V. Cipriani) writes:

[re recent Internet `worm'; note that R. T. Morris Jr. is still merely
the `alleged' perpetrator---we have to give him the benefit of the
doubt, first; *then* we can rip his arms off :-) ]

>... in fingerd.  Morris managed to get just the right "data" to go
>past the end of buf so that the program behavior was modified the way he
>needed.  Usually reading data passed the end of a buffer gives you a fatal
>error and your process dies.  In this case (I'm really reaching here), the
>stack was modified, say change the return address, to do "something special"
>like go around some permission checks.

You may be reaching, but you are right.  The fingerd attack wrote more
bytes than there were in the buffer passed to gets(); the `extra' bytes
were a hand-crafted stack that `returned' into the stack, into the
buffer itself.  The part just before the hand-crafted stack contained
code to to call execve("/bin/sh", (char **)0, (char **)0).  (There
were in fact ASCII NUL characters embedded in this code; curiously,
gets() reads and stores NULs in its search for '\n'.)

This attack failed if you had made any changes to fingerd or to the C
library start-up code such that the buffer was in a different place on
the stack.  I myself had expanded the buffer, so that there was plenty
of room for the `extra' bytes.  (Hurrah for local modifications! :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris