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

91–100 of 126 posts

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

#91

Post by [deleted] »

croisillon wrote: post #11
nativeit wrote: post #7

Earlier quoted context omitted.

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

is this the one: https://news.ycombinator.com/item?id=43025038

[deleted]

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

#92

Post by vv_ »

NitpickLawyer wrote: post #18
_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.

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

Hilariously, the PPP (Point-to-Point Protocol) is still used in modern IoT modules. It is actually the only way to run your own TCP/IP stack (and maintain control over TLS), as not all modules support QMI or MBIM.

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

#93

Post by internetter »

mook wrote: post #71
SamBam wrote: post #56

Earlier quoted context omitted.

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.

I think you skimmed too fast. Widgets, allegedly, are eagerly evaluated when an app is opened, and the system keeps trying failed attempts:

> After restarting, as soon as SpringBoard was initialized, the extension would be woken up by the system, since it had failed to produce any widget entries before, which would then start the process all over again.

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

#94

Post by mcherm »

rendall wrote: post #63
fc417fc802 wrote: post #53

Earlier quoted context omitted.

And for that reason I wouldn't hassle laymen over it but among the HN crowd I expect a bit more care. An "anything goes" attitude makes communication more difficult. "Soft brick" is the correct term that already exists.

> "Soft brick" is the correct term that already exists. Which is the term that the article uses. "The result is a device that’s soft-bricked, requiring a device erase and restore from backup."

> Which is the term that the article uses.

...except in the headline.

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

#95

Post by xmodem »

miki123211 wrote: post #77
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.

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…

> There have even been stories of peoples' computers being bricked via rm -rf /

I would expect that most systems should be recoverable from this state with a CMOS clear.

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

#96

Post by porridgeraisin »

mcherm wrote: post #94
rendall wrote: post #63

Earlier quoted context omitted.

> "Soft brick" is the correct term that already exists. Which is the term that the article uses. "The result is a device that’s soft-bricked, requiring a device erase and restore from backup."

> Which is the term that the article uses. ...except in the headline.

Need to get you to click on it :-)

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

#97

Post by Ghoelian »

mook wrote: post #71
SamBam wrote: post #56

Earlier quoted context omitted.

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.

The single line part also requires you first set up an app to execute that code as well.

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

#98

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

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

#99

Post by mook »

internetter wrote: post #93
mook wrote: post #71

Earlier quoted context omitted.

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.

I think you skimmed too fast. Widgets, allegedly, are eagerly evaluated when an app is opened, and the system keeps trying failed attempts: > After restarting, as soon as SpringBoard was initialized, the extension would be woken up by the system, since it had failed to produce any widget entries before, which would then start the process all over again.

The article claims that they had to manually cause the widget to crash so that the result doesn't get cached, right? So that's at least one line to trigger the reboot, one line (likely more) to register as a widget, and one to crash it.

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

#100

Post by jillyboel »

e28eta wrote: 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…

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