79 comments

[ 0.26 ms ] story [ 127 ms ] thread
> While Yahoo acknowledged the attack, the company said that it was not nearly as big as Malwarebytes had portrayed it to be.

Prove it, give us the numbers

> “The majority of attacks we are seeing are exploiting software installations that are not up-to-date on the latest security updates,” said Wiebke Lips, a spokeswoman for Adobe.

Then your plugin should stop working by itself when a new version is available, that's how you force users to update if you are a responsible vendor. But of course you don't do that.

I like Flash as a creative tool, but clearly people should stop using it on the web,and browsers should ban it like they banned java on the web. It's just too dangerous and vendors often wash their hands off any consequences. Hopefully the flash IDE can work with webassembly and give up the plugin. If Adobe doesn't do that, someone else will and Flash will be buried for good.

> Then your plugin should stop working by itself when a new version is available, that's how you force users to update if you are a responsible vendor

That's an interesting idea. Is it practical? I think you'd need to run some flash code first to determine the flash version before loading the ad code... I suspect it would take too long.

No, just do it in js.. https://code.google.com/p/swfobject/

But.. I really don't think it is the responsibility of a content provider to do version blocking.. that causes bad karma.

The responsibility is the platform, either Adobe itself or the container, which is the browser. Either way, I struggle to think Yahoo is to blame.

Yahoo bears some, but not all, responsibility.

As for version blocking you are correct that that falls entirely on Adobe and the browser.

One of the most difficult parts of an attack like this is to get people to actually "run" the malicious code. In this case that meant loading some flash object. Embedding malicious flash is one of the easiest ways to get a person to run your code, but you need a popular site to do anything large scale. Yahoo is responsible in that they own a vector (their ad network paired with their popular web properties) that makes this large scale distribution trivially simple for the attacker.

Content providers (web property owners) should be responsible for the ads that get served on their site but, given how the ecosystem has evolved, they have very little control. The most a content creator can do is switch to a different ad network. This case is interesting because the ad network and the content property were owned by the same entity; switching networks makes no sense.

The quality/safety of ads is left up to the network and the ad creators. Obviously the creators cannot be trusted. The network has little incentive to police thoroughly (although it seems like Yahoo did take some action in this case). There is such a glut of ad real estate that individual content creators have effectively zero power to affect change. If one of the networks strove to promise a better experience for the content providers (and us; the ultimate consumer) it could cause content providers to switch networks. But that costs money and no ad network has the incentive to be first. They simply don't need to in order to continue being competitive.

It will be interesting to see what happens in the next few years. It seems like companies (Apple in particular) are starting to try to gobble up as much content as possible. If enough providers sign on to such programs, these "co-ops" could have significant bargaining power with regards to the ad networks. But who knows what other issues will crop up. Today everybody has a website or a blog that they need to independently monetize via ads. Grouping together under the banner of a large company could work well for them, or they could effectively become web serfs. It'll be interesting to see either way.

Yahoo should shoulder blame here. They did no vetting of the objects they allowed to run from their servers. Had they been responsible and checked the ads beforehand, the people they were serving content to would not have been infected.
That's an excellent way to piss off your users. I can forgive it in case of a legitimate 0-day floating around, but come on - sometimes the user doesn't want to, or can't upgrade (e.g. running without installation privileges, common at universities and in corporate environments).

I like the way Firefox approaches it - it disables the outdated Flash plugin and in place of Flash content it renders boxes that say why the plugin was turned off and give option to manually enable it if I'm really, really sure. It's annoying enough to force people to update while still giving you an option to run the old version if you absolutely have to.

Yeah, this. The amount of pure rage inside my department directed at Java because of their boneheaded security stuff is enough to power a small city.

Okay, so open up the management interface for my SAN. Yes, I want to allow Java to run. Yes, I know it's not signed. No, I don't care.

Okay, now I have to go add the domain to an obscure control panel because a freakin' popup is too much to ask.

Now I go reload the page, yes I want to run the plugin, no I don't care that it's unsigned, yes I know that this may hose my computer, yes* i want to load the damned applet already.

