sorted by: new top controversial old
30
submitted 1 day ago* (last edited 1 day ago) by [email protected] to c/[email protected]

XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.

Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.

Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks.

Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits.

Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much.

As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked.

Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks.

By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked.

Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes.

GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging.

Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all.

Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up.

GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastboot zeroing.

New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits.

Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.

If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable.

See https://grapheneos.social/@GrapheneOS/112204428984003954 for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us.

Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock.

One of our community members has uploaded the Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:

https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/4

We have info on XRY, Graykey and others but not the same level of reliable details as this.

[-] [email protected] 1 points 3 days ago

Vanadium is still more secure than fennec

Why? Well, vanadium has these security improvements:

  • Type-based Control Flow Integrity (CFI)
  • Hardware memory tagging (MTE) enabled for the main allocator
  • Strict site isolation and sandboxed iframes
  • JavaScript JIT disabled by default with per-site toggle via drop-down permission menu

Also many more security improvements

2
submitted 3 days ago by [email protected] to c/[email protected]

Changes in version 111:

  • update max supported version of Play Store to 41.0

A full list of changes from the previous release (version 110) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

10
submitted 3 days ago by [email protected] to c/[email protected]

Pixel 4a (5G) and Pixel 5 are end-of-life and shouldn't be used anymore due to lack of security patches for firmware and drivers. We provide extended support for harm reduction.

Tags:

  • 2024051500-redfin (Pixel 4a (5G), Pixel 5)
  • 2024051500 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, emulator, generic, other targets)

Changes since the 2024050900 release:

  • revert our initial approach to blocking DNS leaks with third party Android VPN apps since it changed the behavior in a slightly different way than intended and caused compatibility issues with certain apps (particularly Proton VPN) which blocked us from releasing 2024050900 to the Stable channel (will be replaced in the near future with another approach)
  • improve GrapheneOS Predicted Satellite Data Service (PSDS) infrastructure with better logging, cleaner code and more generic code to support Samsung PSDS for the Pixel 8a in addition to Qualcomm and Broadcom PSDS
  • Auditor: update to version 80
  • GmsCompatConfig: update to version 110
  • Vanadium: update to version 125.0.6422.51.0
  • Vanadium: update to version 125.0.6422.53.0
4
submitted 3 days ago by [email protected] to c/[email protected]

Changes in version 125.0.6422.53.0:

  • update to Chromium 125.0.6422.53

