gets() - dangerous?

Discussion in 'C Programming' started by Lee, Dec 24, 2005.

  1. Lee

    Lee Guest

    Hi

    Whenever I use the gets() function, the gnu c compiler gives a
    warning that it is dangerous to use gets(). Is this due to the
    possibility of array overflow? Is it correct that the program flow can
    be altered by giving some specific calculated inputs to gets()? How
    could anyone do so once the executable binary have been generated? I
    have heard many of the security problems and other bugs are due to
    array overflows.

    Looking forward to your replies.
    Lee
    Lee, Dec 24, 2005
    #1
    1. Advertising

  2. Lee

    Jack Klein Guest

    On 23 Dec 2005 20:29:01 -0800, "Lee" <> wrote in
    comp.lang.c:

    > Hi
    >
    > Whenever I use the gets() function, the gnu c compiler gives a
    > warning that it is dangerous to use gets(). Is this due to the
    > possibility of array overflow? Is it correct that the program flow can
    > be altered by giving some specific calculated inputs to gets()? How
    > could anyone do so once the executable binary have been generated? I
    > have heard many of the security problems and other bugs are due to
    > array overflows.
    >
    > Looking forward to your replies.
    > Lee


    The solution is simple: don't use gets(). Not ever. As to what
    happens if you do use gets() and the quantity of input is greater than
    the destination space, the C language does not know or care. As to
    how this undefined behavior might be exploited by someone with
    malicious intent, that too is not a language issue.

    The authors of your compiler, quite properly and responsibly, take it
    upon themselves to warn you that you should not use gets(). Why are
    you still using it?

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Dec 24, 2005
    #2
    1. Advertising

  3. On 23 Dec 2005 20:29:01 -0800, "Lee" <> wrote:

    >Hi
    >
    > Whenever I use the gets() function, the gnu c compiler gives a
    >warning that it is dangerous to use gets(). Is this due to the
    >possibility of array overflow? Is it correct that the program flow can


    Yes

    >be altered by giving some specific calculated inputs to gets()? How


    Yes

    >could anyone do so once the executable binary have been generated? I
    >have heard many of the security problems and other bugs are due to
    >array overflows.
    >
    >Looking forward to your replies.


    Don't hold your breath. Buffer overflow is not a c language topic.


    <<Remove the del for email>>
    Barry Schwarz, Dec 24, 2005
    #3
  4. Lee

    nickptar Guest

    nickptar, Dec 24, 2005
    #4
  5. Lee

    Jack Klein Guest

    On 23 Dec 2005 21:53:53 -0800, "nickptar" <> wrote
    in comp.lang.c:

    >
    > Barry Schwarz wrote:
    >
    > > Don't hold your breath. Buffer overflow is not a c language topic.

    >
    > But is well documented elsewhere:
    > http://en.wikipedia.org/wiki/Buffer_overflow


    Nothing in Wikipedia can be considered well documented without
    additional credible references.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Dec 24, 2005
    #5
  6. nickptar wrote:
    > Barry Schwarz wrote:
    >
    > > Don't hold your breath. Buffer overflow is not a c language topic.

    >
    > But is well documented elsewhere:
    > http://en.wikipedia.org/wiki/Buffer_overflow


    This is possibly the most poorly-written and inaccurate article I have
    read on wikipedia, did you even read it before posting the link?

    Robert Gamble
    Robert Gamble, Dec 24, 2005
    #6
  7. Lee

    Chuck F. Guest

    Jack Klein wrote:
    > "Lee" <> wrote in comp.lang.c:
    >
    >> Whenever I use the gets() function, the gnu c compiler gives
    >> a warning that it is dangerous to use gets(). Is this due to
    >> the possibility of array overflow? Is it correct that the
    >> program flow can be altered by giving some specific calculated
    >> inputs to gets()? How could anyone do so once the executable
    >> binary have been generated? I have heard many of the security
    >> problems and other bugs are due to array overflows.

    >
    > The solution is simple: don't use gets(). Not ever. As to
    > what happens if you do use gets() and the quantity of input is
    > greater than the destination space, the C language does not know
    > or care. As to how this undefined behavior might be exploited
    > by someone with malicious intent, that too is not a language
    > issue.
    >
    > The authors of your compiler, quite properly and responsibly,
    > take it upon themselves to warn you that you should not use
    > gets(). Why are you still using it?


    However you can always use ggets() (note the extra g, for good).
    This was written to have the convenience and simplicity of gets,
    without any possible overrun. The ISO standard source (thus
    portable to any system) is available at:

    <http://cbfalconer.home.att.net/download/ggets.zip>

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Chuck F., Dec 24, 2005
    #7
  8. Lee

    Malcolm Guest

    "Jack Klein" <> wrote
    >
    > Nothing in Wikipedia can be considered well documented without
    > additional credible references.
    >

    <OT>
    That's what crusty academics say because a new competitor has come along. Of
    course they want people to rely on peer-reviewed literature where they are
    the peers.

    In fact something like 50% of scientific papers make conclusions which are
    later refuted or challenged by further papers. (read Iohannis for a
    peer-reviewed take on the subject).
    No medium written by humans can guarantee complete accuracy, freedom form
    bias, etc. Wikipedia is no different from any other source.
    Malcolm, Dec 24, 2005
    #8
  9. Lee said:

    > Hi
    >
    > Whenever I use the gets() function, the gnu c compiler gives a
    > warning that it is dangerous to use gets().


    No, it's the linker that warns you, not the compiler.

    > Is this due to the possibility of array overflow?


    Yes.

    > Is it correct that the program flow can be altered by giving some
    > specific calculated inputs to gets()?


    Yes.

    > How could anyone do so once the executable binary have been generated?


    By overwriting the stack, for example. On a typical machine, the program is
    loaded from disk into memory before execution. During execution, it is
    present in memory. And the thing about memory is that it can be overwritten
    with new values.

    > I have heard many of the security problems and other bugs are due to
    > array overflows.


    Quite.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Dec 24, 2005
    #9
  10. Malcolm wrote:
    > "Jack Klein" <> wrote
    >
    >>Nothing in Wikipedia can be considered well documented without
    >>additional credible references.
    >>

    >
    > <OT>
    > That's what crusty academics say because a new competitor has come along. Of
    > course they want people to rely on peer-reviewed literature where they are
    > the peers.


    However, it is always useful to see where the author got the
    idea/solution or based her/his own conclusions.

    > In fact something like 50% of scientific papers make conclusions which are
    > later refuted or challenged by further papers. (read Iohannis for a
    > peer-reviewed take on the subject).
    > No medium written by humans can guarantee complete accuracy, freedom form
    > bias, etc. Wikipedia is no different from any other source.


    Yes, for that reason papers are wrote and commented and referenced. To
    prove their accuracy, correct them or throw them away.
    Giannis Papadopoulos, Dec 24, 2005
    #10
  11. Lee

    Malcolm Guest

    "Giannis Papadopoulos" <> wrote
    >
    >> No medium written by humans can guarantee complete accuracy, freedom form
    >> bias, etc. Wikipedia is no different from any other source.

    >
    > Yes, for that reason papers are wrote and commented and referenced. To
    > prove their accuracy, correct them or throw them away.
    >

    Papers are peer-reviewed as a means of selecting which are and which are not
    published. Most publications receive more material then they can or want to
    print.

    Further claims are then made for peer-reviewed literature, which are largely
    unwarranted. In particular, peer review does not "prove accuracy".
    Malcolm, Dec 24, 2005
    #11
  12. Lee

    Guest

    Jack Klein wrote:
    > On 23 Dec 2005 20:29:01 -0800, "Lee" <> wrote in
    > comp.lang.c:
    > > Whenever I use the gets() function, the gnu c compiler gives a
    > > warning that it is dangerous to use gets().


    Personally, I am waiting for the compiler that implements gets as the
    following:

    char * gets (char * s) {
    unlink (__FILE__); /* POSIX */
    return s;
    }

    Since it would improve its predictability.

    > [...] Is this due to the
    > > possibility of array overflow? Is it correct that the program flow can
    > > be altered by giving some specific calculated inputs to gets()? How
    > > could anyone do so once the executable binary have been generated? I
    > > have heard many of the security problems and other bugs are due to
    > > array overflows.
    > >
    > > Looking forward to your replies.
    > > Lee


    (My recommendation is to *learn* about the problem here:
    http://www.pobox.com/~qed/userInput.html )

    > The solution is simple: don't use gets(). Not ever.


    Hmmm ... here's a rhetorical question. What is the value of a
    specifying a function in the language definition if you can't even use
    it -- not ever?

    > [...] As to what
    > happens if you do use gets() and the quantity of input is greater than
    > the destination space, the C language does not know or care. As to
    > how this undefined behavior might be exploited by someone with
    > malicious intent, that too is not a language issue.
    >
    > The authors of your compiler, quite properly and responsibly, take it
    > upon themselves to warn you that you should not use gets(). Why are
    > you still using it?


    Well, fundamentally, the reason he uses it is because its there, and
    because the language standard itself continues to endorse the use of
    this function. Unfortunately, the compiler, even after warning you,
    and with all sorts of comments telling you about it in the man pages,
    goes ahead and compiles/links the code. The compiler/linker *could*
    simply dump out with an error unless you give it a -unsafe flag or
    something like that. I still don't know who exactly is pulling for the
    continued support for this function, but they seem to have a lot of
    influence over compiler vendors and the standards committee.

    The OP sees this linker warning as an annoyance, and wants to make the
    annoyance go away. He's lucky in that here are some reponses here
    telling him to stop using the function, but on another day he'd just
    get a lot of bickering about top-posting, or forgetting to quote a
    previous post or quoting too much of one.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Dec 24, 2005
    #12
  13. Lee

    Jordan Abel Guest

    On 2005-12-24, <> wrote:
    > Jack Klein wrote:
    >> On 23 Dec 2005 20:29:01 -0800, "Lee" <> wrote in
    >> comp.lang.c:
    >> > Whenever I use the gets() function, the gnu c compiler gives a
    >> > warning that it is dangerous to use gets().

    >
    > Personally, I am waiting for the compiler that implements gets as the
    > following:
    >
    > char * gets (char * s) {
    > unlink (__FILE__); /* POSIX */
    > return s;
    > }
    >
    > Since it would improve its predictability.


    The problem is that, while gets _can_ invoke undefined behavior based
    on things the programmer has no control over, it is well-defined as long
    as that does not happen - this is the same reason that it's not legal
    for an implementation to reject a program using it
    Jordan Abel, Dec 24, 2005
    #13
  14. Lee

    Guest

    Jack Klein wrote:
    > On 23 Dec 2005 21:53:53 -0800, "nickptar" <> wrote
    > in comp.lang.c:
    > > Barry Schwarz wrote:
    > >
    > > > Don't hold your breath. Buffer overflow is not a c language topic.

    > >
    > > But is well documented elsewhere:
    > > http://en.wikipedia.org/wiki/Buffer_overflow

    >
    > Nothing in Wikipedia can be considered well documented without
    > additional credible references.


    Uh ... according to a recent independent study, the Encyclopedia
    Britanica has only a 33% better error rate than Wikipedia (meaning
    Wikipedia has roughly 33% more errors per article than Britanica.) Now
    of course, that doesn't mean you should rely solely on Wikipedia, but
    what it means is that if you should apply roughly the same degree of
    trust to Wikipedia that you would a reasonable encyclopedia (maybe its
    as good as Funk & Wagnals :) )

    The funny ironic thing about supposed experts who complain about the
    accuracy of Wikipedia is that they don't bother to come to the
    realization that the degree of correctness of any given Wikipedia
    article is actually in their hands. I wonder -- in who's interest is
    it to denigrate or attack Wikipedia.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Dec 24, 2005
    #14
  15. said:

    > Jack Klein wrote:
    >> On 23 Dec 2005 20:29:01 -0800, "Lee" <> wrote in
    >> comp.lang.c:
    >> > Whenever I use the gets() function, the gnu c compiler gives a
    >> > warning that it is dangerous to use gets().

    >
    > Personally, I am waiting for the compiler that implements gets as the
    > following:
    >
    > char * gets (char * s) {
    > unlink (__FILE__); /* POSIX */


    remove(__FILE__); /* ISO */

    >> The solution is simple: don't use gets(). Not ever.

    >
    > Hmmm ... here's a rhetorical question. What is the value of a
    > specifying a function in the language definition if you can't even use
    > it -- not ever?


    None whatsoever. So let's drop it from the language definition.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Dec 24, 2005
    #15
  16. On 24 Dec 2005 09:35:29 -0800, in comp.lang.c ,
    wrote:

    >Uh ... according to a recent independent study, the Encyclopedia
    >Britanica has only a 33% better error rate than Wikipedia


    If you examine the study rather than news reports on it from seemingly
    uninformed journos, you will find that Nature deliberately excluded
    articles which might be subject to any contention, disagreement or
    debate, ie anything in humanities, much of the science, politics, and
    all biography. This eliminates virtually all of Wikipedia I suspect.

    And 33% more errors in the articles there is no debate about sounds
    pretty dang poor to me. :)

    >The funny ironic thing about supposed experts who complain about the
    >accuracy of Wikipedia is that they don't bother to come to the
    >realization that the degree of correctness of any given Wikipedia
    >article is actually in their hands.


    I always love this bullshit argument.
    "Someone else wrote lies and/or misinformation but thats not their
    fault, its yours for not spending your time fixing it."

    Er, no. Its the fault of the person who was too lazy, biassed or
    ignorant to get the facts right in the first place, and its the fault
    of the maintainers of wikipedia for not applying better editorial
    control.

    >I wonder -- in who's interest is it to denigrate or attack Wikipedia.


    And in whose interest is it to defend it, even when faced with a
    glaring failure ?

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Dec 24, 2005
    #16
  17. a écrit :
    > Personally, I am waiting for the compiler that implements gets as the
    > following:
    >
    > char * gets (char * s) {
    > unlink (__FILE__); /* POSIX */


    Why using an extension when the standard function does exist ?

    remove (__FILE__);

    > return s;
    > }


    BTW, I suppose that you want some [C99] 'inline'. If not, the effect
    would be limited (the implementation file is probably not that close)

    --
    A+

    Emmanuel Delahaye
    Emmanuel Delahaye, Dec 24, 2005
    #17
  18. Emmanuel Delahaye said:

    > a écrit :
    >>
    >> char * gets (char * s) {
    >> unlink (__FILE__); /* POSIX */

    >
    > Why using an extension when the standard function does exist ?


    Good question.

    > remove (__FILE__);
    >
    >> return s;
    >> }

    >
    > BTW, I suppose that you want some [C99] 'inline'. If not, the effect
    > would be limited (the implementation file is probably not that close)


    Well, in all fairness to websnarf, those foolish enough to use gets() would,
    one hopes, tend to be ill-informed students who will be running their
    student exercise programs on the very machine on which they are compiling
    those programs.

    As an educational LART, it's not a terribly bad idea.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Dec 24, 2005
    #18
  19. Lee

    Guest

    Richard Heathfield wrote:
    > Emmanuel Delahaye said:
    > > a écrit :
    > >> char * gets (char * s) {
    > >> unlink (__FILE__); /* POSIX */

    > >
    > > Why using an extension when the standard function does exist ?


    I was just unaware of the existence of remove(), but happened to run
    across unlink() in some incidental search through my documentation some
    time ago. Learn a new thing every day.

    > Good question.
    >
    > > remove (__FILE__);
    > >
    > >> return s;
    > >> }

    > >
    > > BTW, I suppose that you want some [C99] 'inline'. If not, the effect
    > > would be limited (the implementation file is probably not that close)


    Right, and if we don't have C99 then we can't force this to work. Oh
    what a great standard this language has ... *sigh*. Anyhow, my comment
    was really aimed at compiler implementors not general programmers.

    > Well, in all fairness to websnarf, those foolish enough to use gets() would,
    > one hopes, tend to be ill-informed students who will be running their
    > student exercise programs on the very machine on which they are compiling
    > those programs.
    >
    > As an educational LART, it's not a terribly bad idea.


    *DING DING DING DING DING!* Give the man a prize.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Dec 24, 2005
    #19
  20. Lee

    Randy Howard Guest

    Richard Heathfield wrote
    (in article
    <dok52h$art$-infra.bt.com>):

    > Emmanuel Delahaye said:
    >> BTW, I suppose that you want some [C99] 'inline'. If not, the effect
    >> would be limited (the implementation file is probably not that close)

    >
    > ... those foolish enough to use gets() would,
    > one hopes, tend to be ill-informed students who will be running their
    > student exercise programs on the very machine on which they are compiling
    > those programs.


    Possibly, but I wonder how many hits you would find if you could
    grep the source on all of sourceforge for gets(). I suspect
    it's nonzero, and that represents a tiny portion of the software
    out there that could contain it, outside of "student code".
    (Yes, I know a lot of what is on sourceforge is student level,
    at best)


    --
    Randy Howard (2reply remove FOOBAR)
    "The power of accurate observation is called cynicism by those
    who have not got it." - George Bernard Shaw
    Randy Howard, Dec 24, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Mueller
    Replies:
    5
    Views:
    508
    Steven Saunderson
    Jul 10, 2006
  2. jayapal

    why the usage of gets() is dangerous.

    jayapal, Nov 16, 2007, in forum: C Programming
    Replies:
    123
    Views:
    1,959
    CBFalconer
    Nov 28, 2007
  3. John Joyce

    gets gets

    John Joyce, Mar 26, 2007, in forum: Ruby
    Replies:
    2
    Views:
    336
    John Joyce
    Mar 26, 2007
  4. John Joyce

    Return of gets gets

    John Joyce, Apr 23, 2007, in forum: Ruby
    Replies:
    0
    Views:
    184
    John Joyce
    Apr 23, 2007
  5. libsfan01
    Replies:
    5
    Views:
    230
    Jeff North
    Dec 20, 2006
Loading...

Share This Page