3 ms·

Take a look at bstring[0] and you'll see how to circumvent C's null-terminated string in a clean and light way. [0] http://bstring.sourceforge.net/ http://bstr

by lugus35 11y ago

Take a look at bstring[0] and you'll see how to circumvent C's null-terminated string in a clean and light way. [0] http://bstring.sourceforge.net/ http://bstring.sourceforge.net/

anon1385 11y ago
bstring relies on undefined behaviour for security. Do not use it. >Bstrlib is, by design, impervious to memory size overflow attacks. The reason is it is resiliant to length overflows is that bstring lengths are bounded above by INT_MAX, instead of ~(size_t)0. So length addition overflows cause a wrap around of the integer value making them negative causing balloc() to fail before an erroneous operation can occurr. Attempted conversions of char * strings which may have lengths greater than INT_MAX are detected and the conversion is aborted. >It is unknown if this property holds on machines that don't represent integers as 2s complement. It is recommended that Bstrlib be carefully auditted by anyone using a system which is not 2s complement based.
- tomjakubowski 11y ago
  What might go wrong if you only deploy to architectures with the necessary signed integer representation and compile with -fno-strict-overflow? (not that I can imagine an optimization which would make this particular use of overflow go wrong)
- fhars 11y ago
  It is not only unknown if this holds on machines that don't use 2s complement, it is quite likely that this doesn't even hold on machines that do use 2s complement, but have an optimizing compiler. In many cases, the overflow checks contains terms like (b->slen+1) < 0 which an optimizing compiler could compile as b->slen < -1 effectively switching the overflow test off (as there is no non-overflowing execution where this code will produce other behaviour than the original code, and behaviour on overflow is undefined, so the compiler can safely get rid of the addition).
  - fhars 11y ago
    I just had to check what happens using a real compiler using realistic compiler options (gcc-4.9.2 -O2): https://github.com/websnarf/bstrlib/issues/8 https://github.com/websnarf/bstrlib/issues/8
    - anon1385 11y ago
      Thanks for doing that. It's much more productive than just moaning on HN like I did.

by lugus35 11y ago

Take a look at bstring[0] and you'll see how to circumvent C's null-terminated string in a clean and light way. [0] http://bstring.sourceforge.net/ http://bstring.sourceforge.net/

anon1385 11y ago

bstring relies on undefined behaviour for security. Do not use it. >Bstrlib is, by design, impervious to memory size overflow attacks. The reason is it is resiliant to length overflows is that bstring lengths are bounded above by INT_MAX, instead of ~(size_t)0. So length addition overflows cause a wrap around of the integer value making them negative causing balloc() to fail before an erroneous operation can occurr. Attempted conversions of char * strings which may have lengths greater than INT_MAX are detected and the conversion is aborted. >It is unknown if this property holds on machines that don't represent integers as 2s complement. It is recommended that Bstrlib be carefully auditted by anyone using a system which is not 2s complement based.

tomjakubowski 11y ago
What might go wrong if you only deploy to architectures with the necessary signed integer representation and compile with -fno-strict-overflow? (not that I can imagine an optimization which would make this particular use of overflow go wrong)
fhars 11y ago
It is not only unknown if this holds on machines that don't use 2s complement, it is quite likely that this doesn't even hold on machines that do use 2s complement, but have an optimizing compiler. In many cases, the overflow checks contains terms like (b->slen+1) < 0 which an optimizing compiler could compile as b->slen < -1 effectively switching the overflow test off (as there is no non-overflowing execution where this code will produce other behaviour than the original code, and behaviour on overflow is undefined, so the compiler can safely get rid of the addition).
- fhars 11y ago
  I just had to check what happens using a real compiler using realistic compiler options (gcc-4.9.2 -O2): https://github.com/websnarf/bstrlib/issues/8 https://github.com/websnarf/bstrlib/issues/8
  - anon1385 11y ago
    Thanks for doing that. It's much more productive than just moaning on HN like I did.