A full list of changes from the previous release (version 125.0.6422.51.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

7
submitted 4 days ago by [email protected] to c/[email protected]

An experimental prerelease of GrapheneOS for the Pixel 8a is now available via https://staging.grapheneos.org/ including web installer support. It will be made available via https://grapheneos.org/ after we've done basic testing including testing the upgrade path to a future release.

Pixel 8a currently uses Android 14 QPR1 instead of Android 14 QPR2, meaning it's missing many improvements from the 2nd quarterly release including important privacy and security enhancements. It's likely Android 14 QPR3 will be released in June which should resolve this problem.

Android 14 QPR2 is the largest ever quarterly release of Android, because it's the first trunk-based development release. It brought a lot of what Android 15 is going to ship, largely under the hood with new user-facing features largely disabled but present in the code.

Android 14 QPR2 was released on March 4th but had a delay in publishing to AOSP due to issues with pushing the code which was finished by March 5th. GrapheneOS had a release based on it within a day of that, but it took a couple days to reach staging due to regressions we found.

One of those regressions was the High severity Bluetooth vulnerability we found which was introduced in Android 14 QPR2:

https://grapheneos.social/@GrapheneOS/112400427658505385

This issue slipped into our Stable channel release due to only coming up with rare configurations but we got it fixed on March 9th.

Since the Pixel 8a is still using Android 14 QPR1, our initial release is based on porting our changes from our 2024030300 release which was the last one based on QPR1 (https://grapheneos.org/releases#2024030300). It has a current May security patch level, but this doesn't meet our usual standards.

It's missing improvements to GrapheneOS from March, April and May in addition to Android 14 QPR2 changes. We backported our change enabling PAC/BTI for userspace and are using a current GrapheneOS 5.15 LTS common kernel source tree. SHOULD be fixed with June update, QPR3 or not.

We've tested basic functionality including over-the-air updates so our Pixel 8a prerelease is now available via grapheneos.org.

Pixel 8a switched to Samsung GNSS (GPS, etc.) from Broadcom so we need to add Samsung PSDS support to our network services for PSDS to work.

9
submitted 4 days ago by [email protected] to c/[email protected]

Pixel 8a with the latest May 2024 update is running Android 14 QPR1 with backported security patches instead of Android 14 QPR2.

Android 14 QPR2 was released in March 2024 and is by far the largest quarterly release so far due to being the first trunk-based quarterly release.

We're definitely not going to backport all the changes we've made since March to Android 14 QPR1. That means we can't simply make the usual device support branch to support it. It's going to need to start out being treated as if it's an end-of-life device in extended support.

We're working on making an experimental pre-release build of GrapheneOS for the Pixel 8a. It will have the 2024-05-05 security patch level but it will initially be missing the Android 14 QPR2 improvements and also the many GrapheneOS improvements since our March 3rd release.

There's a high chance Android 14 QPR3 will be released in June, and they likely decided it didn't make sense to go through all the work of getting QPR2 ready for release. Launching a brand new Pixel with backports to a previous quarterly release is still quite a strange choice.

11
submitted 4 days ago* (last edited 4 days ago) by [email protected] to c/[email protected]

Our Vanadium browser (https://grapheneos.org/features#vanadium) is based on the stable releases of Chromium. We port to the new releases when they're still in Beta/Dev/Canary but we wait until it's Stable to upgrade, particularly since Stable is the only branch with proper security support.

Within release channels, Chromium uses staged rollouts where initially only a random subset of users get the new release. Recently, the initial Stable channel release started being done 1 week early and only rolled out to a tiny number of users:

https://developer.chrome.com/blog/early-stable

Current release status for Android is at https://chromiumdash.appspot.com/releases?platform=Android. There are 2 variants of a regular Stable release and 2 of an early one, since they enjoy A/B testing changes so much.

We've been following the early Stable, but this month they failed to support it properly...

After the pair of early Stable releases based on v125 for Android, there were 2 pairs of releases based on v124 with 2 rounds of security patches for issues being exploited in the wild. They failed to update the early Stable release as they have before, so we had to deal with it.

Strangely, it appears that the early Stable channel release was only rolled out for Android and the Safari-based iOS app. The 0.2% of Android users receiving the early Stable release aren't getting patches for those 2 vulnerabilities being exploited in the wild. That's not great.

These are the 2 patches missing for Android users who get updated to 125.0.6422.34 or 125.0.6422.35:

https://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_9.htmlhttps://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_13.html

Both are marked as having an exploit in the wild. They should really simply make 1 tag and stop making things overly complex.

7
submitted 4 days ago by [email protected] to c/[email protected]

Changes in version 125.0.6422.51.0:

  • update to Chromium 125.0.6422.51

A full list of changes from the previous release (version 125.0.6422.35.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

[-] [email protected] 0 points 6 days ago

Here is the protonVPN issue on this on their github: https://github.com/ProtonVPN/android-app/issues/136

5
submitted 1 week ago by [email protected] to c/[email protected]

Changes in version 110:

  • update max supported version of Play Store to 40.9

A full list of changes from the previous release (version 109) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

7
submitted 1 week ago by [email protected] to c/[email protected]

Notable changes in version 80:

  • add support for Pixel 8a with either the stock OS or GrapheneOS
  • update Kotlin to 1.9.24
  • update Android Gradle plugin to 8.4.0
  • update Guava library to 33.2.0
  • update AndroidX Core library to 1.13.1
  • update Material Components library to 1.12.0
  • remove redundant style configuration found by lint

A full list of changes from the previous release (version 79) is available through the Git commit log between the releases.

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS app repository and on GitHub. These releases are also bundled as part of GrapheneOS. You can use the GrapheneOS app repository client on Android 12 or later for automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel.

GrapheneOS users must either obtain GrapheneOS app updates through our app repository or install it with adb install-multiple with both the APK and fs-verity metadata since fs-verity metadata is now required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

34
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]

We've received the Pixel 8a for our device testing farm already even though it officially ships May 14th.

Both Android Open Source Project source code tags and stock OS factory images / updates will likely be published on May 14th. We'll need those to add GrapheneOS support.

They typically ship pre-ordered devices a few days early to provide most people with an estimated delivery date on the launch day. It's a bit odd they don't publish everything on the day they ship instead of the planned arrival day since many do arrive early. It's fine with us.

Today, we're going to be adding support for the Pixel 8a in Auditor along with generating and backing up official GrapheneOS signing keys which are separate for each device for security reasons. We can't do much else before the official launch day when the code is published.

Once code is published, it will only take us a couple hours to add support for the device. We'll just need to largely automatically generate a device support branch, port over our work from the earlier 8th generation Pixels, make an adevtool state build and then a real release.

14
submitted 1 week ago by [email protected] to c/[email protected]

https://grapheneos.social/deck/@GrapheneOS/112401228331673501

Response we've received is the Bluetooth vulnerability we reported in March they fixed for Pixels in May will be included in the SEPTEMBER Android Security Bulletin.

Android Security Bulletin should be expanded to include Pixel Update Bulletin patches...

[-] [email protected] 3 points 4 weeks ago

Thank you. Me too

[-] [email protected] 4 points 1 month ago

The physical USB data lines are disabled by the OS's current USB management, this is done as USB device ID's can be spoofed, which opens up a security whole.

[-] [email protected] 1 points 1 month ago

According to the officially supported devices list for the OS, there is a pixel fold device that can run the OS.

-Pixel 8 Pro (husky) -Pixel 8 (shiba) -Pixel Fold (felix) -Pixel Tablet (tangorpro) -Pixel 7a (lynx) -Pixel 7 Pro (cheetah) -Pixel 7 (panther) -Pixel 6a (bluejay) -Pixel 6 Pro (raven) -Pixel 6 (oriole) -Pixel 5a (barbet)

[-] [email protected] 1 points 1 month ago
[-] [email protected] 2 points 1 month ago

Sorry to see that are experiencing this. Sounds like a problem with the watch itself, since you have to reset the watch to fix the problem. Hopefully the manufacture of the watch fixes this issue soon.

[-] [email protected] 1 points 1 month ago

I don't have a watch to test. .

[-] [email protected] 1 points 2 months ago

That's frustrating. Are you on matrix by any chance?

[-] [email protected] 1 points 2 months ago

I'll pass this along to them. Thank you for your kind comment.

view more: next ›

KindnessInfinity

joined 11 months ago
MODERATOR OF