secure integer library

[Keith Thompson]

Actually, Tom St Denis did, though you may have him killfiled and
Jacob chose to quote him in a totally nonstandard way.

Actually, I not only read Tom St Denis's use of the phrase "the end of
the earth as we know it", it was also quoted in jacob's article to
which I responded. I just missed it somehow. He used it
sarcastically, but I think I misinterpreted jacob's response to it.

Looking back at the thread, and particularly at jacob's article to
which I was responding, I'm no longer quite sure what point jacob was
trying to make.

 

[stdazi]

The CERT/CC has released a beta version of a secure integer library for
the C Programming Language. The library is available for download from
the CERT/CC Secure Coding Initiative web page at:
http://www.cert.org/secure-coding/

The purpose of this library is to provide a collection of utility
functions that can assist software developers in writing C programs that
are free from common integer problems such as integer overflow, integer
truncation, and sign errors that are a common source of software
vulnerabilities.

Functions have been provided for all integer operations subject to
overflow such as addition, subtraction, multiplication, division, unary
negation, etc.) for int, long, long long, and size_t integers. The
following example illustrates how the library can be used to add two
signed long integer values:

long retsl, xsl, ysl;
xsl = LONG_MAX;
ysl = 0;
retsl = addsl(xsl,ysl);

For short integer types (char and short) it is necessary to truncate the
result of the addition using one of the safe conversion functions
provided, for example:

char retsc, xsc, ysc;
xsc = SCHAR_MAX;
ysc = 0;
retsc = si2sc(addsi(xsc, ysc));

For error handling, the secure integer library uses the mechanism for
Runtime-constraint handling defined by TR 24731 "Specification for
Safer, More Secure C Library Functions" available at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

The implementation uses the high performance algorithms defined by Henry
S. Warren in the book "Hacker's Delight".

For more information on vulnerabilities and other problems resulting
from the incorrect use of integers in C and C++ please read Chapter 5 of
"Secure Coding in C and C++" which is available as a free download from
the CERT web site:

http://www.cert.org/books/secure-coding/moreinfo.html

Please address any defect reports, comments and suggestions concerning
the Secure Integer Library or CERT Secure Coding Initiative to me.
Thanks to Henry and to Juan Alvarado who coded the implementation.

Thanks,
rCs

I was always missing a functionality to detect integer overflows
(sometimes it's a pain when you realize the "wrong answer" is due to a
overflow), but I'd never really like to use the above implementation.

It stunts performance and (most importantly) coding time. I don't want
to think how ugly the code looks in a for loop manipulating many
integers. It's not that hard to put some "limits" in regions of code
you find prone to overflows - after some time, you get used to.

The best place for that kind of utility is IMO the compiler, and IIRC,
there is a patch for gcc too!

 

[rCs]

Random response to some of the ideas I've seen expressed in this
thread.

First of all, when I talk about integers I talk about "unexpected"
behavior. We all know that unsigned integers are defined by the C
standard as modulo so by definition this is the correct behavior. In
practice, however, many programmers fail to code for modulo behavior
resulting in unsigned overflow, incorrect program behavior, and
software vulnerabilities.

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

Third, I would also like to see range checking built into compilers.
There is of course, a great deal of overhead even here (I have heard
100%-500%). I think my favorite idea is to extend the specification
to allow for a new type of range checked integers, for example:

int i 25:100 = 35;

This is similar to the range clause in Ada and would in this example
declare an integer with a range of 25 to 100, initialized to 35. The
compiler would be required to make sure the range is not violated.

I don't think performance is an issue in this case because you won't
get the overhead unless you use the feature and in that case you are
only paying for what you get.

Error handling is more of a problem. How do you report a range error
given the lack of an error handling mechanism in C? My best solution
would be to implement the runtime constraint mechanism used in TR 24731
and the secure integer library that started this thread but I am open
to other ideas.

If you expect your existing compiler to provide integer range checking,
good luck! I know that gcc provides an -ftrapv flag that provides
overflow protection for a small list of signed integer operations.
Their implementation handles errors by calling abort(). As far as I
know, Visual Studio offers no overflow protection although they have
tried to tighten up their compiler warnings for integer truncation.

