KindnessInfinity

joined 2 years ago
MODERATOR OF
 

Chromium has merged the WebAssembly interpreter submitted by a Microsoft Edge engineer:

https://chromium-review.googlesource.com/c/v8/v8/+/5509903

Once this reaches a Chromium stable release, Vanadium will support WebAssembly by default instead of requiring turning on JS JIT via drop-down site settings.

Chromium has a V8 Optimizer toggle for disabling the 2 optimized tiers of the Just-In-Time (JIT) compiler to greatly reduce attack surface. However, it doesn't disable baseline JIT and therefore still does dynamic native code generation. They did this to avoid breaking Wasm.

In Vanadium, our JIT toggle fully disables the JIT and therefore currently loses Wasm support. An increasing number of sites are depending on Wasm with no fallback to JavaScript. Most of these sites perform perfectly fine with only the fast V8 interpreter and no JIT compilation.

Vanadium has JIT compilation disabled by default as part of the security focus. This Wasm interpreter will be a nice usability improvement for sites depending on it with no fallback code since users won't need to toggle on the JIT compiler for the site unless it performs badly.

 

Changes in version 127.0.6533.64.0:

  • update to Chromium 127.0.6533.64
  • enable visited link partitioning

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

 

Notable changes in version 71:

  • only allow toggling include audio while recording when it was initially enabled, since CameraX doesn't currently support enabling it if it didn't start out enabled

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

This app is available through the Play Store with the app.grapheneos.camera.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.camera app id are published in the GrapheneOS App Store and on GitHub. You can use the GrapheneOS App Store 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 Store 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.

 

Notable changes in version 70:

  • downgrade Android Gradle plugin from 8.5.1 to 8.5.0 to work around a CameraX extensions library minification issue

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

This app is available through the Play Store with the app.grapheneos.camera.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.camera app id are published in the GrapheneOS App Store and on GitHub. You can use the GrapheneOS App Store 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 Store 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.

 

Notable changes in version 69:

  • add support for saving video as previewed for portrait mode (mirror mode)
  • avoid in-app gallery resetting to first image on configuration changes such as rotation
  • add double-tap to zoom for the in-app gallery
  • add support for for toggling audio while video recording is ongoing
  • change rendering approach for the QR scanning overlay for improved compatibility
  • migrate to official CameraX APIs for EIS
  • update CameraX to 1.4.0-beta02
  • update AndroidX Core to 1.13.1
  • update AndroidX AppCompat library to 1.7.0
  • update Material Components library to 1.12.0
  • update Android Gradle plugin to 8.5.1
  • update Android NDK to 26.3.11579264
  • update Android build tools to 35.0.0
  • update Gradle to 8.9
  • update Kotlin to 2.0.0

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

This app is available through the Play Store with the app.grapheneos.camera.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.camera app id are published in the GrapheneOS app repository and on GitHub. You can use the GrapheneOS App Store 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 Store 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.

 

Changes in version 124:

  • update max supported version of Play Store to 41.9

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

 

Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.

Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.

GrapheneOS is defending against these tools with generic exploit protections rather than by patching specific vulnerabilities. Until recently, it's likely that it was our generic memory corruption exploit mitigations including hardened_malloc which was successfully stopping this.

In February 2024, we added a new feature for disabling the USB-C port at a hardware level. In March 2024, we set the default mode to "Charging-only when locked, except before first unlock". In June 2024, we increased the default security level to "Charging-only when locked".

Later in June 2024, we extended our software-level USB protection, merged it into the newer hardware-level protection feature and extended the hardware-level protection to pogo pins on the Pixel Tablet. There's extremely strong protection against these USB-based attacks now.

Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for overall Android devices. Other than the Titan M2 on the Pixel 6 and later not being successfully yet to bypass brute force protection, it's largely just based on what they've had time to support.

In January 2024, we reported several vulnerabilities being exploited by the XRY tool from MSAB to get data from Android devices including stock OS Pixels. In April 2024, Pixels shipped a reset attack mitigation we proposed preventing the whole attack vector. We plan to expand it.

Currently, non-Pixel devices are still vulnerable to these reset attacks. In June 2024, Android 14 QPR3 included another feature we proposed providing wipe-without-reboot support for the device admin wipe API. We shipped this early and use it in our duress PIN/password feature.

We also began triggering a full compacting garbage collection cycle in system_server and SystemUI when the device is locked based on info about these attacks. This releases memory for no longer allocated objects to the OS, where our generic zero-on-free feature clears all of it.

In the near future, we plan to ship support for adding a PIN as a 2nd factor to fingerprint unlock to enable users to use a strong passphrase combined with PIN+fingerprint secondary unlock for convenience. We have an initial implementation, but it needs more work before shipping.

We're going to continue advancing the state of the art for protection against exploitation. Hardware vendors are welcome to collaborate with us if they want to protect users. We're regularly filing vulnerability reports and making suggestions to improve the security of Pixels.

Glossary:

BFU: Before First Unlock exploitation of OSBF: Brute Force password after BFU exploitation, which requires bypassing secure element brute force protection if implementedAFU: After First Unlock exploitation of OSFFS: Full Filesystem Extraction from an unlocked device

BF capability does not bypass hardware-bound key derivation, so a brute force is still rate limited but no longer has an extremely small number of attempts. Cellebrite Advanced Services may be able to bypass this through extracting data from hardware, but it would be difficult.

BF implies ability to bypass random 6 digit PINs. It does not imply ability to bypass a decent passphrase where hardware-bound key derivation slows them down too much. A truly strong passphrase is safe even if they bypass hardware-bound key derivation and use a huge server farm.

 

