5 ms·

> Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust,

by adev_ 3y ago

> Take for example CVE-2022-21658 (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) in Rust, related to a filesystem API. It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. That just plain wrong. Just simply wrong. And I hope it is not a lie done on purpose. The C++ community acknowledge the issue as soon as the Rust one posted the problem and issued a fix which is already deployed with major compilers [^1] [^2] It does not have a CVE associated since the issue was spotted within Rust stdlib first. This is this exact kind of FUD and zealotism that makes people hate the Rust community. I wish the community mature a bit on this aspect. [^1]: https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d8c82c2d47771ee89192b8 https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d... [^2]: https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9e24e171201db189b661700bf https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...

nindalf 3y ago
> 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?
masklinn 3y ago
> It does not have a CVE associated since the issue was spotted within Rust stdlib first. That is blatant nonsense. Even if the vulnerability is similar or identical, CVEs are submitted for every affected project. If it were not there would not have been a bounds-check CVE in the last 35 years. The only situation in which that might not be the case is if the vulnerability is in an upstream library, but even then you often get a CVE in both upstream and downstream (or a CVE shared between multiple products) e.g. the libwebp 0-day from late 2023 got a CVE for Apple’s various OS (two in fact) and a shared CVE for libwebp and chrome, mozilla used that as their upstream CVE in emitting a security advisory. The CVE-2022-21658 only covers the Rust standard library, that is not upstream of either libc++ or libstdc++, and neither fix references it anyway. The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.
- adev_ 3y ago
  > The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability. No this is also just plain wrong. It was reported to both compiler through channels dedicated to report security vulnerabilities and has been fixed as such. The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more.
  - boxed 3y ago
    > The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more. Still.. that little detail makes comparing the numbers of CVEs for Rust and C++ skewed by an enormous amount.
CJefferson 3y ago
I was pointed multiple times by people to the C++ standard, which clearly states (when introducing the filesystem library): "The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system." and was told that made this bug not a compiler issues, but just undefined behaviour, exactly as if you'd written an array out of bounds or dereferenced an invalid pointer, the compiler can do anything it likes if another program changes the filesystem while your program runs.
- adev_ 3y ago
  > The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system. There is a lot to bet that this has been added for portability reasons. The POSIX atomicity guarantees on file operations are not provided on every system. The facts are, when this issue came, it has been treated as it should have been. This is, once again, a sign of mature security processes and behaviour regarding the compiler implementers.

by adev_ 3y ago

nindalf 3y ago

> 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?

masklinn 3y ago

> It does not have a CVE associated since the issue was spotted within Rust stdlib first. That is blatant nonsense. Even if the vulnerability is similar or identical, CVEs are submitted for every affected project. If it were not there would not have been a bounds-check CVE in the last 35 years. The only situation in which that might not be the case is if the vulnerability is in an upstream library, but even then you often get a CVE in both upstream and downstream (or a CVE shared between multiple products) e.g. the libwebp 0-day from late 2023 got a CVE for Apple’s various OS (two in fact) and a shared CVE for libwebp and chrome, mozilla used that as their upstream CVE in emitting a security advisory. The CVE-2022-21658 only covers the Rust standard library, that is not upstream of either libc++ or libstdc++, and neither fix references it anyway. The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability.

adev_ 3y ago
> The GP might have gone a hair too far in saying that C++ “does not consider it a problem at all”, but they’re correct that C++ compiler/stdlib maintainers do not consider it a vulnerability. No this is also just plain wrong. It was reported to both compiler through channels dedicated to report security vulnerabilities and has been fixed as such. The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more.
- boxed 3y ago
  > The fact it did not make his way through a CVE is mainly related to how CVE naming and reservation works, nothing more. Still.. that little detail makes comparing the numbers of CVEs for Rust and C++ skewed by an enormous amount.

CJefferson 3y ago

I was pointed multiple times by people to the C++ standard, which clearly states (when introducing the filesystem library): "The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system." and was told that made this bug not a compiler issues, but just undefined behaviour, exactly as if you'd written an array out of bounds or dereferenced an invalid pointer, the compiler can do anything it likes if another program changes the filesystem while your program runs.

adev_ 3y ago
> The behavior is undefined if the calls to functions in this library introduce a file system race, that is, when multiple threads, processes, or computers interleave access and modification to the same object in a file system. There is a lot to bet that this has been added for portability reasons. The POSIX atomicity guarantees on file operations are not provided on every system. The facts are, when this issue came, it has been treated as it should have been. This is, once again, a sign of mature security processes and behaviour regarding the compiler implementers.