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.
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.
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?
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.