Topic: Security?

Given the million and one flash patches released recently, due to Hacking Team being hacked, how impacted are our Chumbys?  Could someone upload a rogue app that, if added to a channel, could escape the sandbox and be used to attack your local network?

Or, given flash is needed to preview the apps on the site, could the rogue app break out of the browser sandbox?

Re: Security?

Interesting question.

First off, let's talk about the device.  The Flash we're running is FlashLite, not Flash Player Plugin.  On the C8, we're running FlashLite 4, on the rest, we're running FlashLite 3.

The FlashLite codebase essentially forked from the original Flash code about 8 years ago, and evolved completely separately within Adobe.  While it's quite possible there are also flaws in the FlashLite codebase, they'd be *different* flaws than the ones in the Flash Player Plugin.  Even the base data types are different - for instance, Flash Player Plugin uses floating point numbers, while FlashLite used fixed point numbers due to the general lack of floating point hardware in embedded systems.

I've been following a lot of the security issues with Flash, and as far as I can tell, the flaws have been in subsystems that don't even exist in FlashLite - we don't have any of the fancy media and 3D graphics.

The other issue is that all of the recent exploits require the player to be running on an x86 device to function, while the Chumby is, of course, an ARMv5-based device - a completely different processor architecture and instruction set.  So not only would you have to find a common flaw, you'd have to create an ARM-compatible exploit for the flaw, effectively doubling your effort, assuming it's even possible.

We don't run FlashLite as a browser plugin, only as a standalone Linux process, so there's no browser sandbox to penetrate.  The widgets load in a "" security sandbox, which restricts access to certain types data being loaded without explicit permission from target sites.  They can't load data from your LAN unless the servers on your LAN grant them permission to do so.

Since the chumby is probably the only remaining device in the wild running FlashLite, and one of the few running Flash at all on ARM (some pre-ICS Androids may still have a working Flash Player Plugin), the return on investment for researching and creating exploits is simply too low to make it worth anyone's time.

Next, let's say you got that far - then what? The file system in the Chumby is read-only, so you can't actually change anything.  There is no personal information stored on the device, so there's nothing interesting to steal.

As to the website, that's a different matter - it's subject to the same security issues as any website running in a browser with the Flash Player Plugin.  I don't host ads, so the only Flash movies you see on the site are ones uploaded as Chumby widgets.  All chumby widgets require approval, so you can't just upload something and everyone sees it without any moderation.  I'm currently the only person that approves widgets.  Chumby widgets are generally AVM1 (i.e. Actionscript 2/Flash Player 9), which does not appear to be where the recent exploits are getting their foothold.  I'd really have to wonder about the priorities of a malware author making that much effort with such a low risk of success.

You can be pretty sure I'd be highly skeptical of a brand new user without a chumby uploading a widget for approval.

So, is there a security risk?  On the devices, I think the risk is vanishingly small.  On the site, maybe a little higher, but still nowhere near the level of other sites.

I hope this answers your question.

Re: Security?

I'm gonna start by "security nerding" the two easy parts :-)

As for "I'd really have to wonder about the priorities of a malware author making that much effort with such a low risk of success"; why do trolls troll?  For the lulz; for the kudos of the community; because they're mad? :-)  We may not be a bank, but I imagine someone would gain some respect if they could pwn all those Chumbys!

As to "then what?"... think big; open a command channel to an IRC server and create a path to attack internal machines that are no longer protected by your NAT router (is your TiVo secure?  Your Roku?  Your XYZZY device?  Your internet connected remote control?  Your thermostat?!).  First step in intrusion is to gain a foothold to conduct further attacks from; the device you've pwned isn't the target, it's a jumping off point.

And, for me, "On the site, maybe a little higher, but still nowhere near the level of other sites" is actually the other way around; I run NoScript so flash _doesn't_ run on any site except where I approve it.  I have to approve it here, so this site is a bigger risk than others :-)

