It's a ginormous codebase in a non-memory-managed language which was written back before the industry got serious religion on security. It is free, has a very wide install base, and in common deployments will execute code provided by any host on the Internet. This makes it a very attractive target.
Applications of similar complexity/surface area can swallow hundreds of millions of dollars of security research. Flash has not received this. (Windows/Office/etc have.)
While technically true, this diagnosis is a bit misleading.
The question is "Why is Flash so vulnerable?" and the part of Patio's answer is "codebase in a non-memory-managed language." Well, practically everything we seriously use has the codebase in a non-memory-managed language.
All the common operating system guts -- written in a non-memory-managed language. All the common browsers guts -- written in a non-memory-managed language. Even the guts of the "memory managed languages" are -- written in a non-memory-managed language.
C and variations, and not memory managed. And nobody managed to replace C and dialects with something else. The Rust language will maybe manage to be used for something serious, already implementing the experimental layout engine but at the moment it's still too hard even to replace the current Firefox engine with the one written in Rust. It's a good thing that Rust and other developments exists, but in practice, C is still everywhere.
So Flash is not an exception in being written in C or the dialect of it. That some parts of some systems can be implemented in memory-managed languages is a very old thing, and it doesn't protect them from exploits. Parts of Firefox are written in JavaScript. Even when something is written in Java (which is memory-managed) didn't mean a thing, as recently Java code was the favorite attack vector (in spite of being "virtual" and "memory managed").
Security is hard. Certainly, millions of dollars of security research and the implementation of their results help the most, more than "it's not memory managed" as it is too simple an answer to be of much use in the given context.
So why then Flash? Because of many things, but specifically Flash brought to the browsers huge functionality which is still slowly being reimplemented in the form of the standard features of the browsers. Even ignoring the fact that they brought these features without too much external reviews, the only way to bring so much functionality to the huge infrastructures that existing browsers are was for Flash to cross a lot of boundaries. And the attacks are the boundary crossings, so piggybacking on what Flash does is often the best thing for an attacker to do. Then, the second cause is certainly that Flash codebase definitely didn't receive enough attention to become safer. And the current reason is -- even Adobe doesn't expect Flash to ever become something worth of too much investment.
Disclaimer: I've implemented one memory managed language in C. Behind almost every language mentioned anywhere is some non-memory-managed C. Simple "a single island" languages can be very clean and safe. Add the features, use of the system libraries, boundary crossings etc, and "memory managed" is just a small point.
everything we seriously use has the codebase in a non-memory-managed language. This is not true of ASP.NET nor Java applications. There may be very small parts that are in non-memory-managed languages. This is distinct from codebase in a non-memory-managed language.
"memory managed" is just a small point. No, it is a huge point. Doing assessments on an acre or two of asp.net or C# applications, you simply won't see the kind of error you see in flash, like the 400 game over vulnerabilities that google found when they fuzzed it.
> That some parts of some systems can be implemented in memory-managed languages is a very old thing, and it doesn't protect them from exploits.
This is misleading. On the face of it, what you say here is true: there are security vulnerabilities in software written in memory-safe languages. However, what is not true is that there are nearly as memory memory safety-related vulnerabilities in software written in memory safe languages. The conclusion that memory safety doesn't make software more secure would only follow from that premise, which seems empirically false to me.
Applications of similar complexity/surface area can swallow hundreds of millions of dollars of security research. Flash has not received this. (Windows/Office/etc have.)