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:
https://support.roku.com/article/215058 ... -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).
