Hacker News Reader

Comment by judge2020 | Hacker News Reader

judge2020

And people wonder why Apple goes through the trouble of stopping fakes and not allowing third-party software (malware) on devices. Someone in the distribution chain hacks the device, rootkits it, then returns it to the setup state. The consumer would have 0 idea that their device is sending data back to some chinese company for blackmail/adware/botnet/etc.

I'd love to see a foolproof solution that makes it so that only the (non-tech-savvy) person who actually purchased the device and owns it gets to install third-party software without risking a supply chain attack before it gets in their hands.

View on HN

You're conflating a whole bunch of issues. iOS enforces the same sandbox on all installed apps, whether they were installed from the App Store, or using a developer or even enterprise distribution certificate. Opening up to competing App Stores, or allowing 'untrusted' sources, doesn't weaken this security posture. You'd still have to grant permissions to said 3rd party apps, and the kind of low level access you're talking about isn't even able to be granted without an exploit. If you have an exploit, then the current requirement to use Xcode to install your exploit code, isn't stopping anyone even today.

Apple's restrictions exist to protect their 30% cut of all software revenue. Any other benevolence you perceive to be there is naive.

App Store has a number of manual and automated checks.

One of which is checking for private API usage which would allow developers to cause all sorts of unchecked havoc.

And because of the way Objective-C apps work i.e. dynamic dispatch you can't statically check for it in the binary when the app is launched. Nor can you realistically check it at runtime since that code path is the hottest there is and needs to be highly optimal.

I suspect that there will be an App Store SDK that third party stores will need to use that incorporates these sort of checks.

> which would allow developers to cause all sorts of unchecked havoc.

This is simply not true. The security boundary is not at that layer. Calling private methods doesn't escape the sandbox.

Sure, but private methods are another vector - tracking and bypassing the IDFA and potentially acting as official Apple Apps to use/abuse things like Carrier/SIM info[0], updating the wallpaper for the user[1], accessing call history[2], etc.

0: https://github.com/nst/iOS-Runtime-Headers/blob/fbb634c78269...

1: https://github.com/nst/iOS-Runtime-Headers/issues/32

2: https://github.com/nst/iOS-Runtime-Headers/tree/fbb634c78269...

These are all security issues that Apple fixes by moving them outside of the process.

If you can't statically check for it, how does the app store check for it? Do they just open up the app and poke around with the runtime-private-api-detector enabled?

Nearly all jailbreaks since iOS ~5~ 9[0] (besides checkm8 for A11 and earlier devices) have been via sideloading an app and running an exploit chain of sandbox escape->kernel exploit->some form of r/w mounting root (amongst other steps). The attack surface for the sandbox is so large it's basically impossible to ensure absolutely nothing bad happens inside it.

After some exploit gets patched is when all the inventory sitting in logistics become at risk of interception and compromise.

0: https://canijailbreak.com/

You can just restart the device and the infection will disappear.

i guess this is true for most and the mentioned jailbreak, but not for all?

This would require a sophisticated exploit to get around.

i'll take that as a yes

If you're worried about "all" jailbreaks, then there's no need at all to use sideloading.

i'd consider myself interested

Couldn't it just 'pretend' to reboot?

Not if you hold down the power button

That's not the most reliable way to make sure it rebooted. https://blog.zecops.com/research/persistence-without-persist...

Yeah just hold it for long enough and it will reboot

15% up to your first million.

> Apple's restrictions exist to protect their 30% cut of all software revenue.

They don't need the App Store to do that. Xbox and Playstation have retail stores selling their software and they get a cut all the same because if they refuse to sign your game executable ... it won't run on end user machines.

> I'd love to see a foolproof solution

During boot, display a message: "Bootloader unlocked. Non-Apple-approved software has been installed. Unless you did this, the device may be compromised. To factory-reset the device, do the following.."

There are already phones that notify you of bootloader lock state. In fact, tamper-evident devices are a very old technology. It is only because it is profitable to them, does Apple pretend they don't exist.

And whole HN will instantly whine how this warning tramples their right to own hardware they bought.

Are the whole of HN complaining about the existing implementation of this feature on Android? We don't need to speculate about how HN "would" respond.

Nobody is whining because this message is pure security theater. It can be removed by the very same rootkit that "unlocks" your bootloader. The message would have to be unremovable to be useful and if Apple does that the whining starts.

