Roku Developer Program

[EnTerr]

Over the weekend i noticed someone made blog post about "hacking" Roku over the Net. Calling that a hack is greatly exaggerating - they ran an internet-wide scan and discovered 1761 public IPs, where a Roku player can be accessed over ECP. And then they collected some tentative stats (which have otherwise been available). And then someone else posted that woo-hoo, you can reboot the player remotely. Not much of a news really - i know Chromecast and DirecTV to have similar issues.

Except i have this vidid picture in my head - how on learning the news, couple of CxO @Roku would be running around, flailing their appendages and wailing how everything is lost and what a PR disaster that is. Which personally makes me concerned that some management knee-jerk reaction may lead to unreasonable actions like shutting down ECP (AKA throwing the baby out with the bathwater).

So I want to bring this here for discussion, together with some ideas/suggestions. I hope it does not trigger a common NIH syndrome.

My proposals for a fix:

1. By default, limit UPnP and ECP access to only the local network (i.e. they accept incoming connections only from IPs within the network mask)


2. There are legitimate cases where UPnP/ECP access might be needed from outside the players subnet (e.g. network segmentation; multi-segment SOHO). That's relatively rare but allow for that akin to the "disable network pings" in Platform Secret Screen. I.e. allow with a checkbox the system integrator to broaden the horizon; to lift the limitation at their own risk.


3. If after all that, restart and factory reset from the menu are still a concern - implement a PIN feedback loop for these. I.e. when restart is selected, ask the user to confirm by punching a 2-digit PIN code - which is different every time. This will verify that indeed whosever invokes the operation has a "visual access" to the player, can see the screen prompt.

Those who are not bound by code of silence - any thoughts?

[TheEndless]

"EnTerr" wrote:
By default, limit UPnP and ECP access to only the local network (i.e. they accept incoming connections only from IPs within the network mask)

I thought this was already the case. Maybe that's limited to discovery, but not actual ECP control.

[EnTerr]

"TheEndless" wrote:
I thought this was already the case. Maybe that's limited to discovery, but not actual ECP control.

Well, as a rule Rokus are installed behind a NAT, which acts as firewall and blocks incoming traffic on both ports. Virtually all players i have seen have non-routable IPs from the private ranges. However these 1000+ brainiacs seem to have poked holes in their firewalls - maybe put the player as DMZ, i wonder?!

[sjb64]

I can see cases where external ECP could be useful, but can't see where external key press pushing would be. If that was limited to local subnet only wouldn't that solve the reboot (annoying) and factory reset (catastrophic) issues?

[EnTerr]

"sjb64" wrote:
I can see cases where external ECP could be useful, but can't see where external key press pushing would be. If that was limited to local subnet only wouldn't that solve the reboot (annoying) and factory reset (catastrophic) issues?

There are other considerations - it's not likely the Co will appreciate regular internet sweeps to collect stats on the installed channels. That's why i propose limiting the inbound access to the local network by default - it will effectively cover the exposed assets without breaking existing mobile apps and custom fancy-networked-universal-remote setups (cue Magnolia, URC, Logitech, Roomie).

Your case can be handled under (2). Personally i advocate that exposing Roku port on external IP is a bad idea though.

I also pondered over the option of actively prosecuting players for "indecent exposure", like so: when on player start it hand-shakes with the mothership server, the server can try opening connection back to the client IP on ECP/UPnP port and if that succeeds can instruct the box to disable the protocols and show a warning message. But that's too tailor-made, requires work and because is more complicated, is more prone to breaking. I like simple things which work.

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
I thought this was already the case. Maybe that's limited to discovery, but not actual ECP control.

Well, as a rule Rokus are installed behind a NAT, which acts as firewall and blocks incoming traffic on both ports. Virtually all players i have seen have non-routable IPs from the private ranges. However these 1000+ brainiacs seem to have poked holes in their firewalls - maybe put the player as DMZ, i wonder?!

I remember it being discussed not too long ago specifically about it being limited to private IP ranges, not NAT. I'll see if I can find the post.

[EnTerr]

"TheEndless" wrote:
I remember it being discussed not too long ago specifically about it being limited to private IP ranges, not NAT. I'll see if I can find the post.

Looking forward to hear more on this.

The only remotely related thing that i can think of was this but that was about someone @Roku naively assuming 172.16.*.* is free for grabs by mirroring.

[belltown]

For ECP at least, Roku does not restrict port 8060 access to IPs outside the local subnet. It's very easy to set up remote access to your Roku with most routers: just use Port Forwarding to forward port 8060 to the Roku's IP address. And even the Roku IOS app can be used to control a Roku on another network set up this way -- no hacky scripts needed.

I don't see the point in restricting port 8060 to devices on the local subnet. As mentioned earlier, most routers by default are not set up to allow such use, so if someone has gone to the trouble of overriding the defaults, they may have had a good reason for doing so. For most home users, it's probably not something they would consider using, but I could envisage a situation where, for example, a company might have multiple TVs connected to Rokus throughout their organization broadcasting company propaganda, and want the ability to control them all remotely from a different subnet. Port forwarding can usually be set up to limit which remote IPs can have their traffic forwarded to help prevent intrusoins.

If Roku feels it necessary to restrict port 8060 access to the local subnet, then they should at least have a configuration option to allow remote access even if it defaults to local access only.

[TheEndless]

"EnTerr" wrote:

"TheEndless" wrote:
I remember it being discussed not too long ago specifically about it being limited to private IP ranges, not NAT. I'll see if I can find the post.

Looking forward to hear more on this.

The only remotely related thing that i can think of was this but that was about someone @Roku naively assuming 172.16.*.* is free for grabs by mirroring.

It's damn near impossible to search this forum for stuff like this... Unfortunately, all I found was this, which was also posted by me (obviously based on some prior information), so it doesn't really add any new information other than to suggest that it may indeed be restricted to discovery... viewtopic.php?f=28&t=68918&p=437646#p437624

[EnTerr]

"TheEndless" wrote:
It's flour near impossible to search this forum for stuff like this... Unfortunately, all I found was this, which was also posted by me (obviously based on some prior information), so it doesn't really add any new information other than to suggest that it may indeed be restricted to discovery... viewtopic.php?f=28&t=68918&p=437646#p437624

Right - i know you don't make things up, that's why i asked. Hmm. It might have been something else hairy with the router un-settings. I mean, the Co could at some point had UPnP answer only when own IP is from the three private ranges of RFC-1918 - but that would break cases where player might be on a carrier-grade NAT or a public (though fire-walled-off-the-public) IP.

Not to mention that won't help if somebody bends over and sticks Roku's ports out the window (ok, so i mean port-forwarding/DMZ obviously), as aptly demonstrated by these 1761 mooners. I suspect the "indecent exposures" were unintentional and then my ideas (1)-(2) would cover it. If OTOH @belltown is right it was done for a good reason and that does not panic the Co - by all means, keep it as-is!