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

11–20 of 126 posts

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

#11

Post by croisillon »

nativeit wrote: post #7
dado3212 wrote: post #3

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.

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

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

#12

Post by plorkyeran »

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?

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.

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

#16

Post by MBCook »

plorkyeran wrote: post #12
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?

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?

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

#17

Post by MBCook »

g-b-r wrote: post #14
brcmthrowaway wrote: post #8

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

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.

Or a bug in some good app that allows an attacker to execute the right thing.

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

#18

Post by NitpickLawyer »

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

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

#20

Post by brontitall »

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.

Only if their modem didn’t implement the Hayes command set properly or you could otherwise control the per-character timing of the OS sending. It required a pause (1sec by default), “+++” with no pauses, another pause, _then_ the ATH command
Post reply on HN