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.

Comments

Developers or Managers?

[Terwin]

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).

Re:Developers or Managers?

[Anonymous Coward]

There is often ZERO ROI for fixing bugs.

Fixing bugs costs time and money. Clients decide who to go with based on time and money. So, if you spend too much time fixing bugs, your clients all go to your competitors instead.

You have to cut somewhere, and QA is the juiciest target. Once you win the contract, any bugs that your clients never hit represent money you saved that gave you an advantage over your competitors. Any bugs you clients DO hit but can work around, same deal. Any bugs your clients hit, and that you must fix, represent unexpected costs to you which you can afford because you got the contract. Any bugs you fixed in advance...it's impossible to know if they really needed to be fixed, so they were risks you took that could have cost you the contract.

If buyers weren't so keen on always going for the lowest bidder, the situation might be different. But as it stands, your business will fail if you spend too much time and money on quality during development.

So you must release bugs. To succeed.

Re:Developers or Managers?

[Zmobie]

While there is some truth to your statement (at least in the managers eye's), this is a very common fallacy. My previous industry saw many companies that had that exact mindset and while in the short term it can work, long term it will guarantee the failure of a company. For every bug, hack, and poor design choice the company is taking on technical debt. Up front, yes, the first and most important thing for new companies is securing jobs/contracts. Therefore one can afford and may even require a fair amount of corner cutting early on to accomplish that goal to establish initial footing (as said many times, no project has an infinite timeline and infinite budget).

If however that mindset is retained once a company is established the technical debt will accumulate and compounds exponentially over time. It also creates an entrenched mindset (that code has worked for years, no way it broke there!) that makes bug hunting and fixing much harder. Once that becomes the case said company gets a rep for having horrible buggy code that is difficult to fix. It then becomes trivial for the more expensive but higher quality products to take everything over. I know because I watched this exact scenario unfold. My previous employer definitely had their fair share of managers with the speed over quality mindset (I actually wrote a post about that yesterday...), but the overall company strategy was to put out higher quality products than competitors even though it was never going to be cheaper. It worked in spades. They were literally getting jobs to fix other companies' fucked up systems before the installs were even complete because the other companies' reputations got so bad. Keeping that code quality definitely required a lot of fighting between the architects/senior developers and management though (this actually contributed to me leaving that company).

There comes a break point of cost to profitability where that balance shifts to spending too much time/money on perfecting the software. Older game studios were guilty of that a lot I think (see 3D realms and Duke Nukem Forever), but from my point of view the balance has shifted to trying to put out too much stuff now without properly designing, testing, and fixing the underlying framework. It very much seems to be following economic modeling with supply/demand, but I think we are still in a highly volatile time because so much of the technology is new still (first to market is so valuable to businesses). So overall, I disagree that there is zero ROI to bug fixing and preventative measures, but both are undervalued and difficult to measure their ROI.

It's not the language, you stupid jackwagons...

[Penguinisto]

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.

Quote From The Article

[deKernel]

"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.

Not a buffer overflow

[thelexx]

What the author describes is not a buffer overflow. Article is ill-informed click-bait.

It's not a deadline problem (mostly)

[sjbe]

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.

Re:Not overblown

[olsmeister]

B)
____1) Experienced programmers are expensive.

Python or Java Couldn't Exist w/o C/C++

[Slicker]

It is impossible for those languages with "safe" memory access to exist without underlying languages that can openly access memory and that don't hide the truth of the machine beneath them. It is impossible to build an operating system in Java or Python -- they are made-up realities. They are designed to make computer pretend to work in ways they actually don't... in ways humans find easier to view and work with programming logic.

C and C++ do not hide the underlying machine because they are made to build the layers that actually allow software to work with the machine. The machine is instruction sequences in memory that manipulate memory -- memory is a singular long sequence of bytes. At the lowest level in any computer, that's what's there. Definitely not Python or Java. Python and Java must be written in either assembly language or a "true to the machine" language like C or C++. I am quite sure without checking that they are both written in C++. In fact C was specifically created to write the first UNIX... It's core is the core of POSIX of which even Windows shares... as DOS was written in C.

It's truly absurd to blame C and C++ memory unsafety. This illustrates a lack of fundamental understand of how computers work.

C++ compilers should have a "safe" mode

[SpinyNorman]

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 ?).

Re:With great power comes great responsibility!

[AmiMoJo]

Flaws in drivers used to be attractive to malicious actors because drivers ran in the kernel and had immense power. Modern operating systems limit drivers so that the damage they can do is greatly reduced. Also helps with stability because your sound card driver crashing won't bring the whole machine down any more.

That's the key to security. Assume stuff will have bugs, isolate it, sandbox it, put layers of security in and limit the damage. A bug in the network stack should at worst crash the network stack, which while annoying is far less critical than being able to read parts of kernel or process memory.