In the discussion group comp.std.c Mr Gwyn wrote:
< quote >
.... gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)
< end quote >
This is a very positive development. After all those discussions,
reason prevailed and we got rid of that wart.
It *is* possible to influence the comitee as it seems.
This is good news.
jacob
Apr 24 '07
280  8591 
On Mon, 21 May 2007, Tor Rustad wrote:
Tak-Shing Chan wrote:
>On Sun, 20 May 2007, Tor Rustad wrote:
>>>
Why do so many worry about *trivial* thing like gets(), when they don't
have a *clue* about writing secure programs?
Irrelevant. This subthread was about *insecure* programs,
not secure ones.
Yeah, two *totally* unrelated things. ;-)
>P.S. When I search for "there is no problem using gets" on
Google groups, I got exactly one hit. Guess who the author was.
Nice snipping, and your point is? Please read my *full* posts upthread,
before responding.
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
Tak-Shing
Chris Hills <ch***@phaedsys.orgwrites:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>Tor Rustad <torust_at_online.nowrites:
[...]
>>Why do so many worry about *trivial* thing like gets(), when they
don't have a *clue* about writing secure programs?
[...]
Why do so many bother to buckle their seat belts, when they don't have
a *clue* about defensive driving?
For many types of defensive driving the first thing you do is turn off
the air bag..........
I'm not familiar with that, but I suppose I'll have to take your word
for it. Since we're speaking metaphorically (and yes, I started it),
is turning off the air bag a metaphor that favors using gets()?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer said:
How about ggets is just as simple to call, and all you have to do
is remember to eventually free what it returns? Yet it is
perfectly safe.
Except from denial-of-memory attacks, of course.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>Chris Hills <ch***@phaedsys.orgwrites:
>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites
>>>Tor Rustad <torust_at_online.nowrites:
[...]
Why do so many worry about *trivial* thing like gets(), when they
don't have a *clue* about writing secure programs?
[...]
Why do so many bother to buckle their seat belts, when they don't have
a *clue* about defensive driving?
For many types of defensive driving the first thing you do is turn off
the air bag..........
I'm not familiar with that, but I suppose I'll have to take your word
for it.
You can check with any of the higher end security firms.
Since we're speaking metaphorically (and yes, I started it),
is turning off the air bag a metaphor that favors using gets()?
No!
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Tor Rustad wrote, On 21/05/07 01:47:
Flash Gordon wrote:
>Tor Rustad wrote, On 20/05/07 16:03:
>>Why do so many worry about *trivial* thing like gets(), when they
don't have a *clue* about writing secure programs?
The first step in writing a secure program is not to do things you
know are insecure. Not using gets comes under this category. Even if
<snip>
The *first* step in building a secure system, is to design and analyze
it *before* any programming has been started. That is the hard part, in
my experience.
Failing to analyze and design (in my opinion you analyze the problem
before you start the design) is also doing something you know is
insecure, so that is also covered by my statement :-)
Now, after the spec has been implemented, time comes to testing and code
audit. When doing audit, both manual inspection and static analysis
should be done for safety-critical systems.
Agreed. Although secure and safety critical are independent attributes.
For example, I have worked on safety critical SW where security was not
a requirement (it was an embedded avionics system).
Please name a single
security scanner, which don't warn about gets()!
I would not trust any which did not :-)
<snip>
>>How many here worry about making their code time-independent?
Where that is an appropriate consideration (e.g. a login process) I
will use a tried and tested third party library from a source I have
good reason to trust. Far safer to use code from an expert than to try
and get it correct yourself!
I can't afford to trust some software, just because a company have a
good reputation or something. I want proof.
Depending on the level of security I may or may not require proof. For
the stuff I currently work on the reputation of openssl is good enough,
for other things I accept you would require proof.
Making time-dependent PIN or password check, would be a cardinal sin for
a security programmer. DPA (differential power analysis) is is another
example of side-channel attack.
I'm aware of this, although I've never worked on anything critical
enough to worry about it.
>>or verify their calculations???
For security related calculations I will use trusted third-party SW
that undergoes testing of sufficient rigour.
There is a lot of snake-oil on the market.
Agreed. One does have to have proof that the company can be trusted,
such as proper independent audits.
One basic problem, is that
you can't really protect secrets in software, but need tamper-resistant
hardware.
A powerful attack is fault injection, RSA can for example be broken
after a single faulty calculation.
There is more than one way to achieve this. Sometimes this can be
achieved by having the HW in a room with sufficient physical security
(where sufficient depends on the application).
>>How many have done threat analysis, and used formal methods to guard
against sophisticated attacks?
If your threat analysis says you only have to defend against simple
threats then you don't need to go too far in your protection. For
example, if the system is entirely internal *and* the level of
expertise of people on the inside is sufficiently low (builders,
accountants etc) then the cost/benefits analysis says you do not need
to go that far. That does not mean you should not avoid the more
easily avoidable problems.
If the value you want to protect is low, well then of course you don't
use a TCB (Trusting Computing Base), have guards, dual access control
and video surveillance etc.
Depending on your definition of low value, I agree.
OTOH, for a bank, the insider threat is a *major* concern. However,
banks want to make money, so they take calculated risks and in some
cases, higher risks than they are aware of.
Yes, I fully agree.
In my case it really is builders and accountants who are generally not
that knowledgeable about computing, and that factors in to the risk
assessment. There is a lot of money involved, but the chances of anyone
having the access and knowledge to mount a sophisticated attack without
also having sufficient permissions to not need to attack are really small.
>>Unless ppl have read/written a protection profile, you are likely
quite clueless in making a program/system secure IMO.
Unless you avoid the simple problems (which you may well do for all I
know) then you are quite likely even more clueless.
Even a non-expert application programmer know about gets(), but
they don't make secure C programs. You need a security professional to
do that, and no, I have *never* located a gets() call in such code
during audit.
I agree that for real security you need security professionals. Just as
for safety critical applications you need safety experts.
Removal of gets(), will help clueless programmers, who are not building
secure software anyway. For professionals, gets() is a non-issue IMO.
Removal of it means there is one less thing to learn not to do and one
less thing for teachers to get wrong. I admit it will not actually be
removed from the language for at least 20 years, but I don't see that as
a reason not to start the process. Just as changing the law to require
seatbelts be fitted in new cars was a good move even though it did not
magically get seatbelts fitted to all cars.
--
Flash Gordon
Tak-Shing Chan wrote:
>
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
Yes, we do *agree* on this.
--
Tor <torust [at] online [dot] no>
On May 21, 11:10 am, Tor Rustad <tor...@online.nowrote:
Tak-Shing Chan wrote:
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
Yes, we do *agree* on this.
Is there some guarantee that the program/routines meant for a secured
environment will never be used elsewhere?
As for the argument, far upstream, about using gets() with trivial
programs and games I would like to add:
The trival program/game allows someone to add a hostile program that
formats your hard drive or steals your bank account.
How trivial is it now? Just because the program in question is a
little toss away bit of poo-poo does not mean that it can't have a
huge impact on other things that aren't.
This isn't just and academic argument. I have removed gets() calls
from at least one dozen publicly distributed chess programs. These
programs are downloaded by thousands of people and are played over the
internet (e.g. on FICS). The original authors almost universally
pushed back, but eventually they saw the light.
Jack Klein's getsafe() program is not perfect, but it is a lot better
than gets() and no harder to use.
The GNU getline() function is another alternative.
I have great respect for Tak-Shing Chan, but he's wrong about gets().
It's wrong to use it[0] and far worse to advocate it[1].
[0] If your computer is housed in a vault with no internet connection
and impossible to gain access to for anyone but yourself -- then knock
yourself out and gets() all you like. If there is any possibility of
that code ever making it outside by any stretch of the imagination
then it is offensive to use gets().
[1] Most gets() users will not be nearly so smart as Tak-Shing Chan
and will eventually let little gets() beasts loose on unsuspecting
software end-users.
Flash Gordon wrote:
Tor Rustad wrote, On 21/05/07 01:47:
>The *first* step in building a secure system, is to design and analyze
it *before* any programming has been started. That is the hard part, in
my experience.
Failing to analyze and design (in my opinion you analyze the problem
before you start the design) is also doing something you know is
insecure, so that is also covered by my statement :-)
Well, even the detailed design specs shouldn't be language specific. The
local C coding standard, will typically ban gets(), not your design
documents.
>Now, after the spec has been implemented, time comes to testing and code
audit. When doing audit, both manual inspection and static analysis
should be done for safety-critical systems.
Agreed. Although secure and safety critical are independent attributes.
For example, I have worked on safety critical SW where security was not
a requirement (it was an embedded avionics system).
This is really off-topic, but if you re-read my post, I never said safety ==
security.
However, safety, "freedom from danger of risk", is hardly an *independent*
attribute from security. I know what you mean, but some safety-critical
systems, do need to protect against information leakage, others don't.
Denial-of-Service, is that a safety or a security attribute?
Your answer is not important, since we can agree that gets() is both a
safety *and* a security "bug", right?
>OTOH, for a bank, the insider threat is a *major* concern. However,
banks want to make money, so they take calculated risks and in some
cases, higher risks than they are aware of.
Yes, I fully agree.
In my case it really is builders and accountants who are generally not
that knowledgeable about computing, and that factors in to the risk
assessment. There is a lot of money involved, but the chances of anyone
having the access and knowledge to mount a sophisticated attack without
also having sufficient permissions to not need to attack are really small.
If there is a lot of money involved... even threats with little probability,
can be highly relevant. One place I worked, had an insider attack ca. 15
years ago, where they got away with *over* 100 million dollars, which today
would be approx 400-500 million dollars?
The attack was mounted at a time when the company switched over to a new
security system. The insiders was supposed to watch each other, nobody knew
they where lovers. Approx 30 billion dollars passed through that system
each day.
An outsider will typically go after a few accounts on the front-end, while
the insider might very well strike the back-end... with devastating effect.
Main worry for a bank about the front-end, is negative publicity, not really
the money lost. However, avoiding full-scale attack on the back-end, can be
a question about staying in business or not.
>Removal of gets(), will help clueless programmers, who are not building
secure software anyway. For professionals, gets() is a non-issue IMO.
Removal of it means there is one less thing to learn not to do and one
less thing for teachers to get wrong.
If a company lack automated tools to detect bugs like "gets", they don't
take safety and/or security issues very seriously. splint is even free.
There are also commercial tools out there, to enforce your "safe" C subset.
If you still worry, why not comment away the banned API's from the header
files?
Heck, you can scan the binaries, for banned function calls.
--
Tor <torust [at] online [dot] no>
CBFalconer wrote:
How about ggets is just as simple to call, and all you have to do
is remember to eventually free what it returns? Yet it is
perfectly safe.
Really, *perfectly* safe? Wow!
Is that code even reliable? By what magic powers are you born with, to make
such a professional judgment, without having the proper education or
training to do so?
Have you worked for NSA, and secured nuclear missiles or something? What do
you mean by *perfectly* safe? Does such a thing even exist?
Once a torpedo was designed to self-destruct if it turned 180 degrees after
launch. Would that be a safe design? Now, consider what happened when the
torpedo got stuck in the tube, and the sub turned 180 degrees!
FYI, your function is trivially likely to fail code audit for a
safety-critical system, non-deterministic memory usage is *not* what
identify such code.
--
Tor <torust [at] online [dot] no>
Tak-Shing Chan wrote:
>
.... snip ...
>
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
But that program cannot bind that input.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com
user923005 wrote:
On May 21, 11:10 am, Tor Rustad <tor...@online.nowrote:
>Tak-Shing Chan wrote:
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
Yes, we do *agree* on this.
Is there some guarantee that the program/routines meant for a secured
environment will never be used elsewhere?
Hmm.. ITYM an in-secure program entering a secure environment?
If so, you are quite correct that many companies have poor security policies
on this. For example, a programmer may be allowed to use his notebook both
at work and at home, hence she/he might be connected to two networks with
quite different security levels.
At home, the employee surf on porn sites, or even worse, the employee
install in-secure program like a game binary. The next day, he/she enter
the trusted network, and then you suddenly risk having a trojan horse on
the inside, bypassing all the security checks...
Yes, this threat is very real, and is one of the reasons I prefer to have
physical separate networks in companies, where computers exposed to the
outside, are not allowed to enter the trusted network.
As for the argument, far upstream, about using gets() with trivial
programs and games I would like to add:
The trival program/game allows someone to add a hostile program that
formats your hard drive or steals your bank account.
How trivial is it now? Just because the program in question is a
little toss away bit of poo-poo does not mean that it can't have a
huge impact on other things that aren't.
This isn't just and academic argument. I have removed gets() calls
from at least one dozen publicly distributed chess programs. These
programs are downloaded by thousands of people and are played over the
internet (e.g. on FICS). The original authors almost universally
pushed back, but eventually they saw the light.
One solution we use, is that the employee use a different HD for private
surfing & gaming, than the one he can logon to company network with (from
the home PC).
If the employee install non-authorized program on a computer on the inside,
she/he may get sacked. Also, many companies like e.g. banks, has Intrusion
Detection Systems (IDS), which are supposed to detect attacks from the
outside, but can as well detect infected computers on the inside.
[0] If your computer is housed in a vault with no internet connection
and impossible to gain access to for anyone but yourself -- then knock
yourself out and gets() all you like. If there is any possibility of
that code ever making it outside by any stretch of the imagination
then it is offensive to use gets().
There is a great difference in risk, between installing a binary from an
untrusted source, vs writing your own unsafe program with "gets", which is
never checked in elsewhere.
The program written by others, can hide a trojan horse, which has been
targeted to attack a trusted network from the inside.
--
Tor <torust [at] online [dot] no>
On Tue, 22 May 2007, CBFalconer wrote:
Tak-Shing Chan wrote:
>>
... snip ...
>>
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
But that program cannot bind that input.
Why does an *insecure* program, designated as such, need to
bind that input? When I say ``input is bounded'', I mean the
user (and/or the execution environment) is doing the bounding.
Note that I am not advocating gets(). I am simply saying
that banning gets() is a bit too extreme, because gets() has its
proper place in *insecure* programs.
gets() is a sharp tool. If you hurt yourself when using
gets(), it is your fault, not gets(). The use of a sharp tool
deserves the highest level of carefulness---if you cannot be 200%
sure about the boundedness of your inputs, then don't use gets()!
Tak-Shing
Tak-Shing Chan <t.****@gold.ac.ukwrites:
On Tue, 22 May 2007, CBFalconer wrote:
>Tak-Shing Chan wrote:
>>>
... snip ...
>>>
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
But that program cannot bind that input.
Why does an *insecure* program, designated as such, need to
bind that input? When I say ``input is bounded'', I mean the
user (and/or the execution environment) is doing the bounding.
Note that I am not advocating gets(). I am simply saying
that banning gets() is a bit too extreme, because gets() has its
proper place in *insecure* programs.
gets() is a sharp tool. If you hurt yourself when using
gets(), it is your fault, not gets(). The use of a sharp tool
deserves the highest level of carefulness---if you cannot be 200%
sure about the boundedness of your inputs, then don't use gets()!
If gets() weren't already in the language, would you want to add it?
Programmers use gets() unsafely in real life. I strongly suspect that
it's used unsafely far more often that it's used safely (i.e., by
programmers who actually are 200% sure about the boundedness of their
inputs). Having it in the standard tends to encourage its use.
Removing it from the language won't automatically remove it from
implementations, at least not for a long while. If you really want
that functionality, you can write your own gets(); better yet, you can
write an alternative that takes an extra argument specifying the
buffer size.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On May 22, 6:24 pm, Tak-Shing Chan <t.c...@gold.ac.ukwrote:
On Tue, 22 May 2007, CBFalconer wrote:
Tak-Shing Chan wrote:
... snip ...
I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
But that program cannot bind that input.
Why does an *insecure* program, designated as such, need to
bind that input? When I say ``input is bounded'', I mean the
user (and/or the execution environment) is doing the bounding.
Note that I am not advocating gets(). I am simply saying
that banning gets() is a bit too extreme, because gets() has its
proper place in *insecure* programs.
An insecure program can injure a secure program, or even a secure
network. It became insecure with the introduction of that one
insecure program.
gets() is a sharp tool. If you hurt yourself when using
gets(), it is your fault, not gets().
The gets() function is a hydrogen bomb that almost never goes off.
You can knock it over and bonk it with a hammer and the chances of
something bad happening are near zero. But someone who knows how to
set it off may be able to turn on the timer and run away, lauging
manically.
The use of a sharp tool
deserves the highest level of carefulness---if you cannot be 200%
sure about the boundedness of your inputs, then don't use gets()!
The problem is not so much hurting yourself. The problem is
inadvertently (since we are talking about retaining it in the standard
-- and therefore not maliciously) hurting other people. The thing of
it is -- the bomb cannot be defused, in the case where it is picked up
and hauled away by someone else or found sitting there by someone who
knows how to set it off. These bad people are few and far between and
there is little chance that something bad will happen to you,
individually. But your little program might escape, get copied onto
100,000 machines, and now there is a very big chance that it will harm
someone else.
Tak-Shing
On Wed, 22 May 2007, user923005 wrote:
On May 22, 6:24 pm, Tak-Shing Chan <t.c...@gold.ac.ukwrote:
>On Tue, 22 May 2007, CBFalconer wrote:
>>Tak-Shing Chan wrote:
>>... snip ...
>>> I am perfectly aware of the context. My point is that gets
*can* be used in insecure programs if input is bounded; you said
so yourself upthread.
>>But that program cannot bind that input.
Why does an *insecure* program, designated as such, need to
bind that input? When I say ``input is bounded'', I mean the
user (and/or the execution environment) is doing the bounding.
Note that I am not advocating gets(). I am simply saying
that banning gets() is a bit too extreme, because gets() has its
proper place in *insecure* programs.
An insecure program can injure a secure program, or even a secure
network. It became insecure with the introduction of that one
insecure program.
> gets() is a sharp tool. If you hurt yourself when using
gets(), it is your fault, not gets().
The gets() function is a hydrogen bomb that almost never goes off.
You can knock it over and bonk it with a hammer and the chances of
something bad happening are near zero. But someone who knows how to
set it off may be able to turn on the timer and run away, lauging
manically.
>The use of a sharp tool
deserves the highest level of carefulness---if you cannot be 200%
sure about the boundedness of your inputs, then don't use gets()!
The problem is not so much hurting yourself. The problem is
inadvertently (since we are talking about retaining it in the standard
-- and therefore not maliciously) hurting other people. The thing of
it is -- the bomb cannot be defused, in the case where it is picked up
and hauled away by someone else or found sitting there by someone who
knows how to set it off. These bad people are few and far between and
there is little chance that something bad will happen to you,
individually. But your little program might escape, get copied onto
100,000 machines, and now there is a very big chance that it will harm
someone else.
In such cases the precondition of ``200% sure'' is violated.
Therefore you get what you deserved when you use gets().
Tak-Shing
Tak-Shing Chan <t.****@gold.ac.ukwrites:
On Wed, 22 May 2007, user923005 wrote:
>On May 22, 6:24 pm, Tak-Shing Chan <t.c...@gold.ac.ukwrote:
[...]
>>The use of a sharp tool
deserves the highest level of carefulness---if you cannot be 200%
sure about the boundedness of your inputs, then don't use gets()!
The problem is not so much hurting yourself. The problem is
inadvertently (since we are talking about retaining it in the standard
-- and therefore not maliciously) hurting other people. The thing of
it is -- the bomb cannot be defused, in the case where it is picked up
and hauled away by someone else or found sitting there by someone who
knows how to set it off. These bad people are few and far between and
there is little chance that something bad will happen to you,
individually. But your little program might escape, get copied onto
100,000 machines, and now there is a very big chance that it will harm
someone else.
In such cases the precondition of ``200% sure'' is violated.
Therefore you get what you deserved when you use gets().
I don't mind getting what I deserve if I use gets(). I object to
getting what others deserve when *they* use gets().
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
Tak-Shing Chan <t.****@gold.ac.ukwrites:
> In such cases the precondition of ``200% sure'' is violated.
Therefore you get what you deserved when you use gets().
I don't mind getting what I deserve if I use gets(). I object to
getting what others deserve when *they* use gets().
You deserve what you get, if you install software with that low intrinsic
quality.
--
Tor <torust [at] online [dot] no>
Tor Rustad <to****@online.nowrites:
Keith Thompson wrote:
>Tak-Shing Chan <t.****@gold.ac.ukwrites:
>> In such cases the precondition of ``200% sure'' is violated.
Therefore you get what you deserved when you use gets().
I don't mind getting what I deserve if I use gets(). I object to
getting what others deserve when *they* use gets().
You deserve what you get, if you install software with that low intrinsic
quality.
It's just not possible for me to guarantee that. The only way I can
avoid unsafe software is to avoid software altogether, or to restrict
my use of software to such an extent that I can hardly get anything
done.
Do you audit every piece of software you use? I see you're using
KNode; how safe and/or secure is it, and how do you know?
Perhaps I deserve what I get if I fail to do what I can to encourage
high quality software and discourage low quality software. One small
way I do this is to discourage the use of the gets() function, and to
advocate that it be removed from the C standard. I'm under no
illusion that this will magically make everything better, but it's a
small step, and in my opinion it's a significant one.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On May 23, 1:32 pm, Keith Thompson <k...@mib.orgwrote:
Tor Rustad <tor...@online.nowrites:
Keith Thompson wrote:
Tak-Shing Chan <t.c...@gold.ac.ukwrites:
In such cases the precondition of ``200% sure'' is violated.
Therefore you get what you deserved when you use gets().
I don't mind getting what I deserve if I use gets(). I object to
getting what others deserve when *they* use gets().
You deserve what you get, if you install software with that low intrinsic
quality.
It's just not possible for me to guarantee that. The only way I can
avoid unsafe software is to avoid software altogether, or to restrict
my use of software to such an extent that I can hardly get anything
done.
Do you audit every piece of software you use? I see you're using
KNode; how safe and/or secure is it, and how do you know?
Perhaps I deserve what I get if I fail to do what I can to encourage
high quality software and discourage low quality software. One small
way I do this is to discourage the use of the gets() function, and to
advocate that it be removed from the C standard. I'm under no
illusion that this will magically make everything better, but it's a
small step, and in my opinion it's a significant one.
While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
For scanf or sscanf, the length should be mandatory.
In article <11*********************@h2g2000hsg.googlegroups.c om>,
user923005 <dc*****@connx.comwrote:
>While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
Since you can determine the length of the input string, %s can be
perfectly safe with sscanf.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963. ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <11*********************@h2g2000hsg.googlegroups.c om>,
user923005 <dc*****@connx.comwrote:
>>While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
Since you can determine the length of the input string, %s can be
perfectly safe with sscanf.
Agreed.
For scanf(), it's not immediately obvious how to make the length
"mandatory".
For example, this:
char buf[10];
int result;
result = scanf("%s", buf);
is as unsafe as any call to gets(), since arbitrary input can easily
overflow buf. We can avoid the gets() problem by removing the gets()
function from the standard library, but we're not contemplating
removing the scanf() function altogether, so we can't prevent the
string "%s" being passed as the first argument to the scanf()
function.
Probably the best solution would be to mandate that a "%s" directive
with no length always fails; the call scanf("%s", buf) would then
return 0 and would not modify the buf array. (To be clear, this would
be incompatible with the current standard; we're talking about
proposed changes in a future version of the standard.)
In general, we want (or at least I want) to avoid cases where
arbitrary input from stdin can cause a buffer overflow. There are
other cases to consider. For example: fscanf(stdin, "%s", buf)
presents exactly the same problem as scanf("%s", buf); catching it
would require fscanf() to behave differently based on whether its
first argument is stdin.
Even more generally, I think we want to avoid cases where arbitrary
input from an interactive device (not just stdin) can cause a buffer
overflow. The standard doesn't currently require I/O operations to be
aware of whether they're dealing with an interactive device, and this
may not be possible in general. C99 7.19.3p7 provides a vague
precedent:
... the standard input and standard output streams are fully
buffered if and only if the stream can be determined not to refer
to an interactive device.
but I'm not comfortable with the idea of such a drastic change in the
behavior of fscanf(f, "%s", buf) depending on whether f *can be
determined* to refer to an interactive device.
It would be simpler to eliminate "%s" for all of scanf, sscanf, and
fscanf. sscanf and fscanf with "%s" are potentially safe because it's
possible to know the maximum length, but then it's also possible to
*know* the maximum length, and to specify it. If nothing else, the
programmer can just specify the length of the buffer, which I'd say is
good practice anyway.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Wed, 23 May 2007, Keith Thompson wrote: ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>In article <11*********************@h2g2000hsg.googlegroups.c om>,
user923005 <dc*****@connx.comwrote:
>>While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
Since you can determine the length of the input string, %s can be
perfectly safe with sscanf.
Agreed.
For scanf(), it's not immediately obvious how to make the length
"mandatory".
For example, this:
char buf[10];
int result;
result = scanf("%s", buf);
is as unsafe as any call to gets(), since arbitrary input can easily
overflow buf. We can avoid the gets() problem by removing the gets()
function from the standard library, but we're not contemplating
removing the scanf() function altogether, so we can't prevent the
string "%s" being passed as the first argument to the scanf()
function.
Probably the best solution would be to mandate that a "%s" directive
with no length always fails; the call scanf("%s", buf) would then
return 0 and would not modify the buf array. (To be clear, this would
be incompatible with the current standard; we're talking about
proposed changes in a future version of the standard.)
In general, we want (or at least I want) to avoid cases where
arbitrary input from stdin can cause a buffer overflow. There are
other cases to consider. For example: fscanf(stdin, "%s", buf)
presents exactly the same problem as scanf("%s", buf); catching it
would require fscanf() to behave differently based on whether its
first argument is stdin.
Even more generally, I think we want to avoid cases where arbitrary
input from an interactive device (not just stdin) can cause a buffer
overflow. The standard doesn't currently require I/O operations to be
aware of whether they're dealing with an interactive device, and this
may not be possible in general. C99 7.19.3p7 provides a vague
precedent:
... the standard input and standard output streams are fully
buffered if and only if the stream can be determined not to refer
to an interactive device.
but I'm not comfortable with the idea of such a drastic change in the
behavior of fscanf(f, "%s", buf) depending on whether f *can be
determined* to refer to an interactive device.
It would be simpler to eliminate "%s" for all of scanf, sscanf, and
fscanf. sscanf and fscanf with "%s" are potentially safe because it's
possible to know the maximum length, but then it's also possible to
*know* the maximum length, and to specify it. If nothing else, the
programmer can just specify the length of the buffer, which I'd say is
good practice anyway.
Six years ago, I have posted a ``solution'' to this problem
<news:Pine.GSO.4.21.0110151245330.11813-100000@exeter>, but it
seems like the better solution is just to forget it. Those who
have safety in mind wrote their own versions of gets() anyway.
Whether a safe gets() exists or not does not bother them one bit.
Tak-Shing
user923005 wrote:
>
While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
For scanf or sscanf, the length should be mandatory.
My old signature really says it all:
"To this day, many C programmers believe that
'strong typing' just means pounding extra hard on the keyboard". PvdL
The way I see it, the basic problem here is that C lack a highlevel type
like 'string', which know the size allocated and can enforce
runtime-checks.
string buffer1[100]; /* buffer can max store 100 characters */
string buffer2; /* buffer can grow dynamically */
Great bonus with better readability on string operations:
buffer1 = "Hello";
buffer2 = buffer1;
buffer2 += " world\n";
I did discuss this with Dan Pop a while back, but he didn't see the point..
but I can't remember he said that this would require a GC either.
There are so many safety issues with C, that when this is a prime concern,
clueless programmers should really use a language with less pitfalls.
Sadly, I so hate the syntax in Ada, the complications in C++, the memory
usage/slowness of Java.
--
Tor <torust [at] online [dot] no>
On May 23, 5:44 pm, Tak-Shing Chan <t.c...@gold.ac.ukwrote:
On Wed, 23 May 2007, Keith Thompson wrote:
rich...@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <1179959663.252036.13...@h2g2000hsg.googlegroups.c om>,
user923005 <dcor...@connx.comwrote:
While we are at it, let's remove %s for scanf and sscanf only (fine
for printf, fprintf).
Since you can determine the length of the input string, %s can be
perfectly safe with sscanf.
Agreed.
For scanf(), it's not immediately obvious how to make the length
"mandatory".
For example, this:
char buf[10];
int result;
result = scanf("%s", buf);
is as unsafe as any call to gets(), since arbitrary input can easily
overflow buf. We can avoid the gets() problem by removing the gets()
function from the standard library, but we're not contemplating
removing the scanf() function altogether, so we can't prevent the
string "%s" being passed as the first argument to the scanf()
function.
Probably the best solution would be to mandate that a "%s" directive
with no length always fails; the call scanf("%s", buf) would then
return 0 and would not modify the buf array. (To be clear, this would
be incompatible with the current standard; we're talking about
proposed changes in a future version of the standard.)
In general, we want (or at least I want) to avoid cases where
arbitrary input from stdin can cause a buffer overflow. There are
other cases to consider. For example: fscanf(stdin, "%s", buf)
presents exactly the same problem as scanf("%s", buf); catching it
would require fscanf() to behave differently based on whether its
first argument is stdin.
Even more generally, I think we want to avoid cases where arbitrary
input from an interactive device (not just stdin) can cause a buffer
overflow. The standard doesn't currently require I/O operations to be
aware of whether they're dealing with an interactive device, and this
may not be possible in general. C99 7.19.3p7 provides a vague
precedent:
... the standard input and standard output streams are fully
buffered if and only if the stream can be determined not to refer
to an interactive device.
but I'm not comfortable with the idea of such a drastic change in the
behavior of fscanf(f, "%s", buf) depending on whether f *can be
determined* to refer to an interactive device.
It would be simpler to eliminate "%s" for all of scanf, sscanf, and
fscanf. sscanf and fscanf with "%s" are potentially safe because it's
possible to know the maximum length, but then it's also possible to
*know* the maximum length, and to specify it. If nothing else, the
programmer can just specify the length of the buffer, which I'd say is
good practice anyway.
Six years ago, I have posted a ``solution'' to this problem
<news:Pine.GSO.4.21.0110151245330.11813-100000@exeter>, but it
seems like the better solution is just to forget it. Those who
have safety in mind wrote their own versions of gets() anyway.
Whether a safe gets() exists or not does not bother them one bit.
Tak-Shing
It's not exactly a new problem. http://www.wired.com/software/coolap...urrentPage=all
"1988 -- Buffer overflow in Berkeley Unix finger daemon. The first
internet worm (the so-called Morris Worm) infects between 2,000 and
6,000 computers in less than a day by taking advantage of a buffer
overflow. The specific code is a function in the standard input/output
library routine called gets() designed to get a line of text over the
network. Unfortunately, gets() has no provision to limit its input,
and an overly large input allows the worm to take over any machine to
which it can connect.
Programmers respond by attempting to stamp out the gets() function in
working code, but they refuse to remove it from the C programming
language's standard input/output library, where it remains to this
day."
The fact that it *is* ignored does not mean that it *should be*
Keith Thompson wrote:
Tor Rustad <to****@online.nowrites:
>Keith Thompson wrote:
>>>
I don't mind getting what I deserve if I use gets(). I object to
getting what others deserve when *they* use gets().
You deserve what you get, if you install software with that low
intrinsic quality.
It's just not possible for me to guarantee that. The only way I can
avoid unsafe software is to avoid software altogether, or to restrict
my use of software to such an extent that I can hardly get anything
done.
If it's your private computer, then it's your job to bring up the assurance
level to a sufficient level, by not installing crap. It's your choice to use
that same computer for online shopping, it is your choice to use that
computer for home banking and it's you who has selected that bank internet
solution.
Banning gets() solve little, you still need to take backups and avoid poor
quality programs & trojans.
Do you audit every piece of software you use? I see you're using
KNode; how safe and/or secure is it, and how do you know?
I have not performed code audit of KNode, and neither have I any great value
here to protect.
It's mainly out of academic interest, I do a number of things to secure my
own network & computers.. my firewall route all connections from the
outside to another machine. I dynamically trigger FireWall rule updates if
an attack is detected, the binaries get scanned for modifications/trojans
etc. Just toy research..
--
Tor <torust [at] online [dot] no>
Tor Rustad <to****@online.nowrites:
[...]
Banning gets() solve little, you still need to take backups and avoid poor
quality programs & trojans.
[...]
Keeping gets() in the language solves nothing.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
On Thu, 24 May 2007, Tor Rustad wrote:
Keith Thompson wrote:
>Do you audit every piece of software you use? I see you're using
KNode; how safe and/or secure is it, and how do you know?
I have not performed code audit of KNode, and neither have I any great value
here to protect.
[OT] You can write a program to traverse your filesystem(s),
open every object file it sees, and flag every call to gets,
scanf and its ilk to a logfile. This is much weaker than a real
code audit, but it is better than nothing at all.
Tak-Shing
Tak-Shing Chan wrote:
On Thu, 24 May 2007, Tor Rustad wrote:
>Keith Thompson wrote:
>>Do you audit every piece of software you use? I see you're using
KNode; how safe and/or secure is it, and how do you know?
I have not performed code audit of KNode, and neither have I any great
value here to protect.
[OT] You can write a program to traverse your filesystem(s),
open every object file it sees, and flag every call to gets,
scanf and its ilk to a logfile. This is much weaker than a real
code audit, but it is better than nothing at all.
My current professional project, is actually to write a program, which
monitor and analyze the programs/modules on a high-security system. If
non-authorized binary is detected, it will trigger an alarm on another
host.
I could trigger an alarm on gets() calls too, but if an insider
really tried to put in a backdoor, it probably would be far more
sophisticated than that, in order to fool internal and external code
audits.
A more interesting feature, would be to enforce run-time checks of a 3rd
party module, e.g. by placing a wrapper in front of some core API.
--
Tor <torust [at] online [dot] no>
In article <Rf*********************@telenor.com>,
Tor Rustad <to****@online.nowrote:
>I could trigger an alarm on gets() calls too, but if an insider
really tried to put in a backdoor, it probably would be far more
sophisticated than that, in order to fool internal and external code
audits.
Yes, prohibiting gets() does little to prevent an author from
installing a backdoor. After all, they can always call fgets() with a
buffer smaller than the size argument.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
On Thu, 24 May 2007, Tor Rustad wrote:
Tak-Shing Chan wrote:
> [OT] You can write a program to traverse your filesystem(s),
open every object file it sees, and flag every call to gets,
scanf and its ilk to a logfile. This is much weaker than a real
code audit, but it is better than nothing at all.
My current professional project, is actually to write a program, which
monitor and analyze the programs/modules on a high-security system. If
non-authorized binary is detected, it will trigger an alarm on another
host.
I could trigger an alarm on gets() calls too, but if an insider
really tried to put in a backdoor, it probably would be far more
sophisticated than that, in order to fool internal and external code
audits.
A more interesting feature, would be to enforce run-time checks of a 3rd
party module, e.g. by placing a wrapper in front of some core API.
The program I was talking about is actually much simpler.
It scans for dynamic symbols in binary objects and compare them
to a predefined list of banned labels. In the example below, the
banned labels are "scanf", "gets", "strncpy" and "sprintf".
Tak-Shing
----- OT beyond this line -----
/*
** scan.c (requires GNU libbfd)
**
** Released under GPL
**
** Copyright (C) 2007 Tak-Shing Chan
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "bfd.h"
static const char *banned[] = {
"scanf",
"gets",
"strncpy",
"sprintf"
};
int
main(int argc, char *argv[])
{
bfd *abfd;
long storage_needed;
asymbol **symbol_table;
long number_of_symbols;
long i;
long j;
if (argc != 2) {
fprintf(stderr, "usage: find [path] -exec %s '{}' \\;\n",
argv[0]);
return EXIT_FAILURE;
}
bfd_init();
if (!(abfd = bfd_openr(argv[1], NULL))) {
fprintf(stderr, "Cannot open %s\n", argv[1]);
return EXIT_FAILURE;
}
if (!bfd_check_format(abfd, bfd_object)) {
fprintf(stderr, "%s is not an object file\n", argv[1]);
return EXIT_FAILURE;
}
storage_needed = bfd_get_dynamic_symtab_upper_bound(abfd);
if (storage_needed <= 0) {
fprintf(stderr, "%s has no dynamic symbols\n", argv[1]);
return EXIT_FAILURE;
}
if (!(symbol_table = malloc(storage_needed))) {
fprintf(stderr, "Memory allocation failure\n");
return EXIT_FAILURE;
}
number_of_symbols =
bfd_canonicalize_dynamic_symtab(abfd, symbol_table);
for (i = 0; i < number_of_symbols; i++) {
for (j = 0; j < sizeof banned / sizeof *banned; j++) {
if (!strcmp(bfd_asymbol_name(symbol_table[i]), banned[j])) {
printf("%s: %s detected!\n", argv[1], banned[j]);
break;
}
}
}
free(symbol_table);
bfd_close(abfd);
return 0;
} This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: bukzor |
last post by:
Does anyone have a pythonic way to check if a process is dead, given
the pid?
This is the function I'm using is quite OS dependent. A good candidate
might be "try: kill(pid)", since it throws an...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
