Okay so in other words firmware is read only from the perspective of my OS and can't be tampered with unless I pop the back off my phone physically and update by hand. I have the schematics and everything so this is ideal.
I like that.
Conversation
It's not possible to update via OS, not from the perspective of the firmware. No one said the baseband can't receive a firmware update pushed via a cell phone tower, etc. No one said there is verified boot for it. No one said they picked components with security support.
1
1
The baseband is on a separate gemalto daughter card so that is its own black box so I don't think that is in scope here.
That is untrusted by the design of the hardware. Limited access to OS memory .
1
It's not specific to the baseband. It applies to the SoC and the other components. It's also not untrusted in any sense. As a general rule, Linux kernel drivers trust hardware components. You seem to be falling for the false dichotomy of DMA vs. non-DMA being about isolation.
1
Components with DMA can be untrusted, and often are, due to usage of IOMMUs. Components without DMA can be trusted, and often are, due to their role in the design of the device along with the design / implementation of typical drivers trusting the hardware that they support.
1
1
When someone writes a driver for hardware, they're rarely treating that hardware as an attacker. Wi-Fi, much like a cellular baseband, also runs a large RTOS requiring substantial hardening, auditing and regular security updates. You don't get that with these components.
1
If you're simply going to hand an attacker persistent local code execution on a Wi-Fi / Bluetooth / Cellular SoC you're trusting them with direct access to the kernel driver and other code supporting the device from the OS. It's a whole lot more than that too. What about privacy?
2
How are you going to have privacy if you have radios that are broadcasting their vulnerability and can be persistently compromised through known, public exploits? Even without taking control over the OS from there, they have unique hardware identifiers + can track location, etc.
1
This is why I personally will be using the physical switch to leave the radio disabled 99.9% of the time until at least and open/trusted driver exists to assure the memory blast radius is contained.
1
Which radio? All of them? This applies just as much to Wi-Fi and Bluetooth as it does to a cellular radio. They are not substantially different in implementation. Each of these radios is implemented with a substantially large RTOS with a lot of attack surface and complexity.
2
3
If the radio isn't designed with great care taken to avoid persistent state + implement full verified boot, then an attacker compromising it is going to trivially gain persistent code execution there. They get unique device identifiers (IMEI, MAC, and assorted others) to track.
They can do fine-grained location tracking of the device based on nearby Wi-Fi networks and/or cell phone towers and/or Bluetooth devices. They can also do side channel attacks even without trying to exploit the kernel. They can wait until there's a known driver vulnerability.
1
They've got a persistent, local compromise of the device. It's similar to an attacker having a persistent local compromise of a component in the OS. You've already lost your privacy at that point since you're having your location tracked + there's a local attacker for the kernel.
1
1
Show replies