As someone who works in computer security, it’s both inspiring and sad to see Flash die. Inspiring, in that security seems to have played a major role. Sad, in that Flash’s insecurity has little to do with Flash itself: Flash is insecure because C/C++ is insecure. If anything has to die, it should be C/C++.
I’m trying to figure out how this can happen in an age where we’ve built an entire industry on (1) collecting data, (2) finding signals in the data, and (3) acting on those signals. Google should be all over this.
So let’s look at some data, starting with this recent Project Zero blog post, Attacking ECMAScript Engines with Redefinition. It describes 7 attacks on Flash in detail. All of these attacks exploit flaws in Flash’s ECMAScript (i.e., JavaScript) engine.
The post is a bit confused, in my opinion. You might think from the title that the security problems have to do with JavaScript, but actually, the engine (which executes the JavaScript) is written in C/C++, and all of the actual bugs are memory safety bugs that are unique to unsafe languages like C/C++, and not safe languages like JavaScript. It’s really C/C++ that should be mentioned in the title, not JavaScript.
There’s actually not much signal in this particular corpus. It tells us that some of Flash’s insecurity is correlated with C/C++, but not how much. For that, we need to look at a bigger data set.
Here’s a list of all security issues that Project Zero has announced for Flash. As of today, there are 129 issues. Of those 129 issues, 98 are clearly memory safety issues (type confusion, use-after-free, buffer overflows, integer overflows, etc.). In other words, the great majority (at least 75%) of security issues that Project Zero is finding in Flash are due to its C/C++ implementation.
There are some possible biases in this data, of course. For example, perhaps the Flash implementors are particularly bad C/C++ programmers, and other C/C++ programmers aren’t making these mistakes. To account for that, we could widen our search. I’ve looked over all 350 issues reported by Project Zero as of today, which cover many products besides Flash. Based on a quick classification by the summary of each issue, it appears that 267 issues are related to memory safety, and 83 issues are not.
That is, 76% of all of the security issues reported by Project Zero are memory safety issues characteristic of C/C++. So, the memory safety problems of C/C++ afflict far more than just Flash.
Of course, there are also possible biases in this data as well. For example, perhaps Project Zero has chosen a biased sample of programs, or they are particularly good at finding memory safety issues and bad at finding other security vulnerabilities.
To address this, we could widen our search. At this point, someone else will have to take up the task, since I’m only one person and I’m not by any means a data scientist. Perhaps someone like the authors of this paper, who studied 15 years of memory errors as reported in CVEs. They give a useful historical overview, and they discuss the common defenses that have been deployed to mitigate memory errors when they occur (ASLR, etc.). Their conclusion is that “memory errors are still one of the primary threats to the security of our systems. Not only is this confirmed by statistics, trends, and our study, but it is also backed up by evidence showing that even state-of-the-art detection and containment techniques fail to protect against motivated attackers.”
Conclusion
If computer security is a scientific endeavor, we should direct it by (1) collecting data, (2) finding signals in the data, and (3) acting on those signals.
We have been doing a lot of (1), some of (2), and very little of (3):
(1) We have been collecting data on security vulnerabilities for decades.
(2) There is a very strong signal in that data: the most important bugs that harm security today are memory safety bugs that occur almost exclusively in C/C++ programs. But:
(3) Instead of calling for the retirement of C/C++, we are instead shooting (relatively) innocent bystanders like Flash in the head.
Based on how little action I see against C/C++, I have to wonder how many people are even aware of the severity of the problem. I can understand your everyday programmer discounting security as an issue, but the security community has no excuse for silence.