Community Discussions

Connect with other Roku users to learn more about streaming, cord-cutting, finding your favorite content, or talk about the latest entertainment happenings. It's all on Roku!
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 13

Security issue: CVE-2019-11479 -- Roku impacted?

Netflix has reported four different vulnerabilities with Linux system/devices which have the TCP Selective ACKnowledgement (SACK) feature enabled.  Because SACK is generally accepted as improving network performance, it is enabled by default unless a specific vendor of a device chooses to disable it.  But, for those that do use SACK, the developers of the Linux kernel have already produced an update to address the flaw.

Of the four vulnerabilities, most are not that interesting from a Roku perspective.  Instead, they would only result in the Roku crashing and the owner needing to power cycle the Roku (if it doesn't reboot itself automatically).  But the fourth "exploits cause the system to consume large amounts of bandwidth."

If I understand the vulnerability description correctly, even if the Roku player is using SSL/TLS, the TLS encryption does not need to be broken to take advantage of the vulnerability.  The reason is that TLS only protects the layers after TLS decryption such as the video decoder from getting modified or illegitimate packets.  In the case of a TCP layer exploit, the processing of the exploit takes place *before* the packet is handed to the TLS stack.  The only thing the attacker needs to know is an existing TCP session is coming from a Roku, what IP address the packets are going to/from and what the TCP sequence number.  In the case of a shared network such a hotel or dorm wireless, all three of these are available to everyone on the network.  For example, all network packets with a MAC address starting with 08-05-81-xx-xx-xx are from a Roku.  Then the attacker can masquerade as the other IP address and TCP sequence number to take over the session and issue the exploit.

A "for the LOLs" anarchist attacker on the same hotel or dorm network can leverage this issue while leaving the Roku owner responsible for the resulting network bandwidth generated as a result.

Roku's own knowledge base indicates the Roku should be fit for use in a hotel or dorm: ... -internet-

I feel to continue to satisfy what is implied by a Roku being fit for use on a shared network, it is desirable for Roku to provide an official response at some point for this specific issue (even if it is just to disable SACK in the short term).
0 Kudos
Community Streaming Expert

Re: Security issue: CVE-2019-11479 -- Roku impacted?

Not to discount the potential here, but most hotels block wireless devices from seeing other devices on the network. So staying in a Hilton or Marriott likely doesn't make you a target to attack. Dorm rooms are an entirely different matter. While this forum isn't considered the best method to reach the Roku developers, hopefully the moderators will pass it on. From what I've heard, Facebook and Twitter gets faster responses. 

Roku Community Streaming Expert

Help others find this answer and click "Accept as Solution."
If you appreciate my answer, maybe give me a Kudo.

I am not a Roku employee, just another user.
0 Kudos
Level 13

Re: Security issue: CVE-2019-11479 -- Roku impacted?

Wireless private vlan mode assumes everyone is playing by the rules.  It doesn't stop a tools like kismet from sniffing the traffic to get the source and destination IP address and the TCP sequence number, other tools can allow injection of packets directly or using the information to issue masquerade packets externally.  While the BCP #46 (Best Current Practice) document from the IETF should have put an end to external IP masquerade attacks a long time ago, we are far from every ISP and hosting provider honoring it.

This attack does not seem to be commonly in the wild... yet.  But it doesn't seem it would be that hard for someone to create tools to perform and automate.  The how large the target population of systems and devices to this type of attack, I do expect to see someday there be someone that enables the "script kitty" community with this.  I don't see hotel's clicking the checkbox for private vlan mode as being a strong enough replacement for applying the patch to the devices or mitigating the flaw by disabling SACK.

As to getting a faster response via social media, I was aware of that as an option.  I am not looking to shame Roku through social media to get an immediate response.  Right now I am much more comfortable discussing this on a forum that Roku has direct control over.  If that means I don't see any response this week, I am alright with that.  However, should it come to pass that Roku remains unresponsive for a lengthy period of time, I will keep my options in mind.  But please keep in mind this is an industry wide problem.  There is every reason to believe products from Google and Amazon need to be updated to address this as well.  I'm only picking on Roku because it is the device I personally use and care about.  I am not claiming there is any "better" alternative.
0 Kudos