Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why is it dangerous?

Reply
Thread Tools

Why is it dangerous?

 
 
CBFalconer
Guest
Posts: n/a
 
      08-11-2008
santosh wrote:
> Antoninus Twink wrote:
>> santosh wrote:
>>> CBFalconer wrote:
>>>
>>>> Correction: That omits many useful tests. I suggest:
>>>> gcc -W -Wall -ansi -pedantic
>>>> for better error detection.
>>>
>>> I would also recommend:
>>> [...]
>>> -Wpointer-arith

>>
>> This is redundant, since it's already enabled by -pedantic.

>
> This is not mentioned in my gcc documentation. Looking it up on the
> Web... yes I see you're right. Must have been added recently.


I am running gcc 3.2.1, dated 2002, and that option is available.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-11-2008
CBFalconer <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:
>> CBFalconer <(E-Mail Removed)> writes:
>>

> ... snip ...
>>
>>> I didn't drop it. I conceded your 'non-standard' point. I
>>> maintain that, for new code, including it will result in better
>>> code, and maintain conformity. It may object to some actually
>>> conforming code.

>>
>> So it seems you did not accept *my* point of a program that
>> requires a diagnostic which -Wwrite-strings suppresses.

>
> No. I consider the chance of a complex program trying to write to
> a non-writable string is more likely than the case you brought up
> (which I have absent-mindedly forgotten). And, if I need it, I am
> quite capable of remove -Wwrite-strings from the command for a
> particular compilation.


I think we have crossed wires. I use that option. I think it useful
and I know you can remove it when you need to (as I can). It is just
that you seemed to be suggesting that it did not break conformity,
only that it objected to some conforming code. People (particularly
learners) should know that it silently allows some programs though
that should have a constraint diagnosed.

--
Ben.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-11-2008
CBFalconer <(E-Mail Removed)> writes:
> santosh wrote:
>> Antoninus Twink wrote:
>>> santosh wrote:
>>>> CBFalconer wrote:
>>>>
>>>>> Correction: That omits many useful tests. I suggest:
>>>>> gcc -W -Wall -ansi -pedantic
>>>>> for better error detection.
>>>>
>>>> I would also recommend:
>>>> [...]
>>>> -Wpointer-arith
>>>
>>> This is redundant, since it's already enabled by -pedantic.

>>
>> This is not mentioned in my gcc documentation. Looking it up on the
>> Web... yes I see you're right. Must have been added recently.

>
> I am running gcc 3.2.1, dated 2002, and that option is available.


The question wasn't whether it's available, it was whether
"-Wpointer-arith" is enabled by "-pedantic".

In any case, it would be a good question for gnu.gcc.help.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Dow Allen
Guest
Posts: n/a
 
      08-11-2008
