Comment by adev_ | Hacker News Reader

Comment by adev_ | Hacker News Reader

Parent Full thread

> 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-fo...

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.

The answer to that is there: 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)

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.

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://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!!!"

C++ is the standard. Not the implementations. The bug is fixed in the implementations, but remains in C++.

Where is the bug in the C++ standard? std::remove_all states:

> 1,2) The file or empty directory identified by the path p is deleted as if by the POSIX remove. Symlinks are not followed (symlink is removed, not its target). > 3,4) Deletes the contents of p (if it is a directory) and the contents of all its subdirectories, recursively, then deletes p itself as if by repeatedly applying the POSIX remove. Symlinks are not followed (symlink is removed, not its target).

Nowhere in there does it say "lol but FUCK YOU if you're on a multiprocessing system lololololol" or anything remotely close to that.

> 29.11.2.3 File system race behavior [fs.race.behavior]

> 1 A file system race is the condition that occurs when multiple threads, processes, or computers interleave access and modification of the same object within a file system. Behavior is undefined if calls to functions provided by subclause [fs.race.behavior] introduce a file system race.

> 2 If the possibility of a file system race would make it unreliable for a program to test for a precondition before calling a function described herein, Preconditions: is not specified for the function. [ Note: As a design practice, preconditions are not specified when it is unreasonable for a program to detect them prior to calling the function. — end note ]

There you go. "Behavior is undefined" is essentially "fuck you, you won't get any error you'll just get garbage at runtime". It does thankfully allow the implementations to make it an error at runtime (as they did), but does not require it, so the standard still has the bug.

> I think you do not really know what you are talking about here.

Yeah, maybe.

The reference says

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

My understanding of the vulnerability happens because a different process interleaves access to the same object in the file system between the time of check (TOC) and time of use (TOU) leading to the TOCTOU bug. And this isn't a vulnerability in C++ because it's considered UB by the spec.

I'd be really interested in hearing you explain why this section of the spec isn't relevant to the TOCTOU bug. I'd learn something new if that's the case.

I know you're frustrated by the discussion of CVEs but please understand that the entire article and this thread is based on understanding C and C++'s security record based on CVEs. Herb Sutter compared C++ with Rust, pointing out 61 CVEs in C++ and 6 in Rust. Therefore it's really relevant to compare the attitudes of both communities about filing those CVEs. The fact that the exact same vulnerability warranted a Rust CVE but not a C++ CVE is quite telling.

I'm not happy with the CVE system, no one is. You're not either. All I'm saying is, comparisons of CVEs across languages, like Sutter has done, aren't helpful or useful. He claims that C++ will be equally safe as Rust if CVEs were reduced by 90%. But as long as the C++ community doesn't file CVEs when Rust does, that's not correct. And it's likely to be more incorrect if the community follows through with Herb's suggestion to take control of the CVE filing mechanism.

> My understanding of the vulnerability happens because a different process interleaves access to the same object in the file system between the time of check (TOC) and time of use (TOU) leading to the TOCTOU bug. And this isn't a vulnerability in C++ because it's considered UB by the spec.

The definition as Undefined Behaviour in the spec is quite unfortunate and a mistake. We do agree on that.

> I'm not happy with the CVE system, no one is. You're not either. All I'm saying is, comparisons of CVEs across languages, like Sutter has done, aren't helpful or useful.

On this I do agree too. And saying that a lot of communities have things to learn from the Rust core team about security issue handling is a completely fair statement.

What infuriated me was your point:

> but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed

Which tend to under-mean that the C++ community took no action regarding to this exact problem. When, in fact, it is already patched and released in all major implementations (exactly like Rust did).

Yeah you're right, I originally said no action was taken because I was going off of my recollection of the original issue 2 years ago. When Rust released this blog post (Jan 20th 2022) the same issue had been fixed already in Python. When I asked around about C++, people pasted the reference link and said it didn't need to be fixed because it was defined as UB. I stand corrected, they did fix it. And good on them for fixing it and not closing it as "spec says its fine".

It's still bad they didn't file a CVE for it, knowing that other languages did so. It reduces trust in their ecosystem.

> It's still bad they didn't file a CVE for it, knowing that other languages did so. It reduces trust in their ecosystem.

Curiosity question: Do you know if python has also a CVE for this exact same problem ? I am not able to find it back through their git history.

In my understanding, no. I believe it was bpo-4489 [1], and I couldn't find a matching advisory from the PSF's database [2] which should contain most historical advisories as well (it does seem to miss earliest advisories like PSF-2005-001 and PSF-2006-001 though).

[1] https://github.com/python/cpython/issues/48739

[2] https://github.com/psf/advisory-database/

Reply on news.ycombinator.com