46

I’m not talking about server-side security or even necessarily XSS vulnerabilities, as these are attacks on vulnerable services and do not use any pre-existing vulnerabilities on the client side to affect an end user. They will exist as long as web developers keep making vulnerable web applications.

I want to focus on the security of the end-user in these two different scenarios:

  1. Flash installed and enabled, but JavaScript disabled
  2. JavaScript enabled, Flash not installed or enabled

I am interested in the answers that I might get from posing a type of question that requires the comparison of two almost completely different (internally), yet competing technologies, in terms of end-user security.

alexwlchan
  • 177
  • 11
Jonathan Gray
  • 1,036
  • 7
  • 11

3 Answers3

54

In theory, if all servers and connections to them were perfectly secure (impossible) and trustworthy (not true), neither one would be more "secure" than the other - mainly because the developer(s) of the website are in full control of the content of the site. Since Flash and the JS is served to clients, the server would have to serve malicious content to the end user in order for the end user to be affected.

Sadly, we don't live in a perfect world and JS tends to be more secure in the case of a server compromise - it is far more limited in its ability to affect the client. Many Flash vulnerabilities have the ability to execute arbitrary code, which is far more damaging than browser exploits, which often require multiple vulnerabilities to break out of the sandbox. This means that JS exploits often can only manipulate the client while the client is viewing that page and is usually unable to persist after it is closed, whereas Flash exploits can infect clients with RATs or other malware, which enables the attacker to have control over the client even after the browser is closed.

Another benefit of using JS is that the source is viewable by clients. Someone using the site may notice something suspicious in the source and notify the developers, allowing for the intrusion to be more easily detected. In the case of Flash, a malicious attacker can inject malicious code into an existing swf and since users cannot view the source without dissembling the swf, malicious code may go undetected for longer.

For an end-user, scenario 2:

JavaScript enabled, Flash not installed or enabled

would be much safer for the reasons above and given Adobe Flash's history of exploits. A search in the NVD reveals a total of 610 vulnerabilities, 330 of which are between January 2014 and December 2015. Most JS-related exploits tend to be browser specific, which reduces the number of clients affected, while Flash is meant to be cross-platform, which increases the number of affected clients (less nowadays, considering that many people have Flash disabled).

TLDR: Keep Flash off and use JS instead.

