Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How a single line of code could brick your iPhone

rambo.codes

Post reply on HN
Print view View original

41–50 of 126 posts

Re: How a single line of code could brick your iPhone

#41

Post by taneq »

95014_refugee wrote: post #31

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.

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

Re: How a single line of code could brick your iPhone

#42

Post by driverdan »

Rygian wrote: post #6
_rrnv wrote: post #2

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.

Ping of death was already a thing two decades ago. https://web.archive.org/web/19981206105844/http://www.sophis...

When I was in college circa 2001 we used to prank each other with the ping of death and other crash exploits. Also random IPs on the college network when we were bored. It was crazy how long it was around for and how easy it was to exploit.

Re: How a single line of code could brick your iPhone

#43

Post by plorkyeran »

duskwuff wrote: post #28
plorkyeran wrote: post #12

Earlier quoted context omitted.

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…

This is an internal broadcast notification API (akin to dbus on Linux), distinct from the API used to display notifications to the user.

Yes, I am aware. I'm not sure what makes you think I was talking about UI notifications?

Re: How a single line of code could brick your iPhone

#44

Post by plorkyeran »

MBCook wrote: post #16
plorkyeran wrote: post #12

Earlier quoted context omitted.

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…

Wasn’t it in OS X before that?

Documentation claims 10.6, which is the equivalent OS X version (both are the 2009 releases).

Re: How a single line of code could brick your iPhone

#45

Post by two_handfuls »

the__alchemist wrote: post #36
95014_refugee wrote: post #31

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.

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.

Ah yes, the Goebbels effect, also known as "A lie told a thousand times becomes the truth."

Re: How a single line of code could brick your iPhone

#46

Post by anyfoo »

jasongill wrote: post #32
Rygian wrote: post #6

Earlier quoted context omitted.

Ping of death was already a thing two decades ago. https://web.archive.org/web/19981206105844/http://www.sophis...

It was actually almost 3 decades ago, making me feel extremely old - the period right at the end of '96 and into mid '97 when this was a popular way to cause mischief via IRC was truly a magical time

Hard to believe that during those times in IRC, you were used to automatically (and proudly) advertising your IP address, your exact client version, and the means for a direct connection to your client without any server in between (CTCP, literally “client-to-client protocol”). And all of that most often with no packet filter whatsoever, not even NAT, in between.

Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).

Re: How a single line of code could brick your iPhone

#47

Post by bee_rider »

plorkyeran wrote: post #43
duskwuff wrote: post #28

Earlier quoted context omitted.

This is an internal broadcast notification API (akin to dbus on Linux), distinct from the API used to display notifications to the user.

Yes, I am aware. I'm not sure what makes you think I was talking about UI notifications?

FWIW I also thought you meant UI notifications (the reason is: I’m dumb). But anyway, I found the point of clarification helpful even though it wasn’t strictly necessary.

Re: How a single line of code could brick your iPhone

#48

Post by chasd00 »

jasongill wrote: post #32
Rygian wrote: post #6

Earlier quoted context omitted.

Ping of death was already a thing two decades ago. https://web.archive.org/web/19981206105844/http://www.sophis...

It was actually almost 3 decades ago, making me feel extremely old - the period right at the end of '96 and into mid '97 when this was a popular way to cause mischief via IRC was truly a magical time

Death on flaxxen wings

Re: How a single line of code could brick your iPhone

#49

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

Re: How a single line of code could brick your iPhone

#50

Post by lilyball »

jonplackett wrote: post #5

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?

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.
Post reply on HN