eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Every summer, the annual Black Hat USA security conference trots out a conga line of security experts, many of them with zero-day exploits in hand. More often than not, those exploits get fixed in a relatively short period of time after the conference ends, but not always.
Case in point is a Google Chromecast security vulnerability first publicly demonstrated at the Black Hat USA event last year. Chromecast is Google’s popular media streaming device. In the Arsenal tools showcase as part of Black Hat, Dan Petro, security researcher at Bishop Fox, demonstrated a Chromecast hack and tool called the Ricmote. Now a year later, Petro’s Chromecast vulnerability remains unpatched and is likely to remain so for a variety of reasons.
With his Chromecast hack, Petro publicly demonstrated (see the eWEEK video here) how a small Raspberry Pi ARM computer he dubbed the Ricmote could abuse Chromecast’s functionality and send an arbitrary video to a Chromecast user. As part of the Chromecast takeover, Petro’s device streamed Rick Astley’s “Never Going to Give You Up” music video in an attack known as rickrolling, though Petro noted that any content could be sent.
In an interview with Petro ahead of Black Hat 2015, he told eWEEK that from where he sits, it isn’t likely that Google will fix the Ricmote vulnerability at all. Petro said there isn’t a great way of fixing the flaw without impacting usability in a way that would be unacceptable for how Google wants Chromecast to work.
“It’s part of a design choice that Google made, and Chromecast is going to be ‘rickrollable’ indefinitely into the future,” he said.
The way the setup works is intended to make it easy for users to quickly get a Chromecast up and running, which is where the Ricmote vulnerability comes into play. An attacker needs to access the initial SSID broadcast from the Chromecast to execute the attack. If Google changed its setup to not enable the initial SSID broadcast, no doubt it would be more difficult for users to set up their Chromecast.
In addition, for the Ricmote attack to work, the attacker needs to be relatively close to the Chromecast, so this isn’t a remotely exploitable attack. Plus, there is no indication that the Ricmote gets access to user information or passwords on the Chromecast.
So, while the Ricmote issue is a vulnerability that can be exploited, the exploit is more of a nuisance than an issue that could leave Chromecast owners exposed to a real risk.
That’s the thing about Black Hat—and vulnerability disclosure in general. The simple truth is that not every bug or vulnerability is something that really matters even if an attacker is able to exploit it. In the case of Chromecast, Google’s inaction shows that it isn’t really worried about the actual risk to users of being rickrolled. Despite the public demonstration at Black Hat of the vulnerability, it isn’t worth the trouble of making a major usability change to Chromecast.
Considering that I have yet to see any widespread reports of Ricmotes being used to inconvenience Chromecast users, I suspect that Google isn’t wrong either.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.