secure integer library

[Robert Seacord]

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


--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC

Work: 412-268-7608
FAX: 412-268-6989

 

[MrDev]

Non-Windows version?

 

[jacob navia]

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

This is very interesting thing. It gives the layout of a "secure" form
of performing the basic operations. It could be easily and much more
efficientely implemented with compiler support, what I will try to
implement in the next future.

I have already implemented within the framework of lcc-win32 an overflow
exception detection with compiler support, and this could be an
extension to that.

Another interesting feature is that this library uses the mechanism
proposed by the secure C library document to handle the exception, as
I proposed in this group some time ago. That mechanism could become
the standard way to signal errors within the C community. This would
be a welcome change from the complete ignoring of error handling and
error treatment within the language.

This attitude (that the standards comitee implicitely supports) is
designed to destroy all usages of C within modern software development.

Happily things are starting to move, obviously from outside the
standards comitee.

 

[Tom St Denis]

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.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

 

[Ark]

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.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.
1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.
2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.
3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

 

[jacob navia]

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.

You want to help people write secure code by forcing to re-write

a = b + c;

to

a = add2siciasi(b, c); // or whatever your macros are... I stopped
laughing after looking at a few files

Right...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

What about just teaching developers to use the right data types? I'd
say that's more important than teaching them to use your library.

Tom

Tom

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.
1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.
2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.
3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

All the problem he has disappear with a C compiler that supports
operator overloading.

Note that the pentiums (Intel architecture) support arithmetic with
saturation too, and they have a huge piece of the market.

 

[Tom St Denis]

Sorry Tom, your post is sheer nonsense.
0.
You are not forced to use it everywhere; if you do know what you are
doing, go ahead and do it.

But it's *secure* so clearly if I'm not using it then I'm insecure.
You think that's nonsense? Try working for a PHB.

1.
Everything has its uses, and I, as well as you, can easily see the
usefulness of this stuff.

I can't. Of course I know how to develop software in a portable
fashion.

2.
On efficiency: some architectures (e.g., ARM Architecture 5 and above)
support arithmetic with saturation in the instruction set, so the if the
functions are inlined, there may me no performance penalty.

For those specific applications a trivial macro set is all you need for
portable development. It's a very niche subset of problems though.

3.
The reality of this world is that application domain experts (also) get
to write (embedded) production code. Those types naturally think of a +
as of a mathematical operation, not as a signedness-and-length-dependent
gobbledygook C made of it. For them, this library is indispensable.

Yeah, see I disagree. The C standard may be confusing as **** w.r.t.
data types but the platforms are not.

unsigned long a, b, c;
a = b + c;

On ANY platform you touch that's guaranteed to perform at least a
32-bit addition. Even though an unsigned long may be 47 bits, have 9
trap bits and 6 padding bits, the operation is still guaranteed to have
a numerical accuracy across different platforms and at least 32 bits of
precision amongst them.

[etc, etc].

Learning when to mask things off with an AND and how to load/store data
in a portable fashion should be Intro to C 101 material.

Tom

 

[Tom St Denis]

All the problem he has disappear with a C compiler that supports
operator overloading.

If you wanted operator overloading use fucking C++. My god is it that
hard? Why would you choose a language that doesn't have what you want
over one that does? Oh right, because you're a MORON [or joe-jobbing]

Note that the pentiums (Intel architecture) support arithmetic with
saturation too, and they have a huge piece of the market.

You won't make a lot of friends using them though, unless you use check
the cpu revision first.

Tom

 

[CBFalconer]

.... snip ...

This is very interesting thing. It gives the layout of a "secure"
form of performing the basic operations. It could be easily and
much more efficientely implemented with compiler support, what I
will try to implement in the next future.

I have already implemented within the framework of lcc-win32 an
overflow exception detection with compiler support, and this could
be an extension to that.

The C standard permits you to trap all integer overflows. You may
not trap any unsigned overflows. Since your systems operate solely
on the x86, implementation of overflow protection is extremely
simple. Arm the appropriate interrupt vector (I think it may be 0)
on startup, and follow each actual arithmetic operation with the
'into' instruction. This will only act if the overflow flag is
set.

You can enable/disable all this action simply by controlling that
interrupt vector. It it points to a 'reti' instruction all will be
ignored. This won't detect overflows within casts, etc.

