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

81–90 of 126 posts

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

#81

Post by genewitch »

bslanej wrote: post #27
NitpickLawyer wrote: post #18

Earlier quoted context omitted.

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

I’m too lazy to look it up but there was some string you could send over IRC that would make some routers drop the connection immediately - if you pasted that string in a big channel you would see dozens of people immediately disconnect.

On AOL in chatrooms you could play sounds, so if you sent S{/con/con As the sound, you could crash anyone on windows that hadn't shut off user sounds.

My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.

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

#82

Post by genewitch »

gitroom wrote: post #66

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?

Depends, are people going to keep producing new code?

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

#83

Post by cantrecallmypwd »

saagarjha wrote: post #80
cantrecallmypwd wrote: post #74

Earlier quoted context omitted.

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.

Except that's not true because rendering a target's device unusable temporarily and/or effectively permanently is a useful payload regardless of what you think.

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

#84

Post by croemer »

agos wrote: post #75
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…

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

Only sensitive notifications require an entitlement. Tracking wasn't mitigated.

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

#85

Post by LunaSea »

tgv wrote: post #72
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…

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

Facebook predates iPhones by 3 years.

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

#86

Post by razakel »

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…

[flagged]

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

#87

Post by jen20 »

LunaSea wrote: post #85
tgv wrote: post #72

Earlier quoted context omitted.

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

Facebook predates iPhones by 3 years.

NSNotificationCenter predates the iPhone by 13 years, though…

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

#88

Post by saagarjha »

cantrecallmypwd wrote: post #83
saagarjha wrote: post #80

Earlier quoted context omitted.

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.

Except that's not true because rendering a target's device unusable temporarily and/or effectively permanently is a useful payload regardless of what you think.

A useful payload for whom? Point me to someone who is willing to pay for such a bug and I'll believe you. Zerodium's old payout scale didn't even list denial of service, and to my knowledge no other serious vendor does either. If I can list a bunch of people who don't care about this surely you can find one who does.

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

#89

Post by icoder »

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…

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

Post reply on HN