Safe Integer Arithmetic in C

Librerie sicure per C e C++ « Satius est supervacua scire

Librerie sicure per C e C++ « Satius est supervacua scire — Wed, 02 Apr 2008 18:57:29 GMT

PingBack from http://manuel91.wordpress.com/2008/04/02/librerie-sicure-per-c-e-c/

eschew » Blog Archive » links for 2006-11-02

eschew » Blog Archive » links for 2006-11-02 — Mon, 13 Nov 2006 16:52:11 GMT

PingBack from http://eschew.org/blog/?p=138

List of useful security libraries

HoraceWang — Thu, 16 Mar 2006 16:33:24 GMT

List of useful security libraries

Michael Howard's Web Log — Tue, 28 Feb 2006 00:23:55 GMT

I was asked last week for a list of "drop-in-and-more-secure" replacements, created at Microsoft,&nbsp;for...

re: Safe Integer Arithmetic in C

David LeBlanc — Tue, 07 Feb 2006 06:40:15 GMT

There's a few things to remember about taking this approach - the first is that conversion between integer types on entry into a function will happen without any warning, IIRC, even at warning level 4. So if you do have signed values coming in and forget to use the conversion function, you'll get unexpected results and no warning. Another aspect of this is if you don't know what casting behavior to expect - what if the input is a short? If I pass a short to a function expecting an unsigned int, serious mayhem can ensue since it will sign extend first.

The second thing is that there are some common cases where you'll get a lot better perf by writing a dedicated function. Specifically, a*b+c is a common case where if you have 32-bit inputs, you can upcast all of them to either _int64 or unsigned _int64 (depending on the sign of the inputs), and if they're all the same sign, the operations cannot overflow internally, and you can then check for overflow on the whole value instead of having many chained comparisons. For this specific case, you'd get better perf than SafeInt as well. We wrote such a function for Office and used it fairly often.

Lastly, while reviewing Office's MSO.dll for integer problems, we found a number of cases where someone changed from signed to unsigned, and created vulnerable code that wasn't previously a problem. While it is true that unsigned numbers are a LOT easier to check, if you had something along the lines of if(input < 0) return InputError();, then changed input from signed to unsigned and forgot to correctly change all the code (to something like if(input > max_size) ), then you're creating problems.

The thing to remember is that when correcting integer problems, you really have to be careful. It's a complex problem.

While I am indeed biased, I have also spent a great deal of time thinking about this problem. If you are using C++, SafeInt is much less likely to allow errors than any C constructs. As an example, I was shown an early version of IntSafe and a code snippet that 'proved' IntSafe was substantially better performing than SafeInt. It turned out that SafeInt was checking 3 operations, and IntSafe was checking one. It wasn't a fair comparison, and more importantly, SafeInt was giving the programmer a LOT more protection. If you're stuck with C, then you obviously cannot use SafeInt, and in that case, IntSafe can be a big help. Nonetheless, be aware of the trade-offs and where you'll need to be doing more work to avoid mistakes.

re: Urgent Offthread Post

Karridine — Sun, 05 Feb 2006 13:30:18 GMT

Michael, your name came up when I Googled "QuickTime blogs", and I went down-page 15 posts but couldn't find a more appropriate thread, so I share with you (and your VAST reading audience) that I've downloaded and installed the eTunes/QuickTime bundle

BUT!
Whenever I click on a QT-enabled website, it STILL tells me to upgrade to QT 4.5 or 7.5 or whatever it is! And I've RE-installed QT twice last week, for a total of 3 installations on WinXP platform, and STILL the detour when I hit a QT-webFunction...

And Yahoo's YahooSetupVideoPlayer.exe is infected with the Trojan Spy.Bombka so I cannot install it... I can't defuse it, excise the bad bits, or notify Yahoo to deal with this PROBLEM, durn it! I still can't play "Its In the Koran!"

Kernel Mustard » Blog Archive » SafeInt

Kernel Mustard » Blog Archive » SafeInt — Sat, 04 Feb 2006 23:07:26 GMT

PingBack from http://kernelmustard.com/2006/02/04/safeint/

re: Safe Integer Arithmetic in C

Alan — Fri, 03 Feb 2006 14:41:53 GMT

Wow, that sucks really amazingly!

So using the nice SafeInt class I could express the concept of safely evaluating a*b+1 by writing, well, a*b+1, but you think it would be much better to write

if (SUCCEEDED(IntToDWord(cElem,&cbElem)) &&
SUCCEEDED(DWordMult(cbBlockSize, cbElem, &cbElem)) &&
SUCCEEDED(DWordAdd(cbElem,1,&cbElem)))

I'm truly appalled. Making code that much less readable makes it harder to see what it's doing, which is going to cause bugs (both security related and non-security related).

Not to mention having to check return values on *every single arithmetic operation* instead of getting a sensible exception and handling it in one place.

What were you thinking? Are you doing this for some kind of bet or joke?

re: Safe Integer Arithmetic in C

Fri, 03 Feb 2006 09:17:18 GMT

Testing to see if these are turned on yet :)

re: Safe Integer Arithmetic in C

Selva — Fri, 03 Feb 2006 04:29:09 GMT

Hi Howard,
I have a very dumb question on the code snippet which was used to demonstrate integer overflow and underflow in the MSDN article
"Reviewing Code for Integer Manipulation Vulnerabilities"
Thanks for the article and I am really enjoying reading it.But I have one doubt:

I think I am not getting the overflow scenario correctly.
"
bool func(char *s1, size_t len1,
char *s2, size_t len2) {
if (1 + len1 + len2 > 64)
return false;

// accommodate for the trailing null in the addition
char *buf = (char*)malloc(len1+len2+1);
if (buf) {
StringCchCopy(buf,len1+len2,s1);
StringCchCat(buf,len1+len2,s2);
}

// do other stuff with buf

if (buf) free(buf);

return true;
}
"
I am continuosly failing to see a statement which could trigger a crash.
The statements which could cause a crash if the value of len2 is 0xFFFFFFFF and value of len1 is 64,are potentially:

1. StringCchCat(buf,len1+len2,s2);
2.if (buf) free(buf);

The reasoning which my silly mind tries to give me is

a.Statement 1 wont crash since len2+len2 gives 63 which is well within the buffer length we have allocated for buf.
b.Statement 2 will crash only when buffer s1 is uninitialized.
c.It is not possible to allocate 0xFFFFFFFF bytes to a buffer.

I tried different combinations but I m not able to make the code crash.

Could you please enlighten me,if possible and if you have a moment?

Thank you very much for your time.