I disagree with Michael's reply. Sandboxing based on blacklisting or whitelisting does work if you implement it correctly, as then there is no way that running code can ever circumvent it. Otherwise sandboxing as a whole would be impossible since even sandboxing in OS kernels uses black-/whitelisting, yet as the kernel enforces the rules, a user-space app has no chance to bypass any of the restrictions, unless it can manipulate the kernel and if it can do that, you have much more serious problems than apps bypassing sandboxing as then any app can take over your entire system.
The main problem of Flash was that it wasn't designed with security in mind. If security is an issue, you need to think about it before you write your first line of code. Yet Flash had a gigantic code base that was written without investing any time to think about security as it wasn't originally written for the web. It started off as a vector drawing app from FutureWave named SmartSketch (1993-1995), that later on offered vector-based, interactive animations. Being a locally executed app, security was not an issue. Only later the idea was born, that these animations could also run inside a browser using a browser plugin. As this was competing with Shockwave from Macromedia (a similar concept, yet focused on bitmap animations, sound, and video), Macromedia obtained SmartSketch from FutureWave, added some of its Shockwave functionality to it and Shockwave Flash was born (1995); this name was later truncated to just Flash.
The problem was that any security concept that Flash offered wasn't part of its core but was later on put over the whole thing and it had holes like cheese. With JIT-compiled code that focused on performance and not on security, it became possible for attackers to intentionally produce stack overflows and then be able to call arbitrary native code of the system, breaking out of the AS sandbox. Also AS allowed direct interaction with many native functions of the Flash player to control animations or access audio hardware. Many of them were predating AS and were simply not prepared for the fact, that someone may intentionally feed wrong data into these functions as when called by the player itself, this would never happen, so sanity and type checks were often missing for performance reasons. And there were thousands of these. By feeding bad/broken/incorrect data into these functions, again, stack overflows could be produced and arbitrary code could be executed or arbitrary functions could be called. Fixing all of them was a whack-a-mole game.
If we learn something from Flash, it is that you will have a very hard time to retrospectively turn an insecure system that was never designed with security in mind into a secure system by trying to put security concepts on top of it. If security is really the top priority, throwing everything away and starting from scratch will be faster and lead to better results. Yet, of course, Adobe, who bought Macromedia, had no interest in doing so. They just wanted to make maximum profit out of their 3.4 billion dollar investment they had to pay to buy a bunch of security-wise rotten systems, that were now maintained by new owners which didn't even know half of the dirty code paths still in the system since day one.