5 ms·

Is anyone working on a microkernel design for privacy-sensitive devices (like phones) that would prevent outright this class of kernel-level arbitrary code exec

by mjamil 5y ago

Is anyone working on a microkernel design for privacy-sensitive devices (like phones) that would prevent outright this class of kernel-level arbitrary code execution exploits? We're stuck with iOS and Android for the foreseeable future, but is there hope that we'll get this right some day? Actually, would a microkernel design even be sufficient? Given that hackers exploit deserialization, memory safety, and variable type confusion issues, there's still plenty of avenues for data corruption and data leakage.

TheRealDunkirk 5y ago
I don't know why anyone would even bother to suggest such a thing when there's a second, completely-independent, unobservable computer running on every phone, with ring -1 access. Until we get rid of those, phones will continue to be the IDEAL surveillance tool for state-level actors. It's like the old saying about security: If you have access to the hardware, all bets are off. In our phones, the cell companies already have hardware-level access. It's almost like the government had a hand in developing the cell phone technology stack to make it so easy to use in this capacity... (Seriously, they did, but I don't want to go down the rabbit hole of finding links.)
bri3d 5y ago
Many of the kernel issues exploited in iOS are caused indirectly by its microkernel architecture, namely, the use of "ports" for kernel to kernel and kernel to user land IPC. For example: https://bugs.chromium.org/p/project-zero/issues/detail?id=2107&q=MACH_SEND_SYNC_OVERRIDE&can=1 https://bugs.chromium.org/p/project-zero/issues/detail?id=21... . Microkernel vs monolithic kernel has little to do with this, IMO. The main issues are asynchronous complexity and memory safety. Also, a lot of your most sensitive data lives in userland. If someone gets access to the iMessage sandbox and the message database files, that's your most sensitive and privileged data gone, no kernel touched.
- stefan_ 5y ago
  And the userland is the worst possible combination of technology imaginable for this purpose - a memory unsafe language with a ton of magic dynamic features. You get the horrible serialization issues from Java & Ruby with the same old heap, stack and integer overflows we've come to love in C and mix in some of the runtime control flow from C++.
fsflover 5y ago
Perhaps something like this: https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor. Or, just use Linux on the smartphone and harden it with a smartcard (Librem 5).
Raqbit 5y ago
Google is, with Fuchsia: https://fuchsia.dev https://fuchsia.dev
- wolverine876 5y ago
  What are they doing?
  - colatkinson 5y ago
    The "marketing fluff" is here [0]. From my understanding, the relatively novel things they're doing at the lowest levels are making it a microkernel, and using a capability-based security model [1]. The former decreases the Ring 0 attack surface, and the latter makes it challenging to cause a confused deputy problem -- you know, the ol' classic "whoops this daemon running as root accidentally allowed a browser tab to read /etc/shadow." Or the time honored problem of a single exploit in one process giving access to all files (and in some cases, all processes' memory and resources) controlled by a given user. Capabilities also make it relatively easy to sandbox userspace code, and to reason about what it has access to. Kinda like containers, but as a core concept rather than tacked on a few decades into development. Now these concepts aren't new, but they haven't been deployed or supported at the scale Fuchsia may end up at. Which obviously makes it a pretty exciting project in terms of real-world impact. That said, I believe there's been some speculation that part of the motivation for Fuchsia is to avoid the mess that is out-of-tree drivers on Android. So on the one hand, the kernel can be updated more easily, but on the other hand there may in practice be a lot more unpatchable binary blobs floating around doing important things. For a more academic project that has many of the same security concepts there's seL4 [2], which has the additional bonus of doing some insanely clever formal verification of the kernelspace code [3]. They have formal proofs that the compiled machine code actually implements the specified of the security model correctly, which is the first of its kind AFAIK. They actually have a set of interactive tutorials for the platform [4], which are a great way to get a feel for how userspace works on a security-focused kernel. As a disclaimer, I'm not associated with either project, and I'm sure my explanations will be ripped to shreds. My information comes purely from following the space in my free time. 0: https://fuchsia.dev/fuchsia-src/concepts/principles/secure https://fuchsia.dev/fuchsia-src/concepts/principles/secure 1: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security 2: https://sel4.systems/ https://sel4.systems/ 3: https://sel4.systems/Info/FAQ/proof.pml https://sel4.systems/Info/FAQ/proof.pml 4: https://docs.sel4.systems/Tutorials/ https://docs.sel4.systems/Tutorials/
kevingadd 5y ago
User-space ACE would still be enough to do something like this. All sorts of user-space apps have the relevant permissions and are not secured against attacks to the necessary extent to stop a state level actor.
fulafel 5y ago
I'm not convinced microkernels are the answwr but we do have QubesOS.
junon 5y ago
Yep, a number of people are, myself included. OSDev channels have a few people who talk about it. The Fuchsia folks are around, too, and are quite friendly people. They probably have the most hopeful chance of a widespread release, though admittedly I worry about the affiliation with Google getting in the way of pro-consumerism. Just my opinion though.
- webmaven 5y ago
  I wonder if some combination of Fuchsia, Titan, and Tensor would be sufficient to mitigate a baseband processor vulnerability.
  - junon 5y ago
    Probably not. Processor vulnerabilities have the perpensity to affect most OSes because they're often pretty fundamental flaws in the basic CPU security mechanisms when discovered.
    - webmaven 5y ago
      If I wasn't clear, I'm asking about vulnerabilities in the baseband processor (BBP), not the CPU. The BBP is what makes a smartphone a phone, rather than a small tablet: https://en.m.wikipedia.org/wiki/Baseband_processor https://en.m.wikipedia.org/wiki/Baseband_processor The thing about the BBP is that it is a second computer running its own proprietary OS (typically an RTOS) to handle the RF modem. The phone's main OS typically has no visibility into that second computer, even as root, but the reverse may not be true. So I was wondering if any of Google's efforts to increase security can mitigate attacks that might come through this particular channel that lurks, Kuato like, just out of sight.
  - saagarjha 5y ago
    Apple mitigates baseband processor vulnerabilities by putting it behind what's essentially an IOMMU.
    - 5y ago
CameronNemo 5y ago
The Intel ME runs a microkernel but it is still exploitable (even if you "clean" it). SEL4 and Fuchsia seem to have a security focus, but whether that results in real world difficult to exploit devices is unclear.
apayan 5y ago
I'm not aware of any microkernels for phones (I'm not sure that would help either), but Android has been sandboxing more and more processing [1] and started using some Rust at the system level [2] ever since the stagefright bug [3]. 1: https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html https://android-developers.googleblog.com/2019/05/queue-hard... 2: https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat... 3: https://en.wikipedia.org/wiki/Stagefright_(bug) https://en.wikipedia.org/wiki/Stagefright_(bug)
eightails 5y ago
Though currently Android-based, grapheneos is planning to move towards a microkernel + virtualisation model eventually. I'd imagine this is several years away at least, though. https://grapheneos.org/faq#roadmap https://grapheneos.org/faq#roadmap There's also sel4, a security focused version of the l4 microkernel which is apparently one of the only formally verified kernels. https://sel4.systems/About/ https://sel4.systems/About/
Veserv 5y ago
Here you go. Phone based on a high robustness microkernel. https://hoyosintegrity.com/products-2/hoyos-phone-2/ https://hoyosintegrity.com/products-2/hoyos-phone-2/

by mjamil 5y ago

TheRealDunkirk 5y ago

I don't know why anyone would even bother to suggest such a thing when there's a second, completely-independent, unobservable computer running on every phone, with ring -1 access. Until we get rid of those, phones will continue to be the IDEAL surveillance tool for state-level actors. It's like the old saying about security: If you have access to the hardware, all bets are off. In our phones, the cell companies already have hardware-level access. It's almost like the government had a hand in developing the cell phone technology stack to make it so easy to use in this capacity... (Seriously, they did, but I don't want to go down the rabbit hole of finding links.)

bri3d 5y ago

Many of the kernel issues exploited in iOS are caused indirectly by its microkernel architecture, namely, the use of "ports" for kernel to kernel and kernel to user land IPC. For example: https://bugs.chromium.org/p/project-zero/issues/detail?id=2107&q=MACH_SEND_SYNC_OVERRIDE&can=1 https://bugs.chromium.org/p/project-zero/issues/detail?id=21... . Microkernel vs monolithic kernel has little to do with this, IMO. The main issues are asynchronous complexity and memory safety. Also, a lot of your most sensitive data lives in userland. If someone gets access to the iMessage sandbox and the message database files, that's your most sensitive and privileged data gone, no kernel touched.

stefan_ 5y ago
And the userland is the worst possible combination of technology imaginable for this purpose - a memory unsafe language with a ton of magic dynamic features. You get the horrible serialization issues from Java & Ruby with the same old heap, stack and integer overflows we've come to love in C and mix in some of the runtime control flow from C++.

fsflover 5y ago

Perhaps something like this: https://www.crowdsupply.com/sutajio-kosagi/precursor https://www.crowdsupply.com/sutajio-kosagi/precursor. Or, just use Linux on the smartphone and harden it with a smartcard (Librem 5).

Raqbit 5y ago

Google is, with Fuchsia: https://fuchsia.dev https://fuchsia.dev

wolverine876 5y ago
What are they doing?
- colatkinson 5y ago
  The "marketing fluff" is here [0]. From my understanding, the relatively novel things they're doing at the lowest levels are making it a microkernel, and using a capability-based security model [1]. The former decreases the Ring 0 attack surface, and the latter makes it challenging to cause a confused deputy problem -- you know, the ol' classic "whoops this daemon running as root accidentally allowed a browser tab to read /etc/shadow." Or the time honored problem of a single exploit in one process giving access to all files (and in some cases, all processes' memory and resources) controlled by a given user. Capabilities also make it relatively easy to sandbox userspace code, and to reason about what it has access to. Kinda like containers, but as a core concept rather than tacked on a few decades into development. Now these concepts aren't new, but they haven't been deployed or supported at the scale Fuchsia may end up at. Which obviously makes it a pretty exciting project in terms of real-world impact. That said, I believe there's been some speculation that part of the motivation for Fuchsia is to avoid the mess that is out-of-tree drivers on Android. So on the one hand, the kernel can be updated more easily, but on the other hand there may in practice be a lot more unpatchable binary blobs floating around doing important things. For a more academic project that has many of the same security concepts there's seL4 [2], which has the additional bonus of doing some insanely clever formal verification of the kernelspace code [3]. They have formal proofs that the compiled machine code actually implements the specified of the security model correctly, which is the first of its kind AFAIK. They actually have a set of interactive tutorials for the platform [4], which are a great way to get a feel for how userspace works on a security-focused kernel. As a disclaimer, I'm not associated with either project, and I'm sure my explanations will be ripped to shreds. My information comes purely from following the space in my free time. 0: https://fuchsia.dev/fuchsia-src/concepts/principles/secure https://fuchsia.dev/fuchsia-src/concepts/principles/secure 1: https://en.wikipedia.org/wiki/Capability-based_security https://en.wikipedia.org/wiki/Capability-based_security 2: https://sel4.systems/ https://sel4.systems/ 3: https://sel4.systems/Info/FAQ/proof.pml https://sel4.systems/Info/FAQ/proof.pml 4: https://docs.sel4.systems/Tutorials/ https://docs.sel4.systems/Tutorials/

kevingadd 5y ago

User-space ACE would still be enough to do something like this. All sorts of user-space apps have the relevant permissions and are not secured against attacks to the necessary extent to stop a state level actor.

fulafel 5y ago

I'm not convinced microkernels are the answwr but we do have QubesOS.

junon 5y ago

Yep, a number of people are, myself included. OSDev channels have a few people who talk about it. The Fuchsia folks are around, too, and are quite friendly people. They probably have the most hopeful chance of a widespread release, though admittedly I worry about the affiliation with Google getting in the way of pro-consumerism. Just my opinion though.

webmaven 5y ago
I wonder if some combination of Fuchsia, Titan, and Tensor would be sufficient to mitigate a baseband processor vulnerability.
- junon 5y ago
  Probably not. Processor vulnerabilities have the perpensity to affect most OSes because they're often pretty fundamental flaws in the basic CPU security mechanisms when discovered.
  - webmaven 5y ago
    If I wasn't clear, I'm asking about vulnerabilities in the baseband processor (BBP), not the CPU. The BBP is what makes a smartphone a phone, rather than a small tablet: https://en.m.wikipedia.org/wiki/Baseband_processor https://en.m.wikipedia.org/wiki/Baseband_processor The thing about the BBP is that it is a second computer running its own proprietary OS (typically an RTOS) to handle the RF modem. The phone's main OS typically has no visibility into that second computer, even as root, but the reverse may not be true. So I was wondering if any of Google's efforts to increase security can mitigate attacks that might come through this particular channel that lurks, Kuato like, just out of sight.
- saagarjha 5y ago
  Apple mitigates baseband processor vulnerabilities by putting it behind what's essentially an IOMMU.
  - 5y ago

CameronNemo 5y ago

The Intel ME runs a microkernel but it is still exploitable (even if you "clean" it). SEL4 and Fuchsia seem to have a security focus, but whether that results in real world difficult to exploit devices is unclear.

apayan 5y ago

I'm not aware of any microkernels for phones (I'm not sure that would help either), but Android has been sandboxing more and more processing [1] and started using some Rust at the system level [2] ever since the stagefright bug [3]. 1: https://android-developers.googleblog.com/2019/05/queue-hardening-enhancements.html https://android-developers.googleblog.com/2019/05/queue-hard... 2: https://security.googleblog.com/2021/04/rust-in-android-platform.html https://security.googleblog.com/2021/04/rust-in-android-plat... 3: https://en.wikipedia.org/wiki/Stagefright_(bug) https://en.wikipedia.org/wiki/Stagefright_(bug)

eightails 5y ago

Though currently Android-based, grapheneos is planning to move towards a microkernel + virtualisation model eventually. I'd imagine this is several years away at least, though. https://grapheneos.org/faq#roadmap https://grapheneos.org/faq#roadmap There's also sel4, a security focused version of the l4 microkernel which is apparently one of the only formally verified kernels. https://sel4.systems/About/ https://sel4.systems/About/

Veserv 5y ago

Here you go. Phone based on a high robustness microkernel. https://hoyosintegrity.com/products-2/hoyos-phone-2/ https://hoyosintegrity.com/products-2/hoyos-phone-2/