I cannot consistently write safe C/C++ code • Hacker News Board

Re: I cannot consistently write safe C/C++ code

#111

Post by Rusky » Mon, Jul 17, 2017, 4:59 PM UTC

ccommsxx wrote: post #80

alfiedotwtf wrote: post #77

Earlier quoted context omitted.

Another scenario: Option 1. Spends 5 years learning the ins and outs of systems programming, whilst using C++. Still writes unsafe code. Option 2. Spends 5 years learning the ins and outs of systems programming, whilst using Rust. Zero unsafe code has ever been written.

Again, the assertion that all code written in rust is automatically "safe" (let alone correct) is false unless you say what precisely you mean with "safe" in very specific terms. While there are some ways in which rust is "safe" while c-family languages are not, these cases are _subtle_ and you _will_ have to understand modern C++ first to see what they are. But yes, rust could turn out to become a new widely accepte…

These cases are not subtle at all. You can understand a good number of them with barely the knowledge from an Intro to Java class- iterator invalidation, data races, etc.

There is no need to understand the particulars of C or C++ to do or appreciate safe systems programming.

Re: I cannot consistently write safe C/C++ code

#112

Post by kbenson » Mon, Jul 17, 2017, 5:03 PM UTC

skrebbel wrote: post #42

millstone wrote: post #25

> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the contex…

That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked". A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

> A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

Those examples are interesting, specifically because history has shown us this point of view to be erroneous through those exact systems.

Automotive control units that are supposed to be segregates from certain data channels sometimes aren't. That was the cause of the Jeep remote hijacking stuff.[1] Any automation has to have some inpute and output to be useful for more than anything as a heater, and assuming your inputs aren't "networked" may not be valid given you likely can't control exactly how it will be used now or in the future.

For aviation, there have been problems with assumptions regarding the integrity of the channels used for communication between planes and the ground. This has led to certain systems being exploitable, even if not as bad as the initial hype made it sound.[2]

1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...

2: https://defcon.org/images/defcon-22/dc-22-presentations/Pols...

Re: I cannot consistently write safe C/C++ code

#113

Post by kbenson » Mon, Jul 17, 2017, 5:14 PM UTC

millstone wrote: post #56

hsjoberg wrote: post #28

Earlier quoted context omitted.

In automotive, code is very rarely written it is mostly generated from simulink models. But yes software for aviation automotive, nuclear and medicine equipment are running safe C code. It is mostly generated from a model not necessarily simulink. The generated code usually have rules for the code so no global parameters, no pointers etc can be used.

That's a great point. Often you need to run your system in simulation via a model. Generating the code directly from the model is one way to prove that your system matches the simulation. Of course the modeling tools speak mostly C. This illustrates how C's weaknesses are mitigated in practice, and how much work prospective C-replacements must do to be competitive.

> This illustrates how C's weaknesses are mitigated in practice

Except there's likely a false sense of security in how well those mitigations work. Part of the problem with C is that later optimizations by the compiler can yield insecure code at a later date because of undefined behavior and compiler optimization techniques that take advantage of it. In other words, if your generated code takes advantage of any undefined behavior, there's no guarantee that the same code compiler on the same compiler with the same flags but with a different/newer version of that compiler will yield bug free code in both cases.

Can those models produce C code with absolutely no undefined behavior? Maybe? When's the last time someone did a close look at exactly what they were generating? Did they make sure to look again when the underlying architecture changed (even from one version of ARM to another...)?

See the somewhat recent Cap'N'Proto remote vuln[1] submission for a modern case of this, and a good discussion of the problem in detail.

1: https://news.ycombinator.com/item?id=14163111

Re: I cannot consistently write safe C/C++ code

#114

Post by kbenson » Mon, Jul 17, 2017, 5:23 PM UTC

clarry wrote: post #95

simias wrote: post #94

Earlier quoted context omitted.

Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance th…

> Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled. > And I don't think -Werror is a good general purpose solution because it's too broad. It sure is too broad for all e…

> It sure is too broad for all existing software to compile, but if we're talking about security-critical software

The problem I have with this is the assumption that software you write that may be used by others can easily be classified into security-critical software and non-security-critical software. Sometimes you don't know, sometimes it changes ten years later as something gets pulled in and used because it's easier, multiple times over the years until the original author of a portion of the code may be entirely unknown, much less their intention for whether it was sufficiently robust for security critical situations (think an OSS library that may have forked a few times, and copied small bits of code such as utility functions from some other projects).

It's time to switch to safety by default. We should fail safe, and require flags to allow previously failing code to compile, not to just hear that it might cause a problem.

Re: I cannot consistently write safe C/C++ code

#115

Post by kbenson » Mon, Jul 17, 2017, 5:29 PM UTC

sytelus wrote: post #43

millstone wrote: post #25

> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the contex…

The aviation/automotive code doesn't get deployed on to millions of personal computers of tons varieties and locals and probed by professional hackers endlessly for vulnerabilities. The aviation/automotive code runs in very well defined environment, almost completely locked down and unavailable for user interaction for most parts. Its unfair to compare them with open ended applications like browsers which has to hand…

