Live data from Hacker News

A 0-click exploit chain for the Pixel 10

projectzero.google

121–130 of 255 posts

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

#121
post #55

Earlier quoted context omitted.

Could you be any more specific about what features they've removed such that the hardening functions work? Because I think there are none

They're quite open about it. https://grapheneos.org/features#attack-surface-reduction

You said removing features. This link is talking about making certain feautures optional and disabled by default, not removing them.

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

#122

Do we have any evidence on how AI has affected NSO et als’ businesses? Does it render them obsolete? Or are they now superpowered?

Without knowing details I guess that ai is changing the game a lot and a lot of 'capital' in the form of zero days has been destroyed.

If this is the case it's good news for everyone else besides NSO and Co

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

#123
post #117

Earlier quoted context omitted.

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

I think it's "don't use parsers written in unsafe languages".

I think it's simpler: don't touch untrusted content unless/until you need to.

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

#124

Earlier quoted context omitted.

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark. That said you can enable overflow checks in Rust's release mode. It's literally two lines: [profile.release] overflow-checks = true I wonder if it would make sense for ISAs to have trapping v…

It does seem like "What if we offer checked integer arithmetic operations?" is a cheaper experiment than CHERI's "What if we mechanically reify extent based provenance"?"

But also way less impactful. It would solve maybe 20% of serious security vulnerabilities whereas CHERI solves like 60% at least. More if you use its strong compartmentalisation capabilities (heh).

That said, CHERI is super complicated. Checked integer arithmetic operations would be way simpler.

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

#125
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…

> 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.

Where are users being given an actual choice? There is no option for "iphone without these features", and I would wager that it has 0 bearing on anyone's decision to purchase a new iphone

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

#126

Earlier quoted context omitted.

It isn't because no ISA implements add like that, so there's always performance on the table if you check every time, and people would probably endlessly moan about how Rust is 20% slower than C on this add-heavy microbenchmark. That said you can enable overflow checks in Rust's release mode. It's literally two lines: [profile.release] overflow-checks = true I wonder if it would make sense for ISAs to have trapping v…

I think it is 3 extra instructions on RISC-V if you add signed numbers. So 1 addition (the most popular operation) turns into 4 instructions. What are those people thinking? I generally like RISC-V but this part in my opinion, is wrong. They should just have added "overflow enabled" bit to the add instruction.

In fairness I don't think it's quite as much of a no brainer as you'd think. Firstly, when RISC-V was developed Rust was still pre-1.0. People didn't think it would amount to anything. So most high performance code was C/C++ which doesn't have checked arithmetic.

Second, it's easy to say "trap on overflow" but traps are super annoying. You really ideally would want to avoid leaving user mode. As soon as you trap to the OS you're now dealing with signals which are pretty much the worst thing in the world. The 4 instruction case at least lets you just branch to other code.

So you ideally want an "add or branch" instruction, but there isn't enough space in the opcodes for that. The fallback is flags, which also massively suck. I don't know if anyone has a great solution to this problem.

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

#127

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.

That should be the default behavior, not a special lock down option that also disables other features.

Why can't they just make it like most email clients? No preview by default, give a banner with an option to explicitly allow a preview for that specific message or conversation?

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

#128
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.

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

#129
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…

Even that's not sufficient. Consider an email client that doesn't parse images until you interact with the message. So you click on it, realize it's dodgy, but it's too late now because all the complex bug prone machinery has already been triggered.

Or my favorite, I marked an extremely suspicious message with what was almost certainly a malicious attachment as junk in a certain BigTech webmail client (the only other option was phishing which it most certainly was not) and it "helpfully" opened the unsubscribe link in my local browser without first asking me for permission. It's difficult to imagine the level of incompetence and dysfunction required to not only write but review, approve, and deploy such a feature in a security and privacy sensitive context.

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

#130
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…

Even that's not sufficient. Consider an email client that doesn't parse images until you interact with the message. So you click on it, realize it's dodgy, but it's too late now because all the complex bug prone machinery has already been triggered. Or my favorite, I marked an extremely suspicious message with what was almost certainly a malicious attachment as junk in a certain BigTech webmail client (the only other…

The email client I use doesn't display images in an email until I explicitly ask it to.
Post reply on HN