How a single line of code could brick your iPhone

[e28eta]

I’m fascinated that they aren’t requiring an entitlement for all usage of setting & posting notifications through this API. A way to share 64 bits of information (at a time) to any process on the device? That is right in the wheelhouse of tracking a user across apps.

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.

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 & re-install, as long as there isn’t a reboot in between.

I think you could easily use it to work around IDFA or IDFV resets, as a simple example.

[tgv]

> That is right in the wheelhouse of tracking a user across apps.

The design is old. It probably predates facebook, so it's not been intentional, as your comment might be interpreted. But it certainly seems ripe for abuse. I'm curious if it would actually be used for that, because any app that can access internet already has a better way to share information.

[agos]

this is exactly where my mind went immediately - 64 bits is more than enough for easy (1 line!) unenforced cross-app tracking of a user for advertising purposes, basically a super cookie for iOS. If they now require an entitlement for this API it's a privacy win

[icoder]

The IDFV already supports tracking user across apps, as long as they are from the same vendor. It resets when apps from a vendor are removed from a device. Not sure if the user can reset it by themselves, but the vendor could then always tie things together using another self-generated identifier stored on the device, as long as any of its apps are on it, which boils down to the same.

I think the approach you describe allows roughly the same, except perhaps doing so without (or with different) permissions, and allowing to do this between vendors (that must agree upon this upfront).

[jillyboel]

As per the DMA if it's available to Apple's own apps it has to be available to third party apps as well. Of course apple will fight this tooth and nail so they can maintain their walled garden, making them billions per year.

[95014_refugee]

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

[miki123211]

There's physically no way to permanently "brick" an iPhone.

DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable.

Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac.

This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked. There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without

[the__alchemist]

From observation, "brick" has evolved, as things do in language. In practice, it rarely means the traditional definition you refer to, but the softer one used here.

[taneq]

“Bricking” isn’t a rigorously defined term, it’s more like “realtime” in the sense that it comes with an implicit “(for this particular user in this particular scenario)”. For most users a device is bricked if it doesn’t turn on and work when you press the power button. For most readers here, using dev tools to re-flash a bootloader would be fairly easy but if USB stops working it might be game over. I’m sure there are a few around who could de-cap an ASIC and circuit bend it back to life.

[mook]

More importantly, the single line only forces a reboot; even if we consider needing external fixes to be a brick, the title is still incorrect.

[kjkjadksj]

A tethered restore is still devastating considering how few people backup their iPhone.

[cantrecallmypwd]

Correct. The terminology is wrong. It's an annoying, repeated DoS that doesn't ruin the device permanently but could lose user data if it must be erased.

[dado3212]

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.

[nativeit]

I read a comment under the story about the recent YouTube vulnerability where one could unmask the related Google account and its owner using the standard YouTube API (something similar to that anyway), and they explained a lot of lesser-known nuances in establishing values for bounties like these, and it helped explain a lot (not all) of the reasons for what might seem like low-ball/high-ball valuations on the surface. If I can find their comment I’ll post back, it was really insightful. That said, there are also plenty of examples of people just getting shafted.

[cantrecallmypwd]

Maybe Zerodium would've paid $75k but that would be less ethical because Israel and America would weaponize it.

[_rrnv]

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.

[Rygian]

Ping of death was already a thing two decades ago.

https://web.archive.org/web/19981206105844/http://www.sophis...

[NitpickLawyer]

Back in the dial-up days you could disconnect someone by adding ATH commands to a ping payload field.

[urbandw311er]

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

[rashkov]

Seems like this should have been obvious to someone on the iOS team, no?

Like, "hey we need a way to trigger springboard UI events.." "ok let's just use this unauthenticated bus and have springboard subscribe to it"

Something like that? Only thing I can think of is that this line of code was written so long ago and it's way at the bottom of the abstraction stack, so no one had a look

[jonplackett]

Anyone know how long ago that system would have been introduced?

It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?

[plorkyeran]

The notification API is quite old (iOS 3). It's explicitly an untrusted API that you shouldn't use for something like showing the restore in progress UI, so I suspect that was something written quite a bit later. Widget extensions are iOS 14. There's older ways to run background tasks, but none of them would give the soft brick. Background fetch, for example, originally didn't run until after you launched an app for the first time after restarting.

[lilyball]

Darwin notifications are so old they don't have any availability annotations (block-based darwin notification APIs like notify_register_dispatch() were introduced in macOS 10.6 / iOS 3.2, but the rest of them are declared as always available). They absolutely predate any notion of an AppStore, of being able to install apps without implicitly putting a lot of trust in the app to not be malicious.

[andrekandre]

  > That single line of code was enough to make the device enter “Restore in Progress”.

  > as established before, any process could send the notification and trick the system into entering that mode.

sleep data, sleep...

[moduspol]

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

[cryptonector]

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

In practice this is not a big problem because usually one grants very few users direct access to a PG DB.

[gitroom]

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?

[genewitch]

Depends, are people going to keep producing new code?

[doesnt_know]

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

[kvetching]

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

[Loocid]

The sheer simplicity of this exploit is wild.

[brcmthrowaway]

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

[piyuv]

Lots of credible apps use lots of dependencies. Find an abandoned one, get your code into it, …

[g-b-r]

Or a reputable one with that line of code included (in one of the updates, after having built a good reputation); maybe dormant until a certain date.

[saagarjha]

Yes.

[keepamovin]

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

[shrx]

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

This should probably be reworked regardless if the patch described in the article was implemented.

[pmlnr]

I wonder if this can be "ported" to dbus, udev, or devd.