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!
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.
Rather than tracking cookies it's a form of delivery confirmation via unique url. One of the mitigations is to configure the server to unconditionally fetch (and retain) all embedded media immediately on receipt of the message. Which makes the BigTech example all the more egregious.
Why are you withholding the name of the webmail provider?
Literally the only thing even remotely pressuring these firms to implement better security is bad PR (and it barely does that), so by not being explicit you are bypassing 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?
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
Since it's a pure function, you can even keep using the legacy C code while still putting it in a sandbox: compile to WASM, then AOT transform to native code, and now it runs in the WASM sandbox at practically-native speed.
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 language, when the only business value the feature delivers is a postage-stamp-sized preview image.
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!?
> legacy unsafe formats like PDF using safe managed languages, typically JavaScript.
Are you ironic? If any JS and v8 have tons of CVE's.
Stop being deluded with these hip languages. Rust? you wish.
Maybe inferno with proper namespaces AND in-kernel namespace support.
No, not like Linux. LIke 9front.
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
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.
We all go through that stupid phishing training. They give us a list of red flags to help determine if an email is legit.
Then the next day, the CTO sends out an email that says IMPORTANT and the only text body says PLEASE READ THE ATTACHED .DOCX FILE. This is exactly what we were just trained not to open, but its from some exempt C-level who didn't have time to take the training, and all he is now doing is training the employees to open mails that look like phishing.
Google owns Android. Google does not care about you or other users. Their customers are ads publishers. 0days does not matter for them! Because there is hardly one alternative: iphone (and Huawei, but maybe not everywhere). Not much to care about.
We all need a new phone OS and hardware level. Urgently.
This does not make much sense at all and is also not in line with empirics. It does not make much sense, because if flagship Android's security reputation worsens, more high-value customers (which are interesting to ad publishers) will go to iPhone. I think this is already an issue for Google because the most popular iPhones are all flagship models, whereas the most popular Android models are low- to mid-range Samsung A series:
This reduces the opportunity for Google to extract money from their ecosystem (Ads, Google One, etc.) and gives it to Apple.
Second, it does not line up with empirics, because after Apple, Google has been the manufacturers most aggressively pushing hardware security. E.g. Pixels have had a Titan M secure enclave for a long time now (most Android manufacturers do not have any and rely on TrustZone), Google Pixel was one of the first devices to adopt memory tagging (MTE), etc. They do a lot of work to try to reduce the blast radius of 0-days, there is a reason why e.g. GrapheneOS has so far only supported Google Pixel devices.
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
ESPECIALLY when we're trying to be concious about the amount of resource that "AI" uses. I don't need to burn GPU cycles on something I can read with my own eyes.
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.
I have always found the whole "Don't trust links" a faux-pax when it comes to user training. As it just means that the failure to secure systems in the first place has already failed.....
It's worse, often the saying goes "don't click on suspicious links"/"don't open suspicious attachments". If I (target of such hint) knew the link was "suspicious" I wouldn't click it! Users are not opening suspicious attachments, they open (what they think is) important invoice or message from their boss.
"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 phishing email that looks exactly like one of those that they sent you.
It's not possible to tell whether a message giving you a link to something is 'sketchy' or not before clicking the link, and any 'security' that relies on people knowing whether a message is malicious or not by magic is broken in the real world.
>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.
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.
There's also something about "admin" and "HR" systems in companies where they ignore everything they told you not to do.
I don't think I've worked anywhere yet that does 2FA, SSO, or even a vaguely usable system that doesn't look like it was made 30 years ago in these departments.
Which is extra troubling as these systems are the ones with the PII!
If the solution you're suggesting is not a solution, then the solution I suggested (which is a solution) seems to be the best one we have at the moment.
I was at an "AI Security" talk recently, that centred around "While we blindly will injest inputs to and from AI, and that's a security issue. There's nothing we can do, so just deal with the aftermath".
Including saying "If a threat actor updates your internal documentation, they can use that to influence the AI".
If a THREAT ACTOR IS UPDATING DOCUMENTATION, YOU'RE COMPROMISE!
A "threat actor" can be a company employee who is intentionally permitted to update internal documentation, but not intentionally permitted to change the behavior of an LLM whose context window includes that documentation.
I think it's reasonable for a security conference to talk about how if you put the internal documentation in the LLM context, that means you're elevating the permissions of anyone who can edit the documentation by transitively giving them the ability to instruct the LLM in its "actions" (outputs).
While it should be obvious that's what you're doing, I would say most people I talk to about LLMs do not understand that all parts of the context window together shape LLM output, and there is no such thing as "only obey instructions from the system prompt".
> 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.
"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!