Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!uflorida!ukma!tut.cis.ohio-state.edu!osu-cis!att!cbnews!lvc
From: lvc@cbnews.ATT.COM (Lawrence V. Cipriani)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <2044@cbnews.ATT.COM>
Date: 9 Nov 88 22:16:07 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <1031@cps3xx.UUCP>
Reply-To: lvc@cbnews.ATT.COM (Lawrence V. Cipriani)
Organization: AT&T Bell Laboratories
Lines: 21

In article <1031@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
>This may be a naive question, or perhaps I haven't followed the right
>stories, but what is the problem with using gets versus fgets?

The only argument to gets() is a character pointer, or buffer; fgets() has
a FILE*, a character buffer, and most importantly a count.  Used properly,
this prevents writing passed the end of the buffer.  Since gets() doesn't
have the count, this could be used to read passed the end of some buffer,
say buf, 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.  Neat, very neat.  Now will someone
please send me a copy of Morris's program :-)

>John H. Lawitzke      UUCP: ...rutgers!mailrus!frith!fciiho!jhl

-- 
Larry Cipriani, AT&T Network Systems, Columbus OH,
Path: att!cbnews!lvc    Domain: lvc@cbnews.ATT.COM