Combine that with the fact that the Java web plugin sandbox and all this security appears to be trivially bypassed, and I wish they'd screw off with the multiple confirmation prompts and let me just control it with the browser.

* The number of times I've cared about the code signing status of any application in the last decade can be counted on one hand.

> It's annoying enough to force people to update while still giving you an option to run the old version if you absolutely have to.

FireFox now has changed the default to click-to-activate for the Flash plugin, but this behavior a couple of years ago led me to enable click-to-activate on all my computers, when I opened up an older machine I hadn't fired up in a while and noticed that Flash was conveniently disabled everywhere.

Until FF's recent change, this behavior broke a lot of websites, and clearly now they're fixing their interaction with click-to-activate behavior. Some sites would have an element with js handlers over the flash plugin for ads or something else, some would just display a message that's like, "You should download the flash player", which meant they were entirely broken.

He was referring to Adobe not Yahoo. So no they wouldn't need to run flash code first it could just check a database to see if it's blacklisted on account of a zero day and refuse to run like Firefox did but from the plugin itself.
Adobe already has an "automatically install updates" option that it encourages you to accept. If I wanted version blocking, I don't think I'd want to rely on Adobe to provide it.
I used an android app that did that - I no longer use it.

Just require users to click to enable plugins and that should take care of everything.

It's Adobe's implementation that's the problem, not the concept.

I think it's better as a plugin because then you get to easily enable/disable it (off by default is good) and the browser can also isolate it; something not so easily done for built-ins like JS.

> I think it's better as a plugin

Except that every instance runs as its own process. A page with a dozen flash ads is a dozen flash programs all hogging memory and processor cycles, happily exposing holes in your security.

That's actually a plus. OSes have good isolation for processes, and good performance fixes (shared read-only pages) on top of that. Browser developers implementing sandboxing is not exactly the best use of their time and expertise.

The problem is that instead of the browser streaming user interaction events to the Flash (or any NPAPI plugin) process and asking for a render from time to time, the plugin window is overlaid on the browser, and waits patiently for events streaming down from the mighty plugin.

Chrome autoupdates Flash and Firefox blocks old versions of Flash. (I'm not sure what IE does.) That should help limit the number of people who are exposed.
(comment deleted)
Ad networks have been used to distribute malware for years.

When you're an ad sales guy and get a call from a new, big-spending client with no performance goals, it's hard to say no.

And attackers even exploit ad servers directly. We had a client whose OpenX credentials were compromised, and the attacker was able to directly modify the (otherwise legit) ad tags in the database. They turned the exploit code on and off in the ad tags of legit clients to avoid detection.

We had an outside security technology co scanning the tags who picked that particular hack up pretty quickly, but not everyone does...

and this should be reason enough to block all ads that require code to run in the browser, in one form or another.
One more reason advertisers and publishers need to stop blaming visitors for rising ad blocking usage. Until they come to grips with security and good UX, their arguments of lost revenue continue to fall on deaf ears.
I've removed Flash entirely from my computers. I was afraid that it would degrade my experience, but I'm barely missing it.

Sure there are a few sites that insist on using flash for video or some old games, but I'm ok with that sacrifice.

Flash has been a tool of evil for too long: either storing permanent cookies for tracking or as a tool to exploit vulnerabilities in itself or its host.

There is nothing on the web today that should require flash. Using it for adverts is especially egregious considering that it remains a major vector of attack despite all attempts at fixing it.

Though you got downvoted, you're correct! Even the people of HN are overcome with be-positive-bias, when faced with technical questions. Flash is junk!

I disabled it after Brian Krebs tried living without Flash successfully—and reported on it. It's been awesome! If I need Flash, I open a different browser. Easy.

>If I need Flash, I open a different browser.

If I need Flash, I open a different user account!

Some things aren't fungible, though.

Where possible, I do, as well!

If I need Flash, I go to an Internet café or a library.
I've never seen a 'be-positive-bias' in HN.
In general I agree with you, but reliably whenever anyone complains about sites that require javascript or flash to load, people will respond that javascript (or to a lesser degree, flash) is required in the modern web and if you don't have it enabled by default you are some kind of wierd paranoid luddite.
I did the same thing. I have Chrome configured as my "work browser" and have flash set to click to play, due to legacy software concerns. I almost never click on flash applets. I also have Firefox setup as my "personal" browser and never bothered to install flash. I can't say I'm missing anything.

It would be nice if browser vendors got together and announced a Flash EOL on their platforms. On that day Flash becomes a strict click-to-play option by default with big warnings to undo it. Then eventually a tombstoning of Flash where its disabled outright and perhaps only enabled via some registry/config hackery that's user unfriendly but sysadmin/enterprise friendly.

If browsers had a native 'push url to external program' I wouldn't miss most of the web.
They do, it's called a protocol handler, this is how video worked in the 90s.
:) Good point, I never really investigated how to leverage them under linux because of program requiring a tty... Still good reminder.
One huge site that still uses Flash is HBO Go. Surprising considering most other big streaming video services (Netflix, Youtube, Vimeo) have moved or are moving to HTML5.
Just fyi and for others to see, you can remove flash cookies by going to this url: http://www.macromedia.com/support/documentation/en/flashplay...