And this is exactly how it works on Android phones with unlockable bootloader. The firmware just shows a text message underneath the splash screen.

(Ideally it should also allow to install user owned keys for verification and display their fingerprints, but that's the next step...)

The issue is really complicated. People demand the right to repair. They also want to be able to buy cheap 3rd party replacement parts instead of paying a premium for Apple's official parts. But then they also don't want to be hit with malware.

Apple puts a lot of effort into having a secure, verified supply chain. That costs money. Unfortunately, the benefits of all that effort are hard for most people to measure. Apple measures it by looking at their overall reputation. They'd rather be known for having expensive products than for faulty or untrustworthy ones.

>The issue is really complicated.

As a counter-example, consider the Precursor[1] who's CPU is "... an SoC on an FPGA, which means you can compile your CPU from design source and verify for yourself that Precursor contains no hidden instructions or other backdoors."

Device manufacturers could ship firmware as FPGA images, such that end-users can start with a "blank slate" and then install arbitrary firmware upon delivery. They choose not to.

1 - https://www.crowdsupply.com/sutajio-kosagi/precursor

That’s not going to work for a SotA phone like an iPhone. FPGAs are not even close to as fast and efficient as a purpose-built, SotA CPU.

Of course there will always be objections to any change. Everything is a trade-off. But if you wanted a truly secure device, you have to start with idea that every customer gets the same thing - a truly blank slate. It's only recently, and with incredible device density, that this assumption has changed. The fact that manufacturers CAN put extra CPUs and CAN put unique hidden, immutable data in your computer does mean it MUST be so. This is simply the path we've been going down for about the last 20 years or so. It doesn't mean we have to keep going down that path.

I'd also add that computers have multiple CPUs, and an FPGA and an M1, for example, could coexist, with the FPGA serving as the BIOS and firmware repository. I think there are real and frankly chilling reasons why manufacturers will not take this approach, and it's not because of economics. A truly free device is a threat to the establishment.

> They choose not to.

For very good reason. Last I checked, FPGAs capable of running any sort of fast, modern core are typically more expensive than a new iPhone.

I was at my assembler and picked up a 30 layer PCB with two $5000 Xilinx FPGAs on it. Military application, really cool. They were t even special or rad hardened for space.

But “it’s FPGA and you can see the code”… ok, fucking lol though. HeartBleed OpenSSL was an issue for how many years and the code was open to a hundred million people who could read it in some language. I know FPGA developers they couldn’t even remotely follow a softcore CPU configuration. You are talking about less than 100,000 people in the world, and even that is probably way generous, maybe 30k?

You've obfuscated a good point. Open-source is a necessary, but not sufficient condition for openness. Actual human beings must also understand the source well enough to audit it and modify it. If heartbleed occurred in closed source, it would still be an active problem. The vendor would be reluctant to even admit the flaw, because it makes them look bad. And the whole world realized that one guy was maintaining OpenSSL, and he was on the edge of poverty. It was a wake-up call. Thousands of devs looked at the code, and understood it well enough to patch and fork.

It's also true that, because of historical accidents, we have several more examples of https://xkcd.com/2347/. However, that's not an argument against open source. It's an argument that we all should take ownership of what we ship, all the way down, without exception. An open CPU definition is a necessary, but not sufficient, requirement for this level of ownership.

If you are really afraid of backdoors at the processor level, then the idea of an FPGA onboard should make you run like hell, if anything.

>They also want to be able to buy cheap 3rd party replacement parts instead of paying a premium for Apple's official parts. But then they also don't want to be hit with malware.

This is a strawman - people want to be able to buy from Apple's manufacturers at the component level, i.e. they want to be able to buy the $5 charge port instead of being forced to buy the $1300 mainboard the charge-port is soldered onto. Apple deliberately prevents their manufacturers from selling the exact same part to third party repairers, while simultaneously refusing to sell it themselves.

Apple has two satisfactory options here: either stop actively blocking their manufacturers from selling direct, or start selling the components themselves.

...so, Moto's system where you can flash anything you want but it shows a warning screen on boot if you do?

(About the same as Chromebooks, actually)

So MacBooks could be compromised? We better find a laptop with a locked down computer operating system to be safe

Reply on news.ycombinator.com