This is not google, but a third party ad network serving ads through google.
Google tries to sandbox the creatives in an attempt to prevent issues exactly like this, and develops browser features to prevent issues exactly like this.
This is likely a script that somehow avoided google's malware scanning pipelines.
This is definitely not google's malintent.
Disclaimer: Ex googler, worked in ads, dealed with problems like this all the time.
> This is likely a script that somehow avoided google's malware scanning pipelines.
I can't think of a good reason for scripts through google ad syndication to be asking for camera and microphone permissions. I'd assume Google runs these scripts in something like a lab environment to see what's ultimately invoked before deploying them to production? If so, would this be indicative of both a deliberate controls bypass and a ToS violation by the ad network?
Sounds like Google Syndication may have taken care of this by enabling Permissions Policies(1) across its domains? I can't tell because the article references Feature Policy (a predecessor to Permissions Policies(2)) "in Safari" even though Feature and Permissions Policies, as best as I understand them, are delivered from the origin for implementation by the browser. So I'm kinda confused.
And if they don't implement it, it tells me they're totally fine with this kind of fingerprinting.
A prior version of this comment suggested Google should add permissions policies. I since edited it to clarify that I'm quite confused over whether it's something Google already implemented or something Safari overlaid on top of Google syndication origins since I can't verify using the origins themselves. The article seems to suggest it's something Safari specific even though the spec for both FP and PP involves receiving a set of permissions from the origin as a header and implementing them in the browser.
Yes - banner ads are constantly targeted by malicious actors. My employer pays a vendor something like $200k/mo for creative scanning to avoid issues like this. Google certainly spends tens of millions a year trying to avoid issues like this.
Hey, if you want, you can give me $200k/month and I'll scan your ads to make sure they're just flat fucking image files without any arbitrary bullshit code
Doesn't seem like a great example since the image itself is perfectly safe. The exploit still needs JavaScript to extract and execute the payload embedded in the image, and then relied on Flash to install malware. Without JavaScript it's just an image like any other.
The NSO group iMessage exploit is a more interesting example, essentially turning a poorly bounded JBIG2 decompressor into a virtual machine.
haha, if a country wants to spend a 9 figure sum or someone comes back in time from the future to hack me, I'll be happy to consider myself pwned
It's a huge bummer that I HAVE TO block all ads as a security measure, though, and that people accept "Download advertisement.exe and run it in a half-assed sandbox or you're stealing that clickbait article" as the way things should be
After the initial investment in developing the exploit and before the vulnerability was patched, there would have been a near zero cost to hack any one user in particular.
This gets a lot harder to pull off when the images are transcoded by being decoded in one sandboxed process that outputs a bitmap, then encoded in another sandboxed process that outputs what ultimately reaches the user.
Do ad syndication networks like Google transcode images provided by advertisers? When an advertiser uploads an image, Google could transcode it using a strict decoder and their own safe encoder to produce a clean image for syndication.
Malicious script can (1) fingerprint and detect lab machines and therefore not do bad thing — this is arbitrarily easy if Google test lab is the first to ever execute their script, (2) over time build a graph of IPs, geos, test machine characteristics that essentially allow them to avoid the world’s entire test lab infrastructure (there’s only a fixed number of test lab providers in the world since it’s so expensive to set up this infrastructure), (3) yes, bypassing testing like this is a violation of ToS, but that is fairly meaningless as entities and IPs are cheap to incorporate, (4) not sure what you’re saying about permission policies across its domains? Google does have such policies unless I’m missing something.
"In a lab environment" -> Certainly happens, but what if the script targets "specific devices" like "samsung galaxy s10" which google won't be able list exhaustively?
What if bad actors figured out a way to identify google's emulators and avoid doing bad stuff in that situation?
The part i said "google develops browser solutions to prevent issues like this" is exactly what features policy will end up doing. But google's ad systems and chrome features don't always move at the same speed, but you can be sure that whatever ad malware team is finding will help chrome team to strengthen their defense.
The API exists because zoom.com request microphone and camera through an iframe is a legit use case. As OP said below CSPs exist so that enterprises can lock down those vulnerabilities. But wouldn’t make sense to lock it down for all consumers.
Javascript is Turing complete so it is impossible to determine what the script is going to do in all environments without running it in all environments.
The script could just detect the test environment and avoid triggering its malicious behavior.
>Javascript is Turing complete so it is impossible to determine what the script is going to do in all environments without running it in all environments.
No, it just means that it is impossible to do for every program. Google could just make it reject scripts it is unable to handle.
IMO, if you serve content to the user, you're responsible for making sure you're not serving malware, e.g. by not allowing parties you cannot trust to serve arbitrary code.
And this doesn't apply just to the ad network, it also applies to the publisher. I'd really like the publishers to be held liable for malvertising they serve.
There is nothing inherently hard about serving safe ads, we've gotten pretty good at separating code from content nowadays. There is no reason why a "classic adsense" three-blue-links ad should be able to inject malware. Even images can be served safely. The only reason why this happens is because in pursuit of a few percent more profit (and more tracking) everyone allows everyone to include arbitrary scripts.
Some of these APIs are not overridable inside javascript - overriding is pretty much the only way this can be prevented - short of browser features like CSP and FP. This needs to be the first thing that happens, but there's no standard api to run on your browser to do that, so things have flaws.
A static analysis is often relatively easy to circumvent, something like base64Decode(encodedMaliciousScript) can by-pass them.
Google does various runtime/dynamic analysis to figure out issues, but scripts can do interesting things to circumvent those too (like targeting specific devices through user agent and so on).
It's an arms race, often, where google catches up pretty fast, but bad actors move faster.
Feature Policy check addresses these but ad system and chrome features don't always move at the same speed, and often time there are trade offs that needs to be addressed first before it can be widely deployed.
I think you're right, also in the script's URL it's clear the name of the company that owns this particular script. If you know adtech companies good enough, it should be easy to spot.
Note: I also work in adtech, and my daily job is to maintain a library that has to load inside google's safe frame...
That would be anti-competitive by Google. These are different ad networks, not advertisers. Ad networks need to be able to do their own attribution and click spam detection.
This doesn't answer why the end product (the person receiving the ad) is exposed to anything but images and text, which was the question.
Step outside technical approach mode and look at it from the highest level possible -- why are end users ever given more than images and text, or, why are ads anything more than a very simple a href tag.
Spam detection and other protection of the ad platform should be done long before this information ever goes to the eyeball product owners.
No - spam protection needs as many signals as possible, sadly.
You will have headless browsers simulating clicks and so on. This gets extremely hard over time fake, and the more signals there are, the easier it's to spot anomalies.
In a way, the thinking is - a malicious actor will get at least a few of those signals inorganic and ML can detect them...
"Long before the information ever goes to the eyeball" => wish it was true.
Google tries to sandbox the creatives in an attempt to prevent issues exactly like this, and develops browser features to prevent issues exactly like this.
This is likely a script that somehow avoided google's malware scanning pipelines.
This is definitely not google's malintent.
Disclaimer: Ex googler, worked in ads, dealed with problems like this all the time.