5 ms·

> Many of the most damaging recent security breaches happened to code written in MSLs (e.g., Log4j) or had nothing to do with programming languages (e.g., Kuber

> Many of the most damaging recent security breaches happened to code written in MSLs (e.g., Log4j) or had nothing to do with programming languages (e.g., Kubernetes Secrets stored on public GitHub repos). I’m surprised Herb is so defensive here. He normally strikes me as level-headed but he’s arguing in bad faith here. There’s no way a language can prevent arbitrary code execution if the programmer intentionally wants to allow it as a feature & then doesn’t think through the threat model correctly or not managing infrastructure secrets (the latter btw is mitigated by Microsoft’s own efforts with GitHub secret scanning although there should be more of an industry effort to make sure that all tokens are identifiable). But C/C++ is a place where 60-80% of the vulnerabilities are regularly basic things the language can mitigate out of the box. No one is talking about perfection. But it’s disappointing to see Herb stuck and arguing “there’s other problems and even if memory safety is an issue Rust has problems too”. The point is that using Rust is a step function improvement and provides programmers with the right tools so they can focus on the other security issues. A Rust codebase will take more $ to exploit than a C/C++ one because it will be harder to find a memory vulnerability which is easier to chain into a full exploit vs attacking higher level stuff which is more application specific. EDIT: And language CVEs are a poor way to measure the impact of switching to Rust because it’s the downstream ecosystem CVEs that matter. I’m really disappointed this is the attitude from the C++ community. I have a lot of respect for the people working on it, but Herb’s & Bjarne’s response feels like an unnecessary defensive missive to justify that C++ is still relevant instead of actually fixing the C++ ecosystem problems (namely their standards approach is making them move too slowly to ever shore up their weaknesses).

nindalf 3y ago
Their defensiveness makes sense in the current context where in the last few weeks organisations like the White House [1] and Google [2] are explicitly calling out the importance and imminent need of moving away from memory unsafe languages like C and C++. If everyone focussed on this one issue, it is possible that we might actually start moving away from C and C++ in the next 5-10 years. Sutter pointing out that memory safety isn't the only vector for system vulnerabilities would have the effect of spreading cybersecurity efforts and budgets across all of them. In that case memory safety isn't the foremost problem it's being portrayed as, and it isn't worth migrating away from C and C++. [1] - https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-... [2] - https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/ https://research.google/pubs/secure-by-design-googles-perspe...
- steveklabnik 3y ago
  The White House reports also acknowledge that memory safety isn't the only issue, but instead, is a large one that movement can be made on. From page 8 of that report: > To be sure, there are no one-size-fits-all solutions in cybersecurity, and using a memory safe programming language cannot eliminate every cybersecurity risk. However, it is a substantial, additional step technology manufacturers can take toward the elimination of broad categories of software vulnerabilities. And of course, Google as well. Not even the most fervent memory safety advocates believe that it is the sole thing that will make software secure, so arguments like this come across a bit strange.
  - nindalf 3y ago
    No I completely agree, fixing memory safety is not the only thing that needs doing, far from it. I agree with the White House report in particular, which spends time talking about the responsibilities of C suite execs in ensuring their software is vulnerability free. That's good, actionable advice. I called out those two reports because for the first time in forever, there's actual impetus to move away from C and C++. That challenges the standards committee's usual stance that the status quo is acceptable. That's why we see Herb Sutter actually engaging with the issue of memory safety here. Compare that with Bjarne Stroustrup's earlier glib dismissal of these concerns, where his talk started with "The Case Against Switching Languages". Kinda shows where his priorities lie.
    - justin66 3y ago
      I feel someone asserting this is the first time there's been an impetus coming from the government to move away from C and C++ must be entirely unfamiliar with the history of Ada.
      - steveklabnik 3y ago
        While they are similar, they are different: the move towards Ada was scoped purely at the Department of Defense. This situation is one where the government is also trying to work with and encourage practices in general industry.
jcranmer 3y ago
The table stakes here is automatic bounds checking. This is something that pretty much every newer language does already, and even several older languages figured out how to do well. The problem in C/C++ is that pointers don't inherently communicate their bounds, so your options for adding automatic bounds checking are a) fat pointers and consequently (severe) ABI break; b) some sort of shadow memory to store bounds info (ASAN, generally considered inadvisable to use in production); or c) change the language to communicate what the bounds of a pointer are. The good news is that most interfaces will provide the bounds of a pointer as another member of the struct or the function parameter it's part of; the bad news is that actually communicating that information requires a scope lookup change that is hard to get through the committees.
- physicsguy 3y ago
  The reason they don't communicate their bounds is also a performance optimisation. You can certainly do it in C++; use a std::vector for e.g. and use the .at() method to index on it and it'll throw an exception unless you disable that with a compiler flag. The thing is, it's fine to take that risk if you're writing HPC simulation software, but it's much less fine if you're writing an operating system or similar.
  - pizlonator 3y ago
    Yeah, “also” a performance optimization. It’s also just legacy. We’ve always done it that way so we still do it that way for ABI compat and because it’s hard to find a compiler that does it any other way. Imagine if the story was: “you totally can have a bounds on your ptrs if you pass a compiler flag and accept perf cost”. I bet some of us would find that useful.
  - chlorion 3y ago
    The performance and power use cost to checking bounds is trivial! Apple has tested this, on mobile devices even, when working on -fbounds-safety. From the slides: System-level performance impact • Measurement on iOS • 0-8% binary size increase per project • No measurable performance or power impact on boot, app launch • Minor overall performance impact on audio decoding/encoding (1%) • System-level performance cost is remarkably low and worth paying for the security benefit Some more specific synthetic benchmarks suites reported ~5% runtime cost for bounds checking. https://www.youtube.com/watch?v=RK9bfrsMdAM https://www.youtube.com/watch?v=RK9bfrsMdAM https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/01-Na-fbounds-safety.pdf https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/... Bounds checking being omitted due to performance is mostly a myth, the only time this should ever be believed is in very specific circumstances such as performance critical code and when the impact has actually been measured!
deathanatos 3y ago
> although there should be more of an industry effort to make sure that all tokens are identifiable There is, BTW: https://datatracker.ietf.org/doc/html/rfc8959 https://datatracker.ietf.org/doc/html/rfc8959 Getting people to use the standard is another matter.
WalterBright 3y ago
C and C++ could both easily add this feature: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html which is adding slices to the native language. This will eliminate buffer overflow errors (if the user uses that feature). D has had this from the beginning, and while it doesn't cover everything, that feature alone has resulted in an enormous reduction in memory safety errors. BTW, D also has a prototype ownership/borrowing system.
- pptr 3y ago
  C++20 added std::span, which is essentially that.
  - pjmlp 3y ago
    Without bounds checking.
    - vlovich123 3y ago
      Hey. Be reasonable. That's coming in c++26 using the `.at` interface that no one actually uses because `[]` is more natural, shorter (2.5x shorter), and convenient.
      - pjmlp 3y ago
        Yeah, that is exactly the problem. :)
