Boost C++ Libraries: Ticket #6528: Potential vulnerability in programs recompiled for 64-bit platforms

Steven Watanabe — Tue, 07 Feb 2012 02:06:47 GMT

I don't understand. The maximum size of a dynamic_bitset is larger on a 64-bit platform. How can it overflow if it works in 32-bit? In any event, the size it has to get to before it can overflow is ridiculously large. Unless you have an example that demonstrates the problem, I'm going to close this.

anonymous — Tue, 07 Feb 2012 08:45:48 GMT

I mean if you have written a code on 32-bit and are working directly with m_bits, with the default dynamic_bitset<> you may suppose that m_bits is an array of 4byte unsigned ints. But on the 64-bit m_bits.size() is already twice lower! m_bits[index] is very likely to generate segfault in this case. That is, the same code produces different results on 32-bit and 64-bit and the 64-bit one is vulnerable.

There is nothing to do with the

maximum size of a dynamic_bitset

Wed, 08 Feb 2012 12:36:22 GMT

buffer_type m_bits is private. If BOOST_DYNAMIC_BITSET_PRIVATE is defined as public to work around compiler bugs, it should still be treated as private. Further, the block_type isn't exposed in the interface either. In summary, valid code will not not touch m_bits or its elements, so any size differences there are not a problem. Even if by some fiendish hackery you are accessing m_bits, any assumption about the size of its elements are invalid, unless they based on the use of the sizeof operator.

What exactly are you doing? What code is vulnerable to buffer overflows?

anonymous — Wed, 08 Feb 2012 13:23:21 GMT

Replying to Ulrich Eckhardt <ulrich.eckhardt@…>:

What exactly are you doing? What code is vulnerable to buffer overflows?

I have solved the problem by explicit usage of dynamic_bitset<unsigned int> instead of default dynamic_bitset<>. In this case, the code is performed equivalently on all platforms.

Anyway, if you are so confident, that it cannot generate errors in programs where BOOST_DYNAMIC_BITSET_PRIVATE is not "treated as private", you can remove the ticket.

anonymous — Wed, 08 Feb 2012 13:29:16 GMT

Replying to Ulrich Eckhardt <ulrich.eckhardt@…>:

buffer_type m_bits is private. If BOOST_DYNAMIC_BITSET_PRIVATE is defined as public to work around compiler bugs, it should still be treated as private. Further, the block_type isn't exposed in the interface either. In summary, valid code will not not touch m_bits or its elements

P.S.: I find the possibility of accessing m_bits nice. Why must it be private?

Thu, 09 Feb 2012 08:13:54 GMT

It is private exactly so that people don't mess with it and so that dynamic_bitset's class invariants are guaranteed. This is the 101 of encapsulation.

BTW: What you probably want is a look at boost/stdint.hpp, in particular uint32_t there, which is guaranteed to be 32 bits on any platform. Using unsigned int and and relying on its size being 32 bits is simply not guaranteed anywhere. You also make your code more self-commenting.

owner, status changed

acharles — Fri, 21 Feb 2014 11:19:52 GMT

owner changed from jsiek to acharles
status new → assigned

status changed; resolution set

acharles — Fri, 21 Feb 2014 11:20:11 GMT

status assigned → closed
resolution → invalid

This isn't an issue.