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.
(1)https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Po... (2)https://www.w3.org/TR/permissions-policy-1/
---
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.
See vendors like “the media trust”
The NSO group iMessage exploit is a more interesting example, essentially turning a poorly bounded JBIG2 decompressor into a virtual machine.
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.
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 script could just detect the test environment and avoid triggering its malicious behavior.
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.
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.
Why wouldn't google just block access to those API's? I mean I guess that's what this sandbox did.
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.
Note: I also work in adtech, and my daily job is to maintain a library that has to load inside google's safe frame...
Why allow any thing on any advertisement, regardless of network, that is not image or text? Anything else opens up security issues.
"Ad networks need to be able to do their own attribution and click spam detection."
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.
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.