This is a good solution for people that cannot work without flash.

It is a "solution", but not a good solution.

Spying on me by default, and claiming that periodically removing the cookies you've already used to do it on an essentially secret website is sufficient, is not a good solution.

So do you not use browsers then? Cookies are enabled by default in most browsers as well. And you can just as easily figure out how to remove flash cookies as browser cookies.
1. it's not nearly as hidden

2. am I not allowed to dislike both things?

The biggest area it's still important for me in my daily use is live streaming video. Most players are still flash.
It's frustrating that VMWare is moving toward Flash as a management platform. Their entire 5.5 web console is in Flash.
Why flash? What advantages do they get with flash that outweigh the negatives?

https://www.youtube.com/watch?v=31g0YE61PLQ

VMWare probably has a bunch of enterprise customers stuck using IE7-9, so a modern HTML5 SPA for the admin interface is prohibitively expensive to write and maintain.
> Sure there are a few sites that insist on using flash for video or some old games, but I'm ok with that sacrifice.

I use this generic downloader (despite its name) for the few flash video sites that i use. Works great for many sites.

https://rg3.github.io/youtube-dl/

I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module.

All interaction between a Native Client module, the host process, and the host the operating system must be mediated via the PPAPI (Pepper API). Native Client has a set of rules which are enforced via the validator to ensure that untrusted code (that is Adobe Flash itself) cannot jump, load or store outside to addresses outside the sandbox. More information on how Native Client does this can be found in the links below.

Note: you should be familiar with the x86 and x86-64 instruction set for it to make much sense.

Nevertheless, here is some more information:

[1] https://support.google.com/chrome/answer/108086?hl=en-GB

[2] http://www.eecs.harvard.edu/~greg/cs255sp2004/wahbe93efficie...

[3] http://static.googleusercontent.com/media/research.google.co...

[4] http://static.googleusercontent.com/media/research.google.co...

> I don't know if you use Google Chrome, but Adobe Flash Player in sandboxed in Chrome as a Native Client module.

That is, indeed, smart, but I stopped using Chrome on the basis that I don't want to use a browser that is developed by a company whose customers are advertises and for whom I am the product. :/ I was an early Chrome adopted and I saw the tide turning a way I didn't like.

I've actually been pretty happy with Safari and ClickToFlash plugin of late, I'm not as worried about sandboxing it when I only use it in a couple of places behind AdBlockPlus.

I don't use Chrome either. I like Firefox - even if it is less secure (in principle) than Chrome (no process separation between domains or sandboxing of plugins).

The reason Native Client exists extends well beyond Adobe Flash Player. Native Client exists to enable your browser to run native code from any website (think compiled C and C++ code) without it being able to compromise the security of your machine.

Exploits have broken out of the sandbox before using OS-level security holes. The sandbox is not anywhere near 100% effective. If you feel safe using Flash in Chrome because of the sandbox, you might want to re-evaluate.
Can you expand as that? Did they break out via the service runtime, or through an implementation defect in the validator?

