Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language.

If you haven't, I'd encourage you to read the paper "Some Were Meant For C"[0] on why C still doesn't have a real replacement (though it could in the future).

[0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...

But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in (a rather wide subset of) C and detect great many classical pitfalls.

So I'd say that it's not about safe languages, but mostly about safe methods of development for critical software, methods that remove large classes of defects that are commonly exploitable.

This, of course, can be only one layer of protection; the OS and the hardware design should also do their part. Advanced devices, like desktop and phone CPUs, have some very good hardware features for protection, like MMUs, w^x bits for RAM pages, secure enclaves, etc. Simpler devices (like IoT SoCs) often don't, and they can be potentially cracked into more easily.

Like the FAA does.

Never, ever going to happen in enterprise and consumer software.

Meanwhile, I have to argue with developers on a regular basis to convince them that they actually need to patch the libraries in their systems. Yes, even if they don't see an obvious exploit path. Yes, even if it's more work than drop-in-and-ship.

Getting them to use static analysis is a nightmare. Entirely too many developers view each finding as an attack on their style they can negotiate away.

As you so wisely and correctly say, we're at a point in time where we mostly have the tools to employ safer software development lifecycle methodologies. It is telling, then, how often we don't.

> There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C

To be clear, those "alternative implementations" do not exist, and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.

"Fail-Safe C" is a research project that has been dead for ten years. Note:

> Some benchmark results show that the execution time are around 3 to 5 times of the original, natively-compiled programs, in avarage

That overhead is actually a lot higher than similar projects I also consider failures, such as CCured.

To be clear, when we talk about "an alternative implementation of C", it needs to give similar performance and other properties (e.g. function and data interop) to other C compilers. You can't impose a 3-5x slowdown and say "look, C is safe".

When everything else fails, kill the bug with hardware memory tagging spray.

> To be clear, when we talk about "an alternative implementation of C", it needs to give similar performance and other properties (e.g. function and data interop) to other C compilers. You can't impose a 3-5x slowdown and say "look, C is safe".

Pretty much every language (except rust) which claims to be "C but safe" has the same issue, except you have to rewrite your program in it.

A C interpreter is not exactly the sort of thing that the embedded software industry has been waiting to deploy in production.

Further, CHERI is not enough to achieve temporal memory safety, it only provides the primitive that one could use to implement an efficient, correct tracing GC.

Perhaps most importantly, one can not use CHERI today. It is just not an option. Memory safe languages exist, and have existed for quite some time.

Pointer tagging and other approaches like CHERI are very promising. Keeping in mind of course that they double the size of pointers and have a global runtime performance cost. Less ambitious but otherwise similar mitigations are already being adopted.

(Disclaimer: been there, done that, part of the CHERI team)

Best of luck with the research, I'm quite bullish on the work.

https://github.com/stephenrkell/libcrunch

Maybe a safety ranking is in order? How many CVEs from [year], weighed by severity, are impossible to happen in [language]. Obviously this idea has serious problems, but you see my point: C would get a straight up zero, as it should! (well, not completely zero, as many vulns come from dependencies and C's complete lack of a package and dependency system is actually an advantage here)

Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy.

I have no idea, honestly, how you would introduce a use-after-free bug with C++'s smart pointers. Its the lack of schooling, the lack of certification, and the lack of a safety-focused selection of applicants, not a language that you can write bad code in if you ignore all warnings and advice.

Even rust has unsafe{}, but I dont see anyone complain when thats used to introduce safety issues, because "youre not supposed to do that, even though technically you could".

You can have all the safety mechanisms in a language, but you need control, too, and anyone who is completely unqualified will use that to break something.

I understand what you're saying, but I'm not sure I agree.

For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code reviews. They can afford any static analyser on the market. They've got sandboxing. They've got open source so many eyes can spot bugs easily. They can dictate terms on requirements - if Chrome vetos a new web standard and it's as good as dead, and if Google decides plugins have got to go, they go.

And they've got 177 CVEs so far in 2021 [1] - including such greatest hits as use-after-free, buffer overflows and out-of-bounds access.

You and I think we're writing secure C++ - but if the best-resourced team in the world can't write secure C++, isn't it more likely we're just fooling ourselves?

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome

The point is that memory safety bugs are the gift that keeps on giving.

You can throw as much money into the problem as you want, and the inherent complexity of memory management means you are still gonna ship bugs of all severity.

I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed.

A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.

That's needless extremism, moderate programmers benefit from safety mechanisms, and you can't hire a lot of perfect programmers.

I agree, though that's not intractable. There's security compliance like ISO27001, which can't say "you're secure", but can say "you've got a threat model and you take measures to address it". It's then something you document and provide evidence for as part of your compliance obligations.

If we applied the same thing to a programming language I think it could be very clear to see the differences between languages.

That's not at all to say that I think ISO27001 is a good model for security, just that we already have systems that handle very nuanced ideas, so a formal definition, or proof, etc, is not really as necessary as it may seem.

As for the article, the dream to get all UBs right without a systematic approach is idealism.

Wow. It comes from the Libra hearing I guess? By any chance, do you have an link to the exact quote?

Edit: as hsod answered below (I don't really get why this answer was flagged) the congressman isn't really “complaining” and it's not about a Nigerian committing to Rust, but to Libra itself.

“I went ahead and did a GitHub search on who’s actually leading the development on the Libra core side and it looks like, I think it’s gonna be international because it looks like a native Nigerian that’s actually building the actual Libra core in front of the code development of Libra core” - congressman Denver Riggleman (R-VA)

He lost his seat in 2020

Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.

And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4.

Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.

One of seL4's points is that security can still be fast, no?

From https://docs.sel4.systems/projects/sel4/frequently-asked-que...

>To the best of our knowledge, seL4 is the world’s fastest microkernel on the supported processors, in terms of the usual ping-pong metric: the cost of a cross-address-space message-passing (IPC) operation.

But within the Linux kernel, you might not need that cross-process IPC at all, so if you're into squeezing every last microsecond of latency, you likely want your entire app running as a monolith in kernel mode.

But if you want security more than top speed, seL4 + a few daemons you write for other OS needs must be fine.

> Our kernel, Zircon, [is not in Rust](https://twitter.com/cpuGoogle/status/1397265884251525122). Not yet anyway. But it is in [a nice, lean subset of C++](https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...) which I consider a vast improvement over C.

https://blog.cr0.org/2021/06/a-few-thoughts-on-fuchsia-secur...

They are now starting to rewrite OS components in Rust, and I wouldn't be surprised if that happens to Zircon as well, it stared as a C anyway, and thus already suffered one rewrite.

A rewrite usually improves a lot of small things that were found in the previous version. It's like a new major version, even if it does not add new major features.

It's an expensive undertaking, though.

https://www.youtube.com/watch?v=gIT1ISCioDY

False. Which broken telephone did this come from? The Linux kernel has 0% Rust code in it and has no plans to change that.

(And no, "including experimental Rust support" isn't a plan to change that.)

You don't need Rust to compile the kernel. What's changed now is that you could theoretically write a kernel module in Rust. (But you can, e.g., write a kernel module in C++ too, I've done it before.)

As for seL4, doesn’t that just support my point that highly secure software can be written in any language, even C? seL4 is primarily implemented in C. There “executable spec” is written in Haskell, but the actual kernel that people use is written primarily in C and a little Assembly.

You define the threat model for your application and then justify why you're safe. In this case we'd be adding an explicit point to ensure that there are controls for attackers who can exploit memory safety issues.

You could end up with controls like:

1. We sandbox our code, so even though it's C we feel that we're safe

2. We use a memory safe language to reduce the risk of memory safety issues

3. We sanitizer inputs before providing them to the program

etc etc

What ends up being accepted as legitimate would be up to the auditors/ generally a matter of consensus.

Edit: And, of course, a lot of forced static typing and avoiding global scoped stuff. So, for example, you'd make a

    struct Meter {
        float value { 0.0f };
    };
    Meter wall_length;

Then even if you find issues in those third party code libraries, there is the issue of if you are allowed to change them yourself, or how those fixes get provided by the library vendor, warranties and so on.

- Decoders and encoders for video, images, and audio - graphics libraries - Many parts of fast cryptographic libraries

This is typically for performance-related reasons.

Yes on theme, but no on ”there aught to be a law” that bans C/C++ because of an evolving goal of memory safety.

When Rust++ comes out surely there will be people complaining that Rust isn’t safe, and so on.

Best case is you make the consequence punishable (as was described in the article).

Programmers aren't that good at it either.

I know this kind of thing is a lightening rod for a lot of software folks, but it does have the nice property that it's proactive; you don't have to wait around for the obviously-unsafe practice to blow up in someone's face before you can do something about it.

And no one wants to have to get licensed to write some crud app in NodeJS. But maybe these kinds of high-stakes modules related to encryption, security, and so on could be a place to start with it; if you're going to work in these areas, and offer your work to the public (for money or otherwise), then you either need to be licensed by the professional body, or clearly advertise in the header of each file that the work has not be overseen by a licensed professional.

That's the kind of arrangement that could do things like specify languages, methods, interfaces, and so on.

Don't worry, the pricing will be FRAND (fair, reasonable, and non-discriminatory). You just won't be able to see the compiler and runtime sources or follow stack traces into stdlib code. For security reasons. Defense in depth, y'all.

For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941

None of it has anything to do with which tools or methods are used for the practice of engineering— it's all defining jurisdiction and constitutional meta-details about how the leadership is to be selected, term lengths, etc.

So no one can achieve regulatory capture about what kind of concrete is to be used in bridges in Ontario by lobbying the Ontario government; you'd have to lobby the PEO. Maybe your argument is that they're effectively equivalent, but they're really not— the PEO is a pretty different kind of organization from just another government office.

Yes, because this has stopped them doing dumb things before. The gov't will still be in charge of selecting the people in the regulator. The lobbiest will still have influence. There's just no way around it.

Are you really doubting that this is something that "might" happen?

Edit: FAA allowing Boeing to self-certify 737MAX. FDA allowing/not allowing trials of drugs, or allowing a drug meant for one thing to be tried for something else totall untested (ex: AZT).

I don't know that bodies like FAA and ERCOT are really comparable to professional associations; the market conditions make them especially vulnerable to corruption because they both "oversee" such a small number of large players, so you end up with a revolving door. In any case, these are also odd examples to bring up, because in both cases their failure was not about market capture, it was about failure to protect the public. So it seems your argument is amounting to "the regulation provided by the FAA isn't perfect, so it shouldn't exist, just like regulation for security-critical software shouldn't exist."

I specifically asked for examples from "law, medicine, trades, engineering", because those are cases that I feel are much more aligned to what it would be with a professional body overseeing practices for secure software development— they're cases where you have a large number of mostly small-time practitioners, and where the professional oversight mechanism is working in terms of enforcing safe and consistent practices, while also evolving those over time in response to changing conditions.

This is far from what I'm suggesting. I'm just saying that if it is a gov't regulated anything, those regulations will incur wacky decision making due to the influence of outside money. Nobody likes to be regulated against, and if they are in the position to do so, they will use any mechanism available to them to keep the status quo.

I'm also suggesting that any gov't regulation body is not always the panacea people may be dreaming it will be. Anytime a regulation body is proposed, I don't have rose colored glasses. I'd rather be pleasantly surprised that something turns out to be a good thing than having high expectations crushed.

I have less experience with other trades, but you did call out construction separately. My family comes from construction backgrounds at various levels. The 80s in the US saw a boom in the 20 story building construction, and then saw a total collapse (no pun intended) in the construction industry. There are lots and lots of building contracts won by lowest bidder, and the only way to do that is cutting corners somewhere. Usually in quality of material, or reducing the "over-engineered" portions to the point of risking saftey, etc.

It's also widely known in construction that the permitting offices can be gamed. Talk to the right people with the write phrases. NYC is infamous in that people playing by the rules get absolutely nowhere. You have to start spending cash and using influence to get things done. It's all just pointless to being corrupt.

Code reflects the programmer's understanding of the world. If this understanding is flawed, the logic will also be flawed.

Would phones really be that high up given that in environments with high security standards usually people are not allowed to carry them? What about home appliances? Could a state actor hack a bunch of stoves and burn the houses down?

I can easily see some huge bureaucracy being put in place without much benefits ("Federal Programing Language Commission"?).

Most high security environments have a physical component, why not learn from there? Phones could just have a physical switch to cut off microphones and antennae for example, much easier to do than trying to police millions of lines of codes to be secure.

What is this fascination with creating a new language every time we want to add some features? Is it the fame of creating and naming your own computer language? From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.

Example: C++ shared_ptr gives you reference counting which helps prevent use-after-free errors. However, shared_ptr can't stop you getting a raw pointer or reference to the underlying object, which can then be used to trigger a use-after-free bug.

It's like saying "llvm is in C++, and llvm is used to compile Rust, therefor C++ is as safe as Rust". It's just not a tractable argument.

As for the rest of your post, sure, you can create a new revision of C/C++ that's memory safe - feel free to do so. It'll basically be a new language, but that's fine and has nothing to do with the parent's point, which is that we should incentivize memory safety - they didn't say it had to be a new language.

As for why people don't take that approach, it's because: it'll be a massive breaking change, so it's really no different from a completely new language. If you're going to create a completely new language you may as well take the time to fix a bunch of other issues while you're there.

edit: The above applies to libraries too. There are libraries that enforce stronger security in C++ (I want to say... IronC++? Something like that), and it basically ends up being, give or take, the cognitive overhead of a new language, but with the added bonus of no one actually using it.

> From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.

This is unsubstantiated, and I highly doubt it is the case.

It is the job of human intelligence to cause ‘discontention’ - discontent and contention. I like to think of how it as how you can make powerful gears almost seize if you understand their weaknesses properly.

I can tell you exactly how this will end up: like PCI DSS.

Countries already do this. But they also put exemption clauses in the policies.

Ban exemptions (in all policies) first if you want to make progress.

But you won't like it.

Liability should be created where when you expose third party data. That would disincentivise data collection massively.