13 ms·

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are uns

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. 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-preprint.pdf https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...

nine_k 5y ago
Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. 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.
- Karrot_Kream 5y ago
  Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a part of Rust code.
  - pjmlp 5y ago
    Definitly, liability needs to happen, sledgle with lawsuits hammer any company that doesn't take security seriously.
    - throwaway210222 5y ago
      Sledge with lawsuits and company that knowingly buys uncertified software. Like the FAA does. Never, ever going to happen in enterprise and consumer software.
      - pjmlp 5y ago
        It already happens when that enterprise and consumer software is deployed in high integrity computing scenarios.
- swiley 5y ago
  They certainly started off that way but modern static analysis can catch a lot. Plus these other languages (yes, including Rust) are all still at least partly implemented in C/C++ so you cant outright ban it.
- Kalium 5y ago
  At the risk of being confrontational, show me a language without built-in footguns and we can talk. I've seen people fail to check their inputs in every language I've ever touched. I've seen people cobble together their own horrifically insecure SQL query builders. And so on. 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.
roca 5y ago
That paper has many problems. For example: > 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.
- h_anna_h 5y ago
  This is false. There are multiple safe C implementations. compcert and https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html are two such.
  - roca 5y ago
    Compcert is a verified compiler. It guarantees that the generated code does what the source code requires. It doesn't turn unsafe C programs into safe ones. "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".
    - pjmlp 5y ago
      Actually that is what Oracle did with SPARC ADI, Google/ARM are pushing for with MTE, Apple is trying to do with PAC, Microsoft with Phonon. When everything else fails, kill the bug with hardware memory tagging spray.
    - h_anna_h 5y ago
      The CompCert C reference interpreter aborts execution on undefined behavior. > 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.
staticassertion 5y ago
> As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. 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.
franga2000 5y ago
The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe. 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)
- lionkor 5y ago
  An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". 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.
  - michaelt 5y ago
    > Don't hire people who are under qualified. Its really that easy. 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 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome
GoblinSlayer 5y ago
Even in confines of C there are coding conventions with lower bullrun compatibility and there are some projects that use them: putty and s2n use them with C, grpc library uses it with C++. Fat pointers are in talks since 80s and are cheaply implementable, meanwhile Fuchsia, an allegedly new codebase, is written in old good 70s vanilla C as if PDP-7 is still hot. As for the article, the dream to get all UBs right without a systematic approach is idealism.
- pjmlp 5y ago
  I advise you to update your Fuchsia knowledge, it is written in a mix of C++, Rust and Dart nowadays.
mark_l_watson 5y ago
I agree with this article’s criticism of managed languages (Java, C#) for systems programming, but the author does not convince me that Swift and Rust would not be much, much better to build safe(r) systems and infrastructure software.

nine_k 5y ago

Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. 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.

Karrot_Kream 5y ago
Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a part of Rust code.
- pjmlp 5y ago
  Definitly, liability needs to happen, sledgle with lawsuits hammer any company that doesn't take security seriously.
  - throwaway210222 5y ago
    Sledge with lawsuits and company that knowingly buys uncertified software. Like the FAA does. Never, ever going to happen in enterprise and consumer software.
    - pjmlp 5y ago
      It already happens when that enterprise and consumer software is deployed in high integrity computing scenarios.
swiley 5y ago
They certainly started off that way but modern static analysis can catch a lot. Plus these other languages (yes, including Rust) are all still at least partly implemented in C/C++ so you cant outright ban it.
Kalium 5y ago
At the risk of being confrontational, show me a language without built-in footguns and we can talk. I've seen people fail to check their inputs in every language I've ever touched. I've seen people cobble together their own horrifically insecure SQL query builders. And so on. 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.

roca 5y ago

That paper has many problems. For example: > 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.

h_anna_h 5y ago
This is false. There are multiple safe C implementations. compcert and https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html are two such.
- roca 5y ago
  Compcert is a verified compiler. It guarantees that the generated code does what the source code requires. It doesn't turn unsafe C programs into safe ones. "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".
  - pjmlp 5y ago
    Actually that is what Oracle did with SPARC ADI, Google/ARM are pushing for with MTE, Apple is trying to do with PAC, Microsoft with Phonon. When everything else fails, kill the bug with hardware memory tagging spray.
  - h_anna_h 5y ago
    The CompCert C reference interpreter aborts execution on undefined behavior. > 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.

staticassertion 5y ago

> As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. 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.

franga2000 5y ago

The line is far less blurry than you suggest. The stats from the article say 70% of vulnerabilities come from [insert list of a few memory-wrangling mistakes here]. I'd consider any language that enables the top 70% of vulnerabilities to happen to be unsafe. 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)

lionkor 5y ago
An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". 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.
- michaelt 5y ago
  > Don't hire people who are under qualified. Its really that easy. 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 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=chrome

GoblinSlayer 5y ago

Even in confines of C there are coding conventions with lower bullrun compatibility and there are some projects that use them: putty and s2n use them with C, grpc library uses it with C++. Fat pointers are in talks since 80s and are cheaply implementable, meanwhile Fuchsia, an allegedly new codebase, is written in old good 70s vanilla C as if PDP-7 is still hot. As for the article, the dream to get all UBs right without a systematic approach is idealism.

pjmlp 5y ago
I advise you to update your Fuchsia knowledge, it is written in a mix of C++, Rust and Dart nowadays.

mark_l_watson 5y ago

I agree with this article’s criticism of managed languages (Java, C#) for systems programming, but the author does not convince me that Swift and Rust would not be much, much better to build safe(r) systems and infrastructure software.