Hacker News Reader

Comment by jasonhansel | Hacker News Reader

Honestly, if there's a real security risk, I'm surprised Apple hasn't recalled the phones or offered to repair them. Unpatchable firmware flaws are (or should be) no different from hardware flaws in this respect.

View on HN

> if there's a real security risk

There is, but it's not that great. You need physical access to the device and it won't be persistent (a reboot will clean it).

It certainly will _feel_ persistent if you're successfully attacked with this technique.

If your iOS software is swapped out for a version with a backdoor, then the attacker will have collected your passwords and authentication tokens to services you use. If you reboot to clear the backdoor (and let's be honest: no one reboots their phones), then you won't also "clear" your attacker's memory of all your passwords.

Ha, I wonder if an attacker could use this bug to prevent or fake the rebooting process by changing the behavior of the lock/volume buttons when they’re held.

I know there’s also a “hard reset” you can do with volume up -> volume down -> power, not sure if that works at a lower level.

Seems likely that the hard reset works on a lower level as it works even if the phone is hung.

Yes, an attacker using checkm8 could do that if they had a separate exploit for persistence. That exploit would be in iOS and take over at a later point in the boot process, and it would be possible for Apple to patch it with an iOS update. Those bugs are hard to find, but there have been dozens discovered in the past.

I’m a little confused, which part of my comment would require persistence? I was suggesting a lulzy payload that would prevent the user from _actually_ restarting their device by changing the behavior of the power button. As a means of bypassing the “just restart your phone every time you use it” countermeasure.

Would not work, as this is indeed a lower-level function.

I reboot my phone once in a blue moon, but my phone reboots itself roughly every other day (usually because I space on charging it). Am I that unusual, or is "the phone is rarely going to reboot" not really a reliable predicate for attackers?

My reboot frequency is slightly more than 1.0 times per update, but less than 2.0 times per update.

I similarly reboot my phone rarely, but my phone never runs out of battery. I never charge it during the day (except if I'm using it for GPS in my car), and it's just a routine to charge it at night. I don't think my current phone, which I've had for about a year, has ever run out of battery.

Anecdotal, but my family members reboot slightly less frequently than iOS updates come out (they miss a couple).

Only on update, and only if the update requires it.

If your iOS version is swapped out with one that is backdoored, it won’t boot after you reboot it without using this boot loader exploit on a computer again.

This makes you ever so slightly more vulnerable to an evil maid attack, but we don’t even have a jailbreak yet using this so it’s to be determined how it all shakes out.

You don't need to modify the kernel or iBoot on disk to inject a patched OS (or malware). redsn0w didn't, it would boot over dfu every time.

It's totally possible to rootkit a phone and have it reboot just fine (with the rootkit removed).

I believe a reboot will cause you to boot stock iOS again.

> You need physical access

I don't understand why people keep downplaying this. The whole point of a secure phone is that the data can't be accessed even with physical access.

The attack where you implant some kind of backdoor to capture the data is possible even without this exploit, it just makes it easier.

How would such an attack (without this exploit) be pulled off?

For example, you could implant a hardware backdoor that monitors the touchscreen inputs

To do that, you'd need to disassemble the phone to insert your implant. That might be hard to do in the field (ie. not in a repair shop/lab setting with plenty of tools lying around). Not to mention the difficulties of designing and manufacturing an implant. How are you going to get it to fit? I don't think there's a lot of empty space inside a phone. How many variants would you need to design and carry around? I'd imagine that the iPhone SE would need a different implant than the iPhone XS, for example.

A bootrom attack allows you to replace all of that with plugging in your victim's device into your "hackbox" for 10 seconds. Vastly simpler to execute for your typical goon/henchmen and way less likely to get detected.

Agreed there is a substantial difference in difficulty between the attacks. I am only speaking to the parent's point about the phone somehow previously being secure and now not being secure. The only thing that's changed is the difficulty of the attack.

There are easier physical attacks too: for example just replace the whole device with an identical one you control. Replicate the target's lock screen in software and capture their inputs.

You need physical access AND the device pin. None of these hacks allow you to decrypt the device without the pin. The best you can do is load malware that would grab the pin when the user types it in so the defense for this is if the government ever takes your phone for inspection make sure to reboot it before typing in a pin.

Even in the case of an evil maid attack, a device that has been out of your sight and then demands that you enter the passcode instead of allowing you to use biometrics is immediately suspicious.

Uh - this is the standard on iOS - after a certain amount of time or reboot or the power button x5 shortcut, iOS will demand your passcode instead of TouchID/FaceID.

But if the phone has never left your area of trust during that time, there's no problem. If the phone has, then force a reboot of the thing before typing in your PIN. Say you have to walk into a place that demands you relinquish your personal device, but when it is returned to you it requests your pin. The suggestion here is that you reboot your phone to help ensure this jailbreak wasn't done to you. It seems like a simple thing, and fairly painless in this case. Just because you're paranoid doesn't mean...

Good point - I always turn off my devices when entering a checkpoint/border.

Threat modelling. In most models, if someone has uninterrupted physical access to a device, it's theirs.

Phones are more important in that you want to protect the assets from thieves, so we do add non-destructive physical access to our scope, but it's with a higher bug-bar. Someone being able to take your phone, compromise it, then give it back to you so you can input new assets means that a vulnerability has to be severe to be as important as a minor remote vulnerability.

Anything electronic connected via the lightening port has physical access for example: a charger. A charger could be programmed to let a device in a low battery state to run the rest of the way down to empty to cause a reboot before starting to recharge. Not undetectable. But typical users would probably assume user error or a faulty charger before suspecting malware.

The exploit only works in DFU mode. The user would have to press a button chord in order to reboot into DFU for that to work, and it’s not easy to do accidentally

Are you saying if an evil government puts a backdoor on my phone while I'm at customs, can I just reboot twice to completely get rid of it reliably?

But this hack also allows exfiltration of data from your phone, doesn't it?

Apple isn’t really known for doing recalls until they absolutely have to

"Take the number of 'iPhones' in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one."

A modified version of the movie quote to fit the discussion

"the movie quote" = Fight Club, since yes, there's people who have not seen that movie, but we don't talk about that.

Which makes sense too. If Apple was negligent in the security space and these flaws were common then I would be all for a recall.

But Apple clearly has not been negligent in this space and they really have put forth best effort.

You're talking about 100s of millions of devices - I can see why Apple would prefer not.

With roughly 1 billion iOS devices in use that might be an expensive recall.

Reply on news.ycombinator.com