SafeInt

Reopened Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Fri, 14 Jun 2013 06:46:58 GMT

i try to use multiply on int64_t

boost::int64_t a=2;
boost::int64_t b=3;
boost::int64_t c;
SafeMultiply<boost::int64_t,boost::int64_t>(a,b,c);

gcc 4.3.2 and 4.4.1 takes compile time error

SafeInt3.hpp: In function ‘bool SafeMultiply(T, U, T&) [with T = long int, U = long int]’:
test1.cpp:233: instantiated from here
SafeInt3.hpp:4995: error: incomplete type ‘MultiplicationHelper<long int, long int, 11>’ used in nested name specifier

Closed Issue: bug gcc 4.3.2 and 4.4.1 int64_t [8791]

dcleblanc — Thu, 16 May 2013 08:03:30 GMT

Updated Release: SafeInt 3.0.17 (Sep 23, 2011)

dcleblanc — Tue, 18 Dec 2012 22:48:48 GMT

See home page for extended comments on differences between 3.0.17 and 3.0.16. This release passes all the internal verification tests, but has not yet been validated against all of the compilers we support. It does address the issues reported by John Regehr as of today. Once it has been verified against all of the compilers, and has been verified not to emit more warnings, we'll move it to stable.

Very minor update from last night - added LL and ULL 3 places to remove a few warnings.

12/18/12 - Updated to normalize whitespace. No functional changes.

Released: SafeInt 3.0.17 (Sep 23, 2011)

Tue, 18 Dec 2012 22:48:48 GMT

Source code checked in, #96133

Project Collection Service Accounts — Mon, 01 Oct 2012 21:40:31 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #96132

Project Collection Service Accounts — Mon, 01 Oct 2012 21:33:03 GMT

Checked in by server upgrade

Created Issue: nullptr and /CLR [15237]

KeithBurton — Thu, 31 May 2012 06:58:46 GMT

Using Visual Studio 2008 , it is not possible to include the header in mixed CLR and native code because of the definition of nullptr clashes with CLR usage.

Given there is only one use of nullptr in SafeInt3.hpp , defining nullptr seems to be a lot of trouble for dubious benefit.

Reviewed: SafeInt 3.0.17 (Sep 28, 2011)

noloader — Thu, 29 Sep 2011 03:36:56 GMT

Rated 5 Stars (out of 5) - Great job on the latest SafeInt

New Post: SafeInt at Boost?

noloader — Sun, 25 Sep 2011 21:57:01 GMT

Timothy003 wrote:

Boost has really smart people in its community, and sets ultra-high standards. Libraries are peer-reviewed too, so you'd get a lot of good feedback on your code. For example, I grabbed the latest SafeInt3.hpp, opened it up, and immediately saw this:
#if !defined NULL
#define NULL ((void*)0)
#endif
// These two may not be defined, either
#if !defined uintptr_t
#define uintptr_t size_t
#endif

#if !defined intptr_t
#define intptr_t ptrdiff_t
#endif
// Might need this for gcc and older Microsoft compilers
#if !defined nullptr
#define nullptr NULL
#endif
Code like that is evil. The folks at Boost would surely let you know about it, and you'll learn modern C++ programming paradigms, improving the quality of your code.

# Boost has really smart people in its community, and sets ultra-high standards.
I'm not sure about the ultra high standards.

# Libraries are peer-reviewed too, so you'd get a lot of good feedback on your code
That Boost will accept anything and hope that someone will [eventually] spot an error is a detriment, not a feature. For example, it appears Boost accepted threads and rolled them out without rigorous review or acceptance testing. Distributions generally don't backport bug fixes, so downlevel users are stuck with defective code.

On my cursory review, Boost::Threads did not meet production quality (I filed about 15 bugs against it). For example, ignoring return values from WaitForSingleObject and pthread_mutex_lock was egregious. Its something I would expect from a self-taught K&R coder. I don't think a CompSci freshman would make the same mistakes. And I don't want code like that in my code base.

It also appears Boost does not audit the bug database. To date, none of the bugs have even been acknowledged.

# Code like that is evil.
Have a look at Boost::Test and its use of macros sometime...

New Post: SafeInt at Boost?

noloader — Sun, 25 Sep 2011 20:33:23 GMT

Timothy003 wrote:

noloader wrote:

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

Are you implying that dcleblanc's code is safer and more correct? Other than relying on undefined behavior with the type punning, there's already a bug in it; it doesn't validate the packet's size. With vector, iterator debugging will give you a better chance of catching incorrect code.

The two examples don't do the same things, anyway.

# Are you implying that dcleblanc's code is safer and more correct?
Yes, I believe LeBlanc's SafeInt code is safer in general.

If the time ever comes, I believe ignoring wrap and overflow will be grossly negligent. The industry enjoys software patents, it should also enjoy liability.

# Other than relying on undefined behavior with the type punning...
My bad, I was commenting in general, not in the particular examples.

For what its worth, the Visual Studio compiler is more tolerant of punning. I think VS just does the right thing and gets the alignments right (with no warning).

