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

131–140 of 255 posts

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

#131

Post by varenc »

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!

Doesn't that just turn a 0-click exploit into a 1-click exploit? It's unlikely the user can make an informed decision to not process a potentially malicious message, without clicking on the message.

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

#132

Post by subscribed »

kybernetikos wrote: post #119
ImPostingOnHN wrote: post #114

Earlier quoted context omitted.

Sure, in an ideal world different from this one. You should be able to do anything on any device and never worry about security. Unfortunately, since we don't live in that world, we need to not open links, emails, text messages, etc, if they are sketchy. A better solution may someday exist, but as of yet has not been found.

"Don't click on links" is not a solution, and it's not something people actually do, it's just something they think they do. Corporate Security will tell you that it's ok to click links to the payroll system or hr or vanta or the 'secure email service' or jira or github or to docusign or the microsoft office document that a partner company sent you or an amazon delivery notification, but not ok to click links in the…

In my company I regularly see genuine, legitimate emails that carry several huge red flags, like these conveyed to us on trainings.

If I can plausibly claim I wasn't sure it was legit (ie it was sent from the outside form the sketchy looking host), I'd always report it internally as phishing attempt. Just to make the security work with it.

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

#133

Post by krupan »

varenc wrote: post #131
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! Doesn't that just turn a 0-click exploit into a 1-click exploit? It's unlikely the user can make an informed decision to not process a potentially malicious message, without clicking on the message.

Preferably a two-click exploit. One to view the message and one (if I decide it's safe) to process it through your buggy code.

A 0-click exploit is horrendously worse than even a 1-click one. I often don't even open messages from numbers I don't recognize

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

#134

Post by krupan »

YmiYugy wrote: post #128
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…

Getting users to open a message isn’t a terribly high bar. As a user I would not find it acceptable if needed to be careful with which message I open. We tried putting the responsibility on the user with email attachments and I think it’s fair to say it’s been a disaster. Malicious attachments are probably the most important distribution vector for malware.

This isn't even an exploit if the crappy AI or whatever that's trying to do something fancy never "processes" the message. At least give me a choice before you automatically do that

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

#135

Post by krupan »

IshKebab wrote: post #112
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…

I don't know if that is the right lesson. It's kind of like "don't click on links"... Err, no. You should be able to click any link without getting hacked.

Wr aren't talking about clicking links even. This is a bug in some stupid code that tries to read your messages for you and act on them. No thank you!

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

#136

Post by kllrnohj »

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…

I love most of what Rust does, but this is something they just got wrong. The + operator should always trap on overflow. Which Rust kinda wanted to do (hence why it does that in debug builds), but then they chickened out about the performance risk for release builds, undermining the entire thing. The result is just weak lip service to "no UB!", since debug and release still have very different behavior

I think Zig has the most interesting approach here with 3 different "+" operators (+ aborts on overflow, +& wraps, and +| saturates) along with addWithOverflow builtin. It'd probably be a challenge for Rust to adopt that at this point, but it'd be a great improvement

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

#137

Post by encom »

kybernetikos wrote: post #119
ImPostingOnHN wrote: post #114

Earlier quoted context omitted.

Sure, in an ideal world different from this one. You should be able to do anything on any device and never worry about security. Unfortunately, since we don't live in that world, we need to not open links, emails, text messages, etc, if they are sketchy. A better solution may someday exist, but as of yet has not been found.

"Don't click on links" is not a solution, and it's not something people actually do, it's just something they think they do. Corporate Security will tell you that it's ok to click links to the payroll system or hr or vanta or the 'secure email service' or jira or github or to docusign or the microsoft office document that a partner company sent you or an amazon delivery notification, but not ok to click links in the…

>It's not possible to tell whether a message giving you a link to something is 'sketchy' or not before clicking the link

Sure it is. It's just not something the average user can do. But what makes the situation worse is that most emails now use click tracking, so ALL links are sketchy. For example, emails from my union all link to 2mv.aplink.red and are 200 characters long and look like /dev/urandom output. No fucking idea what or who controls that domain, but it for sure is not my union. I've complained multiple times, including acting dumb and asking if they've been hacked because their email look shady as hell.

Email with the unsubscribe link wrapped in click tracking gets sent straight to SpamCop. I hate tech more and more every day.

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

#138

Post by tialaramex »

codedokode wrote: post #75
tialaramex wrote: post #31

Earlier quoted context omitted.

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…

> is a choice you can make when compiling software That is not a solution because it means the code can behave differently, and expose vulnerability if wrong compilation settings are chosen. The functions like "wrapping_add" have such a long names so that nobody wants to use them and they make the code ugly. Instead, "+" should be used for addition with exceptions, and something like "wrap+" or " " or "[+]" used for…

> That is not a solution because it means the code can behave differently, and expose vulnerability if wrong compilation settings are chosen.

If the software is correct nothing changes. The existence of people who write nonsense but expect you to work around that doesn't change between languages, they write crap in Swift or Python or Javascript just the same.

The long names are because there are, in fact, a lot of things you might want. Although Swift manages to take several pages and lots of diagrams to explain what wrapping is, that is in fact all their special operators do. What if you don't want wrapping? Too bad.

Rust provides saturating, which is almost always what you wanted for signal processing (e.g. audio) as well as separate "carry" booleans to do arithmetic the way you were probably shown in primary school, the wrapping most often provided on hardware and useful in cryptography among other places and explicitly cheap but dangerous and expensive but safe options. It also provides both kinds of division (and remainder), which doesn't matter for the unsigned integers but is important for signed integers and is a source of confusion and woe when languages provide only one kind or worse a mixture that makes no mathematical sense. These all need names.

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

#139

Post by fc417fc802 »

seanieb wrote: post #25
deaton wrote: post #22

Earlier quoted context omitted.

This is pure guesswork, I am not a security researcher, but my guess would be that AI is increasing the amount of low quality exploitable attack surface available, while simultaneously providing security researchers with an accelerant for their work. Which is to say, its great if you use it well and really bad if you use it poorly.

Not low quality if it works!

Those two things have almost nothing to do with one another. Lots of low quality things work they're still low quality.

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

#140

Post by jiggawatts »

GeekyBear wrote: post #115
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.

One of the things Apple's Lockdown mode does is disable previews of images or links that are sent to you. It seems like the lesson is that you shouldn't be processing data sent to the device by random strangers without the user explicitly choosing to open the file or follow the link.

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.

Post reply on HN