JohnFen 3y ago
The defensiveness is entirely understandable. There's a very vocal contingent of the industry who is increasingly hostile to anyone who dares to say that C/C++ isn't pure evil. Defensiveness is the natural reaction to that sort of thing.
- vlovich123 3y ago
  Instead of defensiveness, why not talk about the ways in which the C++ committee is changing how they're operating (or even leaving ISO) and changing their culture to shore up these things. Look at past Scott Meyers talks (e.g. [1]). He highlights how the committee has arbitrary set of principles that can be applied to justify or reject any proposal and the inconsistencies in the language are a reflection of this. This isn't a problem of the language itself but rather that it's design by committee with 4 major front-end implementations (Intel, MSVC, Clang, GCC although I believe Intel is standardizing on the Clang front-end at least). Organizational issues like that are tough to spot but it's become clear now for several years that Rust is going to beat C++ silly if the C++ committee doesn't clean up their act and steer the C++ community a bit better (e.g. still no ABI specification, no improvements on macros, no standardized build system, modules are a joke, no standardized package system, etc etc). They're not effective stewards not least of which because they can't even take good impactful ideas from Rust and copy them. [1] https://www.youtube.com/watch?v=KAWA1DuvCnQ https://www.youtube.com/watch?v=KAWA1DuvCnQ

nindalf 3y ago

Their defensiveness makes sense in the current context where in the last few weeks organisations like the White House [1] and Google [2] are explicitly calling out the importance and imminent need of moving away from memory unsafe languages like C and C++. If everyone focussed on this one issue, it is possible that we might actually start moving away from C and C++ in the next 5-10 years. Sutter pointing out that memory safety isn't the only vector for system vulnerabilities would have the effect of spreading cybersecurity efforts and budgets across all of them. In that case memory safety isn't the foremost problem it's being portrayed as, and it isn't worth migrating away from C and C++. [1] - https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-... [2] - https://research.google/pubs/secure-by-design-googles-perspective-on-memory-safety/ https://research.google/pubs/secure-by-design-googles-perspe...

steveklabnik 3y ago
The White House reports also acknowledge that memory safety isn't the only issue, but instead, is a large one that movement can be made on. From page 8 of that report: > To be sure, there are no one-size-fits-all solutions in cybersecurity, and using a memory safe programming language cannot eliminate every cybersecurity risk. However, it is a substantial, additional step technology manufacturers can take toward the elimination of broad categories of software vulnerabilities. And of course, Google as well. Not even the most fervent memory safety advocates believe that it is the sole thing that will make software secure, so arguments like this come across a bit strange.
- nindalf 3y ago
  No I completely agree, fixing memory safety is not the only thing that needs doing, far from it. I agree with the White House report in particular, which spends time talking about the responsibilities of C suite execs in ensuring their software is vulnerability free. That's good, actionable advice. I called out those two reports because for the first time in forever, there's actual impetus to move away from C and C++. That challenges the standards committee's usual stance that the status quo is acceptable. That's why we see Herb Sutter actually engaging with the issue of memory safety here. Compare that with Bjarne Stroustrup's earlier glib dismissal of these concerns, where his talk started with "The Case Against Switching Languages". Kinda shows where his priorities lie.
  - justin66 3y ago
    I feel someone asserting this is the first time there's been an impetus coming from the government to move away from C and C++ must be entirely unfamiliar with the history of Ada.
    - steveklabnik 3y ago
      While they are similar, they are different: the move towards Ada was scoped purely at the Department of Defense. This situation is one where the government is also trying to work with and encourage practices in general industry.

