Slashdot Mirror
The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal With It (vice.com)
What do Heartbleed, WannaCry, and million dollar iPhone bugs have in common? From a report: One bug affects iPhones, another affects Windows, and the third affects servers running Linux. At first glance these might seem unrelated, but in reality all three were made possible because the software that was being exploited was written in programming languages which allow a category of errors called "memory unsafety." By allowing these types of vulnerabilities, languages such as C and C++ have facilitated a nearly unending stream of critical computer security vulnerabilities for years.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
Sure you can draw parallels, but I don't recall my computer processes having constitutional rights, so excuse me if I don't feel quite the same emotional stir over bounds checking as I might when the police state does something untoward.
C/C++ are important for some things. Experienced developers know exactly when and how they should be used
A) Experienced developers do not always use them in appropriate circumstances
B) Not all programming is done by experienced programmers
C) One doesn't get to be an experienced programmer with C/C++ without working with the tools and making a lot of mistakes.
D) Experienced programmers still generate bugs and security holes
E) Tools that require the programmer to catch 100% of a known problem with known solutions are bad tools
F) This problem with C and C++ has been known about and routinely ignored for decades.
G) It is screamingly clear that training will not resolve this problem as a general proposition
We have a bunch of sloppy code, written in a hurry, often by programmers who didn't know what they were doing, built over decades with tools which allow sloppy coding practices to occur. Sure there are occasionally reasons to work without the safety net but these are the exceptions that should prove the rule.
The article is a Mozilla developer trying to push people onto Rust. And while Rust is great for *SOME THINGS*, it is still a new language that falls far too short on too many others. I've recently attempted to build some demo programs in Rust, and had not enjoyed the experience one bit. A simple "hello world" application written in Rust and compiled generates a binary that is in the order of ~500-1000KiB in size. Now, let's put this into a little bit of perspective of where I personally use C/C++ these days. I work with microcontrollers as a hobby, one of which has a total of 8KiB flash ROM. But this is just one example. Now, imagine writing an entire operating system in Rust with that type of file size. How many tiny utilities combined make up Linux or FreeBSD? Just imagine if literally EVERY single utility bundled with the OS was half megabyte in size? There are thousands of utilities, which would lead to OS bloat to an unimaginable level. Rust is promising for sure, and is doing great things for Webrender at Mozilla, but it just isn't there for smaller applications at all.
So you are making the Fast Food Argument.
Sure...it's bad for you...might even kill you.
But it's quick and it's tasty!
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
So I'm a long time C++ Dev, but have been trying to wrap my head around modern C++ (2011 to current) and it seems that there are a lot of improvements that would avoid those kinds of errors.
Unfortunately I observed that C++ is becoming less about writing your program and more about telling the compiler how to build it. It's also filled will all kinds of new acronyms, like SFINAE and CTAD, and new concepts like costexpr.
But I think it's all too little too late. Check out this "simple" map():
std::vector originals { 1,2,3};
std::vector triples;
std::transform(originals.begin(), originals.end(), std::back_inserter(triples), [](int item){ return item*3; });
Who wants to write that code? How does that code convey the intent to the user? You know it's doing a map because I told you. But that code was written for a compiler, not a human to understand.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I don't understand. C/C++ compilers have had options to enforce boundary checking for over 10 years now (at least). Are people really unaware of these things?
Depends on what you're doing. Sounds like you're talking about one off solutions. Regardless, you sound like like some c-level giving a speech to a dev team. We have thousands of customers, and unfixed bugs means cancelled implementation and cancelled maintenance contracts. Fixing bugs costs time and money, but so does developing an application. Maintenance contracts make up the bulk of revenue, and it's very dependable revenue when the product isn't buggy as shit. Keeping those contracts is what keeps your company alive and what keeps your investors happy.
C/C++ is not a language.
C cannot be made safe. It's a language for when you really need raw access. It's a language for kernels, and for writing languages. It's a language for when a memory address actually represents a temperature sensor (if you've ever wondered what a "const volatile int" was). People definitely use it beyond those bounds.
Heck, it's just tradition that keeps kernels in C. Very little of a kernel needs to be.
C++ can be used in a very safe way. All the libraries support it. The continuing problem is that people don't do that. They write "C/C++", that is, they write C++ as if they were writing C. The fact you can do that may make C++ irredeemable for security-conscious code.
I find that very frustrating, having written C++ for years without a memory leak or buffer overflow (it's easy if you use the right primitives). But it would be very hard to police junior coders and keep such vulnerabilities from creeping in, and I wouldn't start a new project in C++ if security was any concern.
At least with C you know where you stand, and that if security is paramount you need to minimize it to where it's the right tool, review it heavily, fuzz test it, and so on.
Socialism: a lie told by totalitarians and believed by fools.
In other words I am very smart.
Or to put my criticism of what you've written a different way, there's a difference between a programming language including a few features that could, if deliberately misused, cause a problem, and a language that cannot be used by a competent programmer without various types of unintentional problem. And no, handwaving and saying "Ah, but then they're not competent" is not an answer: Dennis Richie could be that programmer.
You are not that smart. I'm not insulting you, I'm just telling you the truth, and the truth to every C and C++ programmer sitting here smirking about how they can write solid C code. No, you can't. You may be better at it than the VB programmers in the other office, but you're not smart enough to never miscalculate a pointer, never accidentally dereference, or use pointer arithmetic on a pointer that starts at, null. You'll live long enough to put a buffer overflow in a production environment. You'll "learn" from each event, sure, but the worst part is, you will do it again. If you're very lucky, your code will be peer reviewed, and the bugs will get spotted before they go live.
The difference between a bad C programmer and a good C programmer is not that the latter avoids buffer overflows. It's that the latter is smart enough to know she won't. That she'll eventually fuck it up.
For what it's worth C is especially awful because, in addition to the basic bounds checks every normal language has, so much of its behavior is "undefined", yet developers are actively encouraged to take advantage of its undefined behavior to achieve useful work.
C is an artifact of its time, it's a language designed to program a multitasking operating system into a 16 bit minicomputer that had as little as of 8K of RAM. At that time, not only were the overheads of bounds checking a problem, but writing a programming language that supported such features was hard due to the need to ensure the compiler would fit into memory. Somehow, instead of saying "Wow, Unix has some great ideas, let's incorporate the better ones into the next generation of operating systems", we're stuck with Unix and its clones as the major computing standard at the moment (well, together with Windows which, because of the popularity of C in the 1980s at Microsoft, ended up with the same faults and then some.)
Unix has its flaws even if you dump the code and rewrite it to work in exactly the same way but using (gag!) Modula 2 or some other "safe" language. But it's worse because you can't trust it. You have thousands of C programs installed. And some of them were written by people like you, people who think that they can program in C without making a mistake.
You are not alone. This is not normal. None of this is normal.