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?
Guess what? As clever as Python and Java are, you can't effectively write an entire operating system in them, or a high-performance driver like a graphics card driver in them. You could try, but the result would be bloated and slow and effectively useless. So we have compiler languages like C/C++ that require you to actually be a competent programmer who can write code with proper error checking and error handling. I'm not saying that when you have an entire platoon of programmers all working on parts of the same project (vis-a-vis graphics card driver or OS) that there aren't going to be bugs that crop up, but slapping training wheels onto them isn't necessarily the solution to the problem either.
Note also another 'language' that would have this same problem, and for which there is no substitute for in the highest-performance applications: assembly language. Yes, Virginia, we still use assembly language in some places, so far as I know. Then you really have to know what you're doing.
Maybe the solution to this problem is to educate and train our programmers more thoroughly and carefully.
that they exist?
Shows how optimized your code is. Didnt even make first post.
He forgot to check clock()
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.
Bad developers can create security exploit in whatever is the language of their choice. Sure, with C/C++ you need to be more careful/experienced because they allow this particular type of bug, but in general where C is used it is possibly for a reason and you can't start talking about Java/Python etc (but maybe Rust?), which might be "safer" for a less good programmer.
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
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.
When did I first hear about "Buffer Overflow" which seems to be the bug in the author's bonnet? Oh yeah, about 35 years ago when I first started programming in C.
When I RFTA I was floored by the statement "When I first learned C++ in college, it was expected that sometimes your program would crash." - the author implies that it just happens but that's never been true and I would really be hesitant about hiring a programmer that accepted that his programs sometimes crash.
He doesn't like C/C++, good for him, but programming in Rust or Swift won't help the security problems out there now or in the future.
Mimetics Inc. Twitter
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.
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 ?).
I donâ(TM)t know why K&R rewrote Unix in C; it was a far more stable and secure operating system in the original JavaScript.
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.
Rewrite the everything in their favorite/cool 2018 language, instead of using using the newer features of C++ which are designed to mitigate these problems.
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?
I hate this argument and always have. By straight raw number comparison yes C/C++ are faster than most managed languages. Problem is most of the zealots that parrot that don't bother to tell you it is typically only a few milliseconds, often nanoseconds, faster on the general operations (hell there are instances where is is actually slower, though admittedly not as many, Dictionaries are a great example). Even in compound highly abstracted layers of code you might see a 5 to 10 ms difference on the operation if you can manage an apples to apples comparison (which typically you can't unless it is a very trivial operation because the coding style between C/C++ is vastly different than even C#) for a very compute intensive algorithm. Even then, the main reason the execution speed is better at all is because the C++ optimizer is significantly better and more mature than a lot of other languages. As we have seen more improvements to the compilers and optimizers of other languages the gap has closed (even Java and C# are surprisingly fast these days with their respective JITs).
Even theoretically, the performance hit you're referring to is merely a constant added onto the performance calculations because they are able to perform checks based on memory allocation of the heap in managed languages. Hell, it isn't even a great comparison because C/C++ has to perform scope checks to ensure certain objects are even supposed to be accessing the memory in question that is already allocated to that process. Access violations can still occur in those languages.
At the end of the day very few users can tell much of a difference between a managed and unmanaged language's program, but error rates are way higher in the unmanaged languages (some of it is general unfamiliarity and learning curve of the language, but even experienced developers will still have higher rates from what I've seen). For general use, I dislike C/C++ for writing programs because of the maintenance factor and how many "roll my own" algorithms that can be required, but I will completely agree it does still have solid and semi-common use cases (embedded systems are ruled by those languages and probably will be for a long time). For me, it comes down to using the right tool for the job, and for a lot of business solutions, a managed language is just more suited to doing the work.
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.
...Even in compound highly abstracted layers of code you might see a 5 to 10 ms difference ...
I hate to break it to you but 5 to 10 ms is a huge amount of time when you are dealing with big data. Try sorting a 1 billion row table when each row takes a whole millisecond to get in order. That's a million seconds! For the math challenged out there it is nearly 300 hours!