1
12
App compatibility with GrapheneOS (discuss.grapheneos.org)
submitted 6 months ago* (last edited 6 months ago) by [email protected] to c/[email protected]

A step-by-step troubleshooting guide for problematic apps with possible workaround solutions.

https://discuss.grapheneos.org/d/8330-app-compatibility-with-grapheneos

2
30
submitted 1 day ago* (last edited 22 hours 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.

3
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
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.

5
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.

6
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.

7
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.

8
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.

9
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.

10
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.

11
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.

12
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.

13
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...

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

Our latest OS release that's currently in the Beta channel implements a new feature for blocking DNS leaks by third party VPN service app implementations which were discovered by our community:

https://github.com/GrapheneOS/os-issue-tracker/issues/3442

The good news is this does successfully block these leaks.

The bad news is that we currently don't feel comfortable moving this to the Stable channel due to a few reports of compatibility issues with @protonvpn's app. Doesn't appear to cause issues with any other VPN app after two days of public testing so it's likely a @protonvpn bug.

@protonprivacy

We'll give it another couple days of testing. Unless our users find an issue with another VPN app, we'll likely ship this to the Stable channel instead of cancelling the current change. We can't hold back an important improvement based on a single app which appears to be buggy.

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

Changes in version 125.0.6422.35.1:

  • backport patch for CVE-2024-4671

A full list of changes from the previous release (version 125.0.6422.35.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.

16
14
submitted 1 week 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:

  • 2024050900-redfin (Pixel 4a (5G), Pixel 5)
  • 2024050900 (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 2024050700 release:

  • prevent app-based VPN implementations from leaking DNS requests when the VPN is down/connecting (this is a preliminary defense against this issue and more research is required, along with apps preventing the leaks on their end or they'll still have leaks outside of GrapheneOS)
  • exclude Settings app from visible Location indicator too since it gets triggered from accessing Wi-Fi data when enabling Wi-Fi hotspot and potentially other info tied to Wi-Fi and Bluetooth
  • Vanadium: update to version 125.0.6422.35.0
  • PDF Viewer: update to version 19
17
24
submitted 1 week ago by [email protected] to c/[email protected]

Our PDF Viewer isn't impacted by issues like this in pdf.js. We use a strict Content Security Policy allowlisting the app's static CSS and JavaScript without permitting unsafe-eval or unsafe-inline. It's blocked from using eval or including dynamic JS.

https://github.com/advisories/GHSA-wgrm-67xf-hhpq

Even if we didn't set a Content Security Policy, the whole point of the app is that it renders a PDF in a sandboxed WebView instance without network, file or content access. It exposes a fairly small subset of the attack surface exposed by a web browser to any web site you visit.

The only data in the sandboxed WebView instance is the PDF which is written into it by the app without giving it access to the file/content. Even if an attacker somehow got JavaScript code execution despite our strict CSP, they couldn't do anything beyond attacking the browser.

The reason we use pdf.js is because it's designed to run efficiently in the browser sandbox. However, unlike opening a website in the browser, we use a restricted environment: no network/file/other access, no dynamic JS or CSS, many features disabled via Permissions Policy, etc.

JavaScript is memory safe but normally has pervasive dynamic code execution via inline JavaScript, dynamically included files and eval. It runs inside a restricted browser sandbox. The browser renderer implementing that sandbox runs inside of the browser's OS level sandbox.

GrapheneOS uses a hardened WebView provided by Vanadium. On Google certified Android OSes, it's provided by Chrome. Either way, our approach is far safer than a C++ PDF library in an OS sandbox (isolatedProcess). It provides 2 extra layers of strong security against most attacks.

Exploiting a vulnerability in the PDF library doesn't really work against our PDF Viewer app since there's an allowlist for the code. In practice, an attacker would need to exploit Chromium's rendering indirectly through pdf.js such as targeting browser font/image rendering.

Android uses isolatedProcess for the official PDF rendering library, which lacks our additional layers of protection and is far easier to exploit. Nearly all Android PDF apps bundle their own C or C++ PDF rendering library and don't bother even using an isolatedProcess sandbox.

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

Changes in version 125.0.6422.35.0:

  • update to Chromium 125.0.6422.35

A full list of changes from the previous release (version 124.0.6367.159.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.

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

Every patch in the May 2024 Pixel Update Bulletin is also relevant to a lot of other devices including the High severity Bluetooth issue we reported:

https://source.android.com/docs/security/bulletin/pixel/2024-05-01 https://grapheneos.social/@GrapheneOS/112066872276203917

Android Security Bulletin SHOULD be expanded. All of this should be in it.

OEMs are only required to fix the issues listed in the Android Security Bulletin (ASB). The main section is a list of what gets backported to older AOSP releases, but they should include all Pixel Update Bulletin patches relevant to other devices in the 2nd section of the ASB.

Android Security Bulletin simply assumes other OEMs don't bother shipping monthly and quarterly updates but rather only use the initial yearly release and backport a subset of the security patches to it. Having such low expectations for other OEMs plays a role in what they do.

Low/Moderate severity AOSP patches are no longer listed in bulletins and rarely backported to the older versions.

Quarterly and yearly releases used to list dozens of Low/Moderate severity AOSP patches in Pixel bulletins, often over a 100, all needed by other devices too.

Android security patches are essentially 2 different worlds. There are Pixels shipping all of the AOSP and other Android security patches and then everything else shipping only the subset backported to older releases including Android 14 which is NOT the current Android version.

In general, other OEMs are missing nearly all Low/Moderate security patches until they move to the next yearly release. They won't get most of the Moderate severity patches released this month until they move to Android 15. Many significant privacy issues are classified Moderate.

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

Notable changes in version 19:

  • avoid crash from unhandled exception in PDF date parsing for displaying metadata (was not a regression in version 18)
  • update eslint to 0.21.1
  • avoid false positive lint checks

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to content or files. Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the apk assets. It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with no access to the network (unlike a browser), files, or other content.

This app is available through the Play Store with the app.grapheneos.pdfviewer.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.grapheneos.pdfviewer 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.

21
9
submitted 1 week 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:

  • 2024050700-redfin (Pixel 4a (5G), Pixel 5)
  • 2024050700 (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 2024050300 release:

  • full 2024-05-05 security patch level
  • rebased onto AP1A.240505.005 Android Open Source Project release
  • update our backports of mainline APEX Health Fitness patches
  • kernel (5.10): update to latest GKI LTS branch revision including update to 5.10.213
  • kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.151
  • TalkBack (screen reader): update dependencies
  • Vanadium: update to version 124.0.6367.159.0
  • PDF Viewer: update to version 18
22
37
submitted 1 week ago by [email protected] to c/[email protected]

We've pre-ordered a Pixel 8a for our official device testing farm. They push the Android Open Source Project tags and stock OS factory images on the official release day. Should take us a couple hours to add support for it. We'll build, test and make an official release quickly.

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

Notable changes in version 18:

  • update pdf.js to 4.2.67
  • handle backwards incompatible pdf.js changes
  • use esbuild to handle building the viewer code
  • reorganize code, improve code quality and avoid deprecated APIs
  • update eslint to 9.2.0
  • update dependencies of npm dependencies
  • update Gradle to 8.7
  • update Android Gradle plugin to 8.4.0
  • update Android build tools to 34.0.0
  • update SDK to 34 (Android 14)
  • update target API level to 34 (Android 14)
  • update Kotlin to 1.9.24
  • update Material Components library to 1.12.0
  • update AndroidX Core to 1.13.1

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

Simple Android PDF viewer based on pdf.js and content providers. The app doesn't require any permissions. The PDF stream is fed into the sandboxed WebView without giving it access to content or files. Content-Security-Policy is used to enforce that the JavaScript and styling properties within the WebView are entirely static content from the apk assets. It reuses the hardened Chromium rendering stack while only exposing a tiny subset of the attack surface compared to actual web content. The PDF rendering code itself is memory safe with dynamic code evaluation disabled, and even if an attacker did gain code execution by exploiting the underlying web rendering engine, they're within the Chromium renderer sandbox with no access to the network (unlike a browser), files, or other content.

This app is available through the Play Store with the app.grapheneos.pdfviewer.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.grapheneos.pdfviewer 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.

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

Changes in version 124.0.6367.159.0:

  • update to Chromium 124.0.6367.159
  • prepare our content filter generation script for handling language-specific content filters
  • fix Python 3.12 warnings during build

A full list of changes from the previous release (version 124.0.6367.113.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.

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

Google has listed the CVE-2024-23694 vulnerability we reported in the security acknowledgements for May 2024:

https://source.android.com/docs/security/overview/acknowledgements

This is the Bluetooth issue we found with memory tagging which they assigned a High severity:

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

We fixed this on March 9th.

This vulnerability isn't listed in the baseline Android Security Bulletin despite being an Android Open Source Project issue. It will likely be listed in the Pixel Update Bulletin which should be today with the monthly update of AOSP and the Pixel OS:

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

This vulnerability only impacts Android 14 QPR2 and later. It's possible they only list issues impacting the initial release of Android 14 in Android Security Bulletins and put the rest in Pixel bulletins. It's odd how Pixel bulletins are mostly issues impacting other devices.

Last month, Pixels fixed 2 vulnerabilities we reported which were both classified as High severity and were both exploited in the wild by forensic companies:

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

Both also impact non-Pixels but were only fixed for Pixels and listed in the Pixel bulletin.

We understand why they didn't list those firmware patches in the Android Security Bulletin (ASB) since other devices with the same issues need their own firmware patches for them.

The AOSP 14 QPR2 Bluetooth bug not being listed means ASB is less complete than we thought though.

As we expected, it's listed in the Pixel Update Bulletin despite being an Android Open Source Project vulnerability and patch:

https://source.android.com/docs/security/bulletin/pixel/2024-05-01

Android Security Bulletins only cover the subset of High/Critical severity patches backported to the baseline yearly releases.

view more: next ›

GrapheneOS [Unofficial]

311 readers
31 users here now

Welcome to the GrapheneOS (Unofficial) community

This feed is currently only used for announcements and news.

Official support available on our forum and matrix chat rooms

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility.

Links

More Site links

Social Media

This is a community based around the GrapheneOS projects including the hardened Android Open Source Project fork, Auditor, AttestationServer, the hardened malloc implementation and other projects.

founded 3 years ago
MODERATORS