Slashdot Mirror
The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal With It (vice.com)
What do Heartbleed, WannaCry, and million dollar iPhone bugs have in common? From a report: One bug affects iPhones, another affects Windows, and the third affects servers running Linux. At first glance these might seem unrelated, but in reality all three were made possible because the software that was being exploited was written in programming languages which allow a category of errors called "memory unsafety." By allowing these types of vulnerabilities, languages such as C and C++ have facilitated a nearly unending stream of critical computer security vulnerabilities for years.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
I decided not to read the article when I saw the following:
Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow,"
That is not a buffer overflow. That is an out of bounds access, which a completely different type of vulnerability.
Sometimes, this specific access violation is called a buffer over-read, but anyone calling it a buffer overflow is simply sloppy or wrong---neither of which makes me interested in reading their material.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
When it comes to C/C++ there are pretty much no engineers that manage to avoid these problems. There are millions of engineers who think that these problems only affect other people. They are all deceiving themselves. The vast majority of code written in C/C++ probably should have been written in a safer programming language, which may only have 50% of the performance, would probably only have less than 10% of the critical security bugs.
Disclaimer: I am a bright, very qualified engineer with 20 years experience writing C for embedded systems on some of the largest network devices made by the biggest networking company in the world. And I dearly wish the world would move on from C/C++ to a programming language that gets the basics right!
One of the big eye openers I had at a previous gig involved buying a Klockwork license and running it against our codebase. Granted it's still only static analysis, but I think it found close to 20K possible vulnerabilities about 1/3 of which were real (the other 2/3 were after any end user interaction, internal APIs, so that first third would be the interface side). Took a solid 6 months to address 90% of the issues and the other 10% required redesign of architecture to resolve.
Problem is those tools are *expensive* so most open source projects can't afford them and all but the huge shops don't want to spend the $$.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
The modern Ada compilers actually produce fairly streamlined code. While you might think that there would be an overhead penalty for having to range-check every array access, the reality is that the compiler will remove the range check if it can prove that all of the indices used are within bounds. If you are writing good Ada code (rather than trying to convert your C coding paradigms to Ada), the compiler can actually make this proof most of the time. If you add SPARK to Ada, it will force you to write always-provable code.
I program in C/C++, Ada, and assembly, and I actually enjoy programming in Ada the best out of those three. I did not feel that way when I started learning the language, but I find my own personal error rate is so much lower in Ada (eg. once it compiles, it actually does what I want the very first time) because the compiler will catch many simple errors. I also find my code is significantly easier to read a year later when I need to revisit it to make some modifications.
Problem is those tools are *expensive* so most open source projects can't afford them and all but the huge shops don't want to spend the $$.
Yeah, valgrind isn't all that expensive and can be run on all your tests. Any bug that then gets through vagrinded tests means that the test wasn't testing on or past boundary conditions.
I'm a minority race. Save your vitriol for white people.
The most common vulnerabilities right now are SQL injections and xss-type attacks. Buffer overflows are difficult to exploit these days because of all the kernel protections. Oh and what is the biggest worm right now? Mirai, which spreads by using the default password for devices. It doesn't matter what language you are using that will still be a problem.
"First they came for the slanderers and i said nothing."
It is impossible to build an operating system in Java or Python
No, it is not. There are plenty of OSes written in Java.
C and C++ do not hide the underlying machine
Yes, they do. For starters: you have no access to registers. And for more information I suggest to read: https://en.wikipedia.org/wiki/...
memory is a singular long sequence of bytes.
Strictly speaking no, it is a sequence of "words" of arbitrary length.
Python and Java must be written in either assembly language or a "true to the machine" language like C or C++. ... Oh?! You mean the virtual machine? There are plenty of Java Virtual machines out there that are written in ... Java. Wow ... surprised?
No, Python is written in Python and Java is written in Java.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The question is who expected this. Certainly not any professior worth anything.
I was taught that not only compiler errors, but also all compiler warnings need to be resolved before the code is considered finished. If I had submitted a program that sometimes crashes, my prof would've asked me if I had slept through his class or if I wrote that shit while drunk.
Assorted stuff I do sometimes: Lemuria.org
Perl was *made* for text processing. Though it does make handling binary data a bit awkward.