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