Ask HN: Why is Flash so vulnerable?
7 comments
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.
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.
Large codebase, unsafe implementation language, huge attack surface, and popular target probably covers all the reasons.
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.
"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.
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.
acqq: Cyrus Farivar from Ars Technica. I'm working on a story on this exact issue. Can you email me? cyrus.farivar AT arstechnica.com Thx!
I was listening to the Security Now podcast this morning. On episode 514, Tor's Astoria Client about the first 30 minutes of the podcast is spent going into extreme detail about how a recent Flash vulnerability was exploited.
I can't link to a page for the episode.
Here is the episode list: https://www.grc.com/securitynow.htm
The episode: https://media.grc.com/sn/sn-514.mp3
The transcript: https://www.grc.com/sn/sn-514.txt
I think most of the content is sourced (and credited) to this post from FireEye: https://www.fireeye.com/blog/threat-research/2015/06/operati...
I can't link to a page for the episode.
Here is the episode list: https://www.grc.com/securitynow.htm
The episode: https://media.grc.com/sn/sn-514.mp3
The transcript: https://www.grc.com/sn/sn-514.txt
I think most of the content is sourced (and credited) to this post from FireEye: https://www.fireeye.com/blog/threat-research/2015/06/operati...
Thanks for sharing, this is fascinating.
Given the level of sophistication in this attack, I wonder to what extent the number of vulnerabilities found in Flash is a function of the effort spent disassembling it and searching for them specifically. Since browsers implement their own language runtimes, might they be vulnerable to the same types of attacks? Is there anything that makes Firefox inherently more secure than Flash?
Given the level of sophistication in this attack, I wonder to what extent the number of vulnerabilities found in Flash is a function of the effort spent disassembling it and searching for them specifically. Since browsers implement their own language runtimes, might they be vulnerable to the same types of attacks? Is there anything that makes Firefox inherently more secure than Flash?
To me, it seems like a combination of several factors:
* None of Adobe's products are particularly stable or secure - not even the ones they charge a lot of money for.
* Flash's wide install base and the fact that it's easy to invoke on a target (via the browser) machine makes it an inviting target for hackers.
* Flash is a fairly complex piece of software - after all, it's a language runtime.
* They don't charge for the Flash runtime, so there's no direct return on investment for making it more secure. The main losses are reputational and until there's a mass revolt (which might be coming) it's hard to quantify any financial losses.
I might be stating the obvious - it contains language interpreter. It is hard stuff to do and from the beginning the focus was on speed not the security. Now it is a high value target and it was probably checked for bugs more than any software in history.
That is how big organizations work:
1. they feel flash is slowly dying or that it could be potentially be sold
2. No more investment in order to get the biggest money from the already existing market of customers, a future sale, or force migration to other products of the same company.
They do not understand that the image of the technology and the community is damaged; and that is a pity when I think in the haxe project and the open source community around it.
Now even an open source alternative to the binary flash would not safe the damaged image and HTML5 canvas is predestinated to overtake it.
EDIT: I think adobe lost a big chance in the market with flash by being too much closed and not understanding modern development/online communities.
1. they feel flash is slowly dying or that it could be potentially be sold
2. No more investment in order to get the biggest money from the already existing market of customers, a future sale, or force migration to other products of the same company.
They do not understand that the image of the technology and the community is damaged; and that is a pity when I think in the haxe project and the open source community around it.
Now even an open source alternative to the binary flash would not safe the damaged image and HTML5 canvas is predestinated to overtake it.
EDIT: I think adobe lost a big chance in the market with flash by being too much closed and not understanding modern development/online communities.
I blame Adobe's culture, their culture discourages good programming and their other projects suffer the same problems. For example, bread winners like CS/CC frequently crash, I have a collection of Indesign files that will crash on demand but my concerns have yet to be remedied after 4 years. Internally, they rely on a custom widgeting kit designed to match the functionality found in their pre-OSX mac software (over 20 years!). Build times are said to be several hours.
Adobe is simply not competent at writing modern software, don't forget that if you cant get a flash zero-day you might get one for Adobe Reader!
Adobe is simply not competent at writing modern software, don't forget that if you cant get a flash zero-day you might get one for Adobe Reader!
A company that employees cheap programmers.
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.)