A very interesting book

J

jacob navia

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
 
W

Walter Roberson

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

jacob navia

Walter said:
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.
 
R

Ron Ford

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?"
 
J

James Kuyper

jacob said:
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.
 
T

Thad Smith

Eric said:
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.
 
B

Bart van Ingen Schenau

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
 
J

jacob navia

Ron said:
%- 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.
 
F

Friedrich

Richard Heathfield said:
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
 
G

Giacomo Catenazzi

Dann said:
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
 
F

Friedrich

Bart van Ingen Schenau said:
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
 
J

jacob navia

Richard said:
[Not sure what this is doing in csc - followups set to clc]

Thad Smith said:

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

Bart van Ingen Schenau

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
 
J

jacob navia

Bart said:
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... :-(
 
W

Willem

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
 
J

James Kuyper

Dann said:
....
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.
 
S

Stuart

jacob navia said:
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).
 
N

Nick Keighley

Bart van Ingen Schenau wrote:

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
 
C

CBFalconer

James said:
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.
 
C

CBFalconer

jacob said:
.... 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,832
Latest member
GlennSmall

Latest Threads

Top