5 ms·

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

by zb3 1y ago

fph 1y ago
Two fixes that would be trivial to backport to mainline Android.
- vbezhenar 1y ago
  You can configure USB port for charging only in the developer options.
  - andrepd 1y ago
    On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
    - Scrubbed4426 1y ago
      It is not the same feature as present on GrapheneOS. That is done through the OS while GrapheneOS makes kernel changes to physically shut it down.
    - strcat 1y ago
      That's the standard Android behavior for the USB gadget mode, not something specific to LineageOS, and it does not mean USB is in a charging-only mode but rather than no USB gadget functionality such as file transfer (MTP) is active. It does not mean USB peripherals and USB-C alternate mode are disabled, which certainly work in the default charging-only mode for Android's USB gadget setting. It doesn't even mean that USB gadget mode is fully disabled, only that it's in the MTP mode with MTP disabled. There's a slight difference between the regular and and more advanced setting: MTP mode with MTP disabled vs. no active USB gadget. The USB protection feature on GrapheneOS is for blocking new USB connections as a whole at both a software and hardware level and disabling USB data at a hardware level vs. that setting only controlling USB gadget mode. Most of the attack surface is in the USB protocol implementation and especially the USB peripheral drivers which are not disabled in the default mode Android calls charging-only since it's about USB gadget mode, i.e. using the phone itself as a peripheral.
      - andrepd 1y ago
        Got it, that makes sense! Thanks for explaining :)
  - giantg2 1y ago
    I think that's at the OS level. I think there are things that could be done through the firmware level.
    - wakawaka28 1y ago
      Since no phone on the market has open-source firmware, and the firmware likely has all the capabilities of the base system, I think arguing for a firmware lock on that is kind of pointless. Sure, every little bit of security helps, but ultimately you still need to trust a lot of stuff to use a smartphone or most other modern hardware.
      - giantg2 1y ago
        I had the wrong terminology. Your sibling comment explains it better.
    - strcat 1y ago
      That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact. See https://news.ycombinator.com/item?id=45779241 https://news.ycombinator.com/item?id=45779241 which explains this.
      - giantg2 1y ago
        Sorry, I had the wrong terminology.
  - tranq_cassowary 1y ago
    That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.
    - strcat 1y ago
      That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact. See https://news.ycombinator.com/item?id=45779241 https://news.ycombinator.com/item?id=45779241 which explains this.
      - tranq_cassowary 1y ago
        Thanks, I was confusing it with the Advanced Protection feature.
  - strcat 1y ago
    No, that only changes the USB gadget mode. It doesn't disable USB peripheral support, USB protocol handling, etc. in the OS and doesn't disable USB at a hardware level. It doesn't protect against the vast majority of Linux kernel driver exploits heavily used by Cellebrite. They mainly exploit bugs in USB peripheral drivers but could also exploit lower level kernel code or firmware if they had to. Modern Android on modern devices does support disabling software USB support for USB peripherals and USB gadgets while locked via Android 16 Advanced Protection feature. It also has a device admin API for disabling USB at a software level through device admin apps, which could implement disable it while locked but cannot provide support for still using a USB device connected while unlocked to make it much more usable. None of that provides comparable protection to the GrapheneOS USB protection feature, which is one small part of the overall GrapheneOS exploit protections. By default, GrapheneOS blocks new USB connections at a software AND hardware level when the device is locked and then disabling USB data once existing connections end. You can get similar software level functionality via the Android 16 Advanced Protection feature but not the hardware-level protection or the many other exploit protections in GrapheneOS. https://grapheneos.org/features#exploit-protection https://grapheneos.org/features#exploit-protection explains what's improved compared to standard Android 16. It's not documentation on Android + GrapheneOS features but rather only what GrapheneOS improves.
  - linux_modder 1y ago
    With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.
