A very interesting book

[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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Walter Roberson]

Re: A very interesting book

In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>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.programmin g 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

[Dann Corbit]

Re: A very interesting book

"Walter Roberson" <roberson@ibd.n rc-cnrc.gc.cawrote in message
news:g65bep$r06 $1@canopus.cc.u manitoba.ca...

In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>>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.programmin g 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 **

[jacob navia]

Re: A very interesting book

Walter Roberson wrote:

In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>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.programmin g 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

[Eric Sosman]

Re: A very interesting book

Walter Roberson wrote:

In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

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

--
Eric.Sosman@sun .com

[Richard Heathfield]

Re: A very interesting book

Walter Roberson said:

In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
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

[Mark McIntyre]

Re: A very interesting book

Dann Corbit wrote:

"Walter Roberson" <roberson@ibd.n rc-cnrc.gc.cawrote in message
news:g65bep$r06 $1@canopus.cc.u manitoba.ca...

>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>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?

[Mark McIntyre]

Re: A very interesting book

Richard Heathfield wrote:

Walter Roberson said:
>

>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>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.

[Dann Corbit]

Re: A very interesting book

"Mark McIntyre" <markmcintyre@T ROUSERSspamcop. netwrote in message
news:eQshk.3053 3$c47.19008@en-nntp-06.am2.easynews .com...

Dann Corbit wrote:

>"Walter Roberson" <roberson@ibd.n rc-cnrc.gc.cawrote in message
>news:g65bep$r0 6$1@canopus.cc. umanitoba.ca...

>>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>>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
>>>theoretica l 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 **

[Dann Corbit]

Re: A very interesting book

"Mark McIntyre" <markmcintyre@T ROUSERSspamcop. netwrote in message
news:0Rshk.3053 4$c47.14813@en-nntp-06.am2.easynews .com...

Richard Heathfield wrote:

>Walter Roberson said:
>>

>>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>>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]

Re: A very interesting book

"Dann Corbit" <dcorbit@connx. comwrote in message
news:6fc1b$4886 8110$15205@news .teranews.com.. .

"Mark McIntyre" <markmcintyre@T ROUSERSspamcop. netwrote in message
news:eQshk.3053 3$c47.19008@en-nntp-06.am2.easynews .com...

>Dann Corbit wrote:

>>"Walter Roberson" <roberson@ibd.n rc-cnrc.gc.cawrote in message
>>news:g65bep$r 06$1@canopus.cc .umanitoba.ca.. .
>>>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>>>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
>>>>theoretic al 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 **

[Richard Heathfield]

Re: A very interesting book

Dann Corbit said:

"Mark McIntyre" <markmcintyre@T ROUSERSspamcop. netwrote in message
news:0Rshk.3053 4$c47.14813@en-nntp-06.am2.easynews .com...

>Richard Heathfield wrote:

>>Walter Roberson said:
>>>
>>>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>>>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

[Dann Corbit]

Re: A very interesting book

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:tfadnXXEvJ dnFRvVnZ2dnUVZ8 rKdnZ2d@bt.com. ..

Dann Corbit said:
>

>"Mark McIntyre" <markmcintyre@T ROUSERSspamcop. netwrote in message
>news:0Rshk.305 34$c47.14813@en-nntp-06.am2.easynews .com...

>>Richard Heathfield wrote:
>>>Walter Roberson said:
>>>>
>>>>In article <g65acc$427$1@a ioe.org>, jacob navia <jacob@nospam.o rg>
>>>>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 **

[Richard Heathfield]

Re: A very interesting book

Dann Corbit said:

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:tfadnXXEvJ dnFRvVnZ2dnUVZ8 rKdnZ2d@bt.com. ..

<snip>

>What the
>implementati on 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

[Ron Ford]

Re: A very interesting book

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