Implementing this would be a service to the community. It requires
no source changes. Of course you have to be sure that other
non-standard extensions are not fouling up the system, which may be
a problem for you.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[CBFalconer]

.... snip ...

What about the cases where you WANT overflows to happen [or more
importantly don't care if they do]? e.g. emulating a cyclic rotation.

There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[jacob navia]

... snip ...



The C standard permits you to trap all integer overflows. You may
not trap any unsigned overflows. Since your systems operate solely
on the x86, implementation of overflow protection is extremely
simple. Arm the appropriate interrupt vector (I think it may be 0)
on startup, and follow each actual arithmetic operation with the
'into' instruction. This will only act if the overflow flag is
set.

You can enable/disable all this action simply by controlling that
interrupt vector. It it points to a 'reti' instruction all will be
ignored. This won't detect overflows within casts, etc.

Implementing this would be a service to the community. It requires
no source changes. Of course you have to be sure that other
non-standard extensions are not fouling up the system, which may be
a problem for you.

I just test the overflow flag after every operation that could make an
overflow. Unsigned numbers are not tested.

What was missing was what to do if an overflow is found since it is
not specified. With this secure library implementations I will just
call the current exception handler with an overflow message.

 

[Tom St Denis]

There is no such thing. Once an integer overflow occurs the action
is undefined, and the program is invalid. Just because most
systems do ignore them and perform a 2's complement peculiar action
is no excuse.

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

Tom

 

[Tom St Denis]

You mean

unsigned x = 1UL << 31;

I meant unsigned long

Tom

 

[Clark S. Cox III]

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

No, simply put, that isn't integer overflow.

 

[jacob navia]

No, simply put, that isn't integer overflow.

That is obvious. Besides, nobody is speaking about
overflow for unsigned numbers. Only signed overflow
is undefined behavior according to the standard.

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

jacob

 

[Keith Thompson]

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

jacob, will you *please* stop making up this utter crap about people's
motivations?

Nobody other than you has said anything about "the end of the earth as
we know it", or anything similar.

Most of us here are not implementers. As such we have little or no
ability to control what language features are available to us. We
work with compilers that conform to the C standard as it actually
exists (usually C90 with some extensions, sometimes most of C99,
rarely all of C99). This newsgroup is a place for us to discuss
programming in the C language as it is defined by the standard(s) in
the real world.

If you want to discuss techniques for writing safer code *in standard
C*, this is the right place.

If you want to advocate changes to the standard, or extensions outside
the standard, take it somewhere else. (I've told you many times that
comp.std.c is the most appropriate newsgroup for advocating changes to
the standard; if you don't get a favorable reception there, that
doesn't make your ideas topical here.) And you've practically got
your own newsgroup, after all.

And if you want to accuse either the standards committee or C
programmers in general of not caring about safety, or of wanting to
destroy the C language or keep it stagnant, or whatever paranoid
fantasy you've come up with, please do us all a favor and keep it to
yourself.

 

[CBFalconer]

You mean

unsigned x = 1UL << 31;

x = x + x;

That's going to cause the end of the earth as we know it?

Damn. Ok. Good to know.

That's not an integer overflow, that's an unsigned overflow, and
the action is specified by the standard. Change unsigned to int
(assuming 32 bit ints) and yes, then you have an integer overflow
and UB.

 

[Mark McIntyre]

Nobody other than you has said anything about "the end of the earth as
we know it", or anything similar.

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

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

 

[Mark McIntyre]

All the problem he has disappear with a C compiler that supports
operator overloading.

If I wanted a truck, I'd drive a truck. I don't transport cows in my
sportscar. Similarly if I wanted C++ I'd use it.
--
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

 

[Clark S. Cox III]

That is obvious. Besides, nobody is speaking about
overflow for unsigned numbers. Only signed overflow
is undefined behavior according to the standard.

Actually, this is exactly what Mr. St Denis was talking about. I was
simply pointing out that his example was unrelated to the actual
discussion taking place in the thread.

But any improvement of C in the "more safety"
direction is too much for certain people apparently.

Any "argument" counts:

"... the end of the earth as we know it"

As if anybody caring to ensure the correctness of the software
was half mad or not a "C" programmer.

Ensuring correctness is not worth it if it makes my already correct
programs slower.

Ensuring correctness is not worth it if it makes my legacy code
uncompilable.

I don't remember anyone claiming that "more safety" would cause "the end
of the Earth as we know it."