- ls612 1y ago
  iOS already does both of this afaik. At least the automatic reboot part, I think the USB data functionality is disabled in some cases while locked too.
  - int0x29 1y ago
    iOS is also compromised according to other cellebrite docs so that makes me think Graphene OS just might not be worth the effort for them.
    - ls612 1y ago
      iOS was hackable in 2024 for certain hardware (in particular the checkm8 era phones) or for iOS versions which had known vulns at that point. Modern hardware with updates was still listed as “in research” which means “we can’t”.
      - int0x29 1y ago
        The last leak was in 2024. Hopefully somone nabs the latest iOS release information Edit: last released leak showed they had broken the then most recent iOS release (17.5.1) in AFU state on all but the most recent hardware which was marked "available in CAS" https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... The good news is neither pixel nor iOS seems to show full file system extract under BFU state in the recent tables I can find.
        ls612 1y ago
        Neither have had any known BFU on the latest iOS for years. AFU is occasionally possible but most of the leaks had latest software and hardware as still protected. Powering off the phone is always still a good idea though if you can.
        strcat 1y ago
        That's not true. Cellebrite has working BFU and AFU exploits for recent iOS and usually catches up to the latest iOS versions and hardware in weeks or a couple months. They do not have working brute force support for the Pixel 2 / Pixel 6 or later / iPhone 12 or later due to the secure elements but can still exploit the devices in BFU mode and extract the data available before unlocking. iPhone 17 may work out better due to hardware memory tagging but previous iOS and iPhone models did not hold out in the way you're claiming at all.
- strcat 1y ago
  That's definitely not trivial and it's a small fraction of the security features GrapheneOS provides. https://news.ycombinator.com/item?id=45779157 https://news.ycombinator.com/item?id=45779157 explains several of the relevant features. Using hardware memory tagging for the whole base OS is definitely not trivial, and neither is implementing a much more hardened memory allocator. Our USB protection is not a trivial feature and is much more advanced than the USB protection features available in standard Android via the device admin API and Android 16 Advanced Protection mode.
  - fph 1y ago
    I never wrote that the other Graphene OS features and mitigations are trivial. I agree that there is much more to that. And even if the USB mitigations were hard to write (thanks for all your work, by the way!), they are surely significantly easier to backport from an open source project.
    - strcat 1y ago
      Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult. Google shipped the Pixel 8 with production quality MTE support at a hardware level in October 2023 but still isn't using it by default and their Advanced Protection mode only uses it for a tiny subset of the OS and nearly no user installed apps. Enabling it would involve a whole lot of work fixing the bugs it finds, but we're already doing that work in GrapheneOS. They'd also need to fix several issues with their MTE integration in Chromium and elsewhere. It wouldn't be as good as our better implementation in hardened_malloc, etc. but they could be using it. They could start using it in full async mode for near zero performance and cost and then enable sync or asym mode for more components over time where the performance cost is irrelevant, which applies to most of the base OS. They might not want to use sync mode in the kernel for performance reasons, but other than that it mostly has no noticeable performance cost outside of apps. Performance is likely a major factor Apple is not enabling it by default for apps and is instead discouraging app developers from opting into it by scaring them away with compatibility and performance concerns along with implying apps need to be written with it in mind which is really not the case. It finds memory corruption bugs and doesn't have false positives. Apps should not have memory corruption bugs in regular use and it's more than just an MTE compatibility issue if they do. Android made the smart decision to start tagging points with Top Byte Ignore in the system allocators many years ago which paved the way for HWASan support used by Android to nearly fully replace ASan and then later MTE support. HWASan is similar to MTE but with 8 bit instead of 4 bit tags using Top Byte Ignore but all accesses need to be instrumented to be checked since it's not a hardware feature. HWASan is much slower than MTE but Google has heavily used it for many years which means most of the OS was prepared for MTE other than hardware specific parts not well tested by automated testing.
aussieguy1234 1y ago
The auto reboot is configured by default. Its quite a long window, every 18 hours or so from memory. It can be configured to be shorter than this. I experimented with one hour, but missed an alarm. Its good security practice to reboot your phone before going to bed, this puts it in the much harder to break in to BFU state.
- strcat 1y ago
  Alarms work after reboot in the default system Clock app configuration. However, it does not work in all configurations since not everything is properly handled for the Clock app's Direct Boot mode. Google's Clock app works better since it diverged from AOSP Clock years ago. The main thing you'll miss are push notifications since the vast majority of apps do not have Direct Boot support for detecting there are notifications available. We aren't actually aware of any non-Google app supporting it.

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

