5 ms·

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a p

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

hot_gril 4y ago
At least it's not SHA-2, which is probably more widely used. Or am I mixing them up?
- turminal 4y ago
  You are correct, SHA-2 is much more prevalent.
manholio 4y ago
Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.
- adev_ 4y ago
  > Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc38364248975e08e340a https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span<> and that prevents this kind of out-of-bound access and the party-time that comes with it.
  - saagarjha 4y ago
    C++ offers safer constructs but they have their own sharp edges and you have to actually use them to get their benefits. In security critical software these can still be enough to cause significant problems.
  - boardwaalk 4y ago
    Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behavior is undefined if idx is out of range" or similar. For example: https://en.cppreference.com/w/cpp/container/span/operator_at https://en.cppreference.com/w/cpp/container/span/operator_at
    - adev_ 4y ago
      > Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behaviour is undefined if idx is out of range" or similar. It is regrettable and under fix but: - You generally do have your own implementation with more advance bound check for safety-critical implementation. - We do have our own where I work right now. - Google has its own in abseil. - span allows the usage for range-for loop which combined with subspan() makes possible to avoid pointer arithmetic all together.
      - manholio 4y ago
        When you are already in a deep hole, it's a good idea to stop digging. How much time did it took you to understand all this? What chances does a beginner has to understand these subtle differences and learn the particular way your codebase uses std::span and not footgun themselves? How much productivity is lost to the sheer terror of such footguns - not actual bugs, but time and effort lost that did not move the product forward? And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible?
        adev_ 4y ago
        > And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible? Because the world is a place where billions of lines of code have been written. And these will never be rewritten, but can be modernized. That the reality, and that's why your web browser right now and most of your OS is still written in unsafe language right now. And will still be for the next 15years at least.
  - eterevsky 4y ago
    Code like that in C++ would probably be over-optimized and would skip boundary checks, exposing it to the same problem.
  - tialaramex 4y ago
    WG21 (the C++ Standards Committee) feels that since idiomatic C++ was unsafe (e.g. array operations don't have bounds checks) it is consistent for new C++ features to also be unsafe by default, even if the whole point of those features in other languages is to provide an idiomatic safe way to do things. So for example in Rust you have a native slice type reflecting a dynamically sized view into a contiguous sequence, and of course it's safe -- five[20] will either refuse to compile if the compiler can see this slice is too short, or it will panic at runtime. In C++ as others have mentioned actually std::span just isn't safe when used ergonomically. five[20] in C++ is Undefined Behaviour. std::optional has a safe interface for a Maybe / Option type, but is presented with a more ergonomic unsafe behaviour and that's what people use. This is not an old-fashioned thing the C++ Committee grew out of, std::expected is in C++ 23, that's a Result type and it likewise offers an ergonomic unsafe API. The safe APIs were seen as a nice-to-have which could miss the train because who needs safety anyway? Just don't make any mistakes.
    - pjmlp 4y ago
      Tragically, what I would call idiomatic C++ with compiler provided frameworks pre-ISO C++98, made use of bounds checking in their collection classes, and then the C++ Committee went completly to the other way. Naturally we have now ways to enable them on all major compilers, but many still don't. This is one point I kind of agree with you.
      - tialaramex 4y ago
        The crucial trick in Rust is not that the index operations are bounds checked, that's easy, as you observed plenty of C++ toolchains can do that. The crucial trick is providing the unchecked operations (with improved performance) as unergonomic alternatives. *(five.get_unchecked_mut(20)) = k; // looks horrible. Nobody wants to write that, so when they don't need it they won't write it. The fact calling get_unchecked_mut requires unsafe is part of how Rust could achieve its goals, but the choice to not make this ergonomic is why it actually delivers in practice. What CppFront wants here, and P2687 proposes, and lots of other C++ work has suggested, is roughly: [[suppress(bounds_check)]] { five[20] = k; } Thus imitating what they think Rust does here, rather than what it actually did, and in the process completely missing the point.
  - pjmlp 4y ago
    As much as I like C++, std::span<> would only have helped if the build was built with bounds checking turned on. ISO on their wisdom has turned the safety defaults around in regards to classical C++ frameworks. So C++ secure code, either has to make use of Microsoft's gsl::span<>, or again turn on bounds checking in release builds, you cannot trust everyone to call .at().
- hot_gril 4y ago
  What's to replace C, Rust?
deleted 4y ago
[deleted]

hot_gril 4y ago

At least it's not SHA-2, which is probably more widely used. Or am I mixing them up?

turminal 4y ago
You are correct, SHA-2 is much more prevalent.

manholio 4y ago

Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.

adev_ 4y ago
> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc38364248975e08e340a https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span<> and that prevents this kind of out-of-bound access and the party-time that comes with it.
- saagarjha 4y ago
  C++ offers safer constructs but they have their own sharp edges and you have to actually use them to get their benefits. In security critical software these can still be enough to cause significant problems.
- boardwaalk 4y ago
  Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behavior is undefined if idx is out of range" or similar. For example: https://en.cppreference.com/w/cpp/container/span/operator_at https://en.cppreference.com/w/cpp/container/span/operator_at
  - adev_ 4y ago
    > Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behaviour is undefined if idx is out of range" or similar. It is regrettable and under fix but: - You generally do have your own implementation with more advance bound check for safety-critical implementation. - We do have our own where I work right now. - Google has its own in abseil. - span allows the usage for range-for loop which combined with subspan() makes possible to avoid pointer arithmetic all together.
    - manholio 4y ago
      When you are already in a deep hole, it's a good idea to stop digging. How much time did it took you to understand all this? What chances does a beginner has to understand these subtle differences and learn the particular way your codebase uses std::span and not footgun themselves? How much productivity is lost to the sheer terror of such footguns - not actual bugs, but time and effort lost that did not move the product forward? And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible?
      - adev_ 4y ago
        > And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible? Because the world is a place where billions of lines of code have been written. And these will never be rewritten, but can be modernized. That the reality, and that's why your web browser right now and most of your OS is still written in unsafe language right now. And will still be for the next 15years at least.
- eterevsky 4y ago
  Code like that in C++ would probably be over-optimized and would skip boundary checks, exposing it to the same problem.
- tialaramex 4y ago
  WG21 (the C++ Standards Committee) feels that since idiomatic C++ was unsafe (e.g. array operations don't have bounds checks) it is consistent for new C++ features to also be unsafe by default, even if the whole point of those features in other languages is to provide an idiomatic safe way to do things. So for example in Rust you have a native slice type reflecting a dynamically sized view into a contiguous sequence, and of course it's safe -- five[20] will either refuse to compile if the compiler can see this slice is too short, or it will panic at runtime. In C++ as others have mentioned actually std::span just isn't safe when used ergonomically. five[20] in C++ is Undefined Behaviour. std::optional has a safe interface for a Maybe / Option type, but is presented with a more ergonomic unsafe behaviour and that's what people use. This is not an old-fashioned thing the C++ Committee grew out of, std::expected is in C++ 23, that's a Result type and it likewise offers an ergonomic unsafe API. The safe APIs were seen as a nice-to-have which could miss the train because who needs safety anyway? Just don't make any mistakes.
  - pjmlp 4y ago
    Tragically, what I would call idiomatic C++ with compiler provided frameworks pre-ISO C++98, made use of bounds checking in their collection classes, and then the C++ Committee went completly to the other way. Naturally we have now ways to enable them on all major compilers, but many still don't. This is one point I kind of agree with you.
    - tialaramex 4y ago
      The crucial trick in Rust is not that the index operations are bounds checked, that's easy, as you observed plenty of C++ toolchains can do that. The crucial trick is providing the unchecked operations (with improved performance) as unergonomic alternatives. *(five.get_unchecked_mut(20)) = k; // looks horrible. Nobody wants to write that, so when they don't need it they won't write it. The fact calling get_unchecked_mut requires unsafe is part of how Rust could achieve its goals, but the choice to not make this ergonomic is why it actually delivers in practice. What CppFront wants here, and P2687 proposes, and lots of other C++ work has suggested, is roughly: [[suppress(bounds_check)]] { five[20] = k; } Thus imitating what they think Rust does here, rather than what it actually did, and in the process completely missing the point.
- pjmlp 4y ago
  As much as I like C++, std::span<> would only have helped if the build was built with bounds checking turned on. ISO on their wisdom has turned the safety defaults around in regards to classical C++ frameworks. So C++ secure code, either has to make use of Microsoft's gsl::span<>, or again turn on bounds checking in release builds, you cannot trust everyone to call .at().
hot_gril 4y ago
What's to replace C, Rust?

deleted 4y ago

[deleted]