Fourth, I agree that integer overflow protection is not necessary
everywhere. Protecting each operation is sort of a sloppy approach to
limiting the ranges of values at input and making sure that all the
intermediate representations of integer values have sufficient
precision. However, this can be difficult to guarantee when you have
multiple integer inputs that are combined in a variety of ways. When
no such guarantees are possible, I recommend the use of this library
(or similar protections) for integer values that originate from
untrusted sources (e.g., users) and then are used as sizes, lengths,
loop counters, or indicies as the incorrect use of integers in these
cases most common results in exploitable vulnerabilities.

rCs

 

[jacob navia]

rCs a écrit :

Random response to some of the ideas I've seen expressed in this
thread.

First of all, when I talk about integers I talk about "unexpected"
behavior. We all know that unsigned integers are defined by the C
standard as modulo so by definition this is the correct behavior. In
practice, however, many programmers fail to code for modulo behavior
resulting in unsigned overflow, incorrect program behavior, and
software vulnerabilities.

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

Good point, however it would be impossible to test for this at run time
since this "feature" is part of the expected behavior of
many programs

Third, I would also like to see range checking built into compilers.
There is of course, a great deal of overhead even here (I have heard
100%-500%). I think my favorite idea is to extend the specification
to allow for a new type of range checked integers, for example:

int i 25:100 = 35;

This is similar to the range clause in Ada and would in this example
declare an integer with a range of 25 to 100, initialized to 35. The
compiler would be required to make sure the range is not violated.

Interesting idea.

I don't think performance is an issue in this case because you won't
get the overhead unless you use the feature and in that case you are
only paying for what you get.

Exactly.

Error handling is more of a problem. How do you report a range error
given the lack of an error handling mechanism in C? My best solution
would be to implement the runtime constraint mechanism used in TR 24731
and the secure integer library that started this thread but I am open
to other ideas.

Yes, I proposed using TR 24731 error handling mechanism as a default
error handling mechanism for C in the comp.lang.c discussion group.
http://groups.google.fr/group/comp....211e9/1e5d0a124fe18c1c?hl=fr#1e5d0a124fe18c1c

Obviously that is an interesting idea since silence was the only answer.
Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

 

[Keith Thompson]

Second, integer overflow is not the only problem. For example, the
following code will never overflow for most implementations:

char sc1, sc2, sc_result;

sc_result = sc1 + sc2;

Let's assume for example that signed char is 8 bits and int is 32 bits.
Because of integer promotions both sc1 and sc2 are promoted to signed
integers before this addition takes place. This means overflow is
impossible, but truncation is not. Simply providing an overflow
detection mechanism in this case is insufficient.

[snip]

Truncation isn't the only possibility.

First, let's assume that int is bigger than char. If it isn't (which
requires CHAR_BIT > 8), then some other odd things can happen; we'll
ignore those unlikely possibilities.

sc1 and sc2 are promoted (i.e., converted) to type int and added,
yielding a result of type int. So far, no overflow is possible. Then
the result is assigned to sc_result -- but first it must be converted
from int to char.

For an arithmetic operations on a signed integer type, overflow
invokes undefined behavior. For a *conversion* to a signed integer
type, where the target type cannot represent the value, either the
result is implementation-defined or an implementation-defined signal
is raised (the latter possibility was introduced in C99).

For signed integer overflow on both arithmetic operations and
conversions, the most common behavior is that the high-order bits are
discarded, but the standard allows for many other possibilities.

 

[CBFalconer]

rCs a écrit :
.... snip ...


Yes, I proposed using TR 24731 error handling mechanism as a
default error handling mechanism for C in the comp.lang.c
discussion group.
http://groups.google.fr/group/comp....211e9/1e5d0a124fe18c1c?hl=fr#1e5d0a124fe18c1c

Obviously that is an interesting idea since silence was the only
answer. Skarmander and Keith Thompson answered but none of the
comitee guys answered since obviously I have complained (and
loudly) about gets() being still in the standard...

