New Chrome beta poses security risks

The new Chrome version recently released by Google in the project’s beta channel could pose substantial security risks because of its new capabilities for accessing multimedia hardware of the computer, IT experts warned.

Mountain View shipped the new Chrome beta with the first implementation of the getUserMedia API, a JavaScript interface designed to let HTML5 web “applications” to directly access the PC’s camera and microphone with no need for an external plug-in like the ubiquitous Flash Player by Adobe.

Google presented getUserMedia API as the first, tangible step in the WebRTC project, “a new real-time communications standard that aims to allow high-quality video and audio communication on the web”. But the ability to access a computer’s camera and mic with full control over the hardware is a security risk that could overshadow the “cool new experiences” Google is touting for Chrome, experts suggested.

Trend Micro’s Rik Ferguson describes the getUserMedia tech as especially attractive for cyber-criminals and malware writers. “We have already seen both banking malware and of course targeted threats that make use of the video hardware of the victim through the installation of malware”, Ferguson states, and thanks to the new HTML5 API “the criminal simply has to make a JavaScript that requests access to the video and/or audio hardware”.

With the getUserMedia API there is no need to create a (hidden) record of the conversation or video footage from the PC’s camera to upload on-line, Ferguson explains, because the JavaScript code will simply stream the audio and video feeds back to the cyber-criminal directly from within the browser window.

Sean Sullivan, security advisor of F-Secure, is unimpressed and worried about getUserMedia too: Sullivan fears in particular new “click-jacking” malware, malicious code that could automatically enable the audio&video recording by simply “hijacking” the confirmation clicks from the user’s browser.

Another reason for being worried about the new API is the effort made by Google to secure its backend code: “Imagine if you were to use voice search”, Sullivan said, “but somehow the mic failed to stop recording and collected too much information – à la Google Street View”. Talk about another gigantic privacy failure like the one that haunted Google legal counsellors worldwide.

Source: The Inquirer.

Report a problem with article
Previous Story

Android malware found and removed on Google Play

Next Story

Mountain Lion to drop support for older Macs

20 Comments

Commenting is disabled on this article.

I think the solution to this is to have a button on the webcam hardware that the software will ask you to press to confirm you wish to use your cam and if you don't press it, the webcam doesn't send any data?

still1 said,
it will ask for permission!!! whats the big deal here.

That permission request dialogs might be hijacked, like they were with Flash.

ichi said,

That permission request dialogs might be hijacked, like they were with Flash.


might be??? there is no claim about that anywhere I can see of

ichi said,

That permission request dialogs might be hijacked, like they were with Flash.

How can they be? if they're anything like the location prompt, they won't be a part of the DOM, and instead be an alert bar at the top of the browser window. It would be very hard to hijack something that's floating above the renderer itself.

As a potential solution, they should have a very visible indicator, like turning the toolbar red, and having a flashing "mic" or "video camera" icon to indicate that the hardware is being used, and clicking on the icons allow you to stop the application.

Problem solved! Everybody's happy.

Enron said,
I always feel like somebody's watching me.

If it has ANYTHING to do with Google/Chrome, it IS watching you, and VERY closely, I might add! Personally, as far as I'm concerned, both Firefox and Chrome are security risks all by themselves!! Will NEVER use either.

Opera has the same thing..But it asks for permission first, seems to work pretty good..(I'm sure Chrome does too, but I don't use Chrome )

flexkeyboard said,
HTML5 proves that's it's not better than what it want to replace (flash)...it's actually worse.

I agree but as a developer, I think it'll be better than flash but would like it to be in say an external .dll/.so and with an easy option to disable it completely and option to enable it ONLY on specific sites only with maybe a seperate start up 'Start Chrome/Firefox with JS-Cam'.

flexkeyboard said,
HTML5 proves that's it's not better than what it want to replace (flash)...it's actually worse.

Well, from what I just read it's more how Chrome is attempting to utilize it that poses a security risk...
You can misuse any language or platform and open up security issues for yourself- if they're going to be making it for the masses, they should focus on it's security though. It seems like things like this always happen when someone/something gains a lot of users.

n_K said,

I agree but as a developer, I think it'll be better than flash but would like it to be in say an external .dll....

And now how's that different than say NPSWF32/64.dll? It's the same thing! What I'm more afraid of is HTML5 Storage (HTML5 Cookie). There's a huge potential risk when (if not already) the bad guys misuse it. There's no way to monitor how's it being used. With regular cookies, user can detect and block it. But with HTML Storage, it's completely bypasses the user's control.

flexkeyboard said,
HTML5 proves that's it's not better than what it want to replace (flash)...it's actually worse.

Yes and no, but primarily No...

Flash can be 'contained' which can make it rather secure, look at the Flash integration on Windows 8 for example, it is running inside its own brokered sandbox.

HTML5 is only as secure as the 'browser' implementing it. This is true of ANY technology.

What is laughable is the security concerns for 'hardware' access via WebRTC, yet people ignored the same security warnings concerning WebGL, which allows low level GPU access that can be exploited to do simple things like pull screen information to installing root level software through GPGPU manipulations.

(WebGL can also target specific GPU glitches to literally fry a person's GPU as well as other components. For example circumvent thermal reactions, fan control, and send the GPU on a loop creating insane heat and failure.)

Yet after all these warnings people install Chrome and Firefox with WebGL support and don't care that web sites are taking screenshots of their desktops and other windows. (Demonstrated on OS X, Windows, and Linux)

WebGL btw is NOT HTML5, which has its own 'secure' shader and GPU access specifications, but since Google cannot shove pixels around fast enough to compete with IE9 or IE10, their cute IEFish demos using WebGL made it popular.

flexkeyboard said,
HTML5 proves that's it's not better than what it want to replace (flash)...it's actually worse.

No, this really just a poor article. Chrome obviously asks for webcam & mic permission before granting these media streams to a website. Just like how it does today with location requests.

flexkeyboard said,

And now how's that different than say NPSWF32/64.dll? It's the same thing! What I'm more afraid of is HTML5 Storage (HTML5 Cookie). There's a huge potential risk when (if not already) the bad guys misuse it. There's no way to monitor how's it being used. With regular cookies, user can detect and block it. But with HTML Storage, it's completely bypasses the user's control.

Again, this is NOT an HTML5 security failure, this is a security failure of HTML5 engines.

Implementation issues that need to be further defined are hitting problems with the nature of technologies.

There is a lot of specifications that are too vague and say needs to do abc, yet how abc is done is also important and needs to be part of the specification.

We also have a problem with the base engine models that Chrome and Firefox will NOT ditch, even though they realize they will eventually have to make the jump.

thenetavenger said,

We also have a problem with the base engine models that Chrome and Firefox will NOT ditch, even though they realize they will eventually have to make the jump.

This part I don't understand...can you explain further what you meant?

thenetavenger said,

Again, this is NOT an HTML5 security failure, this is a security failure of HTML5 engines...

That's a pretty paradoxical thing to say. It's like saying there's no Flash security failure, just the security failure of Flash's engine.

n_K said,

I agree but as a developer, I think it'll be better than flash but would like it to be in say an external .dll/.so and with an easy option to disable it completely and option to enable it ONLY on specific sites only with maybe a seperate start up 'Start Chrome/Firefox with JS-Cam'.

I'm a developer too, and if that happened, I would think the average (non-tech-savvy) computer user wouldn't have a clue of what that means. ... Of course, if the website that wants access tells the user about this separate start-up option and tell them they need to use that on this website instead, then maybe it would work...