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 "Specificat ion 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]

Re: secure integer library

Non-Windows version?

Robert Seacord wrote:

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 "Specificat ion 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

[jacob navia]

Re: secure integer library

Robert Seacord wrote:

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 "Specificat ion 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]

Re: secure integer library


Robert Seacord wrote:

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]

Re: secure integer library

Tom St Denis wrote:

Robert Seacord wrote:

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

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

Re: secure integer library

Ark wrote:

Tom St Denis wrote:
>

>Robert Seacord wrote:
>>

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

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

Re: secure integer library

Ark wrote:

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

Re: secure integer library

jacob navia wrote:

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]

Re: secure integer library

jacob navia wrote:

Robert Seacord wrote:
>

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

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

Re: secure integer library

Tom St Denis wrote:

>

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

Re: secure integer library

CBFalconer wrote:

jacob navia wrote:
>

>>Robert Seacord wrote:
>>
>>

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

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

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]

Re: secure integer library

CBFalconer wrote:

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]

Re: secure integer library

Tom St Denis wrote:

You mean
>
unsigned x = 1UL << 31;

I meant unsigned long

Tom

[Clark S. Cox III]

Re: secure integer library

Tom St Denis wrote:

CBFalconer wrote:

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

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


--
Clark S. Cox III
clarkcox3@gmail .com

[jacob navia]

Re: secure integer library

Clark S. Cox III wrote:

Tom St Denis wrote:
>

>>CBFalconer wrote:
>>

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

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