retiring gets(3)

Chris Torek chris at mimsy.UUCP
Thu Nov 10 21:37:53 AEST 1988


In article <2044 at cbnews.ATT.COM> lvc at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list