WillS
  • 769
  • 6
  • 7
  • 4
    Also, I ve saw article on ARs Technica hinting that Mozilla and Google are planning to phase out Flash completely, so you should begin to think about that, and expect that in one or two years, Flash will not be a default at all. (one of thoses article: http://arstechnica.com/security/2015/07/firefox-blacklists-flash-player-due-to-unpatched-0-day-vulnerabilities/) – DrakaSAN Nov 28 '15 at 14:27
  • Is a html5 site more secure, and privacy-friendly ? I'm myself thinking about serving my websites only in html5 for security, and speed purposes – Freedo Nov 28 '15 at 20:03
  • @Freedo I'm no security expert but from my (admittedly limited) experience in security on the web: yes, purely because of the fact that Javascript is sandboxed and Flash isn't. This is why you disable Flash on things like TOR (and admittedly JavaScript if you're super paranoid) – Dan Nov 30 '15 at 13:43
  • 1
    In theory, if all the servers were perfectly secure and trustworthy, your connection to the server could still be compromised. [NSA's QUANTUM series of attacks work that way.](https://en.wikipedia.org/wiki/Tailored_Access_Operations#QUANTUM_attacks) – user Nov 30 '15 at 14:58
  • @MichaelKjörling Good point. Edited answer. – WillS Nov 30 '15 at 16:44
31

In addition to WillS' excellent answer, a couple more differences that affect security:

  • Flash is a product, while HTML5/Javascript is a specification. With a product (and especially a closed-source one), you always depend on the vendor to play a game of whack-a-mole (which Adobe is doing admirably, but long term it is a losing battle). A specification can be re-implemented if necessary (unless there is a flaw in the spec itself - but even that can usually be fixed).
  • End users may not have the latest version of Flash, and may not be able to upgrade. For instance, the Linux and Android implementations are ages old and unsupported.
  • Flash is very old; it was first created last century. Any software that age is likely a huge ball of duct tape at this point. Again, this is mostly a consequence of Flash being a product rather than a specification. HTML and Javascript also date that far back, but don't suffer from this problem, at least not to the same extent.

Update Two additional issues with Flash:

  • Flash can establish its own TCP connections. If a cipher or hash is found to be vulnerable, the browser may deprecate it, but Flash may still use it. Adobe tends to be pretty good about fixing such issues (at least on supported platforms), but it still doubles the whack-a-mole factor.
  • Flash has its own cookies, separate from browser cookies. This is mostly a privacy issue more than a security issue, but many people consider these two issues linked.
Kevin Keane
  • 1,009
  • 7
  • 8
  • 8
    I don't agree that the age of a software product necessarily implies low quality code. In many cases the opposite is true. – Jon Bentley Nov 28 '15 at 19:42
  • @JonBentley 10 years ago Git was released. 15 years ago, software development wasn't as structured as it is now. Bug tracking systems weren't as evolved. Age doesn't imply low quality in terms of code, but it terms of *tools* it usually does. It depends on the company and their regulations sure, but an absence of good tools to help along the code, you end up with lower quality code. – Chris Cirefice Nov 28 '15 at 23:24
  • 8
    Linux, *BSD, PostgrSQL, they're all duct-tape code by now then? – user1067003 Nov 29 '15 at 09:08
  • 5
    If you have 1) a closed source codebase, 2) software developers that come and go all the time, and 3) a boss that cares about features (hereunder: immediate fixes), but NOT software quality, or even that your unittests are passing before shipping, and perceives refactoring as a "risk", then YES, you are absolutely going to end up with a ball of duct tape! – user2394284 Nov 29 '15 at 10:52
  • 3
    @user1067003 Seems that I opened an opinion-based can of worms here! But generally speaking, yes; there even is a term for it: "code rot". I honestly don't know how far the Linux or *BSD kernels or Postgres are affected. The *BSD ecosystem certainly suffers from it. There are three different package managers, for instance. Windows suffers from serious code rot too, which is why even Windows Server Core still runs in a window, and why Microsoft created PowerShell instead of fixing CMD.EXE. In OpenSSL, code rot is what lead to Heartbleed. – Kevin Keane Nov 29 '15 at 23:13
  • 1
    For point 2: End users also may not have the latest version of their browser, or be able to upgrade. (Or not *want* to upgrade, in a way you can't do anything about - say, because their browser vendor keeps overhauling the UI every 10 versions and they hate change) – user253751 Nov 29 '15 at 23:51
  • 1
    @immibis agreed, but that is a much lesser problem than Flash. Browsers nowadays automatically and transparently update; you (or your corporate IT department) has to go through quite a few hoops to disable that. And in any case, if you don't (or can't) update the browser, you have many more security issues to worry about. So HTML5/JS still wins because there is one program to update with a very streamlined update process, vs. two separate programs, one of which usually requires manual intervention. – Kevin Keane Nov 30 '15 at 00:08
  • 1
    @KevinKeane For Flash it's a matter of clicking "yes" after restarting your computer. (And IMO, clicking "yes" to a prompt is the simplest it can be without becoming unethical) – user253751 Nov 30 '15 at 00:32
  • 2
    @immibis The main difference is in having to click yes in the first place (and I have seen situations where "yes" just took you to the download page, even today). Both Chrome and Firefox update completely transparently. Another difference is that a flash update requires you to shut down your browser (or wait until you can use it), and occasionally may even require a system restart (although that's rare nowadays). Adobe has come a long way, but the update is nowhere near as seamless as you make it sound. – Kevin Keane Nov 30 '15 at 00:39
  • @KevinKeane So the main difference is the level of morally dubious behaviour (changing software behind the user's back), where more is better. Interesting. – user253751 Nov 30 '15 at 03:15
  • 2
    The reasons here are ridiculous. Javascript is older than Flash. More people have outdated browsers than flash versions...and, flash PLAYER is a product...just like javascript interpreters are a product. Flash's .swf specs are a spec just like the javascript spec. There's little difference there. You get to a decent end conclusion...but do it through some ridiculous means. Like correctly deciding that a crayon is blue...but getting to that conclusion via the logic that it's blue because the sun god Ra is a naturalized citizen...so therefore the crayon is blue. Just bad reasoning here... – Jimbo Jonny Nov 30 '15 at 03:18
  • @JimboJonny Flash is *not* a specification in the same way JavaScript is a specification. The real name of JavaScript is ECMAScript and all legit implementations are built using ECMAScript standards. Vulnerabilities would be most likely to target a specific implementation of JavaScript which can be continually re-built from the ground up as long as the specification still exists. With a product such as Flash that ends up being more like a cross-platform API rather than specification, it is harder to prevent "code rot" and exploits targeting the implementation tend to be much more effective. – Jonathan Gray Nov 30 '15 at 08:38
  • @JonathanGray - That only means that it ends up with multiple implementations of that standard. While that does mean an exploit does only affect 1 implementation it also means more implementations to find exploits in and more possible exploits to track/counter. While an exploit on 1 ubiquitous implementation of something may be more universal there are also fewer implementations worth of it to find exploits within and deal with countering. As far as the fundamental nature of the security of 1 universal implementation vs. multiple implementations of 1 standard...po-tay-to / po-tah-to. – Jimbo Jonny Nov 30 '15 at 09:13
  • I also find that an interesting usage of the term "code rot". That's usually a term for when the environment the code is running within keeps changing slowly over time until old code starts having more and more bugs, or when a given code is continually updated/added to with more and more bugs presenting in the process. A spec with continually rebuilt implementations from many vendors is MORE prone to code rot of both types...hence why JS code written 15 years ago would have a far harder time running today than a .swf published 15 years ago. – Jimbo Jonny Nov 30 '15 at 09:18
  • Flash can also enumerate your device hardware. That's disgusting. – Mark Buffalo Dec 04 '15 at 20:28
0

From the perspective of "can running xx from your browser crash your machine or compromise your security" the answer is clear - flash is an old technology, not well supported any more, and with a long history of exploits. So it's known to be potentially dangerous.

As for html5, javascript, and other currently buzzworthy technologies, they're not intrinsically any safer - they're running code written by third parties on your machine. There's an attempt to limit what they can do, but the effectiveness depends on the quality of the implementations as well as the underlying design. Exploits are inevitable.

ddyer
  • 1,974
  • 1
  • 12
  • 20