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.
Fully optimized with modern c++ to gaurentee the fristiest of psots!
Use a better lint tool
It's 500x slower and uses 1000x more memory than C++, but it's super safe!
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?
Someday we'll get rid of C and replace it with JS and boot to browser instead of desktop! over my cold dead motherboards!
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.
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.
Itâ(TM)s possible (easy?) to write crap code in most languages. The problem is with the workmen not the tools.
"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.
That does it! We need to do away with all of this memory privelege C++ has, it's very problematic. Clearly C++ developers have a problem and they do not want to face it. It's up to us latte drinking node.js worshipping pink haired flufferkin to sort this out! Quick my easily offended bretheren, to the waahg-mobile!
We all know what a buffer overflow is, this pap doesn't belong on slashdot.
I know what some of you are thinking: "chop off your dicks and use Rust already you stupid nazis"
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.
But somebody mandated seat belts. And airbags. And crumple zones. And lights. And licences plates. And inspections. And I hope you get the picture.
"memory safe" + shit coders = shit software....
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
COBOL, FORTRAN VB, Java, Pascal even, they all return an index error, "out of range" or something similar.
WTF with C?
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.
Please stop using this stupid fucking contraction.
Even for apple hater msmash. Silly girl.
Comment removed based on user account deletion
The performance hit is just the cost of doing business. Even the best programmers make mistakes, and the consequences are too great.
COE
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.
All the C developers below seem awfully sensitive about this.
Is it such a burden for the next version of C to enforce array boundaries?
One would almost think that the C community actually prefers it this way.
Is unskilled, reckless and lazy programmers.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element?
Not sure about Python or Java, but in C++, it'll do what it was programmed to do. Throwing an out-of-range error might be a good idea, or you might want the array to increase in size, and return a default value, or a specific value, or you might return the first element, or the last. It's a problem-domain, not a language-domain issue.
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?
The author is right. You should use Android instead because most Android programs use the safe Java language and Android has virtually no security holes or any problems with privacy.
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.
If this jackass is really a security engineer at Mozilla, I'm going back to Chrome.
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 ?).
COBOL, FORTRAN VB, Java, Pascal even, they all return an index error, "out of range" or something similar.
WTF with C?
How do they do that? How does the program know that you requested an index that was out of range? The answer is that the programs add extra code into the executable that checks every memory request and verifies that it is a request for in-range memory before it allows the program to read it. (There's actually significantly more to it than that, since there's a lot of additional code required for memory management above and beyond just checking indexes.) That's great from a security perspective but it absolutely sucks from a performance perspective. It depends a great deal on the specifics but the difference in performance can be several orders of magnitude in some circumstances. If you hand most people two devices and one is snappy and responsive while the other is slow and laggy, most people aren't going to care that the slow one is much more secure.
Article is click baity and lacks technical insight. Heartbleed doesn't affect Linux it affects OpenSSL. Stop blaming the OS for bugs in third party libraries. This article focuses on the fact that c/c++ makes the developers manage memory themselves. Can you please tell me how and what language I can use to design an OS without managing hardware things like memory. Its an Operating System, if you can't manage lower level hardware operation in your code you probably shouldn't be coding something that its sole purpose is managing lower level hardware operation.
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.
You should never count on developers being great. Most people will never be great, only adequate. If they're good, they'll be given ever more complex and difficult tasks until they're merely adequate.
It should be tools and processes that are great, because they can be replicated more easily than great developers. We should just admit that some developers will inevitably make mistakes, because they're only human.
Don't be jackass, jackass.
"I don't know, therefore Aliens" Wafflebox1
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.
None of those things are meaningful when the 18 wheeler smashes your little car flat. Picture?
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.
Problem solved.
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.
That's why you should give those ones crayons instead of pencils, for when they poke themselves in the eye.
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.
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.
Low level languages are just the thing for low level code like things that interact with the OS or performance critical libraries or services.
But, you have to be more careful when you write such code.
I would say that the effective size of a C program/library that can be confidently considered safe is much smaller (i.e, it does less) than a program written in a high level language like Java. That's just the way it is. Right tool for the job, as always.
C at least is not a general purpose programming language at this point. Probably the same is true of C++. But nothing can beat them for small size and quick speed!
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
At least get that right.
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.
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
(no text)
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.
C/C++ are kind of like assembly language and allow one to program close to the hardware for efficiency. One can optionally access data structures through wrappers/API's that check and protect boundaries, but such checks require processing resources. Thus, it's not directly the "fault" of C/C++, but of library usage decisions.
If you don't want "leaky" structures, you pretty much have two choices: use libraries or languages that check every access request (which slows things), or write carefully.
It's only a language issue in that you CAN skip such checks in C/C++ if you so choose. That they give you an option to skip should not necessarily be held against them. I suppose you could argue that no software should be written without built-in inspection, but we'd have slower stuff and/or have to buy more hardware.
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.
"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.
Java is the obvious solution for everything.
Security, Performance, Stability, and "Write Once, Run Anywhere", java has it all.
All you need for a simple application is a few GB of ram, a few cores [ at least 4 ] , and a 20-30Gb of disk space for a few helper libraries, and you are all set. Then, all you need is the right JVM, and the right libraries, and of course, just a few more GB for compatibility libraries "just in case".
"Hello world" compiles and runs in just minutes on a i7 with as little as 4GB of ram!
Think about it, for a small cost of memory and disk space, and a few cpu cycles, you can have the fastest, more secure code ever!
Or, you know, you could just hand over all your data, whatever works for you.
Most of those "memory safe" tools were written in C/C++ too, you know. I think OP should give good example and quit using the Internet in protest.
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
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.
Is about the level of understanding here. /. are NOT THAT DUMB.
The Internet and indeed every single piece of computing hardware above a
calculator is done in C. So are all the other languages such as Java, Python, etc.
This is ridiculous and I know the publishers of
Or at least they used to be.
Buffer overflows and Null pointer exploits are avoidable, but
eliminating the benefits of direct memory access will cripple
everything going on right now in hardware, as well as the entire
infrastructure of the internet as it has evolved.
It's rebuilt.
Where would our vaunted tech culture be without C?
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.
a steak knife could be used in a restaurant to harm some one... restaurants are insecure and should switch to using scissors for all meat cutting activities...
Like, don't like it, it doesn't matter. Languages which create workarounds around this simply can't express everything computers do.
Computers can write past a boundary which they must obey. You can put in extra checks. The operating system can put in extra checks, but it doesn't matter.
There will be times when it will be necessary to do this when doing system programming. And any language which does not allow it cannot become a systems language. In fact, allowing this type of thing is necessary for Turing completeness.
Any language which doesn't allow it, will necessarily limit the scope of problems it can solve and it will need to be extended with external facilities which solve these problems and pretend that they are already solved "naturally". But these solutions will be created by hooking in libraries written in some Turing complete languages. Heck, even basic was "safe" until you wanted to do something to actual hardware. And at that point you had to peek() and poke(). Or you had to use libraries which did. And peek() and poke() is touching memory to which you don't have abstract access in the language naturally.
Any guest worker system is indistinguishable from indentured servitude.
First, C++ has nothing to do with C in term of security. And if you speak about "C/C++", you just show you do not know what you are talking about.
This "C/C++ is automatically bad" attitude is universally held by people who aren't quite smart enough to really grasp C/C++.
It isn't good or bad. But it is low-level, so you have to be good to use it. Not "just anybody" can use it competently.
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.
The original poster didn't make it a bullet item, but mentioned it later, 'written in a hurry'. One very common experience I had was that I'd have to get it done in two weeks.
This doesn't even pass the bar for a populist article. WannaCry is ransomware, not a bug. Many of the worst vulns in the last couple of years have been deserialization attacks in HLLs like Java and Ruby. That description of a buffer overflow has literally nothing to do with how buffer overflows work (they involve writing data, and critically gaining control of execution).
While certainly rust and other memory safe languages can fix some sorts of attacks against C and C++, and indeed stack and heap protection in conjunction with ASLR already do, the idea that C and C++ equate to the cybersecurity risks we face is pure nonsense. Memory safety is a useful tool, but it's like saying a hammer is a solution to a housing shortage.
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.
I am not familiar with Rust, but there are several other languages that it is easy to write a program that will catch every possible error (outside of severe hardware faults) and at least attempt to do some clean up and report vaguely what happened. That is a lot different than memory errors that get your program terminated instantly by the OS (or can bring the OS down on some simpler systems).
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.
Clearly a millennial wrote this article. Javacrap is the first programming language they learn and they think they know everything there is to know about programming.
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.
Alex is a security dude at Mozilla. Yes the very same company whose browser is so insecure it's not even on the menu of hacking competitions because exploits are too easy to come by.
A security dude who believes "If we make that change and that investment we can make a dramatic improvement to computer security for all users, and make HeartBleed, WannaCry, and million dollar iPhone bugs far less common."
I was very much looking forward to seeing Mozilla lead by example and port the whole browser to Rust or whatever without cheating by ever using any of the unsafe methods the Rust language provides yet it seems this isn't even on the roadmap. Apparently continuing to add new features and improving "performance" is more important to Mozilla than security of their users. They can improve security of their browser right now by compiling it with compile time guards and using any number of third party tools that protect against these things with existing codebase yet Mozilla is consciously choosing not to even though it's security record is among the worst of major browsers.
It is scary yet unsurprising a security guy would believe false nonsense eliminating software bugs would bring about a "dramatic improvement to computer security". The fact is well over 90% of breaches exploit people not weaknesses in computer code. If you snapped your fingers and magically removed all vulnerabilities from all software and hardware tomorrow globally nothing would change. For someone in his position not to understand this basic reality is extremely disconcerting. It means he's trying to saw off the visible portion of an iceberg above water to keep from damaging ships in its path.
A bigger issue is that when developers sit down to choose a programming language for a new project, they're generally making their decision based on what languages their team knows, performance, and ecosystem of libraries that can be leveraged. Security is almost never a core consideration. This means languages which emphasize security, at the cost of ease of use, are at a disadvantage.
Major languages supposed to be immune to low level memory issues are way easier to use.
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?
C and C++ permit you to construct schemes to carry variable sized things with bounds checking.
Perhaps this doesn't happen because it's extra work. Both for the programmer and for the cpu.
Switching to RUST might help the programmer, but not the cpu.
A system that does bounds checking is likely going the check the bounds on something every time it uses it.
(Plan1: Trust but verify, verify, verify,...)
In theory, with C++ one could check the size of inputs once and then assume they are ok through the program.
(Plan2: Trust, but verify once)
In practice programmers and human which leaves no checking.
(Plan3: Trust, but don't verify which makes the bad guys happy.)
If you believe that optimization is something only to be done where it's needed, then the first plan wins, except in special cases where the second plan wins.
Interesting that Plan 3 is not ever desired, but often is used.
Programmed completely in python, and comes with non-optional emacs-based menu system.
.. and this article is absolutely accurate. C and C++ should only be used for low level systems programming and device drivers. The only feature I want from C++ in my higher level languages, Csharp, Swift, Rust, Julia, is complete Cpp18 constant expression support. Give me that and I will never touch C or Cpp again, except for the occasional device driver.
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..
1ms of overhead is too much when your application is a game or a simulation. Sure the web browser may not matter, because there are often 4 levels of abstraction by that time.
In the real world you work with what you're told to work with, or with what provides a large pool of existing libraries
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
Handling this in code is part of any C/C++ beginners tutorial.
Don't blame the tool - blame the dumbass who hired another dumbass to do an important task.
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.
The C language literally allows these things to occur.
Its syntax makes it much easier to write the unsafe code and bad pointer arithmetic, than write the safe code.
How could it not be to blame?
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
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.
Good god I hope your just trolling.
Most languages ultimately depend on C/C++. Punting problems does not solve it. In the end, energy to run programs on millions of devices will be the critical deciding factor. And without the bugs, we would not have a whole new job marked called "Cybersecurity"
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.
I was updating SSL when the noted that the *NEW VERSION* fixes an overflow bug. So the announcement that heartbleed exists, was the new version of the software (SSL) that fixed the bug. The storm that followed came from the news and sites that waited as long as possible to update their systems, while malicious miscreants did their evil. Years ago there was a networking site/webzine called Security Portal that had a weekly column titled "Ask Buffy, by Buffy Overflow". It was all about buffer overflows. This was about 18 years ago. Now that some boffin at Vice has noticed" "hey, I just discovered something called a buffer overflow! I think I might write an article! People should know!" And the great unwashed are more dangerous, because they have a tiny bit of information. And those who already know will have to tell them "yes, ancient news, thanks again. Linux was never really affected as all I/O gets channeled to a special memory area which doesn't allow program execution. C++ has implemented shared pointers in C++0x (the 2010 version) to allow multi-processing/multi-threading and automatic garbage collection (the shared pointers have a reference index for each application accessing the pointer, and when the reference reaches 0, automatically deletes the pointer and all memory associated with it). So its not quite as dire as the Vice article says, but sensational stories sell clicks.
This is not a C/C++ issue. This can happen in any language.
Why? Because the vulnerability isn't at the language level, it's at the instruction level. That's the nature of these exploits. Blaming this on a higher level language demonstrates a lack of understanding of how things work at a low level. Which is not surprising, these days people grow up never having written assembly language.
I was was aware this was a problem back in the early 1990s when graduates at the time had little to no low level knowledge of how the machine they were using worked. Not really a surprise this is still a problem.
My father taught me that bad carpenters blame their tools. He was not a carpenter by trade but rather a master carpenter as a hobby and his work put most professionals to shame.
Same thing here.
Anybody can code in any language, just as anybody can cut a piece of wood, but if the results are bad the problem is not the tools.
Morons write code with memory leaks and buffer overruns. Giving them tools that provide safety rails to protect them and everybody else from their reckless incompetence is a bad idea, since it only masks their underlying incompetence WHICH WILL SURFACE SOMEPLACE ELSE.
C is a very good language in that it allows a good coder to do nearly anything. Only assembly language gives more power to the coder (you C fanatics need to give in on this and admit that's why C has to allow inline assy code). I'm no C++ sycophant (the operator overloading and templates were bad ideas that good coders did not need but bad coders have abused like a bunch of chimps with machine guns) but overall the language is excellent and it is ceertainly not responsible for bad programmers any more than cars are responsible for drunk drivers.
People should really be more discriminating in their choices of "news" outlets. Vice is in the same bag with HuffPo - it's a joke if you are a serious, thoughtful person.
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.
Call me when the first browser gets written in C#
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.
This buffer overflow vulnerability has been known about for years, and the Linux Foundation has ignored it. A discussion was available on StackOverflow for the whole world to see and comment on. The vulnerability occurs as the result of a malloc call for a small amount of memory, but Linux sets a boundary for that memory far outside the requested amount. It was discovered, when the tester was trying to generate a segmentation error, but Linux refused to generate the run time error.
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.
Let's not blame the idiot programmers who don't know what they're doing, but instead let's force everyone to use kiddy languages for amateurs that ensure they can't fuck anything up. God forbid that amateurs be criticized for not know what the hell they're doing.
Also, let's remember that Java and Python are COMPLETELY 100% SAFE and that there has never been a single exploit found in these languages...
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 ?
Yes you idiot. Engineers building critical infrastructure in every other discipline require a license. Computer and software systems have become critical infrastructure, and should be held up to the same standards.
... 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.
Back in the day, I doubled the performance of a piece of code by changing "divide by two" operations into bit-shifts (arithmatic shift right, because the A/D hardware guaranteed the values were always positive) in the innermost data gathering loop.
Afterwards, instead of the program crashing hard two thirds of the way into a test that cost hundreds of thousands of dollars each time it was run, the program ran to completion safely, basically because it could keep up with physical reality.
To put this another way, if saving nano-seconds isn't important, maybe you aren't doing anything exceptionally interesting? There will always be tasks where speed matters, and tasks where it doesn't. I prefer the former!
You are short-sighted.
One example from many across the last couple of years. A C++ service that starts up in milliseconds, processes data (for a huge global company - you probably use them) and consumes under a megabyte of memory, before either shutting down or processing more. It replaced something running on a jvm, which by your metrics was roughly the same - under a millisecond per transaction on average. But orders of magnitude higher memory and startup costs - ignoring those today means that your cloud processing costs are much higher.
Itâ(TM)s all just engineering, not language wars. Get closer to ASM when itâ(TM)s warranted, and donâ(TM)t criticise what you donâ(TM)t understand.
I only troubled to reply to your misguided post in case anyone else was left with the impression that you have - CPU execution time is not 100% of the execution cost, and those costs are more exposed than ever - AWS charge by the millisecond for a reason.
you might see a 5 to 10 ms difference on the operation
When processing high-speed video, doing real-time control, high-speed data acquisition or high-speed trading (to name few examples), 10 ms is an eternity. Operations like this are done all the time and are in everything. This is why C is here to stay for the foreseeable future.
You can take your hipster new web scripting language and take a hike. Meanwhile, C runs the world.
Your attitude is why today's software is bloated and slow..and it still has security issues.
I like C. Fuck your newfangled shit
This is a good point. What I always do is, right after a strncpy, I will set the final byte as a NUL character just to be sure.
Well that will save us from C for sure.
(Hint; if you believe that, you're a moron)
Sshhhh... Quiet, you are going to ruin their fantasies :-)
"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."
As a direct result of Java putting exceptions everywhere even for non-exceptional things, here's what I wind up doing:
while (1) ... Entire program here ...
{
try {
break;
} catch (Exception e) {
}
}
Yup. That's real. And I don't care. Or at least I don't care when I write Java code.
Also, Python is inferior to PHP. Fight me.
For C/C++ code, I'll let it crash hard because I've at least got tons of debugging tools at my disposal, including sweet toys like American Fuzzy Lop.
Heartbleed was NOT caused by a buffer overflow...
A buffer overflow is when you write more data to a buffer than it has space allocated to it. Like trying to fill a 2 gallon gas can with 5 gallons of gas -- it overflows and gets all over the place. Overflow is a memory writing problem and can allow an attacker to inject code into memory.
Heartbleed was NOT caused by a buffer boundary problem...
The mirror image of a buffer overflow is when a program reads data beyond the boundaries of a buffer. This is a memory reading problem and gives the attacker access to memory they would not usually be able to access.
Heartbleed was NOT caused (technically) by any bug at all...
It was a combination of at least two problems -- one implementation related and one language related:
1. I'm sure the RFC specified that the buffer size should match the input size; it appears the implementation didn't check for that match.
2. The language spec doesn't guarantee the contents of newly allocated memory; in this case, you got what was already in that memory.
So, the attacker had to make a request with mismatched sizes (which to program didn't validate) and the language implementation didn't initialize (or clear) the allocated memory so that it contained old data (hence the exploit).
So, the closest thing we have to a bug is not validating input (definitely a security no-no); however, the buffer was allocated correctly (by the language spec) and neither a buffer overflow (didn't write past the buffer size) nor a boundary problem (didn't read past the buffer size) occurred.
So, Heartbleed was caused by a couple of security no-no's: not validating input and not initializing memory. The first opens the door to exploits and the second is the exploit itself -- mitigate either of those and Heartbleed doesn't happen.
While it has been some time, I also seem to remember that the actual bug was that the bounds checking code was bypassed because of a misplaced semicolon in a large chunk of condition code. It looked like the bounds were being checked but the checking code was never executed because of the semicolon.
I have to ask how Alex (a security engineer) doesn't seem to understand what actually caused the Heatbleed fiasco; describing it as a buffer overflow is certainly incorrect as there was no memory management problems in the process (reading or writing past boundaries).
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 recently rewrote a java program in C. It was accessing and parsing proprietary formatted binary files on disk and spitting out human readable data and performing some basic search functions. The java program took around 2 minutes to parse a file that took the C program around 2 seconds. The performance difference is non-negligible as was the amount of system resources required to run the program in each language. The simple fact is most of the languages, even Python, do not even come close to the performance and efficiency of C.
Without C, you wouldn't have any *nix variant. The problem isn't with C or C derivatives. The problem is that bugs are bound to occur no matter what. This is just a puff piece for Rust.
Let us make all languages ANSI....and stop this crap..!
I would love to see a computer run only on a high level language with no "low" level language to build on top of. Write your whole OS in Python.
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.
You need to give it up. No one is going to use Swift. Ever. Language zealots are funny. There is a reason certain languages are popular, and things like Rust and Swift are not.
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.
"the overflow would feed me cool stuff like chunks of grade reports."
No it didn't. All it could give you is what the fortran program had.
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)
Bjarne Stroustrup wears skinny jeans.
C/C++ are the future COBOL with a declining pool of possible experienced developers willing to work on a C/C++ project.
C/C++ project means gaining no skills during the project and effectively losing skills as your non-c/C++ skills get older and older.
I am back in the C/C++ programming for hourly rates game once it gets to $150+ an hour.
FWIW, some of the mainframe tools companies products have a code base going back to the early 1970s in assembler and still having forward development.
My last hybrid .net/c/c++ project ~2015 with 500k+ lines had the 200k+ lines of c/c++ code slowly rewritten to c# over the course of 3 major releases in 2 years. The team could not hire any decent c/c++ developers for rates c# developers got and was unwilling to pay a premium to get quality c/c++ developers.
Just because someone doesn't see the need for untracked memory usage, doesn't mean there isn't a need. The programmer should be responsible for tracking the memory usage. Sloppiness does not make a bad programming language. It makes bad programmers.
I'm starting to become convinced that everyone writing op-eds about how "C is outdated and Rust is the systems language of the future" are the exact same people who wrote that "C is outdated and Ada is the systems language of the future" 30-so years ago.
Theoretically those new languages aren't enormously slower than C, as proven in benchmarks. In practice, however, they are much, much slower and less responsive. All those little millisecond differences add up at the scale of a real application. Then you tack on garbage collection and before you know it there is noticeable latency in the application.
And that doesn't even consider memory consumption, load time, and the general malaise that comes from enormous binaries.
One or two programs written in fancy languages like Java or C# are ok, but when half the applications you're using day to day are such, it really starts eating into actual time. You know this, I know this, everyone knows this. Modern systems are probably less responsive for everyday work than they were 10 years ago because of all this bloat.
That's what ADA was invented for. Do you see ADA used for everything? I certainly don't.
My best friend tells me Delphi is the best!
ZIP
Bingo! Even working on big data sets I went from python to c++ and 24 hr runtime went to 20 minutes. Rewrote lockfree c++ and it was 13 minutes. Switched from gcc to icc compiler with no other changes and it ran in 11 minutes.
Huge win and c++ is why...
"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"
What you mention is only a basic part of compliation and during run time the kernel is validating memory pages just like it has to for any other language running except that language is doing the same work in user space as well.
The sort of unreasonable competence your referring to can't be expected at scale. It also supposes that people are infallible.
These sorts of languages are simply dangerous in a security context and must change or be disallowed entirely from use. Memory unsafety is lunacy.
...program in PL-I, or LISP if in a hurry.
"predict exactly what they will do"
Lower wages and import more H1-Bs. That will fix it!
Do you really think we dint know this?
The problem you described is called "Off by one." and is well known. It's a expected part of unmanaged languages.
As it is not unique to C or C++, or any other language for that matter. And it can occur in java, python, an C#. It is rarer as the garbage collection can hide the problem. But in all cases we ate expected to recognize this and fix it. We know it can lead to bugs and vonuerabilities such as buffer overruns.
This whole article sounds like someone who is just getting started with the basics, rediscovered this, then didn't bother to look it up, and blamed the language for, it rather than him/her self.
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 had a table containing various numbers, but when loading it it kept spewing nonsense. Due to my errot, I was always loading different part of memory than I intended. I concluded that is the case after cca 30 mins, fixed the code and added around four lines of another code that should catch the problem should it arise again.
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."
One, not a buffer overflow. Two, if you're really concerned about this you can turn on bounds checking (side note, it's dog slow). Three, modern C++ has language features that eliminate many historical problems
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.
Hey hipsters: How's that Python version of the Linux kernel coming?
I think I'll continue to do my core development in C and assembly, thanks. -Every systems hacker worth their salt.
and never will be the problem.
IMO, programing, the act of converting an idea into something a computer can understand, has never been a disciplined act. There are disciplined practitioners but most are not. Most code I've had to fix over the last 3+ decades was written using the noodle method, try something until it sticks, or works in this case. Then once they have a working noodle, regardless of how good it is, copy/paste and edit until it works for the next solution. A language that does bounds checking is not going to help, the errors will just get subtler.
As for that, i'm getting tired of all the marketing pieces that follow the "oh, look, see why my favorite language is better than C! Bound checking!". Who cares. Buffer overflows and other memory related issues have other means of mitigating their affects. The fact that they can be used to execute code in an unexpected fashion is a symptom of a more basic problem. The underlying OS allows code to execute without any bounds checks to protect itself.
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.
I've been writing C code since 1987. Even though there are lots of C++ and C# programmers out there, almost none of them could write C code. And true C will allow you write yourself into a big hole, the majority of C programmers from the 1980's who survived into the 1990's always put array bounds on their pointers.
You need to work pretty hard to be able to do buffer overflow with C++ and C# today and that does make for lazy programmers. I didn't say it couldn't be done, I'm saying you would have to work at it to make it happen.
If I wasn't a good programmer, I would have survived this industry for 36 years and probably have moved into management. I enjoy being a code monkey and will probably be doing it up until the day before I die.
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.
And now a new car costs $30k, and is totalled in the most minor of collisions (because replacing all the damaged sensors and deployed airbags is expensive, and undoing the mechanical damage to a crumple zone is impossible). Yes, this makes people safer, and dramatically increases costs.
I'm not saying there aren't useful improvements, but sometimes people seem to get too carried away trying to make everything perfectly safe. A perfectly safe car would be perfectly unaffordable, and also terrible at being a car. Software development is the same way. Yes, we should use safer tools and better practices. But we shouldn't be dogmatically squealing because everything isn't being written in Rust or whatever else is popular nowadays.
Not all risks can be reasonably avoided, and some are acceptable trade-offs.
I'm not fond of these newer tools that allow you to build applications without really knowing what you're doing. That comes with other consequences in my mind. If you can't plan to set buffer sizes in what other regards are you failing to understand what you're programming and the best way to approach the problems you're facing? It's really not even that hard. Input validation is a thing. Don't allow a process or a user to ask for more than what's been allocated. But it does require one to dot the i and cross the t.
And here again we have someone who can't tell the difference between cause and effect.
ADA's lack of general prevalence isn't related to its own merits or lack thereof. Evidence? It's quite common in places where programs actually, you know, work. Reliably. As intended. That ought to tell any reasonably intelligent person a thing or two about why it's used or not.
We can all draw our conclusions from you apparently not getting it.
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++.
Probably in C as well, since you would implement a list using functions.
If you're just talking about array out-of-bounds references (which are not really the same as buffer overruns) then you can implement bounds checking on every access manually.
That's what all the other languages do behind the scenes, anyway, even though it slows down array operations.
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.
In my environment, strncpy NULL terminates a string on the Linux compiler, but not the Windows compiler. So we have a macro around strncpy that always writes a NULL character at the end. It's ridiculous we have to use a macro!
Soooo, JavaScript is the best Language?