I
Ian Collins
Tak-Shing Chan said:
Discarding the last character in a buffer read with fgets() is hardly a
burden.
Discarding the last character in a buffer read with fgets() is hardly a
burden.
T
Tak-Shing Chan
A good programmer is a lazy programmer.
When the entire user base is one person, it might be feasible
to shift the burden of safety to the user. The programmer needs
only to forewarn the user of the consequences of exceeding the
prescribed line length. If the user ignores this advice, then
the responsibility lies with the user, not the programmer.
Tak-Shing
I
Ian Collins
That's why they wrap fgets() in a function that checks for error andTak-Shing Chan said:
removes the newline!
So you'd rather add code to warn the user than remove a newline.
T
Tak-Shing Chan
For a five-line throw-away program, that would be overkill.
In Charles Richmond's case, the user is /also/ the
programmer, so there is no need to add code.
Tak-Shing
F
Flash Gordon
Tak-Shing Chan wrote, On 20/05/07 12:00:
#include "mygetswrapper.h"
Not a big overhead since you only need to write the wrapper once.
It's surprising how often those quick hack jobs end up being used by
others. Personally I would still use fgets even if I deleted the source
5 minutes later.
#include "mygetswrapper.h"
Not a big overhead since you only need to write the wrapper once.
It's surprising how often those quick hack jobs end up being used by
others. Personally I would still use fgets even if I deleted the source
5 minutes later.
R
Richard Heathfield
Tak-Shing Chan said:
If you're truly lazy - sufficiently lazy to invest a little time now in
saving a lot of work later - look up "library" when you get a minute.
If you're truly lazy - sufficiently lazy to invest a little time now in
saving a lot of work later - look up "library" when you get a minute.
T
Tor Rustad
Richard said:
Why do so many worry about *trivial* thing like gets(), when they don't
have a *clue* about writing secure programs?
How many here worry about making their code time-independent?
or verify their calculations???
How many have done threat analysis, and used formal methods to guard
against sophisticated attacks?
Unless ppl have read/written a protection profile, you are likely quite
clueless in making a program/system secure IMO.
For starters, ppl can start to write state-diagrams of their programs,
*before* doing any programming, i.e. at the design phase.
<gd&r>
K
Keith Thompson
[...]Tor Rustad said:
Why do so many bother to buckle their seat belts, when they don't have
a *clue* about defensive driving?
C
Chris Hills
Keith Thompson said:
For many types of defensive driving the first thing you do is turn off
the air bag..........
F
Flash Gordon
Tor Rustad wrote, On 20/05/07 16:03:
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 you
believe that using gets is safe because you are in full control of the
input it would still be better to write your own replacement that takes
the size of the buffer (you know the size otherwise you do not know it
is large enough) and "fails" in a controlled manner (aborting the
program, throwing away the remainder of the line or whatever you
consider safest/most appropriate) just as a matter of normal defensive
programming.
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!
For security related calculations I will use trusted third-party SW that
undergoes testing of sufficient rigour.
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.
Unless you avoid the simple problems (which you may well do for all I
know) then you are quite likely even more clueless.
I've done state diagrams in the requirements analysis phase in the past,
where it was appropriate.
Anyway, all the good work of analysis and design is wasted if you use
gets and someone can attack through it. If you don't use gets at least
that is one less attack vector.
I hope you ducked fast enough to avoid this...
<fx: throws cream pie>
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 you
believe that using gets is safe because you are in full control of the
input it would still be better to write your own replacement that takes
the size of the buffer (you know the size otherwise you do not know it
is large enough) and "fails" in a controlled manner (aborting the
program, throwing away the remainder of the line or whatever you
consider safest/most appropriate) just as a matter of normal defensive
programming.
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!
For security related calculations I will use trusted third-party SW that
undergoes testing of sufficient rigour.
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.
Unless you avoid the simple problems (which you may well do for all I
know) then you are quite likely even more clueless.
I've done state diagrams in the requirements analysis phase in the past,
where it was appropriate.
Anyway, all the good work of analysis and design is wasted if you use
gets and someone can attack through it. If you don't use gets at least
that is one less attack vector.
I hope you ducked fast enough to avoid this...
<fx: throws cream pie>
M
Malcolm McLean
If code is correct then it is also secure.Tor Rustad said:
If it is not correct it might be vulnerable to a very determined reverse
engineeering type attack,or it might be wide open. Quite a lot of people
know how to hack gets(). Fewer people would invest a lot of time and effort
looking for a way of running malloc() out of memory and exploiting a wild
null pointer, though of course if you are implenting a system dealing with
money, for instance, it might be worth doing this.
T
Tak-Shing Chan
Irrelevant. This subthread was about *insecure* programs,
not secure ones. Charles made it clear by saying that ``if I had
to write something that needed to be secure, I would certainly
*not* use gets()'' (30-04-2007, this subthread).
Tak-Shing
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.
T
Tor Rustad
Tak-Shing Chan said:
Yeah, two *totally* unrelated things. ;-)
Nice snipping, and your point is? Please read my *full* posts upthread,
before responding.
T
Tor Rustad
Keith said:
The C car, don't have seat belts.
T
Tor Rustad
Flash said:
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.
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. Please name a single
security scanner, which don't warn about gets()!
$ cat ex_lint.c
#include <stdio.h>
int main(void)
{
char overflow[10];
if (NULL != gets(overflow))
{
(void)puts(overflow);
}
return EXIT_SUCCESS;
}
$ splint ex_lint.c
Splint 3.1.1 --- 20 Jun 2006
ex_lint.c: (in function main)
ex_lint.c:7:15: Use of gets leads to a buffer overflow vulnerability. Use
fgets instead: gets
Use of function that may lead to buffer overflow.
Finished checking --- 1 code warning
I can't afford to trust some software, just because a company have a
good reputation or something. I want 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.
There is a lot of snake-oil on the market. 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.
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.
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.
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.
Removal of gets(), will help clueless programmers, who are not building
secure software anyway. For professionals, gets() is a non-issue IMO.
T
Tak-Shing Chan
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
K
Keith Thompson
Chris Hills said:
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()?
C
Chris Hills
Keith Thompson said:
You can check with any of the higher end security firms.
No!
R
Richard Heathfield
CBFalconer said:
Except from denial-of-memory attacks, of course.
Except from denial-of-memory attacks, of course.
F
Flash Gordon
Tor Rustad wrote, On 21/05/07 01:47:
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
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).
I would not trust any which did not
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.
I'm aware of this, although I've never worked on anything critical
enough to worry about it.
Agreed. One does have to have proof that the company can be trusted,
such as proper independent audits.
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).
Depending on your definition of low value, I agree.
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.
I agree that for real security you need security professionals. Just as
for safety critical applications you need safety experts.
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.
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
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).
I would not trust any which did not
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.
I'm aware of this, although I've never worked on anything critical
enough to worry about it.
Agreed. One does have to have proof that the company can be trusted,
such as proper independent audits.
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).
Depending on your definition of low value, I agree.
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.
I agree that for real security you need security professionals. Just as
for safety critical applications you need safety experts.
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.