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
A 0-click exploit chain for the Pixel 10
121–130 of 255 posts
Re: A 0-click exploit chain for the Pixel 10
#122Do we have any evidence on how AI has affected NSO et als’ businesses? Does it render them obsolete? Or are they now superpowered?
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
#123Earlier 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".
Re: A 0-click exploit chain for the Pixel 10
#124Earlier 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"?"
That said, CHERI is super complicated. Checked integer arithmetic operations would be way simpler.
Re: A 0-click exploit chain for the Pixel 10
#125I 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.
Re: A 0-click exploit chain for the Pixel 10
#126Earlier 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.
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
#127Earlier 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.
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
#128I 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…
Re: A 0-click exploit chain for the Pixel 10
#129I 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…
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
#130I 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…