On Aug 10, 6:25*pm, Antoninus Twink <(E-Mail Removed)> wrote:
> >> a_03.c.text+0x4d): warning: the `gets' function is dangerous
> >> and should [never] be used.

> ...
> Of course, this is nonsense. There is a perfectly safe way to use
> gets(), namely by being in control of what appears on stdin.


Heresy! I'm surprised no one launched a diatribe here
against Mr. Twink, so let me offer a diatribe in support!


Six comments on gets().


First, some history. (Some c.l.c'ers weren't
even alive at the time of the infamous Internet
Worm.)

The infamous worm was complex enough to attempt
exploitation of at least 4 different security loopholes,
but just one of the loopholes was ubiquitous enough
to make it necessary and sufficient for the Worm's
"success." That loophole was the dangerous use
of gets() in a program (fingerd) usually run with
superuser authority. It was the exploits of the
Internet Worm that led to the deprecations against
gets(). (The exploiter, IIRC, wasn't a larcenous
"black hat", but rather a "gray hat" who deliberately
aroused the Unix community from its apathy about
such bugs.)

The fingerd->gets() exploit was not trivial.
The overrun buffer was an automatic variable just
below a procedure frame, whose return-address was
modified to point to executable code within the overrun
buffer. That code loaded and ran another program
(misnamed 'sh' or 'csh') which, among other things,
executed the 'fake finger' program to exploit the
fingerd->gets() bug on still other machines.

The detailed steps of this exploit get elided in the
retelling, and programmers are left with the take-home
lesson: use gets() and the Russian mob will take
over your machine and the rest of the world.
One doesn't have to be a gets() enthusiast to note
fingerd's special nature, and that the claim that
all gets() usage risks catastrophe is confused.


Second, a confession.

Whenever I build the Index to the Fabulous Pedigree
http://fabpedigree.com/altix.htm
I do several hundred thousand gets()'s, but none of
them are "dangerous". I live with a few "dangerous"
messages during the build (although I'm sure the pedants
would prefer that each of the several hundred thousand
gets()'s produced its own such message.
Perhaps there's a way to disable gcc's "dangerous"
message but, in keeping with the FSF philosophy, I'm
sure the cure is worse than the disease, something like
setenv IM_AN_UNREPENTANT_MORONIC_ASSHOLE


Third, a boast:

Since another of my "eccentric" codings, in private
throw-away code, is to *not* test malloc()'s return for
zero (failure leads to a core dump, which is what I want
anyway(*)), I'm sure that many in this ng believe that
James Dow Allen's code is buggy! I do not believe
this is the case. When I was rehired after a year to
add new support to a complete OS I wrote as a contractor
I was pleased to note that no changes had been found
necessary to my delivered code. Code reliability
doesn't require ingenuity (indeed the two may be
inversely related!); it requires conscientiousness
and avoiding the cheap substitution of dogma for thought.

AFAIK, I've never used gets() in code I've delivered
to a customer. (This is partly because most of my delivered
code has been OS or standalone, with any stdio library
calls unavailable.) I do use gets() sometimes, on
private code, when the gets()'ed string was itself
machine-produced. The gets() buffer is usually at least
ten times as large as the longest machine-produced
string. The executables are protected from the
Internet by an Impenetrable Firewall. If someone does
break into my house, intending computer mischief,
I'd be surprised if his mischief needed to invoke gets().

The gets() deprecators aren't wrong; indeed I'll cheerfully
concede that their position is more defensible than mine!
But I'm happy to take a Devil's Advocate position to
encourage critical thinking when I see the preposterous and
dogmatic over-generalizations which become so routine in
this ng. Is gets() a *potential* source of bugs? Obviously.
But I'd love to organize a wager, between me and one of
the pedants, on whose code contains more *actual* bugs.

* - Detractors will argue that what I *should* want to
do is spend hours writing a diagnostic for such malloc()
failures! In fact I don't want to do anything about them
since the smallish malloc()'s I use to build the website
Aren't Going To Fail(tm). (The pedants will respond to
this with some nonsense about how the website building
may be ported, some day, to the limited-memory chip
inside my car's fuel injection system !)


Fourth, a peeve:

fgets() preserves LineFeeds, gets() discards them.
Either behavior is fine (an application whose
stringency requires special treatment of an
"unterminated last line" probably will avoid
fgets() for other reasons anyway), but similarly-named
functions *SHOULD BEHAVE SIMILARLY*.
Assuming gets() came first and it was too late to
redefine it, fgets() should have either handled LineFeeds
the same, or have been given an obviously different name.
Whoever created the disparity in these similarly-named
functions should have done to him what Jesse J. secretly
claimed to want to do to Obama.

I *might* have changed from gets() to fgets() on some
of my private code if it weren't for the above nit.
(And yes, I *do* know how to do
if (*s == '\n') *s = 0;
in C.)


Fifth, an oft-overlooked truism:

Programming (and much real-world activity) involves
compromise between thoroughness and convenience.
strncpy(), for example, can do everything(*) strcpy()
can do, *except*, when properly coded, overrun a buffer.
In other words, the *only* reason to ever use strcpy()
(besides deliberately creating a security loophole!)
is the convenience of a 2-argument function call compared
with a 3-argument call. (* -- yes, strcpy() doesn't
null-pad. Any c.l.c'er ever write code that relied
on the *non*-padding?)

Thoroughness is not wrong, *BUT YOU SHOULD SPEND YOUR
THOROUGHNESS WISELY*. The original Hubbell Telescope
program spent $10,000 studying whether or not to do a
$3 Million test. Meanwhile the flaw, that showed up
post-launch, could have been found with a simple $50 test.
I'll bet some engineer would have done the $50 test
if not dizzied by the testing paperwork requirements
dictated by pedants.


Finally, let's note that programming and lawyerism
are different crafts.

The Authorities(tm) who post so pedantically in this
ng are often not completely wrong, but their pretentious
comments about gets() show confused thinking. In
particular, I wonder if some of them are law school
dropouts.

When I mention the gets()'s that I use, in private,
behind my Impenetrable Firewall(tm), on strings generated
by my own Bugfree Software(tm), they never acknowledge
that some gets()'s are less dangerous than others
but instead reject "safe" usages of gets() based on
pipe(fd);
dup2(fd[0], 0);
write(fd[1], "Hello world\n", 13);
printf("%s\n", gets(buff));
on grounds that the semantics of pipe(), etc. are *not
guaranteed* by the C Standard(tm).

If anyone has trouble understanding the absurdity and
hypocrisy of this legalistic view, I refer them to answers
previously given, here in the ng.

Hope this helps,
James Hussein Allen


 
Reply With Quote
 
Serve Lau
Guest
Posts: n/a
 
      08-11-2008

"James Dow Allen" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
On Aug 10, 6:25 pm, Antoninus Twink <(E-Mail Removed)> wrote:
> >> a_03.c.text+0x4d): warning: the `gets' function is dangerous
> >> and should [never] be used.

