Live data from Hacker News

How a single line of code could brick your iPhone

rambo.codes

71–80 of 126 posts

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

#71
post #56
post #55

Earlier quoted context omitted.

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.

It doesn't just force a reboot, it forces a never-ending loop of reboots, rebooting each time you reboot it. > The result is a device that’s soft-bricked, requiring a device erase and restore from backup. Requiring a device erase isn't a full brick, no, but it's still pretty serious.

No, the _single line_ part forces a single reboot. The never-ending loop requires setting up a widget, so that's more than one line.

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

#72
post #49

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 bei…

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

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

#73

Earlier quoted context omitted.

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

That's actually just for the block-based APIs like notify_register_dispatch(), the other notify APIs have no availability annotations at all.

Manual page says Mac OS X 10.3.

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

#74

Earlier quoted context omitted.

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

They wouldn’t, especially considering they aren’t operating anymore.

Which was Vupen too before that. One company name is unimportant because multiple shady groups and individuals are out there buying and selling 0daya. This is definitely the case because state actors don't develop 100% them themselves and must get them from somewhere. It's a small but nonzero market of expediency.

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

#75
post #49

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 bei…

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

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

#76

Earlier quoted context omitted.

Incorrect. Bricking means a device becomes a doorstop that cannot be resurrected or repaired by the user non-invasively. That's the whole point of the term.

When devices were a bit larger, we would customarily refer to “boat-anchors”

That was a pejorative for unwieldy and inconvenient devices like rugged government secure cell phones that lagged behind consumer tech.

Brick means entirely useless except as a doorstop, projectile, or building material.

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

#77

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.

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

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

#78

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.

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 damag…

rm -rf is nightmare, if used mistakenly. I myself have been victim of this.

https://news.ycombinator.com/item?id=43775027

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

#79
post #6
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...

DOS yes, but that freebsd cve I referenced is a theoretical RCE.

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

#80

Earlier quoted context omitted.

They wouldn’t, especially considering they aren’t operating anymore.

Which was Vupen too before that. One company name is unimportant because multiple shady groups and individuals are out there buying and selling 0daya. This is definitely the case because state actors don't develop 100% them themselves and must get them from somewhere. It's a small but nonzero market of expediency.

I'm sure there are companies that have stepped up to fill the void. But the market for "I DDoSed your phone" doesn't really exist.
Post reply on HN