Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 0-click exploit chain for the Pixel 10

projectzero.google

Post reply on HN
Print view View original

161–170 of 255 posts

Re: A 0-click exploit chain for the Pixel 10

#161

Post by dehrmann »

krupan wrote: post #66

I followed the link to the Pixel 9 bug/exploit and saw this: "Over the past few years, several AI-powered features have been added to mobile phones that allow users to better search and understand their messages. One effect of this change is increased 0-click attack surface, as efficient analysis often requires message media to be decoded before the message is opened by the user" Haven't we learned our lesson on this…

> Don't read and act on my sms messages without me asking you to!

Being an accidental or curious tap away from an RCE isn't actually much better. The fix is using sanitizing and safe parsers.

Re: A 0-click exploit chain for the Pixel 10

#162

Post by amarant »

thrownthatway wrote: post #159
lupire wrote: post #153

Earlier quoted context omitted.

Because many people know not trust unknown senders.

I should have said “a well crafted malicious email” or SMS etc.

No such thing as completely idiot proof. But I think we can all agree an exploit that requires a click is a lot better for the intended victim than one that doesn't. This way they at least have a chance to not click it. Then we can start tackling the other problems with separate solutions

Re: A 0-click exploit chain for the Pixel 10

#163

Post by amarant »

michaelt wrote: post #156
jiggawatts wrote: post #140

Earlier quoted context omitted.

Sorry, but that is an insanely defeatist attitude blended with a hint of blaming users for wanting features. Image decoders are pure functions and all should have been rewritten as 100% safe Rust years ago. Users need functionality. It’s up to us to figure out how to provide that safely. Saying to users they shouldn’t have those features isn’t sage advice, it’s admitting failure.

The thing is, nobody's happy just previewing jpegs and pngs. Before you know it, people want to preview SVGs, PDFs, video, HTML and so on. And to do that properly means you've got to support obscure formats like JBIG2 and CCITT Fax. Malicious vector images with a billion elements to render. XML that lets one file embed another. And good luck getting the budget to re-implement them all from scratch in a better languag…

Perfection is the enemy of the perfectly good.

And let's be honest, you'll have what, 0.0001% of users who want to preview CCITT in 2026? Less? Probably less.

Re: A 0-click exploit chain for the Pixel 10

#164

Post by jiggawatts »

michaelt wrote: post #156
jiggawatts wrote: post #140

Earlier quoted context omitted.

Sorry, but that is an insanely defeatist attitude blended with a hint of blaming users for wanting features. Image decoders are pure functions and all should have been rewritten as 100% safe Rust years ago. Users need functionality. It’s up to us to figure out how to provide that safely. Saying to users they shouldn’t have those features isn’t sage advice, it’s admitting failure.

The thing is, nobody's happy just previewing jpegs and pngs. Before you know it, people want to preview SVGs, PDFs, video, HTML and so on. And to do that properly means you've got to support obscure formats like JBIG2 and CCITT Fax. Malicious vector images with a billion elements to render. XML that lets one file embed another. And good luck getting the budget to re-implement them all from scratch in a better languag…

Most of these are solved problems to one degree or another. Web browsers have generally switched over to decoding legacy unsafe formats like PDF using safe managed languages, typically JavaScript.

> JBIG2 and CCITT Fax

Since performance isn't such a critical concern with obscure legacy formats, it really wouldn't be much more than a day or two of work for a competent developer with AI agent tooling to convert an existing decoder to safe Rust.

Meta set nearly a hundred billion dollars on fire for a total failure that everybody saw coming, a trillion dollars is what the current AI investment crazy is pouring into concrete and TSMC chips, but... a couple of days for a developer is asking too much!?

Re: A 0-click exploit chain for the Pixel 10

#165

Post by tialaramex »

pessimizer wrote: post #113
JumpCrisscross wrote: post #100

Earlier quoted context omitted.

> Haven't we learned our lesson on this? What is the purported lesson we should have learned? Users choose phones with rich messaging features. This was a major selling point for iPhone, first, with iMessage, and later with Android until iOS caught up with RCS.