I recall that Chris Rohlf presented an implementation defect in one of the two at a Black Hat conference some years back, but the sandboxing is otherwise solid.

Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features. It absolutely does not use a strict PPAPI sandbox and does not run under NaCl. To explain some differences, the Flash plugin is not bound to Web origins like NaCl plugins are, because Flash cannot strictly follow the Web origin model. And there are platform differences as well, such as on Windows where Flash requires GDI access but for other sandboxed content we block the entire win32k subsystem (including GDI).

My advice for security conscious people is to enable click-to-play in Chrome for Flash content, because it has a featureset and legacy dependencies that prevent it from ever being sandboxed as strongly as other content.

> Flash in Chrome uses PPAPI plus some private APIs that were necessary to support Flash-specific features

Thanks for the authoritative reply!

If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI?

Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI?

If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome?

Finally, can you comment on this quote from http://krebsonsecurity.com/2015/07/adobe-to-patch-hacking-te...:

> Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology

It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect?

> If Flash doesn't run under NaCl why use the PPAPI? Wouldn't libc be much more convenient, since you don't have to port Flash to the PPAPI?

I think you might have a few misconceptions. Chrome employs an outer process sandbox using OS primitives like seccomp-bpf on Linux and token restrictions on Windows. This process level sandboxing is what we use for running all untrusted content in Chrome. NaCl runs inside this outer sandbox as well, but it also applies an inner sandbox enforcing code flow integrity by verifying binaries against a subset of allowed instructions. PPAPI provides a portability layer that also serves to broker access to resources for any of Chrome's sandboxing mechanisms. So, something like PPAPI is needed for any sandboxed Chrome code, regardless of the sandboxing mechanism.

> Furthermore, I would imagine using the PPAPI directly wouldn't do much to enforce security since Flash can do whatever it likes in it's virtual address space, including jumping past checks and assert instructions in the PPAPI?

PPAPI isn't a security layer. As I mentioned above, it's a portability layer that can be used to broker resource access to sandboxed code. And PPAPI Flash is definitely sandboxed; it's just in a process sandbox that doesn't have the additional restrictions of NaCl's CFI sandbox. To explain a bit more, sandboxing in general isn't a binary state. Rather, there are varying degrees of restrictions that can be employed depending on the content, and in the case of Flash there are certain implementation details and legacy requirements that prevent it from running under the full set of restrictions that Chrome can apply to other content.

> If Flash doesn't run under NaCl, does it run under the same user and privilege as Chrome?

No, as I mentioned above Flash is sandboxed and runs at a severely reduced privilege. However, depending on the platform Flash may run at slightly greater privilege than Chrome runs e.g. Web content. And on all platforms, the Flash sandbox is less restrictive than the NaCl CFI sandbox (mostly due to the absence of CFI, but there are a few other differences as well).

>> Several reports on Twitter suggested the exploit could be used to bypass Google Chrome‘s protective “sandbox” technology

> It's frustrating that there is no source. However, the above quote would suggest that Flash runs inside NaCl. Is this factually incorrect?

The Hacking Team leaks included a Windows kernel escalation exploit against font parsing code exposed by Windows GDI. The vulnerability has since been fixed by Microsoft, but it was previously exposed to any process that could access GDI, which includes Flash in Chrome (and every other browser for that matter).

This also highlights the point I made earlier about varying degrees of sandboxing on different platforms, because Chrome doesn't expose GDI to Web content. Rather, Chrome uses a capability present in Windows 8 and above to disconnect the win32k subsystem from sandboxed Web processes, shutting off GDI and all other Win32 attack surface entirely. However, the same approach is not viable for Flash because the Windows version of Flash is coupled very tightly with GDI.

I uninstalled Flash and just pop open Google Chrome for the occasional site which needs Flash. I'm surprised by the number of sites which have HTML5 fallback for when Flash is not present now. It's a far cry from what it was a year ago.

After flipping whatever switch in about:config that enabled HD Youtube video in the HTML5 player in Firefox last year, I haven't really had any use for Flash at all.

The bare minimum any ad network should be doing before allowing an advertiser to use a Flash .swf file on their network (or even custom HTML/JS for that matter) is to whitelist certain functions and elements. They need to automatically decompile the .swf for analysis upon upload and reject it if it contains any ActionScript commands that aren't specifically whitelisted.

