March security bulletin lists 2 vulnerabilities as actively exploited in the wild:
https://source.android.com/docs/security/bulletin/2025-03-01
CVE-2024-43093 patch was in Android 15 QPR1 released in December. It's just being backported now.
CVE-2024-50302 doesn't impact GrapheneOS due to our exploit protections.
Android Security Bulletins are very commonly misinterpreted as being Android's monthly security patches. They're actually backports of most High and Critical severity patches to older releases of Android: 12, 12L, 13, 14 and 15. Yes, Android 15 is an older release of Android.
CVE-2024-50302 is one of 3 vulnerabilities which Amnesty International recently found being exploited by Cellebrite. This one was fully eliminated as a bug in GrapheneOS through zeroing. Separately from that, our USB-C port control blocked reaching any of the 3 bugs while locked.
For more details on the 3 Linux kernel USB bugs exploited by Cellebrite, see the previous thread on the socials. #GrapheneOS blocked reaching all 3 while locked at both a hardware and software level, eliminated one and made the other 2 much harder to exploit even when unlocked.
They included one in the February security bulletin, another this month and still need to add CVE-2024-53197. We patched all 3 earlier via the kernel.org LTS revisions. Our exploit protections blocking exploiting them prior to patching is the far bigger difference.
March security bulletin lists 9 Critical severity Bluetooth vulnerabilities caused by use-after-free bugs. Our hardened_malloc project provides strong protections against exploiting these, especially on Pixel 8 and later where it has very good hardware memory tagging integration.
When a memory allocation of 128kiB or below is freed on GrapheneOS, memory tagging gives it a dedicated tag detecting any invalid access. It goes through a random quarantine and first-in-first-out quarantine before reuse. First reuse is guaranteed to use a different random tag.
Memory tagging also zeroes the allocation. On devices without it, we still zero it at free time and then check for the zeroing at allocation time to detect write-after-free and guarantee that fresh allocations are zeroed. With memory tagging, it detects the invalid accesses.
After a memory allocation is freed, goes through both quarantines, is allocated again, freed again, goes through both quarantines and is allocated again there's still a 14/15 chance for the random tag to detect an invalid memory access. Attackers also usually need to chain bugs.
GrapheneOS users have been regularly finding obscure Bluetooth memory corruption bugs with specific accessories. We generate user-facing notifications for MTE detecting invalid accesses for users to report to us and app devs. We can likely close several more of those issues now.
We've actually had these Critical severity Bluetooth patches backported for a month already:
Good news is that we've already had those patches for a month. Bad news is it's not the reason for the remaining issues being caught by MTE, will need more work.
"Fix UAF in sdp_discovery.cc" patch was included upstream previously, it's just a backport. The others we applied ourselves last month. They weren't listed in the bulletin or included in the monthly update but they were published and they did fix some issues we'd caught with MTE.
#GrapheneOS version 2025030300 released.
This is an early March security update release based on the March 2025 security patch backports since the quarterly Android Open Source Project and stock Pixel OS release (Android 15 QPR2) scheduled for this month hasn't been published yet.
- full 2025-03-01 security patch level
- Network Location: temporarily disable using altitude in trilateration for now because 3D trilateration is using an excessive amount of CPU time and we need to greatly optimize it with algorithm level improvements, porting it to Rust and other optimizations before we can use 3D
- App Store: update to version 29
- App Store: update to version 30
Messages are end-to-end encrypted, reporting messages works by a user who received the message opting-in to report it to the provider. Providers can only see it if the users choose to submit the message that's been decrypted on their device to the provider.
Oh, that's what you meant, assumed you meant having no access to the Wi-Fi rather than disabling it.
For WiFi being off, this would depend on if you enable the setting "Wi-Fi Scanning" in Settings -> Location. This is a toggle to scan for nearby WiFi networks even when WiFi is off. Need to enable it.
Oh, that's what you meant, assumed you meant having no access to the Wi-Fi rather than disabling it.
No since enabling this feature connects to a GrapheneOS Proxy (or Apple if someone chooses). Making it local wouldn't though, which is a goal.
Bro nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0 are you looking at the posts? 😂 thank you but you are ctrl + C.
Sometimes the bridge for Mastodon isn't there and I can't see it 👀
nostr:nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43q4gnztg the connection is being through USB as the car does not support android auto connection via bluetooth, and I guess the audio should not be able to pass that way. But I don't know, it must be sneaking through the bluetooth somehow.
USB audio output is also not profile-specific.
nostr:nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43q4gnztg nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0 To what extent is data not shared between private and personal space?
If I have android auto in the private space, I connect it to the car and play music from the personal space, how is it that android auto plays me the song that is playing in the other space (which has no google services or android auto)?
I don't understand it at all.
#askNostr #GrapheneOS #privacy
The project account reply didn't bridge:
Wi-Fi and Bluetooth connections aren't per-profile. You're ending up streaming the audio through that. It's a separate thing from apps accessing data.
The Android Security Bulletin tells you of CVEs that get uncovered and patched in Android. They'll also link the commits that patch them.
In this case example only CVE-2024-53104 was patched and it happened this month.
https://source.android.com/docs/security/bulletin/2025-02-01
CVE-2024-53197 and CVE-2024-50302 have been patched upstream in the Linux kernel but have not yet been in Android. It doesn't effect GrapheneOS due to the security features and us updating Linux kernel Generic Kernel Image (GKI) every time there's a new revision rather than Google only doing it quarterly or less and only backporting patches in special cases.
Because of that, many upstream kernel vulnerabilities are available in Android but not GrapheneOS, we talk about that on the site here:
I talked about CVE-2024-53014 prior here, we patched this vulnerability months prior thanks to earlier and complete kernel patching, appears to be December. We were pretty right on the money with what our assumption this vulnerability was being used for and by who.
The Android Security Bulletin tells you of CVEs that get uncovered and patched in Android. They'll also link the commits that patch them.
In this case example only CVE-2024-53104 was patched and it happened this month.
https://source.android.com/docs/security/bulletin/2025-02-01
CVE-2024-53197 and CVE-2024-50302 have been patched upstream in the Linux kernel but have not yet been in Android. It doesn't effect GrapheneOS due to the security features and us updating Linux kernel Generic Kernel Image (GKI) every time there's a new revision rather than Google only doing it quarterly or less and only backporting patches in special cases.
Because of that, many upstream kernel vulnerabilities are available in Android but not GrapheneOS, we talk about that on the site here:
Amnesty International’s Security Lab has a post about 3 vulnerabilities exploited by Cellebrite to extract data from locked Android devices. #GrapheneOS blocked exploiting these vulnerabilities in multiple different ways. We also patched them much earlier.
Each of these is an upstream Linux kernel vulnerability:
* CVE-2024-53104: heap overflow in a Linux kernel USB webcam driver
* CVE-2024-53197: heap overflow in a Linux kernel USB sound card driver
* CVE-2024-50302: uninitialized heap memory in a Linux kernel USB touchpad driver
GrapheneOS blocks reaching any of these vulnerabilities for locked devices through our USB-C port and pogo pins control feature disabling new connections at a hardware level and a software level after locking along with disabling USB data in hardware too:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
CVE-2024-50302 is benign on GrapheneOS. For both the kernel and the rest of the OS, we use the combination of use zero-on-free and either zero-on-allocate or a write-after-free check at allocation time. On devices with hardware memory tagging (MTE), it's done as part of tagging.
CVE-2024-53104 and CVE-2024-53197 are both kernel heap overflows in slab allocations. We provide improved defenses against these attacks in multiple ways covered in the kernel section at https://grapheneos.org/features#exploit-mitigations. Our defenses in userspace are far stronger due to hardened_malloc.
We recently enabled hardware memory tagging (MTE) for Linux kernel after over a year of deploying it for userspace via hardened_malloc. It provides an approximation of memory safety which can be improved over time. It requires hardware support exclusive to 8th/9th gen Pixels.
GrapheneOS shipped patches for these 3 vulnerabilities significantly before the stock Pixel OS or inclusion in an Android Security Bulletin through shipping the latest Linux kernel GKI LTS releases. However, what really matters is we prevented them being used before discovery.
We have a recent post at https://grapheneos.social/@GrapheneOS/113961075324902277 covering how we've significantly improved our defenses against forensic data extraction since January 2024. It covers a lot more than what we talked about here and we recommend reading it along with our features page covering more.
nostr:nprofile1qqstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgspzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz7qgawaehxw309ahx7um5wghxy6t5vdhkjmn9wgh8xmmrd9skctcnv0md0 it seems the revolut workaround is no longer working...
Not received any feedback saying this is the case in our channels... Please make sure GrapheneOS and Revolut is up to date.
Amnesty International’s Security Lab has a post about 3 vulnerabilities exploited by Cellebrite to extract data from locked Android devices. #GrapheneOS blocked exploiting these vulnerabilities in multiple different ways. We also patched them much earlier.
Each of these is an upstream Linux kernel vulnerability:
* CVE-2024-53104: heap overflow in a Linux kernel USB webcam driver
* CVE-2024-53197: heap overflow in a Linux kernel USB sound card driver
* CVE-2024-50302: uninitialized heap memory in a Linux kernel USB touchpad driver
GrapheneOS blocks reaching any of these vulnerabilities for locked devices through our USB-C port and pogo pins control feature disabling new connections at a hardware level and a software level after locking along with disabling USB data in hardware too:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
CVE-2024-50302 is benign on GrapheneOS. For both the kernel and the rest of the OS, we use the combination of use zero-on-free and either zero-on-allocate or a write-after-free check at allocation time. On devices with hardware memory tagging (MTE), it's done as part of tagging.
CVE-2024-53104 and CVE-2024-53197 are both kernel heap overflows in slab allocations. We provide improved defenses against these attacks in multiple ways covered in the kernel section at https://grapheneos.org/features#exploit-mitigations. Our defenses in userspace are far stronger due to hardened_malloc.
We recently enabled hardware memory tagging (MTE) for Linux kernel after over a year of deploying it for userspace via hardened_malloc. It provides an approximation of memory safety which can be improved over time. It requires hardware support exclusive to 8th/9th gen Pixels.
GrapheneOS shipped patches for these 3 vulnerabilities significantly before the stock Pixel OS or inclusion in an Android Security Bulletin through shipping the latest Linux kernel GKI LTS releases. However, what really matters is we prevented them being used before discovery.
We have a recent post at https://grapheneos.social/@GrapheneOS/113961075324902277 covering how we've significantly improved our defenses against forensic data extraction since January 2024. It covers a lot more than what we talked about here and we recommend reading it along with our features page covering more.
Work towards a #GrapheneOS network location service is coming to fruition:
https://github.com/GrapheneOS/platform_build/pull/69
This is a major feature. Network location providers will allow faster results and greater accuracy with locations inside buildings, by default GrapheneOS uses the OS' satellite location (GNSS) for location, with an optional toggle for using Google's existing location service.
For users who want network location and not Google, this network location service would use a GrapheneOS proxy to Apple's WiFi positioning service. Users may choose to not use the proxy.
Eventually, we'll be making our own local database using scraped data from Apple's service to implement network location and SUPL for users who want network-based location without connecting to them.
#GrapheneOS version 2025022700 released.
Introducing opt-in network location, 5G-Only mode, blocking callers not in contacts and back port patches.
• add opt-in GrapheneOS network location implementation available via Settings > Location > Location services based on using the Apple Wi-Fi positioning API either through a GrapheneOS proxy or directly via Apple's service, which will be extended with much more functionality in the near future including incorporating altitude into trilateration, using cell towers if it provides a better estimate than Wi-Fi and using our own network location database either via a service or offline database downloads (we're in the process of building our own database by scraping all of the data from Apple's service and have already done a test run obtaining essentially all the cell tower data along with lots of Wi-Fi data)
• fix Wi-Fi APEX issues preventing an OS network location service from doing Wi-Fi scans without the INTERACT_ACROSS_USERS / INTERACT_ACROSS_USERS_FULL privileged permissions
• Sandboxed Google Play compatibility layer: add support for using an OS network location provider for the default enabled rerouting of Google Play location requests to the OS location service
• add support for "5G only" and "4G or 5G only" modes in addition to our existing "4G only" mode
• enable support for blocking callers not in Contacts
• resolve regression for secondary user SMS in Android 15 QPR1 by enabling partial upstream fix since we dropped this part of our fix for the issues but the upstream fix wasn't actually active
• fix Storage Scopes / Contact Scopes app settings link not working for apps in nested profiles in some cases
• Launcher: limit 4x5 grid option to phones
• kernel (6.1): update to latest GKI LTS branch revision
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.79
• backport mainline APEX module patches for DocumentsUI, Media Provider and Network Stack
• Vanadium: update to version 133.0.6943.89.0
• Vanadium: update to version 133.0.6943.121.0
• Vanadium: update to version 133.0.6943.137.0
• Vanadium: update to version 134.0.6998.39.0
• App Store: update to version 27
• App Store: update to version 28
• Messaging: update to version 5
• Messaging: update to version 6
• Messaging: update to version 7
• PDF Viewer: update to version 21
• PDF Viewer: update to version 22
• PDF Viewer: update to version 23
• PDF Viewer: update to version 24
• PDF Viewer: update to version 25
• PDF Viewer: update to version 26
• Camera: update to version 79
• Camera: update to version 80
• Camera: update to version 81
Currently GrapheneOS uses GNSS for location by default instead of a network-based location service. GNSS doesn't have the device send anything out. There are plans to make this not depend on any provider by using scraped data stored locally. Most if not all of it is scraped already if I remember correctly, it just needs implementation.
These services use a collected database of WiFi access points or cell towers (we don't use this one yet) and their geographical locations to help return your location faster. It works by sending nearby BSSIDs (access point MAC addresses) to Apple, then Apple returning the geographical locations of other nearby SSIDs to you. The location is then calculated based on signal strength of the nearby access points.
That info is generated by Apple from iPhone users. You can technically opt out of this mapping by putting '_nomap' on your access point name.
Page 6 and 7 of this letter by Apple to a representative explains it more: https://web.archive.org/web/20101208141602/https://markey.house.gov/docs/applemarkeybarton7-12-10.pdf
You can assume Google's network location or other companies operate in a similar fashion. Mozilla had one called Mozilla Location Service but is now closed.
Appears Clicks is going to be releasing a Pixel 9 case with a physical keyboard attached to it soon. Black one releases first.
https://www.clicks.tech/en/products/clicks-for-google-pixel
Unlikely some #GrapheneOS users will use it because of the requirement to disable USB port controls... but more ordinary users or Stock OS users might. A nice novelty item I guess.
The yellow/purple version is hideous. Unless you think of it like #nostr themed