The problem with security through obscurity (which is what this approach is analogous to), is that obscurity can't really be guaranteed, and you usually can't be sure exactly how your code will be implemented in the future. Here's some somewhat recent examples of that, where a Jeep was remotely controlled because the system's bus wasn't correctly segregated[1], and where an avionics messaging channel may be exploitable to send bogus information between planes and air traffic control[2].

1: https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...

2: https://defcon.org/images/defcon-22/dc-22-presentations/Pols...

Re: I cannot consistently write safe C/C++ code

#116

Post by kbenson » Mon, Jul 17, 2017, 5:32 PM UTC

clarry wrote: post #86

danieltillett wrote: post #59

Earlier quoted context omitted.

The good thing about C is there is an amazing tool support that can make it as safe as any other language. The bad thing about C is that most developers don’t know about (or don’t use) all the tools.

They don't even use their compiler.. case in point: https://news.ycombinator.com/item?id=14787072 Of course they always just blame the language. Like the language needs to be responsible for the implementation and its proper use.

Any tool that requires special knowledge to use safely rather than defaulting to safe operation and requiring special knowledge to use unsafely is poorly designed. If the design specification for that class or tools encourages or requires that, it's a poor specification indeed.

Re: I cannot consistently write safe C/C++ code

#117

Post by kbenson » Mon, Jul 17, 2017, 5:39 PM UTC

amelius wrote: post #102

Isn't this the same as saying you can't consistently write bug-free code? And isn't this sort of the holy grail of CS?

You are conflating "safe" with "bug-free", when safety has a specific meaning in this context, which is memory model safety. Safe code eliminates a class of errors, and thus reduces the possible bugs your program may exhibit.

At this point we can eliminate certain classes of bugs, and sometimes with no runtime cost. The usual example used is Rust, where extra information supplied in the source is used to ensure certain bugs are not possible at compile time. It requires some extra work, but I think likely quite a bit less than the more extreme coding standards used to produce safe C code, but those may cover a different or larger subset of bugs.

Re: I cannot consistently write safe C/C++ code

#118

Post by clarry » Mon, Jul 17, 2017, 6:35 PM UTC

kbenson wrote: post #114

clarry wrote: post #95

Earlier quoted context omitted.

> Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled. > And I don't think -Werror is a good general purpose solution because it's too broad. It sure is too broad for all e…

> It sure is too broad for all existing software to compile, but if we're talking about security-critical software The problem I have with this is the assumption that software you write that may be used by others can easily be classified into security-critical software and non-security-critical software. Sometimes you don't know, sometimes it changes ten years later as something gets pulled in and used because it's e…

Right, that is why I proposed people to use -Werror, even if that means you have to vet and fix third party code (which you should do anyway if you're depending on it). Ideally you use other tools too.

Apart from that, don't assume flags and static analyzers can save you. If you're building something security critical, you do not make any assumptions about the code you depend on. You don't assume it is in some class. You don't "don't know", you vet the code. Flags and analyzers, default or not, are at best going to save you from a small subset of problems. The code might still be completely backwards and insecure.

Re: I cannot consistently write safe C/C++ code

#119

Post by adrianN » Mon, Jul 17, 2017, 7:06 PM UTC

millstone wrote: post #79

skrebbel wrote: post #42

Earlier quoted context omitted.

That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked". A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

I don't follow your point. Software has to be prepared to deal with abnormal inputs, whether those are from a malfunctioning sensor, or an attacker on the same WiFi hotspot. Safety is a property of a system and the context in which it's used. Safety is not a property of its individual components, including its code. If your CPU's GPIOs were directly accessible through the Internet, your computer would be hacked too;…

A malfunctioning sensor is very unlikely to prepare a specially crafted input that exploits a bug. An intelligent adversary is something completely different.

Your claim that MISRA and standards for safety critical software also provide security against targeted attacks does not really follow.

Re: I cannot consistently write safe C/C++ code

#120

Post by hsjoberg » Mon, Jul 17, 2017, 7:32 PM UTC

kbenson wrote: post #113

millstone wrote: post #56

Earlier quoted context omitted.

That's a great point. Often you need to run your system in simulation via a model. Generating the code directly from the model is one way to prove that your system matches the simulation. Of course the modeling tools speak mostly C. This illustrates how C's weaknesses are mitigated in practice, and how much work prospective C-replacements must do to be competitive.

> This illustrates how C's weaknesses are mitigated in practice Except there's likely a false sense of security in how well those mitigations work. Part of the problem with C is that later optimizations by the compiler can yield insecure code at a later date because of undefined behavior and compiler optimization techniques that take advantage of it. In other words, if your generated code takes advantage of any undef…

Yeah testing needs to be done with compiled code on target card otherwise you can't be sure it works. Usually compiling code is super strict no further optimization then the standard can be used etc. Only specific cards and compilers are "trusted" to use.