There is no reason for a Flash file on an ad network to be permitted to use any functions other than those necessary for basic animation, mouse/touch interaction handlers, and a navigateToURL call. The same principle applies to custom HTML/JS. Otherwise the advertiser might as well toss a bitcoin miner into their scripts; it's not like Yahoo is stopping them.

By not implementing the bare minimum of incredibly obvious basic precautions for handling mysterious executable content before spraying it indiscriminately across the entire web, Yahoo's incompetence borders on malice and in my mind that makes them complicit in these crimes.

Do you know if any ad networks actually manage to do this?

This strikes me as an extremely hard problem. ActionScript supports an eval() function, which should make static analysis almost impossible - how can you tell if someone is compiling together an evil string (that calls functions you have banned) and then passing that string to eval()?

We (ClarityAd) do this for major ad platforms. We use a mix of static and dynamic analysis to assess risk. We've been able to detect and stop major exploit kit campaigns over the last few months. Ads have specific expected behaviors and their SWFs are not supposed to generate code dynamically.
ActionScript is, as I understand it, a lot like Javascript, and that solution won't work for Javascript because there's too many ways to execute code. For a whitelist like that to even have a chance it would have to be implemented in the runtime itself as a sandbox, and even then I'd be skeptical about its effectiveness in JS.

(Retrofitting sandbox-ness onto a dynamic language is on the list of things that are really hard to retrofit onto an implementation that wasn't designed for it, whereas if you design for it from day 1 it isn't necessarily that difficult.)

Note that there are open-source alternatives to Adobe's official Flash Player:

https://en.wikipedia.org/wiki/Gnash

https://en.wikipedia.org/wiki/Lightspark

https://en.wikipedia.org/wiki/Swfdec

They haven't been updated to support the latest features, but could be a good solution for those wanting to play old Flash games and the like. The chances that they have the same vulnerabilities as Adobe's implementation is low.

So I'd be able to use these to watch old Homestar Runner cartoons? Sweet.
I've had good success using Gnash to watch Homestar Runner.
Those of us running adblockers and/or who have deinstalled flash remain blissfully unaffected. The ad industry needs to get its shit together.
> The ad industry needs to get its shit together.

When I have brought this up at work in ad-driven companies, the numbers I have seen basically show that the worst ads are the most effective and they don't give a fuck, and we let them.

And that's why I don't feel one iota bad about running an ad blocker, because in today's world, it's more effective and important at protecting against Malware and Identity Theft than anything else.

I think I will use flash only inside some disposable VM... I'm getting really sad when hearing yet another problems with this increasingly useless plugin...
This is so sad. I like Flash for several reasons and just few days ago I heard that Adobe is trying to get its potatoes together and that they're working on security patches hard. Oh well...
The patch for this exploit was released by Adobe a month ago, within 48 hours of discovery. They always fix such exploits extremely quickly.
So the reason "everyone" is complaining about or flat out hating Flash is that they have security holes to begin with?
I set the Flash plugin settings in Safari to "When visiting other websites: Ask" so that it only runs after explicit permission via popup window has been granted. Two things jumped out at me:

1) How many sites call the flash plugin while doing nothing of any value with it (tracking and ads are not considered of value). Every time you deny permission, a line is added in the prefs window with a "block" statement at the end, and this list is getting quite large...

2) How few websites actually need flash to be useful

Almost nothing of value has been lost.

How much responsibility do you think Yahoo deserves for this? Personally I think they bear the brunt of it, since they're in the best position to prevent the malware distribution.
I've removed it immediately after reading the Hacking Team story and never looked back
For those that have been saying there is no reason to need flash. I was recently surprised to find out that if you want to provide clipboard controls like the copy button on github next to the repo url, flash is the only way I think you can do that. I think there is a clipboard API in Chrome canary but I'm pretty certain it isn't available to the general population yet.
I have not run flash on my computers for some time now. If I come across a site that requires it for content display or playback I go elsewhere. Simple as that.

If a critical mass of people stop using it then those sites will switch to something else. And Apple has proved this already.

I use a handful of services that still rely on it, but I'm happy with click-to-activate for them.