by zb3 1y ago

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

fph 1y ago

Two fixes that would be trivial to backport to mainline Android.

vbezhenar 1y ago
You can configure USB port for charging only in the developer options.
- andrepd 1y ago
  On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
  - Scrubbed4426 1y ago
    It is not the same feature as present on GrapheneOS. That is done through the OS while GrapheneOS makes kernel changes to physically shut it down.
  - strcat 1y ago
    That's the standard Android behavior for the USB gadget mode, not something specific to LineageOS, and it does not mean USB is in a charging-only mode but rather than no USB gadget functionality such as file transfer (MTP) is active. It does not mean USB peripherals and USB-C alternate mode are disabled, which certainly work in the default charging-only mode for Android's USB gadget setting. It doesn't even mean that USB gadget mode is fully disabled, only that it's in the MTP mode with MTP disabled. There's a slight difference between the regular and and more advanced setting: MTP mode with MTP disabled vs. no active USB gadget. The USB protection feature on GrapheneOS is for blocking new USB connections as a whole at both a software and hardware level and disabling USB data at a hardware level vs. that setting only controlling USB gadget mode. Most of the attack surface is in the USB protocol implementation and especially the USB peripheral drivers which are not disabled in the default mode Android calls charging-only since it's about USB gadget mode, i.e. using the phone itself as a peripheral.
    - andrepd 1y ago
      Got it, that makes sense! Thanks for explaining :)
- giantg2 1y ago
  I think that's at the OS level. I think there are things that could be done through the firmware level.
  - wakawaka28 1y ago
    Since no phone on the market has open-source firmware, and the firmware likely has all the capabilities of the base system, I think arguing for a firmware lock on that is kind of pointless. Sure, every little bit of security helps, but ultimately you still need to trust a lot of stuff to use a smartphone or most other modern hardware.
    - giantg2 1y ago
      I had the wrong terminology. Your sibling comment explains it better.
  - strcat 1y ago
    That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact. See https://news.ycombinator.com/item?id=45779241 https://news.ycombinator.com/item?id=45779241 which explains this.
    - giantg2 1y ago
      Sorry, I had the wrong terminology.
- tranq_cassowary 1y ago
  That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.
  - strcat 1y ago
    That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact. See https://news.ycombinator.com/item?id=45779241 https://news.ycombinator.com/item?id=45779241 which explains this.
    - tranq_cassowary 1y ago
      Thanks, I was confusing it with the Advanced Protection feature.
- strcat 1y ago
  No, that only changes the USB gadget mode. It doesn't disable USB peripheral support, USB protocol handling, etc. in the OS and doesn't disable USB at a hardware level. It doesn't protect against the vast majority of Linux kernel driver exploits heavily used by Cellebrite. They mainly exploit bugs in USB peripheral drivers but could also exploit lower level kernel code or firmware if they had to. Modern Android on modern devices does support disabling software USB support for USB peripherals and USB gadgets while locked via Android 16 Advanced Protection feature. It also has a device admin API for disabling USB at a software level through device admin apps, which could implement disable it while locked but cannot provide support for still using a USB device connected while unlocked to make it much more usable. None of that provides comparable protection to the GrapheneOS USB protection feature, which is one small part of the overall GrapheneOS exploit protections. By default, GrapheneOS blocks new USB connections at a software AND hardware level when the device is locked and then disabling USB data once existing connections end. You can get similar software level functionality via the Android 16 Advanced Protection feature but not the hardware-level protection or the many other exploit protections in GrapheneOS. https://grapheneos.org/features#exploit-protection https://grapheneos.org/features#exploit-protection explains what's improved compared to standard Android 16. It's not documentation on Android + GrapheneOS features but rather only what GrapheneOS improves.
- linux_modder 1y ago
  With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.