You are one of the few people who have total control over some
compiler system. This should be your opportunity to do something
important. I already advised you how to insert overflow checking
in x86 object code (which you may well have already known). If you
create a system that does this, and simultaneously STRICTLY ADHERES
to the C standard, be it C90, C95, or C99, you will have done the
community a service. To do all this you have to have a switch,
preferably on by default, which bans all extensions.

Even if such a compiler system is limited to Windows use, it will
be used fairly heavily to expose coding faults. It need not be the
fastest, but it does need to me the most accurate. This could
start by properly detecting all integer overflows, and expand
later.

For example, it is possible (at great run time overhead) to make
all pointers indirect and thus totally control pointer validity.
This might be a future direction for a supersafe validation
system. I don't recommend it as a first effort.

Consider it.

 

[Mark McIntyre]

Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

The part from "since" onwards is unnecessary, insulting and
gratuitous, and explains exactly why people killfile you. If you want
to be listened to, stop making defamatory remarks.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Obviously that is an interesting idea since silence was the only answer.
Skarmander and Keith Thompson answered but none of the comitee guys
answered since obviously I have complained (and loudly) about gets()
being still in the standard...

I've also complained about gets() being in the standard, and I get
responses from committee members all the time.

jacob, it seems to me that you are *really bad* at guessing other
people's motivations. That's ok (not everyone can be good at
everything), but I suggest that you stop trying to do so, at least in
public, until you figure out how to do it right. It would greatly
improve your personal signal-to-noise ratio, and would likely cause
people to pay more serious attention to your ideas.

I admit I'm being a bit sarcastic here, but this is also intended as
serious advice.

 

[jacob navia]

Mark McIntyre a écrit :

The part from "since" onwards is unnecessary, insulting and
gratuitous, and explains exactly why people killfile you. If you want
to be listened to, stop making defamatory remarks.

Mr Gwyn, that is related to the people in the comitee
answered AT LENGTH defending gets().

You can read that thread in Google:
Thread name: Why does rewind() ignore errors?
Thread author: Keith Thompson
Date: May 26th 2006 21:34

There you will se Mr Gwyn defending gets() and treating people that
wanted that function away from the standard as "fanatics".

This was done under the thunderous SILENCE of the other comitee members.

NONE of them cared to express a different view.

I am not insulting anybody, neither did I treat them as "fanatics"
as they did to me.

jacob

 

[jacob navia]

Keith Thompson a écrit :

I've also complained about gets() being in the standard, and I get
responses from committee members all the time.

Yes, all of them defending gets().

Maybe I am exaggerating. I hope so actually that it is just an
oversight, but really, after that discussion about gets() there is
nothing that can be done there.

The next standard is not even "in the works", and language evolution
is completely at a standstill, because, (as they have often repeated)
their job is to leave the language as it is without any change
so that legacy software doesn't get disturbed and C can die a
quite death without even a whisper.

C++ is where all development is done. The language is relatively
new, and people there accept that a language must be improved
by the comitee, that in C++ has a very positive function.

Contrast that with the C situation where getting rid of a bug
like gets() implies insults from the comitee representatives
like "fanatics".

Nothing is done, no new directions, no improvements and proposal like
getting rid of trigraphs/gets()/asctime()/ provoke only answers
like "nothing will be done".

But maybe there are people in the comitee that have another opinion,
they just do not participate to any discussion.

I spoke with the French standards comitee and they would maybe care to
review my suggestions AFTER I spend 10 000 euros in costs...

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

jacob

 

[Keith Thompson]

The next standard is not even "in the works", and language evolution
is completely at a standstill, because, (as they have often repeated)
their job is to leave the language as it is without any change
so that legacy software doesn't get disturbed and C can die a
quite death without even a whisper.

You see, this is exactly what I meant when I said that you are *really
bad* at guessing other people's motivations.

I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

[...]

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

 

[jacob navia]

Keith Thompson a écrit :

You see, this is exactly what I meant when I said that you are *really
bad* at guessing other people's motivations.

I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

There are several "technical reports" but it is not at all clear
how binding they are.