# With vector, iterator debugging will give you a better chance of catching incorrect code.
I love debug builds and asserts (I'm a student of John Robbins), but this is a problem in practice. To convince yourself, install libboost via apt-get or yum and define _GLIBCXX_DEBUG (http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html). I recently [incorreclty] filed a report against Boost::Regex (it was an ABI problem).

I know I could have built the source from scratch. But Boost has broken the tried and true configure/make/install in favor of something else buried in a spaghetti of documentation. I could be wrong, but I had no joy in building on Solaris (a Boost bug report was filed, no acknowledgement to date).

Jeff

New Post: SafeInt at Boost?

Timothy003 — Sat, 24 Sep 2011 20:44:51 GMT

noloader wrote:

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

Are you implying that dcleblanc's code is safer and more correct? Other than relying on undefined behavior with the type punning, there's already a bug in it; it doesn't validate the packet's size. With vector, iterator debugging will give you a better chance of catching incorrect code.

The two examples don't do the same things, anyway.

New Post: SafeInt at Boost?

noloader — Sat, 24 Sep 2011 20:28:56 GMT

Timothy003 wrote:

.... In most cases, the overhead will be negligible. Without solid profiling, I can't justify the security tradeoff. But if you have proof that the vector has too much overhead, then of course you shouldn't use it. Otherwise, it would be premature optimization.

Seriously? A program has to be correct before anything else.

Out of curiosity, how can you be certain the attacker does not control the input?

Updated Release: SafeInt 3.0.17 (Sep 23, 2011)

dcleblanc — Fri, 23 Sep 2011 17:25:15 GMT

Released: SafeInt 3.0.17 (Sep 23, 2011)

Fri, 23 Sep 2011 17:25:15 GMT

Updated Release: SafeInt 3.0.17 (Sep 23, 2011)

dcleblanc — Fri, 23 Sep 2011 14:33:25 GMT

Released: SafeInt 3.0.17 (Sep 23, 2011)

Fri, 23 Sep 2011 14:33:25 GMT

Commented Issue: integer overflows [14278]

dcleblanc — Fri, 23 Sep 2011 07:14:27 GMT

I've been tracking down some integer overflows in Firefox and seem to have narrowed some of them down to the SafeInt library.

As an example, the "a = -a;" assignment at SafeInt3.hpp:2102 is sometimes invoked while a has value INT_MIN. Of course, negating INT_MIN is undefined behavior in C++98 and C++11.

To reproduce, change the code like this:

if( a < 0 )
{
if (a==INT_MIN) printf ("oops!\n");
a = -a;
fIsNegative = true;
}

Then run MultVerify(). Here is what I get:

[regehr@gamow safeint]$ g++ -O -w TestMain.cpp MultVerify.cpp -o TestMain
[regehr@gamow safeint]$ ./TestMain
oops!
oops!
oops!
oops!
oops!
oops!

This is 3.0.16p. There are some other overflows in SafeInt, please let me know if you are interested in bug reports about them.
Comments: ** Comment from web user: dcleblanc **

This issue should be addressed by the 3.0.17 release. Note to consumers - 3.0.17 is still considered a beta. It is strongly recommended that if you are using a compiler which aggressively optimizes that you also enable (and pay attention to) the warnings that it is removing code.

Created Release: SafeInt 3.0.17 (Sep 23, 2011)

dcleblanc — Fri, 23 Sep 2011 07:12:09 GMT

Released: SafeInt 3.0.17 (Sep 23, 2011)

Fri, 23 Sep 2011 07:12:09 GMT

Updated Wiki: Home

dcleblanc — Fri, 23 Sep 2011 07:08:16 GMT

SafeInt is a C++ header containing the SafeInt class, non-throwing functions to check common operations, and the associated internal mechanisms.

SafeInt is currently used extensively throughout Microsoft, with substantial adoption within Office and Windows. If you are compiling for the Microsoft compiler only, a very similar version is now available with Visual Studio 2010.

It can be used with any compiler that has good template support, and is known to work on Visual Studio 7.1 or later.

Thanks to help from Jeffrey Walton of the OWASP project, we now have a very complete runtime test harness. There's still a couple of files to get posted, but the files we have on the download section contain most of the new work. To avoid confusion, the test harness is now a different release than the main header.

Also thanks to Jeffrey, we have extended the list of compilers that are supported to:

Microsoft Visual Studio, version 7.1 through the latest.
Reasonably new versions of gcc, including the latest version that will compile for Apple platforms.
The Intel compiler, with some caveats - it doesn't support some of the friend overloads, but does work properly with the runtime checks.
Clang is also now supported.

The most recent version is 3.0.17. The main change between minor versions 15 and 16 is that the Intel compiler will quite vigorously optimize away some of the signed addition overflow checks. Changes have been made such that intermediate calculations are done with unsigned numbers, and unsigned overflow is defined by the standard, which means the Intel compiler won't optimize them away. There have been instances of the gcc compiler doing the same thing, but this hasn't been demonstrated in SafeInt. As of this version, there won't be a possibility of the compiler actually removing checks.

Thanks to John Regehr of the University of Utah for noticing that the compiler may also become aggressive about removing things when you attempt to perform a unary negation on a signed number, and that signed number is a compile-time constant with a value of MIN_INT. I personally have a low opinion of compilers doing this sort of thing - seems like there's an awful lot of code out there with some extremely subtle bugs when compiled with these compilers. Compiler warnings are your friend, and it seems like the more compilers you have, the better your coverage. As it turns out, Clang will warn about when this might happen, which enabled a more comprehensive scrub of the code than we were able to do in 3.0.16.

The fix for this particular issue is to go ahead and code in a dependency on 2's complement representation of negative numbers - the compiler may remove -x, but it won't remove ~(unsigned)x + 1, which emits the same bit pattern (and the same assembly code).

Important note - the runtime test harness does catch it when the compiler optimizes away tests. You should compile and run the runtime checks to verify that everything is working properly with your compiler. Note - as of 3.0.17, we have some work to do to update the runtime tests to account for compile-time constants. We'll get this updated as soon as practical.

In addition, SafeInt now compiles warning-free with all warnings enabled on both latest gcc and the Microsoft compiler. It will still emit a few warnings with the Intel compiler.

Known outstanding work - I have yet to do the work to correctly annotate the class with throw() in the case of an error handler that does something other than C++ exceptions (structured exceptions, terminate the app, etc).