Cellebrite Premium documentation we published in May and which recently received a lot of media coverage was from April 2024. Someone has shared a newer version of the iOS table indicating Cellebrite caught up to iOS 17.5.1 or higher along with the iPhone 15 for the OS exploits.

It's common for them to fall behind by a few months for new iOS and Android versions. Android and iOS have no secure way to automatically get devices back into Before First Unlock from After First Unlock as GrapheneOS does so attackers can simply wait until they have an exploit.

We're currently waiting for one of our several sources to provide us with the new Android and iOS documentation. We aren't going to post the leaked iOS table in this thread because we can't confirm that it's authentic yet. We should have the new documentation quite soon though.

It's unfortunate that there was a whole bunch of secondary news coverage where it was misreported that Cellebrite was unable to exploit current iOS based on documentation from April 2024. It's July 2024 now, and they've had months to restore the capabilities broken by an update.

 

GrapheneOS App Store now includes a mirror of Accrescent, which is a privacy and security focused alternative to the Play Store distributing developer builds of apps:

https://accrescent.app/

Accrescent comes from within the GrapheneOS community and we're collaborating together.

Accrescent is in alpha and isn't yet open to any developers uploading their apps. It will have a lot more apps available in the future. It will become a full alternative to Play Store permitting closed source apps too, but you'll be able to filter to show only open source apps.

Lead dev of Accrescent is a GrapheneOS user and contributor. It'll be a good place to publish apps for GrapheneOS users. AppVerifier, BeauTyXT and Transcribro are from the same person who wrote our Info app. Molly is a security-focused fork of Signal from another GrapheneOS user.

AppVerifier was based on a planned GrapheneOS feature for users to verify APK files based on their key fingerprint. The feature is currently stalled since relying on the clipboard isn't ideal. For now, users can use AppVerifier from Accrescent until we ship a built-in approach.

We'll be delegating distributing developer builds of apps signed by the developers to Accrescent rather than doing it in ourselves. Our App Store will be focused on our own apps and eventually hardened, rebranded builds of important third party apps widely used by our community.

 

We published the Cellebrite Premium documentation from April 2024 in May 2024:

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

Our thread properly explains the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later.

Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume it didn't change.

404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage.

The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions.

The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet.

We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is working.

It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes.

In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY.

In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY.

In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit.

GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.

 

Notable changes in version 24:

  • change name from Apps to App Store
  • delay update check for 10 seconds after the automatic update job starts to work around the network being declared as ready before it's functional (often caused by VPN apps)
  • use a dedicated error message for failed background updates to make it easier to understand
  • add a package flag for opting out of bulk updates
  • declare DEFAULT and APP_MARKET intent categories
  • update Android build tools to 35.0.0
  • update Material Components library to 1.12.0
  • update AndroidX AppCompat library to 1.7.0
  • update AndroidX Fragment KTX library to 1.8.1
  • update AndroidX Core KTX library to 1.13.1
  • update AndroidX Lifecycle libraries to 2.8.1
  • update Android Gradle plugin to 8.5.1
  • update Gradle to 8.9
  • update Kotlin to 2.0.0
  • update Kotlin Symbol Processing to 1.0.21
  • improve code quality

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

Apps is the client for the GrapheneOS app repository. It's included in GrapheneOS but can also be used on other Android 12+ operating systems. Our app repository currently provides our standalone apps, out-of-band updates to certain GrapheneOS components and a mirror of the core Google Play apps and Android Auto to make it easy for GrapheneOS users to install sandboxed Google Play with versions of the Google Play apps we've tested with our sandboxed Google Play compatibility layer.

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.

 

Changes in version 126.0.6478.186.0:

  • update to Chromium 126.0.6478.186
  • reimplement reading content filtering rules from config app to avoid upstream memory corruption bug caught by hardware memory tagging

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

Oh gosh ๐Ÿ˜ฎ

[โ€“] KindnessInfinity@lemmy.ml 2 points 2 years ago (2 children)

My post is cross posted from there, actually. Odd they are ignoring or not seeing my post. :/

You can install on the devices that are listed here. https://grapheneos.org/faq#supported-devices

If your phone is secure with screenlock, kept up to date and uses grapheneos than your banking should be safe. Using grapheneOS auto reboot feature would prevent anybody accessing private data stored in RAM , as it's all at rest after reboot

It's harder for the average person. You have to know how to change device boot order in BIOS/UEFI, average person barely knows what an operating system is, let alone how to find their PC UEFI/BIOS setting menu to configure boot order. Grapheneos explains it clearly, how to install. You simply tap a few buttons on the browser and on the phone, when prompted.

That is correct they are

Pixel only for now, yeah.

Here's the list of officially supported pixels: https://grapheneos.org/faq#supported-devices

Permission toggles are are what things apps have access to, Grapheneos gives:

  • Sensors permission (this is how your phone can use sensors to determine if you are walking, moving, how far your phone is away from your face)

  • internet permission toggle (this allows you to control what apps can directly connect to the internet)

  • Storage Scopes (You can control what files or directory any app that uses legacy storage permissions have access to instead of blank allowing all files access to the app)

  • Contact Scopes (This allows, like Storage Scopes, for you to control what apps can access contacts and who's contact the app can or can not see)

You can and should give https://grapheneos.org/features a read.

As for banking apps, depending on what they are, may work. Paypal and some others work.

[โ€“] KindnessInfinity@lemmy.ml 2 points 2 years ago (4 children)

Thank you. The communities I moderate are on Lemmy.ml

GrapheneOS is protecting people from bad actors who get ahold of these devices

Ohh that is valid. I do miss that feature. Hopefully someday it is brought to AOSP

Only ever needed root when I used gingerbread devices

view more: โ€น prev next โ€บ