4 ms·

> It does not have a CVE associated since the issue was spotted within Rust stdlib first. I don't see why this is true. Are you saying that people with affecte

> It does not have a CVE associated since the issue was spotted within Rust stdlib first. I don't see why this is true. Are you saying that people with affected code would have seen a Rust CVE and then updated their C++ toolchains? There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety. The lack of CVE associated with the fixes you pointed out support the original assertion rather than refuting it. In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ (https://en.cppreference.com/w/cpp/filesystem https://en.cppreference.com/w/cpp/filesystem). Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature.

adev_ 3y ago
> There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety A security report has been filed for both compiler and actions taken for both of the major toolchain. This is a sign of mature security processes in used by both of the major C++ compiler implementations. CVE are one among many way to address security vulnerabilities, one way that is currently heavily under criticism [^1] > In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ The vulnerability reported (even in case of the Rust CVE) has nothing to do with a concurrent usage of the API. I think you do not really know what you are talking about here. > Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature. My definition of immature includes the fact of throwing false statement over the internet, getting them refuted with sources and quote included. And still stance on them. This is a sign of immaturity. [^1]: https://portswigger.net/daily-swig/cvss-system-criticized-for-failure-to-address-real-world-impact https://portswigger.net/daily-swig/cvss-system-criticized-fo...
- CJefferson 3y ago
  The issue entirely hits that undefined behaviour. The problem is a race condition in symlinks -- a race condition implies a change, which is concurrent access, and the C++ standard clearly states any change to the filesystem by another program leads to undefined behaviour. Sure, the "concurrent access" is another program, but the standard says another program changing an object you are accessing leads to undefined behaviour -- which does make, writing basically any C++ program that does filesystem access on a modern OS with other programs running completely impossible according to the letter of the standard, so I'm really not sure why it's written in that way.
  - adev_ 3y ago
    The answer to that is there: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4003.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40... It is mainly wording around specifying that the result of a concurrent access can not be guaranteed. Which here Rust is no different, it just does not have a specification for his stdlib (yet)
    - CJefferson 3y ago
      I disagree, while rust doesn't have a formal specification, they would consider any crashes in safe code caused by parallel filesystem access to be unacceptable, while for years the C++ committee has been happy to say "You fool, you invoked undefined behaviour. Game over". I don't see any evidence from looking at the standard this bit of undefined behaviour is somehow "less undefined" than any other bit of undefined behaviour.
  - kllrnohj 3y ago
    No it isn't, it's just a bug and it was fixed, just like it was for Rust. Nobody hid behind UB for this and the time from reporting the issue to fixing it was about 2 weeks for both libcxx and libc++ https://bugs.chromium.org/p/llvm/issues/detail?id=19 https://bugs.chromium.org/p/llvm/issues/detail?id=19 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 Absolutely zero mention or attempted defense of "hurr durr but UB says we can do this!!!"
PH95VuimJjqBqy 3y ago
how would you define concurrent access to a filesystem? That's a serious question, if I open a file for reading and another process writes to it, exactly how is the C++ standards supposed to protect against that?

adev_ 3y ago

> There seems to be no reason this shouldn't have been a C++ CVE other than the fact that C++ community has different standards for what constitutes safety A security report has been filed for both compiler and actions taken for both of the major toolchain. This is a sign of mature security processes in used by both of the major C++ compiler implementations. CVE are one among many way to address security vulnerabilities, one way that is currently heavily under criticism [^1] > In fact, I'll tell you why there was no CVE for C++ - concurrent access to filesystem APIs is undefined behaviour in C++ The vulnerability reported (even in case of the Rust CVE) has nothing to do with a concurrent usage of the API. I think you do not really know what you are talking about here. > Reasonable people can disagree on this though, so I can see where you're coming from. There's no reason to immediately fling around accusations of lying and zealotry. It makes the writer look immature. My definition of immature includes the fact of throwing false statement over the internet, getting them refuted with sources and quote included. And still stance on them. This is a sign of immaturity. [^1]: https://portswigger.net/daily-swig/cvss-system-criticized-for-failure-to-address-real-world-impact https://portswigger.net/daily-swig/cvss-system-criticized-fo...

CJefferson 3y ago
The issue entirely hits that undefined behaviour. The problem is a race condition in symlinks -- a race condition implies a change, which is concurrent access, and the C++ standard clearly states any change to the filesystem by another program leads to undefined behaviour. Sure, the "concurrent access" is another program, but the standard says another program changing an object you are accessing leads to undefined behaviour -- which does make, writing basically any C++ program that does filesystem access on a modern OS with other programs running completely impossible according to the letter of the standard, so I'm really not sure why it's written in that way.
- adev_ 3y ago
  The answer to that is there: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4003.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n40... It is mainly wording around specifying that the result of a concurrent access can not be guaranteed. Which here Rust is no different, it just does not have a specification for his stdlib (yet)
  - CJefferson 3y ago
    I disagree, while rust doesn't have a formal specification, they would consider any crashes in safe code caused by parallel filesystem access to be unacceptable, while for years the C++ committee has been happy to say "You fool, you invoked undefined behaviour. Game over". I don't see any evidence from looking at the standard this bit of undefined behaviour is somehow "less undefined" than any other bit of undefined behaviour.
- kllrnohj 3y ago
  No it isn't, it's just a bug and it was fixed, just like it was for Rust. Nobody hid behind UB for this and the time from reporting the issue to fixing it was about 2 weeks for both libcxx and libc++ https://bugs.chromium.org/p/llvm/issues/detail?id=19 https://bugs.chromium.org/p/llvm/issues/detail?id=19 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 Absolutely zero mention or attempted defense of "hurr durr but UB says we can do this!!!"

PH95VuimJjqBqy 3y ago

how would you define concurrent access to a filesystem? That's a serious question, if I open a file for reading and another process writes to it, exactly how is the C++ standards supposed to protect against that?