gets() - dangerous?

[Lee]

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

 

[Jack Klein]

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?

 

[Barry Schwarz]

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

 

[nickptar]

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

 

[Jack Klein]

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

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

 

[Robert Gamble]

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

 

[Chuck F.]

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

 

[Malcolm]

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.

 

[Richard Heathfield]

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.

 

[Giannis Papadopoulos]

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

 

[Malcolm]

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

 

[websnarf]

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.

 

[Jordan Abel]

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

 

[websnarf]

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.

 

[Richard Heathfield]

(e-mail address removed) said:

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

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

remove(__FILE__); /* ISO */

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.

 

[Mark McIntyre]

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 ?

 

[Emmanuel Delahaye]

(e-mail address removed) 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)

 

[Richard Heathfield]

Emmanuel Delahaye said:

(e-mail address removed) a écrit :

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.

 

[websnarf]

Emmanuel Delahaye said:

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.

 

[Randy Howard]

Richard Heathfield wrote
(in article

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)