Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.
It has just arrived today, I was waiting for it since several weeks. http://www.di.ens.fr/~simona/book.html
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32 126  4248 
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>All is not lost however. In the book
>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow. The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
There may be constructs in C that are -prone- to buffer overflows
when used by typical programmers, but that doesn't establish
that buffer overflows are "a fact of C". Therefor, any analysis
such as the book you refer to is not a book about C, but rather
a book about algorithms and about C implementations. That
makes it relevant for comp.programming and to newsgroups dealing
with the specifics of implementations similar to the ones s/he
discusses, but does not make the book relevant to comp.lang.c .
--
"There are some ideas so wrong that only a very intelligent person
could believe in them." -- George Orwell
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g6**********@canopus.cc.umanitoba.ca...
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>>All is not lost however. In the book
>>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Startup or shutdown code may call library functions. These library
functions may overflow a buffer. To say that there is no possibility of
buffer overflow is an error.
The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
I think we have to admit that buffer overflows are a *problem* of C. I
guess that a C dialect could be produced where every single library function
was formally proven. In such a system, buffer overflows would only occur
when the compiler end-user created one.
There may be constructs in C that are -prone- to buffer overflows
when used by typical programmers, but that doesn't establish
that buffer overflows are "a fact of C". Therefor, any analysis
such as the book you refer to is not a book about C, but rather
a book about algorithms and about C implementations. That
makes it relevant for comp.programming and to newsgroups dealing
with the specifics of implementations similar to the ones s/he
discusses, but does not make the book relevant to comp.lang.c .
Having tools or ideas on how to analyze C programs for problems like buffer
overflow is clearly a good thing. I disagree that the book is not relevant
to comp.lang.c because buffer exploits are the single largest problem with
the language (by far), with manual memory management being the second most
significant issue [clearly, my opinion only]. I suggest that
news:comp.std.c is more on target than news:comp.lang.c but I definitely
think it is worth discussing here as well.
--
"There are some ideas so wrong that only a very intelligent person
could believe in them." -- George Orwell
** Posted from http://www.teranews.com **
Walter Roberson wrote:
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>All is not lost however. In the book
>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
Well, happily for C, that is not true. What the author proposes is to
apply mathematical reasoning to the sets of values a variable in C can
have, and then, to reason mathematically about those sets. It uses
geometrical concepts like "lattices", and other mathematical
"software" to determine possible values. It is too early for me to
tell you exactly how he does it, I received the book today.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow. The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
What is the point of that triviality?
Always the same. You take some sentence in my message, take it out
of its context, then find a single "counterexample", and then
that was it.
>
There may be constructs in C that are -prone- to buffer overflows
when used by typical programmers, but that doesn't establish
that buffer overflows are "a fact of C".
There may be constructs yes. There "may" be constructs that are prone
to buffer overflows when used by typical programmers. Blame the
programmers that are typical, not the geniuses that live in
COMP.LANG.C
where they are a dime a dozen.
Therefor, any analysis
such as the book you refer to is not a book about C, but rather
a book about algorithms and about C implementations.
Yes, algorithms surely. C implementations surely. It is not
an abstract book. Obviously for some people in this group
C stops at anything concrete that goes beyond the usual
void main(void) is not correct
i= i++ + ++i; is not correct.
and discussing forever homework issues.
That
makes it relevant for comp.programming and to newsgroups dealing
with the specifics of implementations similar to the ones s/he
discusses, but does not make the book relevant to comp.lang.c .
OFF TOPIC. !!!
A book about analysis of C programs is OBVIOUSLY
OFF TOPIC in comp.lang.c
The only on topic stuff is a sterile repeating of such important
stuff like
void main(void) is not correct
i= i++ + ++i; is not correct.
and discussing forever homework issues.
This people are just against ANY discussion.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Walter Roberson wrote:
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>All is not lost however. In the book
>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow. The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
By that logic (if "logic" is the right word), you have
also shown that the preprocessor is not a fact of C, nor the
modulo operator, nor the `for' statement, nor the `static'
keyword, nor the entire Standard library. Brevity, in this
case, is the soul of witlessness.
-- Er*********@sun.com
Walter Roberson said:
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>>All is not lost however. In the book
>>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Your point might have been more pointy if you'd written a program that
actually used a buffer.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Dann Corbit wrote:
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g6**********@canopus.cc.umanitoba.ca...
>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>>All is not lost however. In the book
>>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Startup or shutdown code may call library functions. These library
functions may overflow a buffer.
But are those startup and shutdown functions part of the C language?
Richard Heathfield wrote:
Walter Roberson said:
>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Your point might have been more pointy if you'd written a program that
actually used a buffer.
Ah but his point was exactly that.
"Mark McIntyre" <ma**********@TROUSERSspamcop.netwrote in message
news:eQ*******************@en-nntp-06.am2.easynews.com...
Dann Corbit wrote:
>"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g6**********@canopus.cc.umanitoba.ca...
>>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Startup or shutdown code may call library functions. These library
functions may overflow a buffer.
But are those startup and shutdown functions part of the C language?
I don't think it is possible to say. They are part of the C compiler.
** Posted from http://www.teranews.com **
"Mark McIntyre" <ma**********@TROUSERSspamcop.netwrote in message
news:0R*******************@en-nntp-06.am2.easynews.com...
Richard Heathfield wrote:
>Walter Roberson said:
>>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Your point might have been more pointy if you'd written a program that
actually used a buffer.
Ah but his point was exactly that.
By what magic do the two of you know that no buffer is involved?
Here is the disassembly for the provided program on a C compiler:
---
c:\tmp\minimal\minimal.c ---------------------------------------------------
int main(void) { return 0; }
010B1370 push ebp
010B1371 mov ebp,esp
010B1373 sub esp,0C0h
010B1379 push ebx
010B137A push esi
010B137B push edi
010B137C lea edi,[ebp-0C0h]
010B1382 mov ecx,30h
010B1387 mov eax,0CCCCCCCCh
010B138C rep stos dword ptr es:[edi]
010B138E xor eax,eax
010B1390 pop edi
010B1391 pop esi
010B1392 pop ebx
010B1393 mov esp,ebp
010B1395 pop ebp
010B1396 ret
Did you notice the rep stos? That is a string fill operation.
REP STOS m32 -- Fill (E)CX doublewords at ES:[(E)DI] with EAX
** Posted from http://www.teranews.com **
"Dann Corbit" <dc*****@connx.comwrote in message
news:6f******************@news.teranews.com...
"Mark McIntyre" <ma**********@TROUSERSspamcop.netwrote in message
news:eQ*******************@en-nntp-06.am2.easynews.com...
>Dann Corbit wrote:
>>"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g6**********@canopus.cc.umanitoba.ca...
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Startup or shutdown code may call library functions. These library
functions may overflow a buffer.
But are those startup and shutdown functions part of the C language?
I don't think it is possible to say. They are part of the C compiler.
Program startup is referenced 23 times in the C99 standard and program
termination is referenced 31 times. So by definition, startup and shutdown
are part of the C language specification. Whether startup and shutdown are
referenced as functions or not is unclear.
** Posted from http://www.teranews.com **
Dann Corbit said:
"Mark McIntyre" <ma**********@TROUSERSspamcop.netwrote in message
news:0R*******************@en-nntp-06.am2.easynews.com...
>Richard Heathfield wrote:
>>Walter Roberson said:
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
Buffer overflows are a fact of life, and, more specifically, a fact
of C.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow.
Your point might have been more pointy if you'd written a program that
actually used a buffer.
Ah but his point was exactly that.
(Not much of a point, then.)
By what magic do the two of you know that no buffer is involved?
I haven't claimed that no buffer is involved. I've claimed that the C
program as shown doesn't use a buffer. It doesn't. What the implementation
does in translation is of no concern as long as it faithfully interprets
the program's semantics. If it chooses to add a buffer, so be it - but the
C program does *not* use one.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:tf******************************@bt.com...
Dann Corbit said:
>"Mark McIntyre" <ma**********@TROUSERSspamcop.netwrote in message
news:0R*******************@en-nntp-06.am2.easynews.com...
>>Richard Heathfield wrote:
Walter Roberson said:
In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>Buffer overflows are a fact of life, and, more specifically, a fact
>of C.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
>
On the other hand:
>
int main(void) { return 0; }
>
is a C program that has no possibility of buffer overflow.
Your point might have been more pointy if you'd written a program that
actually used a buffer.
Ah but his point was exactly that.
(Not much of a point, then.)
>By what magic do the two of you know that no buffer is involved?
I haven't claimed that no buffer is involved. I've claimed that the C
program as shown doesn't use a buffer. It doesn't. What the implementation
does in translation is of no concern as long as it faithfully interprets
the program's semantics. If it chooses to add a buffer, so be it - but the
C program does *not* use one.
The point discussed was in connection with vulnerabilities in connection
with the C programming language.
If a C program calls library functions, uses inline assembly or whatever and
performs buffer movements then that is salient to the discussion of
vulnerabilities and buffer overflow.
Whether or not it was the end-user of the compiler or the compiler vendor
who broke something is irrelevant to the discussion.
If a library call or other normal operation of any given C compiler causes a
buffer overrun, then that is a vulnerability.
In fact, I propose that is a more serious vulnerability than one found in
end-user code because it is potentially much harder to detect.
We can run programs that eat a pile of C code and perform static analysis
and detect buffer overruns. But it will be harder still to perform the same
analysis against the C run time libraries because (potentially) much of it
will not even be written in C and harder still to find problems in the goo
projected by the compiler that does not come from the run time libraries.
To say: "I don't see any buffer use." when examining a fragment of C code
does not mean that buffer overruns will not happen because of using a C
compiler. I think that this is a very important subject that directly
focuses on the chief criticism of the C language. If we can figure out
solutions, or at least partial solutions, then we end up with a better C
compiler and safer code in the long run. It is perhaps the biggest obstacle
in C's future.
** Posted from http://www.teranews.com **
Dann Corbit said:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:tf******************************@bt.com...
<snip>
>What the
implementation does in translation is of no concern as long as it
faithfully interprets the program's semantics. If it chooses to add a
buffer, so be it - but the [snipped] C program does *not* use one.
The point discussed was in connection with vulnerabilities in connection
with the C programming language.
If a C program calls library functions, uses inline assembly or whatever
and performs buffer movements then that is salient to the discussion of
vulnerabilities and buffer overflow.
Perhaps it is, but that isn't the impression I get about what's eating the
"C is prone to buffer overflow" crowd. Rather, I think they're saying it's
too easy to screw up when writing C code itself - e.g. it's too easy to
write something like this:
char foo[32];
puts(prompt);
gets(foo);
or
strcpy(foo, toolongstring);
or
sprintf(foo, "Now is the time for %s to come to the aid of the party",
bar);
And it *is* easy to write that kind of stuff. (It's pretty easy to fly a
fighter jet into the ground, too, but I've always see that as more of an
argument for training pilots than an argument for grounding them.)
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On Tue, 22 Jul 2008 20:53:12 +0200, jacob navia posted:
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.
It has just arrived today, I was waiting for it since several weeks.
http://www.di.ens.fr/~simona/book.html
%- Anyone interested in source code analysis. The formal yet concise
%- definition of an analysis of a real-world programming language can
%- help to define a simiar description for the purpose of slicing,
%- taint analysis, calculating metrics and many other application areas.
I'm somewhat of a non-believer here. There is no calculus to decide.
Isn't 'taint' the scientific name for "perineum?"
--
Let's not burn the universities yet. After all, the damage they do might be
worse.
H. L. Mencken
jacob navia wrote:
Walter Roberson wrote:
>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>>All is not lost however. In the book
>>"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
....
>Therefor, any analysis
such as the book you refer to is not a book about C, but rather
a book about algorithms and about C implementations.
....
>That
makes it relevant for comp.programming and to newsgroups dealing
with the specifics of implementations similar to the ones s/he
discusses, but does not make the book relevant to comp.lang.c .
OFF TOPIC. !!!
A book about analysis of C programs is OBVIOUSLY
OFF TOPIC in comp.lang.c
Well, far more important, at least as far as I'm concerned, is the fact
that this thread is also cross-posted to comp.std.c, where there is far
less controversy about what is topical and what isn't. A book about how
to use C, no matter how well written and interesting it might be, is not
on-topic for comp.std.c, at least not for that reason. This group is
very specifically for discussions about the C standard, not about how to
use the language defined by that standard. "How to use C" can become
relevant, when discussing whether or not a particular existing or
proposed feature of the standard is a good idea, but "How to use C" is
not topical without such a connection.
If the book also contains statements about the C standard, it would be
on-topic to discuss whether or not those statements are true. If it has
suggestions for future versions of the C standard, it would also be on
topic to discuss those suggestions. However, just because it talks about
C does not make it on-topic for comp.std.c.
Eric Sosman wrote:
Walter Roberson wrote:
>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
If buffer overflows are indeed, as you claim, "a fact of C", then
no amount of theoretical analysis will allow you to eliminate them
in any actual C program.
On the other hand:
int main(void) { return 0; }
is a C program that has no possibility of buffer overflow. The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
By that logic (if "logic" is the right word), you have
also shown that the preprocessor is not a fact of C, nor the
modulo operator, nor the `for' statement, nor the `static'
keyword, nor the entire Standard library. Brevity, in this
case, is the soul of witlessness.
Sloppy wording breeds meaningless assertions.
A "buffer overflow in C" is not even a proposition, let alone a fact. A
modulo operator is also not a "fact" of C or anything else.
Let's add precision with some propositions:
1. Buffer overflows occur when some programs written in C are run.
2. Buffer overflows occur when all programs written in C are run.
3. Buffer overflows can occur when running most programs written in C under
some conditions of invocation and inputs.
4. The integer modulo operator is supported by all C compilers.
We may argue the finer points of meaning and methods of evaluation, but
arguing "facts" without clarification seems silly.
--
Thad
[Not sure what this is doing in csc - followups set to clc]
Thad Smith said:
<snip>
>
Sloppy wording breeds meaningless assertions.
A "buffer overflow in C" is not even a proposition, let alone a fact. A
modulo operator is also not a "fact" of C or anything else.
Let's add precision with some propositions:
1. Buffer overflows occur when some programs written in C are run.
2. Buffer overflows occur when all programs written in C are run.
3. Buffer overflows can occur when running most programs written in C
under some conditions of invocation and inputs.
And then let's add:
4. Buffer overflows can sometimes occur when running some carelessly
written programs under some conditions of invocation and inputs, where
these programs are written in any of a variety of languages (certainly
including C, but also including C++ for a start) that are sufficiently
powerful to be capable of being dangerously misused by amateurs.
If you don't want buffer overflows, hire some good programmers. One way you
can tell they're good is that they hold regular code reviews in which they
point out faults in each others' code.
4. The integer modulo operator is supported by all C compilers.
One would hope so, wouldn't one? :-)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On 23 jul, 03:37, "Dann Corbit" <dcor...@connx.comwrote:
"Richard Heathfield" <r...@see.sig.invalidwrote in message
I haven't claimed that no buffer is involved. I've claimed that the C
program as shown doesn't use a buffer. It doesn't. What the implementation
does in translation is of no concern as long as it faithfully interprets
the program's semantics. If it chooses to add a buffer, so be it - but the
C program does *not* use one.
The point discussed was in connection with vulnerabilities in connection
with the C programming language.
If a C program calls library functions, uses inline assembly or whatever and
performs buffer movements then that is salient to the discussion of
vulnerabilities and buffer overflow.
Whether or not it was the end-user of the compiler or the compiler vendor
who broke something is irrelevant to the discussion.
By that reasoning, buffer overflows are a problem for every single
computer language in existance.
Even for the safest of safe languages, you can not possibly rule out
that a (flawed) translator introduces a buffer overflow in the
program.
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Bart v Ingen Schenau
"James Kuyper" <ja*********@verizon.netwrote in message
news:mHwhk.354$oU.53@trnddc07...
jacob navia wrote:
>Walter Roberson wrote:
>>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
...
>>Therefor, any analysis
such as the book you refer to is not a book about C, but rather
a book about algorithms and about C implementations.
...
>>That
makes it relevant for comp.programming and to newsgroups dealing
with the specifics of implementations similar to the ones s/he
discusses, but does not make the book relevant to comp.lang.c .
OFF TOPIC. !!!
A book about analysis of C programs is OBVIOUSLY
OFF TOPIC in comp.lang.c
Well, far more important, at least as far as I'm concerned, is the fact
that this thread is also cross-posted to comp.std.c, where there is far
less controversy about what is topical and what isn't. A book about how to
use C, no matter how well written and interesting it might be, is not
on-topic for comp.std.c, at least not for that reason. This group is very
specifically for discussions about the C standard, not about how to use
the language defined by that standard. "How to use C" can become relevant,
when discussing whether or not a particular existing or proposed feature
of the standard is a good idea, but "How to use C" is not topical without
such a connection.
If the book also contains statements about the C standard, it would be
on-topic to discuss whether or not those statements are true. If it has
suggestions for future versions of the C standard, it would also be on
topic to discuss those suggestions. However, just because it talks about C
does not make it on-topic for comp.std.c.
This:
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
Sounds like it would be interesting to compiler vendors and language
designers to me.
** Posted from http://www.teranews.com **
"Bart van Ingen Schenau" <Ba********************@ict.nlwrote in message
news:57**********************************@x41g2000 hsb.googlegroups.com...
On 23 jul, 03:37, "Dann Corbit" <dcor...@connx.comwrote:
>"Richard Heathfield" <r...@see.sig.invalidwrote in message
I haven't claimed that no buffer is involved. I've claimed that the C
program as shown doesn't use a buffer. It doesn't. What the
implementation
does in translation is of no concern as long as it faithfully
interprets
the program's semantics. If it chooses to add a buffer, so be it - but
the
C program does *not* use one.
The point discussed was in connection with vulnerabilities in connection
with the C programming language.
If a C program calls library functions, uses inline assembly or whatever
and
performs buffer movements then that is salient to the discussion of
vulnerabilities and buffer overflow.
Whether or not it was the end-user of the compiler or the compiler vendor
who broke something is irrelevant to the discussion.
By that reasoning, buffer overflows are a problem for every single
computer language in existance.
Even for the safest of safe languages, you can not possibly rule out
that a (flawed) translator introduces a buffer overflow in the
program.
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because nobody brought it up. Besides which, it would not be topical in
news:comp.lang.c
I don't particularly care if buffer overflows are a problem in {e.g.} Snobol
because I don't use it.
C is not more dangerous than (for instance) C++ in this regard. But it is
more dangerous than (for instance) Ada. I would further argue that an Ada
compiler compiled with C is probably not as safe as an Ada compiler compiled
with Ada and that a C compiler compiled with Ada would probably be safer
than a C compiler compiled with C.
Unbounded arrays and trusting in nul termination of strings are reasons for
my above opinion. I'm not even sure that I want to fix it, if it will make
things a lot slower. But I do want to think about it.
** Posted from http://www.teranews.com **
Ron Ford wrote:
On Tue, 22 Jul 2008 20:53:12 +0200, jacob navia posted:
>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.
It has just arrived today, I was waiting for it since several weeks.
http://www.di.ens.fr/~simona/book.html
%- Anyone interested in source code analysis. The formal yet concise
%- definition of an analysis of a real-world programming language can
%- help to define a simiar description for the purpose of slicing,
%- taint analysis, calculating metrics and many other application areas.
I'm somewhat of a non-believer here. There is no calculus to decide.
Well, mathematics doesn't need beliefs. You should read that book first.
Isn't 'taint' the scientific name for "perineum?"
When a variable has some property, for instance of being allocated with
malloc, this property goes on to other variables when they are assigned
the allocated variable, i.e. they are "tainted" by the right hand side.
The analysis and the following of those properties is "tainted"
analysis.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield <rj*@see.sig.invalidwrites:
If you don't want buffer overflows, hire some good programmers. One way you
can tell they're good is that they hold regular code reviews in which they
point out faults in each others' code.
It has turned out that in all kind of products,
buffer overflows do have and do occur. In languages based on C you can
be king of all programmers, but this errors can get even those. And
unfortunatylly this kind of bugs can lurk around for ages and be not
discovered. Unfortunatly this really is one of the weaknesses in C
based languages, with the attitude "the programmer knows"....
Having good programmres surely will help but it does not mean that
those bugs can not appear in their code also
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Dann Corbit wrote:
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g6**********@canopus.cc.umanitoba.ca...
>In article <g6**********@aioe.org>, jacob navia <ja***@nospam.org>
wrote:
>>Buffer overflows are a fact of life, and, more specifically, a fact of
C.
>The
existance of a single counter-example is enough to disprove your
claim that buffer overflows are "a fact of C".
I think we have to admit that buffer overflows are a *problem* of C. I
guess that a C dialect could be produced where every single library
function was formally proven. In such a system, buffer overflows would
only occur when the compiler end-user created one.
Are buffer overflows problem of *C* or of implementation of *C*?
I see only one problem on C standard, that limits the capabilities
of a compiler (+ run time environment) to check overflows.
I think a C compiler with range checks will be still
faster than other language "without overflows".
So the only problem I see is the dynamic memory.
IMHO C misses functions like:
void * type_alloc(size_t s, type_t type);
type is implicitly or explicitly converted to a
TYPE_UNK value (and information not used, like malloc),
or implementation defined value if an implementation
cares about runtime types.
I think with this additional information, an implementation
could be overflow safe and still conforming.
Or do you see other problem on C?
ciao
cate
Bart van Ingen Schenau <Ba********************@ict.nlwrites:
>
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
because that kind of errors plagues C programs mostly?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Richard Heathfield wrote:
[Not sure what this is doing in csc - followups set to clc]
Thad Smith said:
<snip>
>Sloppy wording breeds meaningless assertions.
A "buffer overflow in C" is not even a proposition, let alone a fact. A
modulo operator is also not a "fact" of C or anything else.
Let's add precision with some propositions:
1. Buffer overflows occur when some programs written in C are run.
2. Buffer overflows occur when all programs written in C are run.
3. Buffer overflows can occur when running most programs written in C
under some conditions of invocation and inputs.
And then let's add:
4. Buffer overflows can sometimes occur when running some carelessly
written programs under some conditions of invocation and inputs,
This idiotic attitude is typical of the people here.
There is nothing wrong, buffer overflows aren't a problem, it is the
fault of the lazy programmers that aren't as clever as they should be.
Typical too is the lack of any software engineering argumentation, and
the desire to always stay in the three main discussions subject of this
group
1: void main(void) is not correct
2: i=I++ + ++i; is not correct
3: Doing lazy student's homework.
Anything that goes beyond that is off topic, for instance a book about
formal analysis of C programs obviously. There is NO NEED for formal
analysis when there are no buffer overflows, all contrary evidence
notwithstanding.
Implicit in this attitude is the attitude of their guru heathfield,
when he just dismisses the problem as above:
"carelessly written programs"... like his book (C unleashed) where
he assumes that sizeof(int) equals sizeof(void *) and gets a buffer
overflow. That he realized his error LATER and put the solution in
the ERRATA should be a reminder to him that not only "carelessly written
programs" happen to contain buffer overflows but that the easy with
which you can do those errors in C is a PROBLEM for C!
But no.
where
these programs are written in any of a variety of languages (certainly
including C, but also including C++ for a start) that are sufficiently
powerful to be capable of being dangerously misused by amateurs.
Yes sure.Those amateurs include heathfield obviously!
If you don't want buffer overflows, hire some good programmers.
Mr heathfield should follow his own advise. When writing a book,
try to hire a good programmer to write the examples.
One way you
can tell they're good is that they hold regular code reviews in which they
point out faults in each others' code.
This did not work in C unleashed.
This did not work in all the buffer overflows we were having in the last
years. And it is extremely expensive.
This attitude is leading to the conclusion for most sensible people that
they should avoid C (and C++) at all costs. Hence languages like Java
and C# appear, where this problem of the C buffer overflow should be
avoided by design.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On 23 jul, 09:17, "Dann Corbit" <dcor...@connx.comwrote:
>
C is not more dangerous than (for instance) C++ in this regard. But it is
more dangerous than (for instance) Ada. I would further argue that an Ada
compiler compiled with C is probably not as safe as an Ada compiler compiled
with Ada and that a C compiler compiled with Ada would probably be safer
than a C compiler compiled with C.
I don't follow you there.
How does the language used to implement a compiler affect the safety
of the code generated *by* that compiler?
I see absolutely no difficulty in writing a compiler in a 'safe'
language with full bounds checking that generates a buffer overflow in
every program compiled with it.
>
Unbounded arrays and trusting in nul termination of strings are reasons for
my above opinion. I'm not even sure that I want to fix it, if it will make
things a lot slower. But I do want to think about it.
I agree that C lacks every kind of safety net.
But I don't blame the language if I have taken every possible
precaution in my source code and the compiler still manages to screw
up. Those things, I blame on the compiler regardless of which language
I am using.
Bart v Ingen Schenau
[followups set to comp.lang.c]
jacob navia said:
Ron Ford wrote:
<snip>
>>
I'm somewhat of a non-believer here. There is no calculus to decide.
Well, mathematics doesn't need beliefs.
It needs a few. They are called axioms.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Friedrich said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>If you don't want buffer overflows, hire some good programmers. One way
you can tell they're good is that they hold regular code reviews in
which they point out faults in each others' code.
It has turned out that in all kind of products,
buffer overflows do have and do occur.
Yes. In fact, it turns out that in ALL walks of life, people - even bright
people - screw up, and the impact of those screw-ups can be serious. Short
of mass suicide, there is no real solution to this problem. If you take
away the potential to cause damage, you generally do so at the expense of
liberty and power. Design a language in which buffer overflows are
impossible, and you'll find at least two consequences: (a) some ideas
become more cumbersome and inefficient to express in the new language, and
(b) some other devilish weakness will manifest itself, causing people to
rail against /that/ language, too. What a colossal waste of time!
In languages based on C you can
be king of all programmers, but this errors can get even those. And
unfortunatylly this kind of bugs can lurk around for ages and be not
discovered. Unfortunatly this really is one of the weaknesses in C
based languages, with the attitude "the programmer knows"....
If the programmer *doesn't* know, then the best thing to do is to keep the
programmer well away from the computer.
>
Having good programmres surely will help but it does not mean that
those bugs can not appear in their code also
No, of course it doesn't - but skilled code review teams can go a long way
towards eliminating these and other bugs.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
[followups set to comp.lang.c]
Giacomo Catenazzi said:
<snip>
Are buffer overflows problem of *C* or of implementation of *C*?
No, they're a problem of C programmers.
I see only one problem on C standard, that limits the capabilities
of a compiler (+ run time environment) to check overflows.
Mandating it would be such a bad idea. Implementations are already free to
do bounds checking if they wish. Let the market decide. Programmers will
generally make the smart move if they're given the time to think about it.
Trust them to decide for themselves.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Bart van Ingen Schenau wrote:
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Bart v Ingen Schenau
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
Zero terminated strings, where there are no bounds checking make it
almost impossible to avoid errors since it requires from the programmer
never to forget the lengths of buffers!
I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield wrote:
) [followups set to comp.lang.c]
)
) jacob navia said:
)
)Ron Ford wrote:
)<snip>
)>>
)>I'm somewhat of a non-believer here. There is no calculus to decide.
)>>
)>
)Well, mathematics doesn't need beliefs.
)
) It needs a few. They are called axioms.
A mathematician doesn't need to believe in the correctness his axioms.
It's only when mathematics get applied to the real world that the validity
of the axioms become important.
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
jacob navia said:
Richard Heathfield wrote:
<snip>
>4. Buffer overflows can sometimes occur when running some carelessly
written programs under some conditions of invocation and inputs,
This idiotic attitude is typical of the people here.
If I strip that sentence of its emotional (and highly biased) content, it
boils down to "I disagree with your claim", which is up to you, but I
think you're wrong, obviously.
There is nothing wrong, buffer overflows aren't a problem, it is the
fault of the lazy programmers that aren't as clever as they should be.
Yet again, you are mischaracterising my position. OF COURSE buffer
overflows are a problem. But they aren't the problem you'd like them to
be; they are merely the problem they are. They're just bugs, and - like
other bugs - they need to be fixed. And, like other bugs, they're made by
bad, or inexperienced, or hurried, or careless, or simply bad-hair-day
programmers. Don't blame the language for people's inability to program
perfectly in it.
Typical too is the lack of any software engineering argumentation,
What's to argue? Buffer overflows are a risk, yes. And for those who cannot
abide running that risk, well, all they have to do is use a language in
which it is guaranteed that buffer overflows can't occur. Isn't that
blindingly obvious? So obvious as not to need saying?
and
the desire to always stay in the three main discussions subject of this
group
1: void main(void) is not correct
2: i=I++ + ++i; is not correct
3: Doing lazy student's homework.
Yet again, you have mischaracterised my position.
Anything that goes beyond that is off topic, for instance a book about
formal analysis of C programs obviously.
But I haven't claimed that the book is off-topic.
There is NO NEED for formal
analysis when there are no buffer overflows, all contrary evidence
notwithstanding.
I have not claimed that there is no need for formal analysis. Nor have I
claimed that there are no buffer overflows in C programs. If I made stuff
up about you at the rate you make it up about me, you'd have sued me for
libel by now, and probably won, too.
Implicit in this attitude is the attitude of their guru heathfield,
when he just dismisses the problem as above:
I am no guru. I am certainly not "their" guru. That's your misperception of
the social dynamics of this group.
>
"carelessly written programs"... like his book (C unleashed) where
he assumes that sizeof(int) equals sizeof(void *)
Cite, please. You claimed this before, and were shown to be mistaken.
and gets a buffer overflow.
Cite, please.
That he realized his error LATER and put the solution in
the ERRATA should be a reminder to him that not only "carelessly written
programs" happen to contain buffer overflows but that the easy with
which you can do those errors in C is a PROBLEM for C!
If "C Unleashed" contains code that allows a buffer overflow, that is
certainly a problem with the code. Unlike electronic publications, such as
compilers, there are certain practical difficulties with bug-fixing paper
publications, insofar as paper is much more difficult to update than
computer memory. The best we can do is publish errata, so that people are
at least aware of the problems. This is the paper equivalent of a bugfix
release of a compiler - and you've done loads of those, right?
As I say, that's a problem with the code (if the report is correct, which
it probably isn't, because most of what Jacob says is baloney, but there's
an outside chance that he's right - even a stopped clock is right twice a
day). But it is *not* a problem with the language. It just means that the
language was not used correctly. The fix? Fix the code. (Duh.)
But no.
>where
these programs are written in any of a variety of languages (certainly
including C, but also including C++ for a start) that are sufficiently
powerful to be capable of being dangerously misused by amateurs.
Yes sure.Those amateurs include heathfield obviously!
Yeah, although you may find this hard to believe, I've never made any great
claim to be a brilliant programmer. I certainly wouldn't put myself in the
same category as writers of C compilers - which is why I find it so
strange that so often I have to correct you about some aspect of C that
you've misunderstood. You ought to be able to wipe the floor with me in
any technical discussion, but instead you rely on mischaracterisation,
misquotation, misrepresentation and a markedly mistaken understanding of
the purpose of this newsgroup.
>If you don't want buffer overflows, hire some good programmers.
Mr heathfield should follow his own advise. When writing a book,
try to hire a good programmer to write the examples.
We did.
>
>One way you
can tell they're good is that they hold regular code reviews in which
they point out faults in each others' code.
This did not work in C unleashed.
No, it didn't, because we didn't have time. Unfortunately, the deadline was
outside my control. (I will not let this happen again.)
>
This did not work in all the buffer overflows we were having in the last
years. And it is extremely expensive.
How do you know they are buffer overflows? Because someone looked at the
code, right? So it *DID* work after all. All you have to do now is fix
them.
This attitude is leading to the conclusion for most sensible people that
they should avoid C (and C++) at all costs.
You claim to speak for most sensible people? The mind boggles. I thought
you claimed only to speak for yourself.
Hence languages like Java
and C# appear, where this problem of the C buffer overflow should be
avoided by design.
Fine, if you prefer C# or Java, use C# or Java. Why should I care? It's
only a computer programming language, you know, not a religion. God isn't
going to think any the less of you for turning your back on C.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Willem said:
Richard Heathfield wrote:
) [followups set to comp.lang.c]
)
) jacob navia said:
)
)Ron Ford wrote:
)<snip>
)>>
)>I'm somewhat of a non-believer here. There is no calculus to decide.
)>>
)>
)Well, mathematics doesn't need beliefs.
)
) It needs a few. They are called axioms.
A mathematician doesn't need to believe in the correctness his axioms.
Fair point - they're more sort of meta-beliefs, aren't they? IF we believe
THESE things, then THOSE are the consequences...
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Dann Corbit wrote:
"James Kuyper" <ja*********@verizon.netwrote in message
....
>reason. This group is very specifically for discussions about the C
standard, not about how to use the language defined by that standard.
....
This:
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs.
Sounds like it would be interesting to compiler vendors and language
designers to me.
While many on-topic discussions in comp.std.c are "interesting to
compiler vendors and language designers", the simple fact that an issue
is "interesting to compiler vendors and language designers" does not
make it on-topic for comp.std.c, not even if it's specifically about C.
It has to be about the C standard to be on-topic.
"jacob navia" <ja***@nospam.comwrote in message
news:g6**********@aioe.org...
Buffer overflows are a fact of life, and, more specifically, a fact of
C.
All is not lost however. In the book
"Value Range Analysis of C programs" Axel Simon tries to establish a
theoretical framework for analyzing C programs. In contrast to other
books where the actual technical difficulties are "abstracted away",
this books tries to analyze real C programs taking into account
pointers, stack frames, etc.
This sounds very much like the sort of analyses done by tools such as
Polyspace, Absint & Astree.
It is unclear why the author would _try_ to establish such a framework - it
seems to already be done and there are practical tools available to apply
the techniques. These tools are already in use by organizations that place
a premium on code correctness.
Perhaps the book is a text that covers the subject of Abstract
Interpretation and the author is providing the technical details behind the
technique. This would still make it an interesting book, though I would
characterize it as a technical reference book about an established
technique, rather than presenting something new (which is the impression I
take from the "tries to establish" tag).
--
Stuart
On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
Bart van Ingen Schenau wrote:
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
rubbish. Yes gets() is a problem. No one in their right mind
uses gets(). But asctime() *can* be used safely. Just make sure
the buffer is big enough. Now can you name any other standard
function that *cannot* be used safely?
Zero terminated strings, where there are no bounds checking make it
almost impossible to avoid errors
nonsense. Plenty of C gets written using zero terminated
strings which is perfectly fine.
since it requires from the programmer
never to forget the lengths of buffers!
you can get the program to do that for you
I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
I don't think anyone objects to string libraries (at least
a couple of regulars have their own) the argument was aginst
incorporating a string library into the standard. Actually
I'd be interested. I've used C++ strings and it does make
some things easier.
--
Nick Keighley
Programming should never be boring, because anything
mundane and repetitive should be done by the computer.
~Alan Turing
James Kuyper wrote:
Dann Corbit wrote:
>"James Kuyper" <ja*********@verizon.netwrote
...
>>reason. This group is very specifically for discussions about
the C standard, not about how to use the language defined by
that standard.
...
>This:
"Value Range Analysis of C programs" Axel Simon tries to
establish a theoretical framework for analyzing C programs."
Sounds like it would be interesting to compiler vendors and
language designers to me.
While many on-topic discussions in comp.std.c are "interesting
to compiler vendors and language designers", the simple fact
that an issue is "interesting to compiler vendors and language
designers" does not make it on-topic for comp.std.c, not even
if it's specifically about C. It has to be about the C standard
to be on-topic.
Extremely short sighted. Even if limited to readers on c.s.c
(which it was not, since it was cross-posted) it is ridiculous to
suggest that readers should maintain total ignorance of anything
written outside of the actual standard. I have no knowledge of the
book in question, but such information is essential to anyone
daring to modify the actual C standard.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
jacob navia wrote:
>
.... snip ...
>
This did not work in all the buffer overflows we were having in
the last years. And it is extremely expensive.
This attitude is leading to the conclusion for most sensible
people that they should avoid C (and C++) at all costs. Hence
languages like Java and C# appear, where this problem of the C
buffer overflow should be avoided by design.
Of course the minor detail that a fix for most of such errors, in
language form, was well developed 5 or 10 years before C appeared
(and 20+ years before C89) is ignored here. See ISO 7185, and the
successor ISO 10206.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Bart van Ingen Schenau wrote:
>
.... snip ...
>
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because the basic design of C is such as to make automatic machine
checking of possible overflows impracticable to implement. That
was a choice during development.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Nick Keighley wrote:
On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
>Bart van Ingen Schenau wrote:
>>So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
rubbish. Yes gets() is a problem. No one in their right mind
uses gets(). But asctime() *can* be used safely. Just make sure
the buffer is big enough.
No you can't make sure the buffer is big enough. The standard mandates
a 26 byte buffer.
Now can you name any other standard
function that *cannot* be used safely?
strncpy
>
>Zero terminated strings, where there are no bounds checking make it
almost impossible to avoid errors
nonsense. Plenty of C gets written using zero terminated
strings which is perfectly fine.
Sure sure.
>since it requires from the programmer
never to forget the lengths of buffers!
you can get the program to do that for you
No
>I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
I don't think anyone objects to string libraries (at least
a couple of regulars have their own) the argument was aginst
incorporating a string library into the standard. Actually
I'd be interested. I've used C++ strings and it does make
some things easier.
The library uses operator overloading with counted strings.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
CBFalconer <cb********@yahoo.comwrote:
jacob navia wrote:
This attitude is leading to the conclusion for most sensible
people that they should avoid C (and C++) at all costs. Hence
languages like Java and C# appear, where this problem of the C
buffer overflow should be avoided by design.
Of course the minor detail that a fix for most of such errors, in
language form, was well developed 5 or 10 years before C appeared
(and 20+ years before C89) is ignored here. See ISO 7185, and the
successor ISO 10206.
YM ISO 1989, I'm sure.
Richard
CBFalconer wrote:
James Kuyper wrote:
....
>While many on-topic discussions in comp.std.c are "interesting
to compiler vendors and language designers", the simple fact
that an issue is "interesting to compiler vendors and language
designers" does not make it on-topic for comp.std.c, not even
if it's specifically about C. It has to be about the C standard
to be on-topic.
Extremely short sighted. Even if limited to readers on c.s.c
(which it was not, since it was cross-posted) ...
That was rather my point; it should not have been cross-posted to
comp.std.c, it should only have been posted to comp.lang.c.
... it is ridiculous to
suggest that readers should maintain total ignorance of anything
written outside of the actual standard. I have no knowledge of the
book in question, but such information is essential to anyone
daring to modify the actual C standard.
I'm not suggesting ignorance, I'm suggesting that there's appropriate
places to discuss various topics. That general topic of buffer overruns
is an important one that many people should be interested in, and should
discuss - but only in the appropriate forum - comp.std.c is not such a
forum.
Discussions of whether and how the standard should be modified to make
it easier to avoid buffer overruns would be entirely on topic in
comp.std.c (and arguably (everything on c.l.c is arguable!) off-topic
for comp.lang.c). I've seen no such discussion so far.
Nick Keighley wrote:
On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
>Zero terminated strings, where there are no bounds checking make it
almost impossible to avoid errors
nonsense. Plenty of C gets written using zero terminated
strings which is perfectly fine.
>since it requires from the programmer
never to forget the lengths of buffers!
you can get the program to do that for you
>I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
I don't think anyone objects to string libraries (at least
a couple of regulars have their own) the argument was aginst
incorporating a string library into the standard. Actually
I'd be interested. I've used C++ strings and it does make
some things easier.
Such libraries permits new types of attack.
Actual strings forces reading the memory from
beginning, so strings should terminate earlier
(by a "random" 0 character, or a segmentation fault).
On new libraries, the libraries could take advantage
of new fields, and thus it could access the end of
the string, so in kernel or other library space.
OTOH new strings will reduce programmer error, and
thus start of attacks.
Anyway alternate strings libraries already exists,
but it seems that they are not widely used, so
I don't think they are ready to be standardized.
BTW, an alternate string library should really
have a good design, allowing simple plug-in
of i18n, so reducing transition costs.
FYI I found n1173, with some rationale on these goals:
1.1.6 Preserve the null terminated string datatype
1.1.7 Do not require size arguments for unmodified strings
1.1.9 Library based solution
ciao
cate
jacob navia wrote:
Nick Keighley wrote:
>On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
>>Bart van Ingen Schenau wrote:
>>>So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
rubbish. Yes gets() is a problem. No one in their right mind
uses gets(). But asctime() *can* be used safely. Just make sure
the buffer is big enough.
That won't do the job. The right way to use asctime() safely is to make
sure it's argument points at a structure whose contents won't cause a
buffer overrun.
No you can't make sure the buffer is big enough.
You're right about that, but not about this:
... The standard mandates
a 26 byte buffer.
The standard mandates that the actual implementation be equivalent to
specified implementation. Since the consequences of writing past the end
of a buffer are that the behavior is undefined, there is no behavior
that is prohibited to asctime() when called with a pointer to a struct
tm whose contents would cause that buffer to overflow. Which means that
an implementation which used a longer buffer would be just as conforming
as one which did not.
>Now can you name any other standard
function that *cannot* be used safely?
strncpy
A single counter-example is sufficient to disprove a general assertion
like "strncpy() cannot be used safely". If your assertion were true,
there would have have to be some safety issue with the following code.
Would you care to explain what you think that issue is?
#include <string.h>
#include <stdio.h>
int main(void)
{
char input[] = "This is the input string";
char output[10];
size_t size = (sizeof output - 1 < sizeof input ?
sizeof output - 1 : sizeof input);
strncpy(output, input, size);
output[size] = '\0';
printf("%s\n", output);
return 0;
}
The '-1' and the explicitly forced null termination are needed only if
downstream processing requires that output[] be a null-terminated
string. That is true in the code above, but has not been true in any of
the cases where I've have a reason to use strncpy() recently, which
makes safe usage of strncpy() a lot simpler.
If "input" and "output" were pointers rather than arrays, determine the
correct value for the third argument of strncpy() would be more
complicated, but is still feasible.
jacob navia <ja***@nospam.comwrites:
Nick Keighley wrote:
>On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
>>Bart van Ingen Schenau wrote:
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
rubbish. Yes gets() is a problem. No one in their right mind
uses gets(). But asctime() *can* be used safely. Just make sure
the buffer is big enough.
No you can't make sure the buffer is big enough. The standard mandates
a 26 byte buffer.
Yes, asctime() provides its own static buffer. But you can use
asctime() safely by ensuring that the arguments (or rather, the
members of the struct tm object pointed to by the single argument) are
within safe bounds.
asctime() is a poorly designed and specified function. It can't be
changed *too* much without breaking existing code. It *could* be
tweaked to require implementation-defined but safe behavior for
out-of-bounds arguments, and I would support such a change. But I
suspect that most existing code that uses asctime() uses it with an
argument corresponding to the current time, which will be safe until
the end of the year 9999.
It absolutely is not as dangerous as gets(). gets() cannot be used
safely (unless you have absolute control over what will appear on
stdin, which is not normally possible). asctime() *can* be used
safely with some care, and it usually is. For example, the following
program is safe if it's executed before the year 10,000 (assuming the
time() function doesn't misbehave):
#include <stdio.h>
#include <time.h>
int main(void)
{
time_t now = time(NULL);
fputs(asctime(localtime(&now)), stdout);
return 0;
}
>Now can you name any other standard
function that *cannot* be used safely?
strncpy
You are mistaken. strncpy() is poorly named, and is difficult to use
safely if you don't understand what it actually does, but it most
certainly can be used safely, if you happen to need the rather odd
data structure that it supports.
Yes, I can write unsafe code using strncpy, but that wasn't the
question. I can write unsafe code without using any library functions
at all.
[...]
>>I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
I don't think anyone objects to string libraries (at least
a couple of regulars have their own) the argument was aginst
incorporating a string library into the standard. Actually
I'd be interested. I've used C++ strings and it does make
some things easier.
The library uses operator overloading with counted strings.
I think that explains the lack of enthusiasm. A proposal for a
library that can be used with C compilers other than yours might have
gotten a better reception.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
CBFalconer <cb********@yahoo.comwrites:
James Kuyper wrote:
>Dann Corbit wrote:
>>"James Kuyper" <ja*********@verizon.netwrote
...
>>>reason. This group is very specifically for discussions about
the C standard, not about how to use the language defined by
that standard.
...
>>This:
"Value Range Analysis of C programs" Axel Simon tries to
establish a theoretical framework for analyzing C programs."
Sounds like it would be interesting to compiler vendors and
language designers to me.
While many on-topic discussions in comp.std.c are "interesting
to compiler vendors and language designers", the simple fact
that an issue is "interesting to compiler vendors and language
designers" does not make it on-topic for comp.std.c, not even
if it's specifically about C. It has to be about the C standard
to be on-topic.
Extremely short sighted. Even if limited to readers on c.s.c
(which it was not, since it was cross-posted) it is ridiculous to
suggest that readers should maintain total ignorance of anything
written outside of the actual standard. I have no knowledge of the
book in question, but such information is essential to anyone
daring to modify the actual C standard.
Anyone daring to modify the actual C standard should certainly have
sources of information beyond comp.std.c.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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" rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
CBFalconer <cb********@yahoo.comwrote:
>jacob navia wrote:
This attitude is leading to the conclusion for most sensible
people that they should avoid C (and C++) at all costs. Hence
languages like Java and C# appear, where this problem of the C
buffer overflow should be avoided by design.
Of course the minor detail that a fix for most of such errors, in
language form, was well developed 5 or 10 years before C appeared
(and 20+ years before C89) is ignored here. See ISO 7185, and the
successor ISO 10206.
YM ISO 1989, I'm sure.
ISO 7185 and ISO 10206 are Pascal; ISO 1989 is Cobol.
I haven't used Pascal in many years, but as I recall it paid a price
for its relative safety.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Keith Thompson <ks***@mib.orgwrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
CBFalconer <cb********@yahoo.comwrote:
jacob navia wrote:
This attitude is leading to the conclusion for most sensible
people that they should avoid C (and C++) at all costs. Hence
languages like Java and C# appear, where this problem of the C
buffer overflow should be avoided by design.
Of course the minor detail that a fix for most of such errors, in
language form, was well developed 5 or 10 years before C appeared
(and 20+ years before C89) is ignored here. See ISO 7185, and the
successor ISO 10206.
YM ISO 1989, I'm sure.
ISO 7185 and ISO 10206 are Pascal; ISO 1989 is Cobol.
I know.
I haven't used Pascal in many years, but as I recall it paid a price
for its relative safety.
Yah. Quite a one. And so did COBOL.
Richard
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Nick Keighley wrote:
>>On 23 Jul, 10:36, jacob navia <ja...@nospam.comwrote:
Bart van Ingen Schenau wrote:
So, why do people complain all the time about the possibility of
buffer overflows in C, but not in other languages?
>
Because functions like gets() asctime() and other standard
functions (still in C99 standard even if gets() got deprecated)
make buffer overflows almost MANDATORY.
rubbish. Yes gets() is a problem. No one in their right mind
uses gets(). But asctime() *can* be used safely. Just make sure
the buffer is big enough.
No you can't make sure the buffer is big enough. The standard mandates
a 26 byte buffer.
Yes, asctime() provides its own static buffer. But you can use
asctime() safely by ensuring that the arguments (or rather, the
members of the struct tm object pointed to by the single argument) are
within safe bounds.
The C standard shows a piece of code that will overflow its static
buffer if used with a year value greater than 8900 (if I remember
correctly)
Similarly, if the month value is greater than 12 it will
show UB.
Obviously, showing such a piece of code is a reminder to the rest
of the world how much the standard cares about buffer overflows.
The discussion in this group confirms this. Look at Mr Thomson:
asctime() is a poorly designed and specified function. It can't be
changed *too* much without breaking existing code.
Absolutely not. I derived the formula for the EXACT size of the buffer
in this discussion group. It is relatively simple. The only thing that
needs to be changed is the "26" in the size of the buffer.
I mailed a correction of asctime to Mr Plauger, probably member of the
comitee. Never an answer.
It *could* be
tweaked to require implementation-defined but safe behavior for
out-of-bounds arguments, and I would support such a change.
Then why you don't support it now and act to get rid of a buffer
overflowing code written in the C standard document?
But I
suspect that most existing code that uses asctime() uses it with an
argument corresponding to the current time, which will be safe until
the end of the year 9999.
No, the end is 8100 since you add 1900
It absolutely is not as dangerous as gets(). gets() cannot be used
safely (unless you have absolute control over what will appear on
stdin, which is not normally possible). asctime() *can* be used
safely with some care, and it usually is. For example, the following
program is safe if it's executed before the year 10,000 (assuming the
time() function doesn't misbehave):
#include <stdio.h>
#include <time.h>
int main(void)
{
time_t now = time(NULL);
fputs(asctime(localtime(&now)), stdout);
return 0;
}
>>Now can you name any other standard
function that *cannot* be used safely?
strncpy
You are mistaken. strncpy() is poorly named, and is difficult to use
safely if you don't understand what it actually does, but it most
certainly can be used safely, if you happen to need the rather odd
data structure that it supports.
After all those "poorly named", "difficult to use", "odd data structure"
couldn't we get RID OF THAT PIECE OF ... ???
Yes, I can write unsafe code using strncpy, but that wasn't the
question. I can write unsafe code without using any library functions
at all.
You misunderstand the whole point. Apparently you do not understand what
ERROR PRONE
means?
Would you drive a car that kills you at the slightest mistake
for years and years?
You CAN drive a car like that if you never make any mistakes
obviously. And after several thousand people have died you
CAN say:
They are just bad drivers. They made mistakes.
[...]
>>>I have proposed a string library for C to make those errors more
difficult. The reception was as expected... :-(
I don't think anyone objects to string libraries (at least
a couple of regulars have their own) the argument was aginst
incorporating a string library into the standard. Actually
I'd be interested. I've used C++ strings and it does make
some things easier.
The library uses operator overloading with counted strings.
I think that explains the lack of enthusiasm. A proposal for a
library that can be used with C compilers other than yours might have
gotten a better reception.
You jsut do not want to understand. I presented it as an example
of the direction that C could take, that is why I presented it in
this group.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Nick Coghlan |
last post by:
Thought some folks here might find this one interesting. No great revelations,
just a fairly sensible piece on writing readable code :)
The whole article:...
|
by: makko |
last post by:
Hello,
anyone know how to writre a program that take a commandline formula
and prints the calculated result? example;
$program 1+(2x3(3/2))-8
reagrds;
Makkko
|
by: Alvin Bruney [MVP] |
last post by:
I have two managed windows applications A and B. Both have their own config
files. Application A invokes application B thru process start. However,
since B runs in A's context, B starts up and...
|
by: natG |
last post by:
On a 3 column table, the PK consists of all 3 columns.
I have queries on the first two columns, as well as on the last two
columns. (Select * where column3=x and column2=y.)
I was hoping that...
|
by: nufuhsus |
last post by:
Hello all,
First let me appologise if this has been answered but I could not find
an acurate answer to this interesting problem.
If the following is true:
C:\Python25\rg.py>python
Python...
|
by: Mike |
last post by:
Hi
I am wonderinf if there are interesting examples to learn C.
Or any good idea?
Mike
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
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:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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...
| |
