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?
What TFA is arguing for is a layer of verifications performed by the program's execution environment, checking its every move.
The checks aren't free — they make everything a little slower and/or consuming more resources (such as RAM). Whether that slow-down is worth the increased safety may be subject to debate...
But the parallels with human lives are inescapable. The checks argued for are no different from the much-denounced police practices, such as "stop-and-frisk", tracking citizens' identifications, and movements — and the arguments for and against them are much the same...
In Soviet Washington the swamp drains you.
"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.
Heartbleed was a buffer overflow in an already allocated pool. Memory safety wouldn't have mitigated it.
Memory safe languages have some advantages, but are not immune to bugs as a result. They are also less efficient.
In my experience, they also have a tendency to leak memory, when the algorithm is complicated enough, or that other manual resource allocation had a bug in it.
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.
Subject says it all.
If you pine for a "safe" language it's likely because you know you're outclassed without your training wheels.
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.
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.
... of C/C++, that creates an outsized number of issues. An even larger part is due to poor programming practices by the developers who write the insecure code.
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.
/sarcasm Because PHP, Javascript, etc. are more "secure" **snicker**
See, I can play this game too.
You can write crappy code in ANY language. And while some languages make it far easier the problem isn't the language but the bigger problem is between the ears.
It takes time & money to do it the right way.
Engineering is all about trade offs -- programming is no different.
There is never time to do it right, but there is always time to do it over.
Comment removed based on user account deletion
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.
But somebody mandated seat belts. And airbags. And crumple zones. And lights. And licences plates. And inspections. And I hope you get the picture.
So you want federally mandated software development standards that, because they don't know a damn thing, would require 100% unit and functional test coverage along with passing a State approved linter and vulnerability scanner?
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 wrote C for a good number of years. Within a year or two of programming in it professionally, I was using string functions that limit the length, like strncpy, and 95 times out of 100, I used for/next loops, NOT WHILE (forever) loops.
If you're not doing that, you've got a lot to learn.
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.
To me, "just happens" carries the connotation of "for no reason", and _that_ has never been true. There's a reason. Usually programmer error, sometimes hardware error, rarely random glitch. But there's always a reason and the vast majority of the time it's human error.
You're quite correct that crashes are to be expected, especially in a learning environment. And that's how I read the article author's statement too. But I can see where mykepredko could read it otherwise and disagree with that reading.
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.
There's a million libraries that enforce array boundaries, if you want it done for you, then feel free to use one of them. But for those of us who would rather not run code that is essentially
for(i = 0; i < array_len; i++) //do stuff //throw exception
{
if (i > 0 && i < array_len)
{
}
else
}
we'd rather not. I don't need double array bounds checks. I know how to code.
If you are used to a language with seat belts, like java, and you still routinely get ejected, maybe C isn't for you.
Verified C, the CERT C Secure Programming standards, the JSF coding standards, Power of Ten, the Hoard malloc replacement, Valgrind, LLVM's static checker, Z3, contract programming - all partial solutions that show some developers care.
Linux could use a mix of these to achieve higher levels of reliability without impacting performance or capability.
So could most software.
And therein lies the problem. Some developers don't care, or are opposed to people caring. The numbers don't matter, one person can block a thousand. Change requires consensus.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Heatbleed wasn't even a buffer overflow. It was a buffer over read.
I think you mean create C for non-idiots?
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 think suutar said it best by saying if a program crashes, there is always a reason for it; maybe it's your code, maybe it's a bad API, maybe the processor caught on fire. There's always a reason for it.
When you are learning to program, you should be learning how to write code that doesn't crash on its own - the implication in the article was that C++ programs crash, that's life. There are too many programmers out there that consider random crashes to be not their fault and don't bother spending any time understanding the problem - because, chances are, it's their fault.
It's not "devilishly hard" to keep C/C++ programs from crashing. The big thing that it takes is accepting that if a program crashes, it's your fault as the programmer until you can prove otherwise.
Mimetics Inc. Twitter
I think the internet has a lot more problem with JavaScript than it does with C\C++
http://progressquest.com/spoltog.php?name=Son+Of+Son+Of+DarkRookie
Nothing is stopping a rogue program from lying about its buffer size it supplies to an API, even inside the ultimate runtime type safety of some languages.
Anyway, the Internet world, AKA the desktop world in a previous incarnation, could use some catching up to the high-liability embedded world, where buffer size checks are required. It still won't stop rogue programs from lying, but should catch internal errors and mistakes.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Until you arrive in callback hell, that is.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element?
If you develop a program expecting to deal with a list of 10 numbers and you allow scenarios where the 11th element could be requested, you would have done a horrible job in any programming language. Period.
Let's now assume that you made the aforementioned mistake (your fault, something perfectly avoidable in any scenario by a reasonably competent programmer) and that an error happens. Under the most logical conditions (99.999999 etc. % of cases), the only difference between these two scenarios is that you would get an error message with a slightly specific, but still quite generic label (not being too useful anyway, but indicating that the given environment caught the error) or a meaningless message referring to some problem with the memory. It might be possible (although tremendously improbable) that the non-managed language would access another valid memory location and, consequently, no immediate error would be triggered. But, even in that case, it would be just one step within the millions of them forming even the simplest piece of software. For example, imagine that this extremely-lucky event occurred in step number 1234th, it would move to step 1235th where that value would have to make sense (otherwise, it would crash there) and then to step 1236th, etc. And so on until the end of the program which, in the tremendously improbable scenario of reaching, would output a random result.
In summary, number of malware attacks provoked by this kind of memory virtually-impossible lottery? Not too many (zero?). Complete responsibility of 100% of all the bugs/malware/vulnerabilities: the given developer (directly or via ridiculous conditions, wrong previous code or similar). Is improving the working conditions something bad? Certainly not. Are managed-memory/newer languages absolutely superior? Certainly not. They have their advantages and drawbacks, are (dis)liked by different kind of people/companies. There is actually lots of hypocrisy on this front as far as escaping from the managed-memory constraints does accelerate things quite a lot and many newer/more popular languages do allow these kind of things (e.g., C# or Go). There is certainly nothing bad with C or C++ or similar for those feeling comfortable with them and doing a proper work. There is something very bad with (probably programming clueless) people thinking that "training wheels" are required for something as demanding and requiring as highly skilled workers as programming. The higher the freedom, the better the final product. The higher the knowledge/experience/awareness, the better the final product. The more clueless the decisions makers, the worse everything.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
The real danger is having 7 years of experience in C/C++ and then trying to land a dev job.
... skill with pointers ... Linux/Windows ... IDE/GDB debugging ... doesn't matter.
Framework knowledge
Not the languages!
You insensitive programming clod!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
And that's basically the net problem you're looking at. Whether it's C++ vs. Java or whether it's Meltdown and Spectre vs. speculative execution.
Yes, you can do everything you do in C++ in Java. Just more slowly. Why? Because of exactly the safety belts that you ask for. Can they be implemented in C++? Sure. For about the same cost. So is Java better because it already has them while you have to take care of them yourself in C++? Depends, if you need them, yes. If you don't need them and all you care about is speed, no.
The question is what do you want? Security? Then you'll have to sacrifice performance. That's not negotiable.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Yes, that's another thing. But if you only have code monkeys that were taught how to "code" in a 8 week seminar with zero idea of the basics of computer science, who consider the heap the pile of clothing in their room and the O-notation something that grades the quality of porn movies, you might actually be better off with languages where you can't fuck up too much. They won't benefit from the speed advantages a language closer to the processor may grant them while they will benefit from the handrails and training wheels available in the more self-sealing languages.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
But ... but ... everyone should be a programmer! They should teach it in schools so EVERYONE learns how to write code!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"and Developers Don't Want to Deal With It." They'd rather deflect the blame to the programmers, even when the best programmers still make these mistakes. The Linux kernel has had its fair share of buffer overruns and "out of bounds" security issues and it is written by good programmers. It's even read and reviewed by good programmers. But, the bugs are still there. The problem is inherent to the language because it is a machine-level problem and C gives you access to the machine. The way forward is not to throw out the language, but to recognize the cause of the problem and fix it. That's what we do when we find a bug. So the language needs to be updated, at least as an optional feature, so that it is capable of detecting these kinds of problems. This is not the kind of problem where you can just say, "managers need to hire better programmers." It's been 20+ years and that hasn't worked! It's way past time to fix the problem. You could say developers are negligent because they know the problem exists and refuse to do anything because they just want to redirect the blame away from their favorite language. This is not the fault of businesses because they've already recognized the need for languages that don't have this problem (Java, Python, PHP, Perl). It is the fault mostly open source developers who insist on using C without fixing the problem.
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.
Ha Ha! As a Java programmer, I approve this message. It's a little exaggerated but nonetheless true. You get safety but you have to pay for it with RAM.
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
Can you believe they still make chain saws? Think of all the children who will be maimed!
Why can't everyone use plastic knives which are of course so much cheaper and safer? You don't need to be a lumberjack to know this.
We need to pass laws to regulate these irresponsible people.
Greed is the root of all evil.
You do realize that you could pretty much replace "C/C++" with any language that has that level of access, usability, and flexibility, right?
You do realize rather few use cases actually need that level of access and flexibility? A LOT of code is written in C/C++ that definitely does not need to be and probably should not be. Limitations are not always a bad thing and its rather rare that a programmer is going to run into a problem that only C/C++ can solve.
The problem isn't that C/C++ don't have good uses. The problem is that they are used WAY too often for problems that don't truly require what they offer. When a decision is made to use C/C++ there are certain categories of bugs like the ones here that are absolutely, positively, going to happen some percent of the time. The solution is to use a different and safer programming tool whenever possible. Just because you can do it with C doesn't mean you automatically should.
The problem with this finger pointing at programmers, managers and companies and the other rationalizations made in defense of C and C++ is that the opposition has an endless supply of ammunition. The clock is ticking on the next monster headline making flaw that shakes "the Internet," and the odds are great that it will be yet another memory safety exploit. And this process isn't going to stop. On November 15, 2019 a new story may appear that chronicles that latest bunch of memory safety exploits attributable to flaws in C/C++ code that appear between now and then.
At some point the Powers That Be will get tired of suffering the consequences of these flaws and seek solutions. I can't predict exactly what they will do but I can predict what they won't; they will not adopt the vaunted wisdom of the denizens of Slashdot and limit software development to that tiny — and probably mythical — cohort of programmers that write flawless code.
Maw! Fire up the karma burner!
What exactly is it Ada can't do but C/C++ can?
"Be better than the other" if the only metrics are producing small, efficient binaries that run on bare metal.
If it could, then it would eliminate some of the features that make Ada different than C - it would just be another procedural language.
Sometimes Ada is a better tool than C, sometimes C is a better tool than Ada. Sometimes neither is better than the other. Same goes for any other pair of languages.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Attacks target the easiest thing first.
By default C has no bounds checking, and it's an easy error to make, so there are a lot of those kinds of errors.
Bounds checking could be added, or you could use a language that has bounds checking, but that just means the attacker will go after the next most vulnerable part of the system.
If Heartbleed was impossible we'd just have more attacks like shellshock.
If you want real security, change the OS so programs can't access anything outside their own memory space - like write to disk, or read files outside of their current directory, or open network sockets, etc.
If an app absolutely has to access something sensitive, make it easy to access it through a safe interface and really hard to do it directly.
In fact, make it so I can optionally lie to to an app if it asks for something sensitive like location data.
if (i > 0 && i array_len) Ummm - is it really your intention to throw on the first iteration of the loop?
When I first learned C++ in college, it was expected that sometimes your program would crash.
When I first learned C++
first learned
I think you glossed over the important part of the sentence. It was expected when first learning C++ that programs would crash. Not "for no reason" but for "having just begun learning" about it. It's similar to finding out that it's expected to fall off a bicycle when starting to learn to ride a bicycle. It's from lack of experience. Sure it's possible to get it right the first try, yes it's more likely with training wheels. C/C++ is learning to ride without training wheels.
Inheritance is the sincerest form of nepotism.
I'm not so sure that's the right answer. Perhaps if the standards would add various built-in bounds checking, that might be a better answer. Naturally, it would need a directive to override it for some situations and a compiler option to turn it off for legacy code.
If you ask for the 11th number, your program, if written correctly, will check the input and then return you either nothing or an error, because you don't return what you don't have. Blaming "memory unsafe" languages instead of the developers whom use them, is like blaming the car for getting into an accident and not the driver.
So you want federally mandated software development standards that, because they don't know a damn thing, would require 100% unit and functional test coverage along with passing a State approved linter and vulnerability scanner?
Well, in some cases... those already exist.
Quo usque tandem abutere, Nimbus, patientia nostra?
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 problems with C++ aren't with C++ per se, but rather with C developers who switch to C++ and continue using C idioms (e.g. an array is int * instead of std::vector)
Python also has a crack dependency on tabs versus spaces, despite tabs being equivalently set at every 8 spaces as God and DEC (but I repeat myself) intended.
Most compilers for all those languages (including C) let you turn bounds checking on and off.
People debug with bounds checking, then turn it off for speed. Java is an obvious exception, it's always slow.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Except strncpy leaves plenty of room to shoot yourself in the foot as well, just like almost everything in the C/C++ world. It for example doesn't guarantee NUL termination of the copied result.
It's not due to C/C++, also memory'safe' languages have been problematic. I mean, how many problem have we had with Java or javascript.. Most malware attack vulnerabilities in other software..
I'm coming at it more from a Swift perspective. I'm not talking so much about exceptions (though that is one area where a program can crash) but more memory errors in general. If you are using Swift and not bridging to C, you will not have memory overruns.
I am also speaking after decades of C, C++, Objective-C, and now years of Swift experience. Swift reduces a a lot of areas where you would find memory related bugs in traditional C or C++ applications... I am not talking about trivial applications, I am talking about production applications that have tens or hundreds of thousands of lines of code (yes, even in Swift there are programs of that size now).
It really is well past time the industry moves past C++, whatever that takes.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Way back Intel took some architectural advice from the old Burroughs mainframes, and put into the 286 chip 4096 special segments, where each segment had its own base and length limits. Smart compilers could be written to allocate a separate segment for each struct or array, as could malloc(), automatically preventing buffer overflows with only minor hardware overhead. Unfortunately the protect mode on the 286 was hard to get into and out of, and 4096 segments was just too few for comfort, and yo'd have to rewrite DOS and Windows a fair amount to work in that mode, and it didn't integrate well with existing real-mode code, so it never really caught on. So we abandoned safety 30+ years ago and never looked back.
That or a RUST salesman.
C/C++ is not a language
C/C++ is one.
No, it is two different languages. And it helps to be aware of that!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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."
Or, you know, you could just learn to do proper programming.
Back in university, I taught my students to do proper input validation and buffer checks in C. There was a certain amount of frustration as I sent them back again and again, but they got it.
C is a tool, and like a chainsaw, you can hurt yourself or others badly with it if you don't know how to use it. But sometimes a chainsaw is exactly what you need. And for performance, a well-written C program still beats the shit out of all other high-level languages.
Assorted stuff I do sometimes: Lemuria.org
Out-of-bounds accesses are undefined behaviour so a C compilers can already add run-time bounds checking. To some degree this is already possible, e.g. use gcc -fsanitize=bounds
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.
So if the programmer has a function shoot_self_in_foot(char *buffer), sometimes passed pointers to arrays of various sizes, maybe sometimes to buffers allocated on the heap, where is the boundary that should be checked?
A static analysis tool (which an incompetent programmer anyways won't be using) could at best warn you that certain usages are suspect. The compiler can't generate runtime code to check since all it has is a raw pointer with no known limit. The C ABI doesn't even permit passing a pointer limit even if one were known.
The real solution is only to use unsafe languages where you have to. Most user land programs shouldn't be using things like raw pointers.
It's all very well to say the programmer should be careful or should use this or that verification tool/option, but at the end of the day people make mistakes (especially given the modern race to the bottom trend of hiring cheap incompetent programmers), and once you've chosen to use a language where shooting yourself in the foot is an option, you can guarantee that it will happen.
Incidently I happen to think C++ (not C) is a fine language for writing applications in, but too bad it relies on programmer constraint to use safe features and avoid legacy C ones.
shit coders => shit software, regardless of circumstances. You can easily write insecure web-applications in any language you can write web-applications in.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
There is nothing wrong with C/C++ and it's rather powerful implementations of memory management. The only thing wrong here is sloppy programmers who seem incompetent enough to forget to add simple bounds checking to their code.
Quit blaming the tools.
Yes, and that's a step in the right direction. Next step is to make it a standard, complete with pragmas or other directive to disable it on a single access. Then, once it is well deployed and everyone is well warned, make that the default with a compiler option needed to turn it off.
Javascript is... Entire Internet is a mess because of that crap. Who thought it was a good idea to let javascript get to the cpu ?
... 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!
For all but the most unusual embed projections, and kernel level code finding memory leaks and related problems in C/C++ is as simple as running an STA tool. Admittedly good ones are expensive but static analysis can find most all of those problems.
This issue people are not doing it.
However while the occasional drive by like Eternalblue results from memory unsafe languages (again system level stuff most application layer programs are not dealing with) it is rare. The vast majority of software problems are application logic issues. Take the libssh author by pass. That isn't a C/C++ problem its a problem of the authors implementing the authentication logic badly. Send commands in an unexpected order the software does unexpected things. Its probably more dangerous to reimplement widely used well tested things like libssh because if a bug like that was hiding for years; who thinks someone can monkey up a java/C#/rust/... replacement and not introduce serious new unknown flaws? I for one don't
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Buffer overruns would not be as dangerous as they are, if stacks would not grow downwards, but upwards. Only because they grow downwards, they can be exploited to overwrite the return address on the stack in such a way that a system call is made.
then use lua, tho you can't write an OS in it like c++
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.
As long as C++ compilers compile C code, it is a perfectly valid contraction.
There may be 2 different languages there for very different purposes, but people do often use them together and hence the contraction.
The contraction exists for the unique circumstance of C++.
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...
I think most compilers will move the bounds check out of the loop, at least if some level of optimization is requested. However the main problem for C-style languages isn't arrays but pointers. It seems to be harder for the compiler to check pointer references.
My father taught me that bad carpenters blame their tools.
He should have taught you that good carpenters don't use bad tools.
Or the software was written before this was available. People forget a lot of this software is very very old.
If you are using char * in 2018 you don't know what you are doing. That has nothing to do with C++. You can write unsafe programs in managed languages as well. It is just no one really uses things like Rust, so people haven't experienced it yet.
Right. So use managed pointers and bounds checked accessor functions. That has nothing to do with C++. If you don't program safely you won't have safe programs, no matter what language you use.
These languages are used in places where performance is important. The key feature of most languages with strict array and memory safety is that they're much slower and larger than C/C++. So the solution here is to abandon C and go straight to assembler?
The biggest problem I see with C/C++ is that the developers are aging out. Newer programmers may be more familiar with computer security issues, but they're also avoiding lower level languages.
Also note that there are a vast number of security issues in high level languages as well. Pointing to C/C++ as the problem is very short sighted. I think much more malware gets distributed from web sites using Javascript or other high level languages than from applications or operating system kernels.
I never said everyone should use Swift. I was saying what I knew to be true BECAUSE OF my experience writing a LOT of C++, a LOT OF C, and a LOT OF Swift. Rust is not that dissimilar, I've juts not had as much experience writing real code with it.
I appear to be the only one left that has professional experience in a wide variety of languages...
Rust would be fine. Maybe Go. Whatever, because *I* am a professional I could care less which way the market blows, I will be fine. But I can tell you with certainly that your adherence to stupidly old languages like C++ is a bad idea and it's a bad idea for all the poor non-technical bastards that suffers every day because of your poor choices in maintaining a technical status quo that is morally unforgivable.
I'll let you have the last response, since I see no need to further debate a point that you are so far in the wrong on.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Most programmers today, sadly, have only ever programmed in a PC, and probably only ever in Windows. To them, worrying about being fast or tiny is unimportant, and they don't even understand the concept of portability. Many of them today don't even really program and instead just tie together pre-built components.
It's more than just a few milliseconds or nanoseconds unless you're on a PC (the equivalent of last decade's supercomputer). When you're on a system with less then 1MB of memory and an instruction takes 1us, you're usually not going to be using Java or Python.
(though there are exceptions, I know one chip that uses Java applets on top of an 8051 base)
It's a good tool, but expensive for home use, and somewhat complex to set up at work.
Good training helps too - as in, just because you can manage all your array operations with a pointer doesn't mean you should; and if you're using buffers you need to put in overflow and underflow checks. Generally it's not hard because so many C programmers have done this over and over that they know how to do it. The snag is from the person who learned how to program by using libraries and has never actually written low level code before.
"predict exactly what they will do"
Lower wages and import more H1-Bs. That will fix it!
In real experiments I have done over the years. Take a real piece of C code and rewrite it in a decent language.
One reason is that Java and .Net do aggressive inline expansion of called methods, and then optimize the hell of what is produced. C programmers tend not to put all their methods in header files to enable this. C programmers also like opaque data types so that libraries can be updated without recompilation.
C++ programmers tend to use the STL to avoid memory issues. This means every time you assign a string you are copying a complex structure rather than just a pointer.
But the big one is that C/++ programs require 64 bit pointers to access more than 4 gig of memory. Java can access 32gig of memory with 32 bit pointers (relying on alignment). There are not many practical applications that require more than 32 gig. Doubling the pointer size unnecessarily is a huge overhead in memory consumption, cache hits etc. The need for 64bit is almost entirely driven by the primitive C programming language.
Modern (1980s) generational garbage collection is impossible in C. But it is faster than reference counting and avoids fragmentation. (It does require discipline to not create too much garbage in the first place.)
Java and .Net also use UTF-16. Which is idiocy, but is not fundamental.
And .Net has an unsafe mode if you are game.
I sense a shitty developer.
And you've summed up the problem in one. Shit developers can write equally shit code in any language, no matter what it is. If everyone were to switch to MPL (My Pet Language) instead of C, we'd still be seeing endless security bugs, only they'd be bugs in MPL, not in C. In this case as soon as I saw the first line of the article:
Alex is a software security engineer at Mozilla
I knew what was going to happen, as soon as he finished bashing C it'd turn into a sales pitch for Rust, his MPL. And, sure enough, a few paragraphs down, hey, look at MPL, Rust will solve all our problems, no need to think about educating the people writing the code to actually write secure/safe code. Yeah, and relying on abstinence will solve teenage pregnancy problems, we don't need to bother with educating people there either.
It essentially solved all the problems. People who think JavaScript automatically solves memory leak issues are ignorant and need to be educated because their code inevitably sucks.
"First they came for the slanderers and i said nothing."
It essentially solved all the problems. People who think JavaScript automatically solves memory leak issues are ignorant and need to be educated because their code inevitably sucks.
You keep blathering on about memory leaks when the topic is security and invalid memory access.
Blaming C/C++ for that is like blaming water for drowning, and saying we'd be safer if we replaced all water with Gatorade, since nobody's ever drown in Gatorade.
I'm not blaming C/C++. Those languages are what they are and there is a lot of good that comes with the problems. I'm blaming programmers for using those languages for use cases that don't really require them or using them when they don't fully understand what they are doing. If C/C++ are truly the best/only way to properly solve a problem then it makes perfect sense to use them. But like with many things their biggest asset is also their biggest liability. Having total flexibility and minimal/no safety net means that the problems we are discussing here become inevitable if used inappropriately. You are quite right that the attack surface is huge so it makes sense to mitigate that problem by using tools with a smaller attack surface whenever feasible.
Sure you can have problems in other languages too. Nobody should claim otherwise. But as a general principle I would argue that as a principle one should use the "safest" language for the use case possible. If that happens to be C/C++ then so be it but it seems obvious that programmers are using C/C++ in many cases because that's the language they know best and we have an "have a hammer so every problem becomes a nail" situation. I think in many cases we have a lot of programmers who are ill equipped to handle the amount of flexibility and power C/C++ grant. Think of it like handing the keys to a Corvette to a new driver - they just haven't learned how to properly handle that sort of power yet and some never really will.
Pretty well the first criticism of C++ was that it lacked automatic garbage collection and proper array objects (or any objects at all, really). How long ago was that?
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
So you want federally mandated software development standards that, because they don't know a damn thing, would require 100% unit and functional test coverage along with passing a State approved linter and vulnerability scanner?
Well, in some cases... those already exist.
Ahhh yes. DISAster, I remember working with them well. In 2008 I spent 6 months fighting with them to get approval to use SSH host key authentication for host automation rather than the already approved RLOGIN method. They are only "slightly" behind the times...
Yes they do have some very useful recommendations, but working in an environment where those recommendations actually have weight proves my point. They can at times be a major hindrance and getting changes or exceptions made is a nightmare task. This can range from having to rewrite already existing tools/packages (and all the associated bugs and support headaches) due to complications bringing in 3rd party (OSS) items or them simply being behind (sometimes by a decade or more) the power curve of modern standards.
My argument isn't that we don't need any regulation, just that regulation is not it is all it's cracked up to be.
Would you settle for ALGOL?
Burroughs did that with the B5000 series, several decades ago.
If you can't keep track of your memory, how are you going to write secure code?
Security? Invalid memory accesses are too hard to exploit these days with things like ASLR and other kernel protections. They can still be exploited but it's not nearly as easy as it used to be. If you want to use C and still be safe, you can create an API for dealing with memory chunks.
The most common types of vulnerabilities these days are things like SQL (or noSQL) injection, and XSS. Invalid memory access doesn't even make the top 10, but of course you already know that.
"First they came for the slanderers and i said nothing."
If you can't keep track of your memory, how are you going to write secure code?
If you don't eat your meat, how can you have any pudding?
Security? Invalid memory accesses are too hard to exploit these days with things like ASLR and other kernel protections. They can still be exploited but it's not nearly as easy as it used to be.
You just contradicted yourself.
If you want to use C and still be safe, you can create an API for dealing with memory chunks.
Or you can spare yourself a lot of pain and just move to a language where that happens by default.
The most common types of vulnerabilities these days are things like SQL (or noSQL) injection, and XSS. Invalid memory access doesn't even make the top 10, but of course you already know that.
Oh, really? Invalid memory issues still make up around 20%, and it's the single-highest category of security vulnerability, even more than XSS, and more than double SQL injection.
Top 10
"First they came for the slanderers and i said nothing."
That's "The Ten Most Web Application Security Risks". Web applications. Most web applications are not written in C/C++.
Human teams have limited mental capacity and time, even capable teams do not like unnecessary cognitive load or TIME getting in the way; therefore, libraries are linked and C++ OOP is used.
You can text and you can drive but you can't do both at 100% at the same time.
The backlash is from competent people who are defensive about needing the crutches other languages force upon you. They may NOT need them; however, they are choosing to distract themselves like a texting driver. Very few deeply technical situations require attention at this level of detail. A hybrid compromise is why C++ became so huge... but it needs to address this problem by default before it finally adds the kitchen sink. Place too many complex issues on developers and they will make errors beneath their skill level (which is likely higher than non-C programmers.)
Democracy Now! - uncensored, anti-establishment news
Oh I agree there entirely. Like I said in my post, C/C++ still rule the embedded systems with an iron fist because those small differences are amplified 1000% when available resources are so restricted. I've seen it in practice far too many times to disagree and am much too familiar with the theoretical side to think otherwise. As I said, right tool for the job comes first. I may dislike the languages but that doesn't mean I won't use them where appropriate.
All web applications are partly written in C. Your link was deficient because it didn't include web applications, which is where most of the code written today actually is. Furthermore, you haven't actually tried to exploit those. A single buffer overflow can't be exploited on a modern system, it takes more vulnerabilities than that.
"First they came for the slanderers and i said nothing."
ll web applications are partly written in C.
The vast majority of web applications are not written in C. The operating system and other underlying software is, but that's not what the OWASP paper was talking about.
Your link was deficient because it didn't include web applications, which is where most of the code written today actually is.
My link had columns for XSS and SQL injection. I explicitly mentioned them in my reply. Aren't you tired of being so wrong about obvious things?
A single buffer overflow can't be exploited on a modern system, it takes more vulnerabilities than that.
It depends on the vulnerability. Also, at the minimum, they often result in a crash. But the fact is that buffer overflows are resulting in exploits.