To Listen Without Consent – Abusing the HTML5 Speech

tl;dr;
I found a bug in Google Chrome that allows an attacker to listen on the user speech without any consent from the user and without any indication. Even blocking any access to the microphone under chrome://settings/content will not remedy this flaw.

Try the live demo… (Designed for Mac  though it will work similarly on any other OS)

Watch the video…


The Sisyphus of computer science

Speech recognition is like the Sisyphus of computer science. We came a long way but still haven’t reached the top of that hill. With all that crunching power and sophisticated algorithms, computers still can’t recognise some basic words and sentences, the kinds that the average human digest without breaking a sweat. This is still one of the areas that humans easily win over computers. Savor these wins, as it will not last much longer;)

One must appreciate Google for pushing this area forward and introducing speech recognition into the Chrome browser. The current level of speech support in Chrome allows us to create application and websites that are completely controlled form speech. It open vast possibilities – form general improved accessibility to email dictation and even games.

The current speech API is pretty decent. It works by sending the audio to Google’s servers and returns the recognised text. The fact that it sends the audio to Google has some benefits, but from applicative point of view it will always suffer from latency and will not work offline. I believe that the current speech support was introduced with Chrome 25. From Chrome 33 one can also use Speech Synthesis API. – Amazing!

But…
Before this fine API we currently have, Google experimented with an earlier version of the API. It works quite the same, the main difference is that the older API doesn’t work continuously and needs to start after every sentence. Still, it’s powerful enough and it has some flaws that enable it to be abused. I believe this API was introduced with Chrome 11 and I have a good reason to believe it was flawed since than.


More Technical Details

Basically, this attack is abusing Chrome’s old speech API, the -x-webkit-speech feature.
What enable this attack are these 3 issues:

  1. The speech element visibility can be altered to any size and opacity, and still stay fully functional.
  2. The speech element can be made to take over all clicks on the page while staying completely invisible. (No need to mess with z-indexes)
  3. The indication box (shows you that you’re being recorded) can be obfuscated and/or be rendered outside of the screen.

The  POC is designed to work on Chrome for Mac, but, the same attack can be conducted to work on any Chrome on any OS.

This POC is using the full-screen mode to make it easier to hide the “indication box” outside of the screen.
It is not mandatory to use the HTML5 full-screen; it’s just easier for this demo.

As you can see in the demo and video there is absolutely no indication that anything is going-on. There are no other windows or tabs, and no some kind of hidden popup or pop-under.
The user will never know this website is eavesdropping.

In Chrome all one need in order to access the user’s speech is to use this line of HTML5 code:
<input -x-webkit-speech />

That’s all; there will be no fancy confirmation screens. When the user clicks on that little grey microphone he will be recorded. The user will see the “indication box” telling him to “Speak now” but that can be pushed out of the screen and / or obfuscated.

That is enough in order to listen to the user speech without any consent and without giving him any indication. The other bugs just make it easier but are not mandatory.

(For the tree in the demo I have used a slightly altered version of the beautiful canvas tree from Kenneth Jorgensen)

— The bug was reported to Google.

grey_mic

31 thoughts on “To Listen Without Consent – Abusing the HTML5 Speech

  1. Anyone that buys a chromebook should know they’re giving away everything that goes into and out of that computer by any means, as often as possible.

    1. But Google does nothing wrong with your data other than provide ads so they can at least make SOME money. Considering all the services are free, that’s not a bad deal. $200 for a laptop that will browse the web, and has a 8 hour battery life?

      Virus free? Geez old people proof.

        1. @Hene, thank you for testing it on Window 8.1. I don’t have this version of Windows so I couldn’t verify it myself.

          1. Mac user over on Reddit also says that it didn’t work for him. There must be an extra factor that we’re missing that causes it to work/not work. Also, the bug link seems to be gone now – did Google hide the bug report?

          2. @Peril , I can assure you that the PoC is fully working on the mac, I just saw it working on other macbooks.

  2. @Seppo Yli-Olli, Google hides the security bugs until it is fixed or until it is declared as not-a-bug. It’s only available for the reporter and the internal google crew.

    @David, good point, and my reason is mostly because:
    Google, as all developers, have a tendency to dismiss the not so obvious security bugs. From my own experience and from looking at many other bug reports to them. This kind of bug could have been marked as just a UX (User Experience) bug and not as a security bug.
    I won’t share the internal discussion, but I can tell you that it got much more attention as the interest about the issue started to rise.
    I do not believe it will be dismissed at this point and it seems like they started to look for a way to quickly mitigate this flaw.

  3. Seems on windows NOT working. On my XP do not work using chrome.
    Maybe it is a bad implementation on MAC chrome.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>