Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

This article doesn't make any sense. I kept waiting for an explanation of how the spyware is installed, and just got this paragraph:

> What sets Insanet’s Sherlock apart from Pegasus is its exploitation of ad networks rather than vulnerabilities in phones. A Sherlock user creates an ad campaign that narrowly focuses on the target’s demographic and location, and places a spyware-laden ad with an ad exchange. Once the ad is served to a web page that the target views, the spyware is secretly installed on the target’s phone or computer.

That last sentence is simply impossible without an unpatched vulnerability on the device. If something is actually installed on the device, the vulnerability allowing this will eventually be patched.

View on HN

I think that this is just a adtech-delivered spyware and likely exploits various zero-day browser issues. Those exploits will be ever changing as some are blocked and others are found. Pegasus has been doing this via SMS messages for more than a decade and they continue to be in operation quite successful even after each exploit made public is patched.

> Pegasus relies on vulnerabilities in Apple’s iOS, the iPhone operating system, to infiltrate a phone undetected. Apple issued a security update for the latest vulnerability on Sept. 7, 2023.

so. many. IOS. vulns.

what is going on over there at Apple?

They've basically shown it's impossible to create memory safe code in C/C++. Many of these vulnerabilities had to do with different image/video (or other file type) handling libraries. It's one reason why you see so many in the industry pushing to use Rust.

Plus, many of the highest value targets are likely iPhone users, so bad guys target where there is the biggest payoff.

> to use Rust.

Also probably wasm for a finer-graded sandbox if rewrite is currently impracticable.

https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

If the module memory corrupt for whatever reason. At least you would be able to unload it as a whole without pollution.

All cases of undefined behavior in C/C++ language can be replaced either with explicit aborts of the program or explicit infinite loops. The result is a subset of C/C++; then anyone can write any C/C++ code, use it as the restricted variant and most exploits resulting from UB (those that cannot cope with the aborting or hangup) will be eliminated automatically. To implement or not such a safe mode is the sole decision of the compiler author. Blame the compiler for rigidity, not language for flexibility. Developing new languages from scratch and tools, libraries for them costs much time and effort and fractures the market of programmers and costs them time to learn it as well.

And yet so many of these corporate giants seem to be embracing Rust. Think they've all got it wrong? They just didn't try hard enough with C and C++?

My point is, the new language way may well be the "harder" one, for implementers or for users. It might be explained as a knee-jerk type reaction. Although new languages can still have some additional benefits of safety. Ways have tradeoffs and agents should evaluate them reasonably. I want to see a well-founded analysis of costs/benefits for the choice between Rust and safe variant of C/C++ or similar choice.

The best I can come up with is that this is some kind of novel abuse of Web Workers or other PWA technologies that, while never escaping the sandbox, effectively implements a spyware payload within constraints that were previously thought sufficient to prevent such attacks.

Any significantly complex attack leverages multiple vulnerabilities.

No shit, but the article is making the unreasonable claims that:

1. This hack is not a result of a device vulnerability.

2. That whatever technique is being used to install spyware cannot be defended against (i.e. with an OS patch).

That is simply impossible if an actual executable is installed on the device.

The article is really vague. Extraordinary claims should come with extraordinary evidence. That said, could it be that the ad has its own JavaScript that does its spying for the time it is visible on the page? Can adds do that?

Even then, that would be a vulnerability in the browser. JavaScript in ads is loaded in its own context and doesn't have permission to access things outside of that context.

That would depend on how the ad is being served, no?

Not really. Ads are basically always served in an iframe precisely so it can't access content in the parent page.

Even if worse came to worst and there was a bug on the parent page that let the ad JS access its parent page context, it should still be sandboxed to just that page.

> That is simply impossible if an actual executable is installed on the device.

There's one exception, if there's a vulnerability in the hard-coded ROM or the silicon itself. One was found not long ago and enabled newer iPhones to be jailbroken. It lacks persistence and requires lightning port access, but it can't be patched.

A no-click remote ACE at the unpatchable physical level would be the mother of all zero days, and too valuable to use for all but the highest of targets.

If such a no click ACE is the mother of all exploits, it could be a little harder to patch, especially for your average end user. If that's not the case, then maybe the advantage to it might be that it can run on the hardware you need it to for a specific use case, but that itself is a big disadvantage for most other use cases. If neither are true, then are they worth the same amount? What makes one ACE better than another?

Let's say this exploit did exist, and it was better for some reason. Then maybe I shouldn't use it, instead I use a cheap one time use exploit on a target that would cause it to be patched anyway.

Yes, but the article is confusing targeted advertising (not really a vulnerability) with actual zero day vulnerabilities. They are not really related, but both can be part of a targeted campaign I guess.

Reply on news.ycombinator.com