«

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

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/~a...FAQ-acllc.html

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 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

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/~a...FAQ-acllc.html

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

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/>

"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.

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)

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.