Potential vulnerability in programs recompiled for 64-bit platforms

[econometrics@…]

Default block size for the dynamic_bitset<> class on a 32bit platform is 4 bytes, while on a 64bit one it is actually 8 bytes. Therefore, objects of dynamic_bitset<> will have different m_bits array lengths on 32- and 64-bit platforms. It is very likely to cause an overflow on the 64-bit platform.

Conclusion: any program using dynamic_bitset<>::m_bits and recompiled from 32- to 64-bit is vulnerable.

[Steven Watanabe]

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]

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

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

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]

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?

[Ulrich Eckhardt <ulrich.eckhardt@…>]

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.

[acharles]

This isn't an issue.