KindnessInfinity

cross-posted from: https://lemmy.ml/post/17265164

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

We questioned why this was only listed in the Pixel Update Bulletin and they agree:

After review we agree with your assessment that this is an Android issue and as such we are working on backports to include this in a future Android Security Bulletin.

April 2024 monthly update for Pixels included a partial mitigation for this vulnerability in firmware (CVE-2024-29748).

Android 14 QPR3 released in June 2024 includes a full solution for all Android devices by implementing the wipe-without-reboot proposal we made in our report.

The issue is that in practice, only Pixels ship the monthly and quarterly updates. Other devices only ship monthly security backports, not the monthly/quarterly releases of AOSP. They were only going to get the patch when they updated to Android 15. They're now going to backport.

The other vulnerability we reported at the same time for reset attacks was assigned CVE-2024-29745 but that's a firmware/hardware issue without a software solution available so we can't get them to include it in the Android Security Bulletin unless we convince Qualcomm to fix it.

Every vulnerability in the Android Open Source Project that's deemed to be High/Critical severity is meant to be backported to yearly releases from the past 3 years (currently Android 12, 13 and 14). Low/Moderate severity vulnerabilities are NOT generally backported though.

The issue is that they're really listing patches rather than vulnerabilities. Both of the vulnerabilities we originally reported impact all Android devices, but both got Pixel specific patches in April 2024 and therefore got treated as Pixel specific vulnerabilities instead.

Since the complete solution for the device admin API is an Android Open Source Project (AOSP) patch, they're going to backport it. Since there's no way to frame the reset attack issue as an AOSP issue, there isn't a good way to get it fixed for other devices through this system.

These patched vulnerabilities and other currently unpatched vulnerabilities are being exploited by forensic tools used by states to target journalists, political opponents, activists, arbitrary people crossing borders, etc. Sure, they target lots of drug users / dealers too...

cross-posted from: https://lemmy.ml/post/16336497

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:

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

• add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down
• disable unused adoptable storage support since it would complicate duress password feature (can be added if we ever support a device able to use it)
• increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature
• disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access
• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153
• kernel (6.1): update to latest GKI LTS branch revision
• Vanadium: update to version 125.0.6422.72.0
• Vanadium: update to version 125.0.6422.72.1
• Vanadium: update to version 125.0.6422.113.0
• Vanadium: update to version 125.0.6422.147.0
• GmsCompatConfig: update to version 112
• GmsCompatConfig: update to version 113
• GmsCompatConfig: update to version 114
• GmsCompatConfig: update to version 115
• make SystemUI tests compatible with GrapheneOS changes

cross-posted from: https://lemmy.ml/post/9939705

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:

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

Changes since the 2023121200 release:

• Keyboard: add new implementation of multi-locale spell checking support to fix crashes and other issues
• Sandboxed Google Play compatibility layer: add Android Auto support with the compatibility layer eliminating the need for most of the permissions and a permission menu with 4 toggles for granting the minimal special access required for wired Android Auto, wireless Android Auto, audio routing and phone calls
• Settings: remove confusing mention of Android Auto from Connected devices screen
• exempt non-app system processes from Sensors permission enforcement (fixes some issues including gpsd crashes)
• fix Bluetooth auto-turn-off race condition to avoid crashes
• work around upstream race condition bug in biometric service
• disable support for pre-approving PackageInstaller sessions due to incompatibility with Network permission toggle
• fix several upstream bugs in handling crash reports mainly to improve our user-facing crash reporting system
• use GrapheneOS Widevine provisioning proxy by default
• add settings for changing Widevine provisioning server
• add configuration for setupdesign and setupcompat libraries to improve system UI theme
• kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.204
• kernel (Pixel 8, Pixel 8 Pro, Generic 5.15): update to latest GKI LTS branch revision including update to 5.15.142
• kernel (Generic 6.1): initial port of GrapheneOS changes for use with emulator builds
• force disable network ADB in early boot to improve verified boot security (no user-facing change since it's currently disabled by default later in the boot process, but not robustly)
• Vanadium: update to version 120.0.6099.115.0
• Vanadium: update to version 120.0.6099.144.0
• AppCompatConfig: update to version 2
• GmsCompatConfig: update to version 88
• GmsCompatConfig: update to version 89
• GmsCompatConfig: update to version 90
• Auditor: update to version 78

cross-posted from: https://lemmy.ml/post/7659570

Pixel 5 is receiving official support past the end of the official update guarantee which is what we predicted for the Pixel 4a (5G) and Pixel 5. It would make a lot of sense for them to be supported until the Pixel 5a end-of-life but it's unclear if that's what will happen.

Nexus and Pixel devices have often received longer support than the minimum guarantee. Pixel C was released December 2015 with a 3 minimum guarantee and got updates until June 2019. Many people misinterpret the minimum guarantee as the end-of-life date, which is not how it works.

Pixel 8 has moved to a 7 year minimum guarantee for major OS updates and security updates, and we don't expect them to go past that. However, we do expect that the Pixel 6 and Pixel 7 will keep getting official major OS updates for their whole 5 year security update guarantee.

cross-posted from: https://lemmy.ml/post/7167256

Our first experimental release based on Android 14 was published on October 6th. We think we already had this issue resolved for that release:

https://arstechnica.com/gadgets/2023/10/android-14s-ransomware-data-storage-bug-locks-out-users-remains-unfixed/

We've made additional fixes for upstream user profile issues still impacting the stock Pixel OS since then too

We've run into multiple Linux kernel f2fs data corruption issues before Android 14 while testing new Linux kernel LTS revisions. We avoided any of the serious issues slipping past our internal testing. The only one to make it into the Alpha channel only caused update rollback.

cross-posted from: https://lemmy.ml/post/6085628

GrapheneOS is now based on Android 14. Most of our changes have been ported already but we still have a lot more porting work to do. It's all going to need to be tested before we can get it all merged, and then we can start making public experimental releases based on 14.

cross-posted from: https://lemmy.ml/post/6053540

Pixel 8 and Pixel 8 Pro are confirmed to have at least 7 years of full support:

https://support.google.com/nexus/answer/4457705?hl=en#zippy=%2Cpixel-later-including-fold

We expect 6th and 7th generation Pixels will also receive major OS updates until the end of their security support period. Bear in mind these are a minimum, not when it ends.

Android only has a single active stable branch, which is the latest major OS release. For example, Android 14 has now replaced Android 13.

Android 11, 12 and now 13 only have standalone backports of Critical/High severity patches and a subset of Moderate/Low severity patches

The alternative to updating 6th and 7th generation Pixels to the latest major OS release until their end-of-life would be continuing to develop an older major release and continuing to have releases for it. We think it's much more likely they give them 5 years of major updates.

It's likely they've already come to that conclusion and it's why it makes sense for the Pixel 8 and Pixel 8 Pro to have at least 7 years of major OS updates to go along with a minimum of 7 years of security patches. It's easier rather than harder for them to do both, especially with Treble.

cross-posted from: https://lemmy.ml/post/1899649

Hello,

Below are linked communities I am moderating, but can't remove inactive/deleted moderators from:

!thehatedone@lemmy.ml

!aosp@lemmy.ml

!androidapps@lemmy.ml

!androidofficial@lemmy.ml

Users along with their posts that are deleted/inactive that neither I or the group owner can't seemingly remove from moderation are:

u/TheSilencedOne can't find posts or comments on ANY of the communities I moderate and that list this account as moderator.

u/Lunacy post https://lemmy.ml/post/85921

u/Zanthed post https://lemmy.ml/post/85569

u/lunacy post https://lemmy.ml/post/86672

u/zenthed post https://lemmy.ml/post/100140

Please remove u/Zanthed, u/TheSilencedOne and u/lunacy from moderation on all above listed communities.

Thank you for your time.

If anybody may please help me or community owner with removing these accounts, it'd be greatly appreciated. Thank you

Hello,

Below are linked communities I am moderating, but can't remove inactive/deleted moderators from:

!thehatedone@lemmy.ml

!aosp@lemmy.ml

!androidapps@lemmy.ml

!androidofficial@lemmy.ml

Users along with their posts that are deleted/inactive that neither I or the group owner can't seemingly remove from moderation are:

u/TheSilencedOne can't find posts or comments on ANY of the communities I moderate and that list this account as moderator.

u/Lunacy post https://lemmy.ml/post/85921

u/Zanthed post https://lemmy.ml/post/85569

u/lunacy post https://lemmy.ml/post/86672

u/zenthed post https://lemmy.ml/post/100140

Please remove u/Zanthed, u/TheSilencedOne and u/lunacy from moderation on all above listed communities.

Thank you for your time.

cross-posted from: https://lemmy.ml/post/1784484

Cellebrite and others in their industry use logical extraction to refer to extracting data from a device after unlocking it, enabling developer options (requires PIN/password), enabling ADB and permitting access for the ADB key of the attached device. See https://cellebrite.com/en/glossary/logical-extraction-mobile-forensics/ The baseline doesn't involve exploitation. The next step up is exploitation via ADB to obtain more data than ADB makes available.

Obtaining data from a locked device requires an exploit. If it was unlocked since boot, the OS can access most data of the currently logged in users.

GrapheneOS includes our auto-reboot feature to automatically get data back at rest so that it's not obtainable even if the device is exploited. Can set this to a much lower value than the default 72 hours. 12 hours won't cause inconveniences for most users, but you can go lower.

User profiles that are not currently active have their data at rest. GrapheneOS provides the option to put secondary users back at rest via end session for convenience. Sensitive global system data is stored by the Owner user, which is why you can't log into another user first.

GrapheneOS also provides the option to disable keeping a secondary user active in the background, to force ending the session when switching away from it.

We provide substantial exploit protection features (https://grapheneos.org/features#exploit-protection), and we're working on some major improvements.

For user profiles that are not currently logged in, their data is protected by encryption even if the device is exploited. An attacker needs to brute force the password. If you use a strong random passphrase, they cannot do it. Otherwise, you depend on hardware-based security.

Most Android devices don't have decent hardware-based encryption security. If a typical Android device has the OS exploited, the attacker can trivially bypass any typical PIN/passphrase via brute force. We only support devices defending against this (https://grapheneos.org/faq#encryption).

iPhones, Pixels and certain other Android devices provide hardware-based throttling of unlock attempts via a secure element. We explain how this works at https://grapheneos.org/faq#encryption. This protection depends on security of the secure element, which is quite good for Pixel 6 and later.

cross-posted from: https://lemmy.ml/post/1573082

We've almost finished adding support for the Pixel Fold but we don't have access to one yet since they weren't sold outside of a few countries.

Does anyone have one that's able to spend a few hours testing different things? You need to be able to run ADB on an attached computer.

If you want to help with this, please join #testing:grapheneos.org on Matrix. Support for the Pixel Fold will come soon but we don't have access to the device ourselves yet and are missing testers as a substitute for that. We can likely finish adding support quickly.

Thank you

Hello,

Post that are under https://lemmy.ml/c/grapheneos aren't federating to https://beehaw.org/c/grapheneos@lemmy.ml url which finds the community but has no posts.

I'm probably just misunderstanding how federation works, so if someone may please kindly explain to me what may be the issue. I'd appreciate it. Thanks