> ...
> Of course, this is nonsense. There is a perfectly safe way to use
> gets(), namely by being in control of what appears on stdin.


>The infamous worm was complex enough to attempt
>exploitation of at least 4 different security loopholes,
>but just one of the loopholes was ubiquitous enough
>to make it necessary and sufficient for the Worm's
>"success."


> That loophole was the dangerous use
>of gets() in a program (fingerd) usually run with
>superuser authority.


The story of the internet worm doesnt make Twink's statement less true.
fingerd was not in control of stdin, so yes it could be exploited. Twink
said that gets can be used safely when you are in control of stdin.

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      08-11-2008
James Dow Allen wrote, On 11/08/08 09:38:
> On Aug 10, 6:25 pm, Antoninus Twink <(E-Mail Removed)> wrote:
>>>> a_03.c.text+0x4d): warning: the `gets' function is dangerous
>>>> and should [never] be used.

>> ...
>> Of course, this is nonsense. There is a perfectly safe way to use
>> gets(), namely by being in control of what appears on stdin.

>
> Heresy! I'm surprised no one launched a diatribe here
> against Mr. Twink, so let me offer a diatribe in support!
>
> Six comments on gets().
>
>
> First, some history. (Some c.l.c'ers weren't
> even alive at the time of the infamous Internet
> Worm.)


Others were.

<snip>

> Perhaps there's a way to disable gcc's "dangerous"
> message but, in keeping with the FSF philosophy, I'm
> sure the cure is worse than the disease, something like
> setenv IM_AN_UNREPENTANT_MORONIC_ASSHOLE


I suspect the only way to disable it is to do a custom build of gcc.

<snip>

> The gets() deprecators aren't wrong; indeed I'll cheerfully
> concede that their position is more defensible than mine!
> But I'm happy to take a Devil's Advocate position to
> encourage critical thinking when I see the preposterous and
> dogmatic over-generalizations which become so routine in
> this ng. Is gets() a *potential* source of bugs? Obviously.
> But I'd love to organize a wager, between me and one of
> the pedants, on whose code contains more *actual* bugs.


I'll wager that the number of usages of gets posted to this group where
the input is not under compete control of the poster (a student is not
in control of what his/her instructor types in) is over a hundred times
more than the number of usages where it is under the posters control.
Actually, I suspect the only safe gets usages posted to this group are
posted specifically to point out that with guarantees beyond the scope
of C you can use it safely. Even on the occasions where input is under
my complete control I would use something else.

> * - Detractors will argue that what I *should* want to
> do is spend hours writing a diagnostic for such malloc()
> failures! In fact I don't want to do anything about them
> since the smallish malloc()'s I use to build the website
> Aren't Going To Fail(tm). (The pedants will respond to


Actually I would not suggest spending hours on it. As it is for personal
use and you are confident it won't fail and would probably just want the
program to abort if it did you could spend a small amount of time
writing a small wrapper that checks the return value and aborts the
program with a failure message if the allocation fails. Not something I
would recommend for general programming, but better than not checking
the value and, if done at the start, will not even cost you 5 minutes.

<snip>

> I *might* have changed from gets() to fgets() on some
> of my private code if it weren't for the above nit.
> (And yes, I *do* know how to do
> if (*s == '\n') *s = 0;
> in C.)


So write a wrapper function (or macro) that does this. Or (if
appropriate) you could get it to emit a diagnostic if an overlong line
is encountered.

<snip>

> Finally, let's note that programming and lawyerism
> are different crafts.


Reviewing code is another craft different from both of those.

> The Authorities(tm) who post so pedantically in this
> ng are often not completely wrong, but their pretentious
> comments about gets() show confused thinking.


I disagree. I've seen more bugs more crashes of SW due to doing things
similar to calling gets (writing and using a function which takes user
input with no protection against over-long input) than I've seen safe
uses of gets. Generally when someone posts code here using gets it shows
that they have not even considered the possibility of buffer overflows,
and in such situations surely pointing out the possibility of a buffer
overflow is appropriate?

> In
> particular, I wonder if some of them are law school
> dropouts.


I suspect none of them are.

> When I mention the gets()'s that I use, in private,
> behind my Impenetrable Firewall(tm), on strings generated
> by my own Bugfree Software(tm), they never acknowledge
> that some gets()'s are less dangerous than others
> but instead reject "safe" usages of gets() based on


I've worked on safety-critical SW (as in real possibility of a person
being killed if it goes wrong) and on SW where a crash would at most
make someone mutter something, so I think I am aware that in some
situations a potential (or real) bug is more serious than in other
situations.

<snip>

> If anyone has trouble understanding the absurdity and
> hypocrisy of this legalistic view, I refer them to answers
> previously given, here in the ng.


I don't consider the view to be hypocritical since I don't use gets in
my code (not even in throw-away code) and if I found it used in code I
was reviewing then I would reject that code.

Also see comments above on the likelihood of someone being aware of the
issues with gets when they post code here that uses it.

> Hope this helps,
> James Hussein Allen


Here is another argument against using gets. It has now been deprecated
so you are limiting portability if you use it. After all, what with it
being deprecated it might not be available in implementations in 50
years time!
--
Flash Gordon
 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      08-11-2008
>
>if you can NOT define the input then I would agree. ...


Can you truly define the input? Can you guarantee that even if the code
is used in controlled conditions now, that it will NEVER be used under
different conditions?

Maybe you can, but by the time you've taken the time to do a proper
security audit of your code and all the ways it would ever be used,
it would be simpler to switch to fgets().
--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-11-2008
On 11 Aug 2008 at 20:02, Eric Sosman wrote:
> Something about this fascination with gets() reminds me of the
> complaints one hears from people who dislike wearing safety belts when
> driving.


Not really.

Usually these "complaints" are just the observation that
self-determination is a pretty fundamental liberty that we should have
in a free society. The state has *no damn business* telling me what I
should or shouldn't do in the privacy of my own car, when it doesn't
affect anyone's safety but my own.

Although Heathfield clearly would love to be the dictator of the world,
actually he isn't, and no one's trying to prevent anyone using gets() by
force of law.

So the sitations aren't really comparable.

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-11-2008
On 11 Aug 2008 at 20:31, Edward A. Falk wrote:
> Can you truly define the input? Can you guarantee that even if the code
> is used in controlled conditions now, that it will NEVER be used under
> different conditions?


Yes, I believe I can.

$ alias throwaway="rm -f"
$ throwaway throwaway-program throwaway-program.c

Or, what part of "throwaway" don't you understand?

 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      08-11-2008
Antoninus Twink wrote:
) Usually these "complaints" are just the observation that
) self-determination is a pretty fundamental liberty that we should have
) in a free society. The state has *no damn business* telling me what I
) should or shouldn't do in the privacy of my own car, when it doesn't
) affect anyone's safety but my own.

Suppose you're driving along and an oncoming car suddenly veers ondy your
lane, hitting you head-on. Wearing a seatbelt would save your life, but
that is your choice, right ? You're the only one harmed by not wearing it,
right ?

Wrong.

The person driviong that other car would, if you were killed, have the
very traumatic experience of having caused your death, as opposed to just
causing you some injuries had you worn your seatbelt.

So by choosing not to wear your seatbelt you put others in danger of being
traumatized by your death.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments