In my last post, I argued that while Adobe’s Flash has had many security problems, the root cause is that Flash is written in C/C++ instead of in a memory-safe programming language. I don’t see many people in the security industry taking up this call, so it’s worth going into more detail.

A useful place to start is this Twitter thread:

Ok Internet: who can help me understand why Flash is so insecure and prone to 0days, etc? Serious question. Email me (in profile). Thx!

— Cyrus Farivar

Looking through the responses, I don’t see anyone mentioning unsafe languages. I think the best response in less than 140 characters is this:

Simple answer: software security is the result of a process. Flash was developed, over years, without good process.

— Steven Bellovin

I agree: security cannot be achieved through one technology (like a programming language). It requires constant work, a process. But Step 0 of the process of building a secure program is choosing a programming language, and that has a huge effect on the rest of the process.

This should be completely obvious to anyone paying attention. For proof, you just have to look at the security news for one week. And any week will do!

Here are some examples from the last week (and there are many, many more in that week).

Google Chrome

A week ago Google released version 44 of Chrome, their popular web browser. A web browser is an excellent comparison for Flash: both of them execute untrusted JavaScript downloaded from the Internet on a client machine. And Google has a good reputation for their security efforts, much better than Adobe’s. How did they do?

Release 44 fixed 43 security bugs, and 13 of those 43 bugs were classified as high risk. It’s hard to say that this is a better record than Adobe’s with Flash.

9 of 13 of the high risk bugs were due to violations of memory safety (heap buffer overflows, use-after-frees, memory corruptions). That is, 70% of the high-risk bugs in Chrome 44 would have been prevented if Chrome were written in a memory-safe language instead of C/C++.

Microsoft Internet Explorer and Edge

Microsoft, like all the other browser makers, has had to deal with many critical browser security issues over the years. For example, the Zero Day Initiative has just disclosed 4 zero day vulnerabilities in Internet Explorer (here, here, here, and here). “Zero day” means that these vulnerabilities have been announced but Microsoft has not yet patched them, so users are vulnerable; and, by the way, all 4 of these vulnerabilities would have been prevented if IE was written in a memory-safe language instead of C/C++.

Nevertheless, I think that Microsoft is the best in the industry when it comes to security in their software development process. They have a lot of very smart people working on tools that make a big difference in security, like compilers, static analyzers, build and test infrastructure, etc. So, it’s interesting to see what security measures they are taking in their new browser, Microsoft Edge, which will be released along with Windows 10.

Trend Micro has an overview. The big news is that Microsoft is using a garbage collector for the DOM. That is, instead of manually allocating and freeing DOM objects, they use an automated process that only frees an object when it cannot be accessed by any pointer held by the program. A garbage collector prevents the use-after-free bugs that have featured so prominently above, including 3 of the 4 zero-day bugs just mentioned.

Garbage collection was invented in 1959, for Lisp, the first memory-safe language. It provides the foundation for memory safety and it is used in most memory-safe programming languages today. (It is also possible to have memory-safe languages without garbage collection, e.g., Cyclone or Rust.)

In other words, what Microsoft is doing is taking technology that was developed for memory-safe languages and is retrofitting it to (part of) their C/C++ program. This is good, but in the context of C/C++ it is imperfect; there are still ways to escape this protection.

This is true for many of the other protections that Microsoft is using. For example, static analysis of C code typically comes with no guarantee against false negatives: code that passes the static analysis may still have a memory corrupting bug. In fact, the technical definition of “safe” is exactly that the analysis catches all of these bugs! This is root of the slogan, “a well-typed program never goes wrong.” And an unsafe language can never achieve this.

Hacking Team

Hacking Team is a company that weaponizes exploits. Its own systems were recently breached and the attacker has released a lot of Hacking Team’s internal emails and documents to the public. Vlad Tsyrklevich has put up a very useful summary of the vulnerabilities that Hacking Team considered for purchase.

Any non-trivial software program has many bugs, but not all bugs are the same. The Hacking Team documents tell us which bugs are important—which bugs can be used by an attacker to hack into a computer. Hacking Team was offered many more bug exploits than it purchased (and by my quick survey it appears that most of them were memory bug exploits). You can be sure that the ones that they spent tens of thousands of dollars on are important bugs.

Vlad points out the following bugs that Hacking Team actually purchased.

• FP1: use-after-free
• FP2: use-after-free
• FP3: integer overflow
• FP4: integer overflow
• STARLIGHT-MULHERN: memory corruption

In other words, all of the exploits that Hacking Team purchased were exploits that would be prevented if software were written in memory-safe languages instead of unsafe languages like C/C++.

The important bugs are memory-safety bugs.

Conclusion

What we have here is a forest fire where people are pointing out one tree (Flash) and saying that it has to be removed because it is flammable. It is probably a good idea to remove the burning tree, but this doesn’t put out the forest fire.

Instead of retiring Flash, we should be sunsetting C/C++. This is a huge job, but the forest will continue to burn until we address it head on. We should not be writing new programs in C/C++, we should be writing them in safe languages, and we should be replacing libraries and components written in C/C++ with libraries and components written in safe languages.

Wake up, sheeple!