jcranmer 3y ago

The table stakes here is automatic bounds checking. This is something that pretty much every newer language does already, and even several older languages figured out how to do well. The problem in C/C++ is that pointers don't inherently communicate their bounds, so your options for adding automatic bounds checking are a) fat pointers and consequently (severe) ABI break; b) some sort of shadow memory to store bounds info (ASAN, generally considered inadvisable to use in production); or c) change the language to communicate what the bounds of a pointer are. The good news is that most interfaces will provide the bounds of a pointer as another member of the struct or the function parameter it's part of; the bad news is that actually communicating that information requires a scope lookup change that is hard to get through the committees.

physicsguy 3y ago
The reason they don't communicate their bounds is also a performance optimisation. You can certainly do it in C++; use a std::vector for e.g. and use the .at() method to index on it and it'll throw an exception unless you disable that with a compiler flag. The thing is, it's fine to take that risk if you're writing HPC simulation software, but it's much less fine if you're writing an operating system or similar.
- pizlonator 3y ago
  Yeah, “also” a performance optimization. It’s also just legacy. We’ve always done it that way so we still do it that way for ABI compat and because it’s hard to find a compiler that does it any other way. Imagine if the story was: “you totally can have a bounds on your ptrs if you pass a compiler flag and accept perf cost”. I bet some of us would find that useful.
- chlorion 3y ago
  The performance and power use cost to checking bounds is trivial! Apple has tested this, on mobile devices even, when working on -fbounds-safety. From the slides: System-level performance impact • Measurement on iOS • 0-8% binary size increase per project • No measurable performance or power impact on boot, app launch • Minor overall performance impact on audio decoding/encoding (1%) • System-level performance cost is remarkably low and worth paying for the security benefit Some more specific synthetic benchmarks suites reported ~5% runtime cost for bounds checking. https://www.youtube.com/watch?v=RK9bfrsMdAM https://www.youtube.com/watch?v=RK9bfrsMdAM https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/01-Na-fbounds-safety.pdf https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/... Bounds checking being omitted due to performance is mostly a myth, the only time this should ever be believed is in very specific circumstances such as performance critical code and when the impact has actually been measured!

deathanatos 3y ago

> although there should be more of an industry effort to make sure that all tokens are identifiable There is, BTW: https://datatracker.ietf.org/doc/html/rfc8959 https://datatracker.ietf.org/doc/html/rfc8959 Getting people to use the standard is another matter.

WalterBright 3y ago

C and C++ could both easily add this feature: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html which is adding slices to the native language. This will eliminate buffer overflow errors (if the user uses that feature). D has had this from the beginning, and while it doesn't cover everything, that feature alone has resulted in an enormous reduction in memory safety errors. BTW, D also has a prototype ownership/borrowing system.

pptr 3y ago
C++20 added std::span, which is essentially that.
- pjmlp 3y ago
  Without bounds checking.
  - vlovich123 3y ago
    Hey. Be reasonable. That's coming in c++26 using the `.at` interface that no one actually uses because `[]` is more natural, shorter (2.5x shorter), and convenient.
    - pjmlp 3y ago
      Yeah, that is exactly the problem. :)

JohnFen 3y ago

The defensiveness is entirely understandable. There's a very vocal contingent of the industry who is increasingly hostile to anyone who dares to say that C/C++ isn't pure evil. Defensiveness is the natural reaction to that sort of thing.

vlovich123 3y ago
Instead of defensiveness, why not talk about the ways in which the C++ committee is changing how they're operating (or even leaving ISO) and changing their culture to shore up these things. Look at past Scott Meyers talks (e.g. [1]). He highlights how the committee has arbitrary set of principles that can be applied to justify or reject any proposal and the inconsistencies in the language are a reflection of this. This isn't a problem of the language itself but rather that it's design by committee with 4 major front-end implementations (Intel, MSVC, Clang, GCC although I believe Intel is standardizing on the Clang front-end at least). Organizational issues like that are tough to spot but it's become clear now for several years that Rust is going to beat C++ silly if the C++ committee doesn't clean up their act and steer the C++ community a bit better (e.g. still no ABI specification, no improvements on macros, no standardized build system, modules are a joke, no standardized package system, etc etc). They're not effective stewards not least of which because they can't even take good impactful ideas from Rust and copy them. [1] https://www.youtube.com/watch?v=KAWA1DuvCnQ https://www.youtube.com/watch?v=KAWA1DuvCnQ