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.
I expect that there are any number of developers who would be happy to address those issues if their managers would only put enough time into the schedule to do so (and not go-back and demand enough additional features to squeeze it back out of the schedule).
Nobody blames the 18-wheeler itself if the driver is too incompetent to load or drive it properly under most conditions, and nobody needs to go around blaming C/++, either.
If you're going to play that close to the metal (let alone doing anything further down, like, say, Assembly), at least try to know WTF you're doing, and get help if you're not sure. The more powerful and flexible the tool, the more dangerous (and less tolerant) things can get for the neglectful, the incompetent, and the ignorant.
Quo usque tandem abutere, Nimbus, patientia nostra?
"Finally, we can shift the culture around security within software engineering. When I first learned C++ in college, it was expected that sometimes your program would crash."
A quote from the article...WTF school is teaching this kind of crap. It would appear that the issue mainly resolves around the teaching practices and not so much the language.
What the author describes is not a buffer overflow. Article is ill-informed click-bait.
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999
I decided not to read the article when I saw the following:
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,"
That is not a buffer overflow. That is an out of bounds access, which a completely different type of vulnerability.
Sometimes, this specific access violation is called a buffer over-read, but anyone calling it a buffer overflow is simply sloppy or wrong---neither of which makes me interested in reading their material.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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 expect that there are any number of developers who would be happy to address those issues if their managers would only put enough time into the schedule to do so
This would account for a percentage of the problem but your argument is something of a cop out because it ignores all the other parts of the problem. You can give programmers all the time and resources in the world and if they used C/C++ these bugs still occur. People are imperfect and they make mistakes. Many programmers are inexperienced and don't know any better. These problems have been known about for decades and yet they still occur even with projects where there are no time deadlines like many open source projects.
It is impossible for those languages with "safe" memory access to exist without underlying languages that can openly access memory and that don't hide the truth of the machine beneath them. It is impossible to build an operating system in Java or Python -- they are made-up realities. They are designed to make computer pretend to work in ways they actually don't... in ways humans find easier to view and work with programming logic.
C and C++ do not hide the underlying machine because they are made to build the layers that actually allow software to work with the machine. The machine is instruction sequences in memory that manipulate memory -- memory is a singular long sequence of bytes. At the lowest level in any computer, that's what's there. Definitely not Python or Java. Python and Java must be written in either assembly language or a "true to the machine" language like C or C++. I am quite sure without checking that they are both written in C++. In fact C was specifically created to write the first UNIX... It's core is the core of POSIX of which even Windows shares... as DOS was written in C.
It's truly absurd to blame C and C++ memory unsafety. This illustrates a lack of fundamental understand of how computers work.
C++ is really two languages in one: backwards-compatible C and modern C++, and unfortunately there's nothing to stop programmers from inappropriately using low level C features when safer C++ alternatives (smart pointers, STL data structures) would be a better choice.
The C++ standards body should define a "safe-C++" subset that doesn't allow legacy features like C-style arrays and raw pointers. The compilers could have an option to enforce safe mode and only allow exceptions in sections of code explicity marked as unsafe (#pragma unsafe ?).
Flaws in drivers used to be attractive to malicious actors because drivers ran in the kernel and had immense power. Modern operating systems limit drivers so that the damage they can do is greatly reduced. Also helps with stability because your sound card driver crashing won't bring the whole machine down any more.
That's the key to security. Assume stuff will have bugs, isolate it, sandbox it, put layers of security in and limit the damage. A bug in the network stack should at worst crash the network stack, which while annoying is far less critical than being able to read parts of kernel or process memory.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
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.