How a single line of code could brick your iPhone

I’m fascinated that they aren’t requiring an entitlement for all usage of setting &amp; posting notifications through this API. A way to share 64 bits of information (at a time) to any process on the device? That is <i>right</i> in the wheelhouse of tracking a user across apps.<p>I don’t specifically know the types of things that you’d want to share across apps, but there’s a long history of cross process information channels being removed or restricted.<p>If the system is storing values for you, and isn’t keeping track of which app they came from, now you’ve got persistent storage across app deletion &amp; re-install, as long as there isn’t a reboot in between.<p>I think you could easily use it to work around IDFA or IDFV resets, as a simple example.

The exploit as described doesn&#x27;t &quot;brick&quot; the device; that would require permanently disabling it. A tethered restore would be all that&#x27;s required to recover in this case.

Neat, $17,500 is pretty good, I’m so used to these blog posts being for peanuts, or where companies fix the vulnerability but don’t pay out at all. Apple’s gotten better about this since 2019.

Great work! This is my favourite type of vulnerability, simple, effective and brutal. Reminds me of a time two decades ago when with a friend from uni we theorised about a perfect server vulnerability where you’d exploit a machine by pinging it. And of course, two years ago it was in fact discovered as CVE-2022-23093.

Nice. I can only imagine what a crap day in the office it was when the iOS core team reviewed that one.

Seems like this should have been obvious to someone on the iOS team, no?<p>Like, &quot;hey we need a way to trigger springboard UI events..&quot; &quot;ok let&#x27;s just use this unauthenticated bus and have springboard subscribe to it&quot;<p>Something like that? Only thing I can think of is that this line of code was written so long ago and it&#x27;s way at the bottom of the abstraction stack, so no one had a look

Anyone know how long ago that system would have been introduced?<p>It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?

<p><pre><code> &gt; That single line of code was enough to make the device enter “Restore in Progress”. &gt; as established before, any process could send the notification and trick the system into entering that mode. </code></pre> sleep data, sleep...

Doesn&#x27;t this imply that third-party apps with their own notification schemes could be impersonated similarly? They wouldn&#x27;t be able to brick the phone, obviously, but they could potentially trigger other actions.

This reminds me of how there is zero authorization for `NOTIFY` in PostgreSQL. IMO there should at least be the option to `CREATE CHANNEL ...` and then use `GRANT` to indicate who can `NOTIFY`.<p>In practice this is not a big problem because usually one grants very few users direct access to a PG DB.

Damn, makes me miss those old IRC days but also, stuff like this just reminds me how risky even tiny changes can be on any tech. You think security ever gets ahead or we just keep patching leaks forever?

I get that it&#x27;s potentially lower priority since a user needs to actively install a malicious app, but that timeline doesn&#x27;t exactly feel me with confidence...

In general, the vulnerability of our computers is major national security concern as we enter in the era of AGI. This administration needs to setup a system hardening commission. In the era of AI... if we aren&#x27;t using the leading AI to hack our own systems first, then when the capability to use the latest models to hack is widely available, we are going to have a bad time.

The sheer simplicity of this exploit is wild.

Ultimately, does this require installing a sketchy app in the first place?

This was an epic read. That very old skool API was so powerful! Cool demo seeing it trigger all this low-level states for iOS. I wonder what happened to notify_post now..

&gt; Looking into the binaries, SpringBoard was observing that notification to trigger the UI. The notification is triggered when the device is being restored from a local backup via a connected computer, but as established before, any process could send the notification and trick the system into entering that mode.<p>This should probably be reworked regardless if the patch described in the article was implemented.

I wonder if this can be &quot;ported&quot; to dbus, udev, or devd.