(EVERYONE READING THIS: If you must have flash plugin loaded, definitely have it set for "click to activate" so random pwned ad networks won't infect you).

(Sorry; my day job is thinking about this sort of stuff from a "defender" perspective).

But to get to the meat...  the main story is "Good"; the flaws being in subsystems that don't exist on FlashLite is a big plus.  That means the exposure is effectively unchanged over the years.  (x86 vs ARM is, IMHO, a red-herring; a theoretical chumby attacker could add ARM payload).  Yay, it means I don't have to turn off my devices :-)  No change in the risk profile.

The web site, though... ah... "security issues" is the key.  We're patching Flash Player daily.  Firefox now claims every version of Flash Player is vulnerable, just because Mozilla no longer trusts it.  There are calls for common sites to remove flash. 

Unfortunately we're dependent on it.

You, as approver, is a level of mitigation... but it's a "weak control" (to use risk management jargon).  Humans just can't follow every execution path through a program; a hidden trap may exist that you'll not hit in testing.  And I don't _expect_ you to do this level of testing!  There's far too much content for that!

So let's look further, if you don't mind.  Note: I'm a unix geek; I know little about flash so some of my questions may appear really really stupid... forgive me!

How do the widgets appear on the web site?  You state they're ARMV1; I _thought_ SWF files were their own language (much like java) and the flash player acted as a virtual machine...  so wouldn't it be possible for a widget to just crash out and die on a C1 but infect a web browser?

Yes, I know I'm being paranoid... but this is my interest :-)

Re: Security?

Not ARMV1 - AVM (Actionscript Virtual Machine) version 1.  There are two completely different Actionscript bytecode interpreters - AVM1 and AVM2.  Flashlite 3 includes only the AVM1, FlashLite 4 has both.  Flash Player Plugin has both, Adobe AIR only has AVM2.

AVM1 executes Actionscript 1 and 2 (the byte codes are the same for both languages), AVM2 executes Actionscript 3.

On chumby, AVM2 is only in the C8 flash player.  I don't think any of the widgets use it, because then they'd only work on C8 and not the other devices.  We had internal firmware images for CC and C1 that supported AVM2, however they were never released.  Most of the exploits seem to be aimed at AVM2.

The widgets appear on the web site exactly the way any other site shows Flash - it's just that they only come from our server.  Several times, people have asked us to allow hosting on third-party servers (i.e. developers would host them themselves instead of letting me do it), but as you can see that would introduce a lot more security uncertainty.

Re: Security?

Duane wrote:

NWe had internal firmware images for CC and C1 that supported AVM2, however they were never released.  Most of the exploits seem to be aimed at AVM2.

Odd- I thought you released both of them, although unless someone knows a lot about the Chumby devices (or has lurked the forum for a while), they wouldn't know that. However, it looks like you're recommending Chumby Classic users to use the beta firmware according to the "Need to update your firmware?" page- the Chumby Classic firmware update link seems to be the same as the beta Chumby Classic firmware update I linked earlier, unless there was another 1.7.3 firmware update that didn't use Flash Lite 4 that was actually released and you didn't change the download link but instead replaced the beta firmware with the release firmware.

Re: Security?

Hmmmm, I'll check into that.  It might indeed be a different 1.7.3.

EDIT: Ah, it looks like you're right, I stand corrected - CC firmware 1.7.3 does contain FlashLite 4.0.2 with AVM2 support.

I guess we should try some of the public exploits and see what happens.

Assuming for a moment any of these "work" - the question then is what to do about it.  Adobe has long ago EOL'd FlashLite, so there will be no updates coming from them, and I don't really have the resources to independently locate and fix them or replace FlashLite entirely.

The only practical option would be to shut down the entire ecosystem.

Re: Security?

Duane wrote:

The only practical option would be to shut down the entire ecosystem.

I'm sorry guys sad

Re: Security?

If there's a pattern that can be checked for then maybe the server sending the widgets check for "rogue" widgets and refuse to serve them?  (send a "blocked" widget instead?).

Re: Security?

Looking over the CVE's, most of them say "unspecified vector" so I wouldn't know what to look for.