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?
Unless you just woke up from a coma from 1993, you should have known about unsafe memory practices in 2018.
Switching to a new language like Rust might help this problem, but it ignores the enormous cost of re-writing software, library compatibility, retraining, etc. The security of the language is just one aspect of selecting the language, not the only one.
And it's not as if you get a magic security shield just because you chose a memory safe language. There's plenty of other security problems that are either language agnostic, or made worse by language choice. Memory safety is just one aspect of security.
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
I achieved this overflow with FORTRAN on a DEC PDP 11/70 back around 1974. My whole college ran on the one machine, and occasionally the overflow would feed me cool stuff like chunks of grade reports.
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
Lets program the the pic16 in the coffee maker with python.
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.
Apparently this article is long enough to actually address all the points everyone here is bringing up as a counter-argument.
Of course its also pushing Rust, which nearly all these articles do.
While I personally have no real opinions or experience with Rust, I don't yet see it being used very much. It mostly seems to be used for novel standalone utilities, which are not parts of larger projects.
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.
If everyone did everything perfectly all the time there would never be any problems.
The solution to everything.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
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 didn't even finish reading the summary, but my guess is this is some sort of Rust millennial who things memory safety doesn't exist in C/C++. Sorry kids: Rust and your boutique languages will not catch on.
And what does the poster think those memory safe languages are written in? I can see the argument that C/C++ are overused, and that the jobs people throw them at could probably be done by safer languages without much performance hit.. but then again, you could just use safe libraries within C/C++ and get the same result.
But at the end of the day, people have been aware of buffer overflow problems for what, 60 years now? And there have been solutions for them nearly as long. But when cycles are dollars, those solutions are always expensive, which is why unsafe C/C++ code is still so common.
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 ?).
What's next? An article on dangers of failing brakes in cars?
Um, I've never heard someone way that it was expected a program can crash because it was written in C/C++. Any program can crash, no matter what language you write it in. How does Rust keep programs from "crashing" (a.k.a stopping abnormally) if there is a non-recoverable error in them? You can catch exceptions probably, but you can do that in C++ as well. The reason your Rust programs don't crash is because they are typically trivial demo programs. There is nothing magical about Rust. You can reduce buffer overflow errors with languages like that, but you can also do that if you use semi-modern C++.
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.
If you are used to a language with seat belts, like java, and you still routinely get ejected, maybe C isn't for you.
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?
There is nothing in the Constitution against tracking your car's movements on a public road either.
But I'm not talking about rights per se, but about whether or not such surveillance make sense at all. That is, whether the costs (the time and money, leaving the morals aside) of it justify the benefits.
In Soviet Washington the swamp drains you.
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.
I think I understand the value that C++ brings to bringing large groups of people to work on a large project, but a lot of dirt piles up in the little corners.
https://www.youtube.com/c/BrendaEM
Personally I think if you were trying to translate an already existing project from C / C++ across to something more memory safe, DLang with memory management might be a better option.
With Rust the fundemental design philosophy is different in terms of features (good or bad) such as lack of object inheritance.
This means it's not just a straight forward translation, with Rust you'd need to spend a lot of time re-orientating how the code is arranged.
This is less of an impact for new projects but has a bigger impact on existing code bases.
A language that's more similar to the prior code base / features but has better memory management would probably be a better option such as DLang (or maybe even C#).
During the good old days before the internet, languages were designed typically in isolation inside companies, without any form of input from a global perspective. This is how we ended up with C / C++ in it's current form.
Higher level languages such as basic's or Java would have performance hits due to not being as close to the bare metal but would be easier to write. So typically you'd use different languages for a given purpose. C for kernel and drivers, C++ for desktops, Higher languages like Java for desktop apps.
With the internet and github and more time we now have better compilers, so if you google "C# vs C++" for example you'll see a lot of discussion on that topic. With better compilers this narrows the gap between the higher and lower languages.
The main advantage though for the higher level ones such as statically typed managed languages is to pick up on bugs before the code is even compiled.
So in this day and age it's a much closer trade off depending on what task your actually trying to do.
My own bias is C# for Higher level stuff like backends of websites, and DLang for lower level stuff.
Although micropython is also a good option for MCU's.
Rust I feel is a little too restrictive on it's feature set
Most of the time, any decent non-C natively compiled language is better than C, except for a small set of cases that have a small enough to be humanly manageable codebase that cannot absolutely afford to make any performance compromises.
It isn't that C does not have a place. It does. It just should not be used as the default systems language.
If you are not willing to place a lot of resources into verifying C/C++ code, the marginal performance penalty imposed by safer, yet still natively compiled languages is more than worth it. No, I am not saying that other languages are error proof, but they do eliminate entire classes of errors quite common in C/C++.
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.
Perl 6 is better. In Perl 6 even grammars are great and easy to use.
"First they came for the slanderers and i said nothing."
The problem is not C or C++. The problem is incompetent developers. They manage just fine to make things in other languages just as insecure.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
... and C++ is Assembler 3.0. Ignore this and you'll always write software that introduces these bad heavy impact bugs at low level. Get off your high horse however and pull that stick out of your ass and stop banking on "we've been doing C for 30 years now and I'm not having some young whippersnapper tell me what's what" and you'll actually learn some really useful stuff. Like Ocaml, Rust or Eiffel and be amazed at how productive you can be and how sound the quality of your output is based on the PL you're using.
To quote demotivator on this: "Tradition - just because you've always done it this way doesn't mean it's not incredibly stupid."
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
...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!
In C++ land, every programmer is a bad programmer.
We are not talking about a college student who learnt C++ last year, who has yet to learn good practices and common sense.
Nearly every C++ bug that makes the news was from high profile projects, written by well-paid and highly experienced programmers. And yet, these blunders are common place.
At some point, one has to conclude that the tool isn't designed according to natural human limitations of otherwise intelligent people.
C language is well known and has no inherent problem. it's behaviour is well documented and you get what you program with it... nothing less, nothing more.
If you use something like while(*a++=*b++); it's at your own risk... The only assurance that C gives you is that the assembler code that'll be generated will exactly do what you asked.
Problem is manyfold :
1) many people don't care about low level anymore
We have a plethora of "high level languages" which hide what is done beneath. Too many programmers don't know what's happening under the hood (well, with some langages, it's nearly impossible due to some level of secrecy about the inner working).
Thinking about the potential consequences of a line of code is becoming quite difficult...
2) CS teaching is not enough centered about secure practice
This is linked to a problem that affect the whole teaching system : teachers usually don't use their knowledge in "real" situation. Far too many teachers ended up as teacher after university without ever working in their study domain. They only have an academic knowledge and as result, they often forget about the security good-practice and such (disclaimer : I'm CS-teacher... but I also worked as programmer before... and I see the above problem with many of my coworkers, not only CS-Teachers)
3) Management usually push for quick and dirty coding ... everything that is not visible... The thing may even be aggravated when the management is computer illiterate and unable to understand the issues...
Too many management forget about the security aspect : the program must be ready as fast as possible, putting aside optimisation, security checking and other,
The management has usually zero-liability for problem arising from program they supervised... so they have no incentive for such a long term investment... If the program is out quickly, they'll most likely get bigger bonuses and that's their only focus...
4) High level languages hide incompetence ...) than using a lower level one (ASM, C, C++, ...) No need to care about memory allocation, bound checking, ... and many errors will trigger an exception and can be hidden.
It's way easier to make a runnable program using high level "script" languages (PHP, Python, C#,
This won't make the program any better... It'll just hide the mistakes... And having something running will too often be enough for the management who don't care to have a look under the hook. I saw my share of awful code done by an incompetent coworker... But with some small-talk and such he used to be able to make it "pass"... he attributed the slowlessness to external factors and until I arrived and had a look at his code, there was nobody who could point the issues...
And I could go on...
Basically, if the program is broken, it's not the langage's fault but the programmer's fault (and often the manager's because he didn't request an high security level). The problem was minor for a long time, because the computers were not connected 24/7... but now, such an error may have devastating results (remind the Nimda worm which exploited an IIS buffer overflow... and infected all exposed IIS in less than 24 hours ?)
Better training about securing the code during CS school (and after) and making managers liable for big security problems could help to limit the problem...