ls612 1y ago
iOS already does both of this afaik. At least the automatic reboot part, I think the USB data functionality is disabled in some cases while locked too.
- int0x29 1y ago
  iOS is also compromised according to other cellebrite docs so that makes me think Graphene OS just might not be worth the effort for them.
  - ls612 1y ago
    iOS was hackable in 2024 for certain hardware (in particular the checkm8 era phones) or for iOS versions which had known vulns at that point. Modern hardware with updates was still listed as “in research” which means “we can’t”.
    - int0x29 1y ago
      The last leak was in 2024. Hopefully somone nabs the latest iOS release information Edit: last released leak showed they had broken the then most recent iOS release (17.5.1) in AFU state on all but the most recent hardware which was marked "available in CAS" https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... The good news is neither pixel nor iOS seems to show full file system extract under BFU state in the recent tables I can find.
      - ls612 1y ago
        Neither have had any known BFU on the latest iOS for years. AFU is occasionally possible but most of the leaks had latest software and hardware as still protected. Powering off the phone is always still a good idea though if you can.
        strcat 1y ago
        That's not true. Cellebrite has working BFU and AFU exploits for recent iOS and usually catches up to the latest iOS versions and hardware in weeks or a couple months. They do not have working brute force support for the Pixel 2 / Pixel 6 or later / iPhone 12 or later due to the secure elements but can still exploit the devices in BFU mode and extract the data available before unlocking. iPhone 17 may work out better due to hardware memory tagging but previous iOS and iPhone models did not hold out in the way you're claiming at all.
strcat 1y ago
That's definitely not trivial and it's a small fraction of the security features GrapheneOS provides. https://news.ycombinator.com/item?id=45779157 https://news.ycombinator.com/item?id=45779157 explains several of the relevant features. Using hardware memory tagging for the whole base OS is definitely not trivial, and neither is implementing a much more hardened memory allocator. Our USB protection is not a trivial feature and is much more advanced than the USB protection features available in standard Android via the device admin API and Android 16 Advanced Protection mode.
- fph 1y ago
  I never wrote that the other Graphene OS features and mitigations are trivial. I agree that there is much more to that. And even if the USB mitigations were hard to write (thanks for all your work, by the way!), they are surely significantly easier to backport from an open source project.
  - strcat 1y ago
    Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult. Google shipped the Pixel 8 with production quality MTE support at a hardware level in October 2023 but still isn't using it by default and their Advanced Protection mode only uses it for a tiny subset of the OS and nearly no user installed apps. Enabling it would involve a whole lot of work fixing the bugs it finds, but we're already doing that work in GrapheneOS. They'd also need to fix several issues with their MTE integration in Chromium and elsewhere. It wouldn't be as good as our better implementation in hardened_malloc, etc. but they could be using it. They could start using it in full async mode for near zero performance and cost and then enable sync or asym mode for more components over time where the performance cost is irrelevant, which applies to most of the base OS. They might not want to use sync mode in the kernel for performance reasons, but other than that it mostly has no noticeable performance cost outside of apps. Performance is likely a major factor Apple is not enabling it by default for apps and is instead discouraging app developers from opting into it by scaring them away with compatibility and performance concerns along with implying apps need to be written with it in mind which is really not the case. It finds memory corruption bugs and doesn't have false positives. Apps should not have memory corruption bugs in regular use and it's more than just an MTE compatibility issue if they do. Android made the smart decision to start tagging points with Top Byte Ignore in the system allocators many years ago which paved the way for HWASan support used by Android to nearly fully replace ASan and then later MTE support. HWASan is similar to MTE but with 8 bit instead of 4 bit tags using Top Byte Ignore but all accesses need to be instrumented to be checked since it's not a hardware feature. HWASan is much slower than MTE but Google has heavily used it for many years which means most of the OS was prepared for MTE other than hardware specific parts not well tested by automated testing.

aussieguy1234 1y ago

The auto reboot is configured by default. Its quite a long window, every 18 hours or so from memory. It can be configured to be shorter than this. I experimented with one hour, but missed an alarm. Its good security practice to reboot your phone before going to bed, this puts it in the much harder to break in to BFU state.

strcat 1y ago
Alarms work after reboot in the default system Clock app configuration. However, it does not work in all configurations since not everything is properly handled for the Clock app's Direct Boot mode. Google's Clock app works better since it diverged from AOSP Clock years ago. The main thing you'll miss are push notifications since the vast majority of apps do not have Direct Boot support for detecting there are notifications available. We aren't actually aware of any non-Google app supporting it.