[...]

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

 

[Keith Thompson]

Keith Thompson a écrit : [...]

I don't believe that *anybody* who has participated in these
discussions wants C to "die a quiet death". That's just your
interpretation, and it's absolutely wrong. I've spent far too much
time trying to help you understand that, but apparently you're
unwilling to listen.

Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

There are several "technical reports" but it is not at all clear
how binding they are.

That's not what I'm talking about. What I'm talking about is your
ridiculous assertion that certain people want C to "die a quiet
death". They don't.

You probably have some good points to make about safety. Your
combative attitude is what causes people to ignore you. Please think
about that.

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Good for you. I have no complaints about the fact that you're
maintaining a free C implementation. (It happens to be of no use to
me, because I don't do win32 programming, but that doesn't mean it's
not a wonderful thing for those who can use it.) My only complaints
are about what you post here.

I don't *really* want you to stop posting. I would like you to post
*constructively*, without insulting people who merely disagree with
you. But I'm just about ready to give up (yet again) on making you
understand that.

 

[Ed Jensen]

Yes, you and many people here would like that I stop.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Jacob, I enjoy reading your comments here, and agree with many of
them.

 

[CBFalconer]

.... snip ...

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

IIRC you withdrew the compiler from the 'free source'
classification several years ago.

 

[Keith Thompson]

IIRC you withdrew the compiler from the 'free source'
classification several years ago.

To be fair, he didn't say it's free source, merely that it's free.

 

[Mark McIntyre]

Mark McIntyre a écrit :

There you will se Mr Gwyn defending gets() and treating people that
wanted that function away from the standard as "fanatics".

*shrug*. There are arguments for and against gets(). Personally I find
the simplest solution is just not to use it. I would consider it
'fanatical' to rant on and on about it though.

This was done under the thunderous SILENCE of the other comitee members.

NONE of them cared to express a different view.

Or perhaps all of them have killfiled you due to your constant
rudeness.

I am not insulting anybody, neither did I treat them as "fanatics"
as they did to me.

I disagree, you frequently insult people, you show blatant disregard
for the customs and rules of the groups, and you treat many posters as
fanatics.

And in what way does /any/ of the above make your original remark less
defamatory and quite probably actionable? Get a grip on yourself.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Herbert Rosenau]

Please tell me then one example of a comitee member
that cares about error handling in the C library specification
and wants to put gets() in the obsolescent part of the standard.

No need for as jacob naiva has already proven that he is a twit only.

Please tell me a single proposal done by the comitee that
proposes a solution to a problem in the language.

The comitee does what is needed on C, not what a twit means tha C
should support.

Contrary to the C++ comitee where they give new directions to
the language and library, the C comitee doesn't propose a single
thing.

It is completely irrelevant what a twit things.

There are several "technical reports" but it is not at all clear
how binding they are.

It is completely irrelevant what a twit things.

[...]

So I am stuck and neither comp.lang.c nor comp.std.c discussions will
change anything.

So do us all a favor and stop posting here.

Yes, you and many people here would like that I stop.

Anybody will profit from you leaving NOT in this group.

You will win eventually. I am very tired, and have been sustaining
with my own personal budget and my own time a free C implementation
since something like 10 years.

Noways. As you have proven yourself you has a compiler that has
nothing to do with C but with a langues that looks partlti as C but is
definitely NOT C and not a bit compatible with the rest of the world.
It is not even compatible to any other compiler on windows.

STOP spamming for your crap here.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Walter Roberson]

No need for as jacob naiva has already proven that he is a twit only.

Herbert, in my opinion, we would be better off without personal
insults of that sort. This newsgroup has disagreements enough
as it is without needing to get into ad hominem attacks. If you
must say something, then attack the ideas (through logic), not the person.

 

[CBFalconer]

Herbert, in my opinion, we would be better off without personal
insults of that sort. This newsgroup has disagreements enough as it
is without needing to get into ad hominem attacks. If you must say
something, then attack the ideas (through logic), not the person.

I think he is trying to replace Dan Pops diplomacy, without Dans
knowledge.