> What is the purported lesson we should have learned? Not to automatically execute things within data that we have been sent.

The subtle lesson, which we won't learn is [astronaut meme] all communication is potentially remote code execution. This isn't a computer thing, it's in the inherent nature of how communication works for us too. You can be more or less careful, but you can't eliminate the problem entirely or else communicating ceases to be effective.

Re: A 0-click exploit chain for the Pixel 10

#166

Post by jcims »

Vexs wrote: post #59
jcims wrote: post #51

Earlier quoted context omitted.

I just did some analysis on this last weekend, in 2024 there were roughly 100 CVEs published every day. In April we hit approximately 200 per day. Going backwards from 2023, the doubling interval for published CVEs was approximately 4 to 4 1/2 years. Since then it’s approximately two years. There has definitely been a rapid uptick.

Published CVEs seems a bad metric to use for this- unless we assume that the ratio of really nasty vulns/not-too-bad vulns is consistent.

Good consideration but I still think there’s an uptick. This is all AI generated as I’m not in a spot to do anything more at the moment but this is a chart of ‘linux kernel’ CVEs rated as high/critical correlated with NVD.

https://imgur.com/a/0DrJuLU

Re: A 0-click exploit chain for the Pixel 10

#167

Post by watchful_moose »

krupan wrote: post #66

I followed the link to the Pixel 9 bug/exploit and saw this: "Over the past few years, several AI-powered features have been added to mobile phones that allow users to better search and understand their messages. One effect of this change is increased 0-click attack surface, as efficient analysis often requires message media to be decoded before the message is opened by the user" Haven't we learned our lesson on this…

Windows had autorun starting Windows 95, but stopped shipping it as a default in Windows 7 (2009). So, yeah, no we haven't learned our lesson.

Re: A 0-click exploit chain for the Pixel 10

#168

Post by denkmoon »

michaelt wrote: post #156
jiggawatts wrote: post #140

Earlier quoted context omitted.

Sorry, but that is an insanely defeatist attitude blended with a hint of blaming users for wanting features. Image decoders are pure functions and all should have been rewritten as 100% safe Rust years ago. Users need functionality. It’s up to us to figure out how to provide that safely. Saying to users they shouldn’t have those features isn’t sage advice, it’s admitting failure.

The thing is, nobody's happy just previewing jpegs and pngs. Before you know it, people want to preview SVGs, PDFs, video, HTML and so on. And to do that properly means you've got to support obscure formats like JBIG2 and CCITT Fax. Malicious vector images with a billion elements to render. XML that lets one file embed another. And good luck getting the budget to re-implement them all from scratch in a better languag…

The business value is reduced attack surface which is a marketable attribute. Seems like the exact type of thing Apple would do.

Re: A 0-click exploit chain for the Pixel 10

#169

Post by fulafel »

shay_ker wrote: post #3

Hmmm... I'd like someone to double check my thinking here. I posted this exact prompt for gpt 5.5 xhigh: ``` does this look right to you? don't do any searches or check memory, just think through first principles static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM…

On its own we can't judge if this is a workable way to find vulns, as we don't know how many false positives you'd get if you ran it on all the code. (iow might be https://en.wikipedia.org/wiki/Base_rate_fallacy)

Re: A 0-click exploit chain for the Pixel 10

#170

Post by fulafel »

tialaramex wrote: post #31
codedokode wrote: post #7

I read about Pixel 9 Dolby Decoder bug, and it is based on integer overflow. It was a mistake to allow "+" operator to overflow, and this must be fixed in new languages like Rust, but it is not.

In Rust the decision about whether to pay for overflow checks or just wrap (because all modern hardware will just wrap if you don't check and that's cheaper) is a choice you can make when compiling software, by default you get checks except in release builds but you can choose checks everywhere, even in release builds or no checks even in debug. By definition in Rust it's incorrect to overflow the non-overflowing int…

"If you turn off checks" is misleading, it's just incorrect by default in release mode: https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...
Post reply on HN