New early security patch level update out.

nostr:nevent1qqsqva4q6cs8cw3sw4a0k69l3c237aqkhzs5ymc80hmpy8xpf87qxncpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyp2x308wkaxwxh95zu7uext5hhdvn6y55a9l84z0nj5tw42xqhy76qcyqqqqqqgurvlf9

All this advanced #security talk can have people worrying about arbitrary threats that don't matter to them. It is good for people to take a breath and have a reality check on the essential security needs and the low-hanging fruit.

The danger in advanced persistent threats aren't just from being advanced, it is the 'persistent' that is far more important. A threat that is persistent is unaccountable and have free reign to keep trying or move to a new victim to target. Even a threat that is not skilled can be dangerous if persistent, because there will always be a victim stupid enough to be hacked by them.

Many victims of cyberattacks are not compromised through sophisticated means, not even APTs prefer to do that. Instead, the threat is simply taking advantage of a simple security flaw. Many of the most dangerous cyber attacks in the world were easily preventable.

Equifax was one of the biggest breaches of the last decade and was started by an Apache Struts remote code execution vulnerability that was not patched despite it being available for months. There was failures in monitoring and segregation of systems. The Chinese state being implied in the attack doesn't change anything since anyone experienced could have tried it.

If you want to protect yourself against threats that actually matter, remember the essentials:

- Keep your devices, apps, drivers etc. up to date.

- Browse the internet securely, use HTTPS only and block ads. Browser security is very important, avoid piling extensions.

- Protect your accounts. Use secure, long and unique passwords, enable two-factor authentication (U2F or TOTP) and use a password manager.

- Protect sensitive information with encryption.

- Back up sensitive information to prevent data loss. Make sure you know how to recover and restore quickly and easily too.

- Don't install unknown apps, don't visit unknown websites, don't read messages from unknown contacts.

- Use your device for-purpose, not for-use. Ask yourself: do I need to do what I'm doing?

- Enforce admin usage based on need-to-know and principle of least privilege.

- Establish boundaries between systems, not everything needs to be networked together.

If you can't do these things, not even #GrapheneOS, Tor, Qubes or anything else can protect you!

If I had a dollar every time I saw GrapheneOS anime girl fan art now, id have 2000 sats :)

nostr:nevent1qqsyzhmc8ytnd3a06kxyx8x4x7upnxq0scz7m40yf84d7zhah4dfvjcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqszyvm63

This malware is reported as a proof of concept. There's some limitations with this sample, such as it doesn't work with UEFI Secure Boot enabled. Linux distributions do a shit job and not all support using it though. It's also likely to be found in digital forensic analysis.

Warez forums have sold bootkits with bypasses for these measures before, but they exploited known, patched CVEs. If zero-days are involved (like a nation state) they'd be better with a remote exploit. Bootkit main benefit is persistence.

Latest #GrapheneOS release (it's out) has a fix for an upstream Android security bug causing Bluetooth contact sharing to be enabled for hands-free calling devices even though the dialog shows it will be disabled. GrapheneOS disables Bluetooth contact sharing by default instead of enabling it for pairing requests made by the user in the foreground.

Talking about boot firmware-based malware on Desktop OSes.

https://stacker.news/items/786377/r/final?commentId=786884

Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices.

Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.

It will likely take around 6 months for a new branch to be considered stable enough with most regressions resolved and another 6 months to successfully integrate and ship it. Therefore, 2 years of support implies yearly migrations to keep up rather than doing it every 2 years.

Upstream LTS releases are closely connected to Android. Moving to 6 years of support was likely closely connected to the Pixel 6 moving to 5 years of support. GKI made the drivers far more standalone and easy to migrate, and Linux moving back to 2 year support is likely related.

Google has been testing newer kernels with the Pixel 6 and later for years. They have 6.6 and newer mainline kernels working fine already, it just takes a long time until the kernels are stable enough to consider shipping them. It's great that it's finally going to be happening.

Newer kernels bring many new features and increasingly complexity which means they bring lots of new security bugs. Older kernels get an increasingly small subset of bug fixes including security fixes backported in the LTS releases. Newer kernels also bring new security features.

Using a year old kernel for around a year and then upgrading to a new year old kernel is likely the best balance that's available. With 2 year support time, they can focus on backporting more patches and providing more testing/stability since there will be far fewer LTS branches.

It's not commonly understood that Android itself only has a single LTS branch, which is current Android 15. It receives monthly and quarterly updates. It moves to a new LTS with a yearly update after it has gone through many months of public testing via Developer Preview / Beta.

Many people including journalists covering it in tech news media wrongly believe Android's monthly security patch releases are the monthly releases. No, the monthly security patches are backports of a subset of the privacy/security patches to older releases. They're incomplete.

Android's monthly releases have many changes beyond privacy/security patches even when it's not a quarterly or yearly release. They also have a lot more privacy/security patches than the Android Security Bulletin backports. They backport High/Critical severity patches, not all.

These updates are a major factor in why Pixels are the only Android devices with competitive security with iPhones. Pixels also have a lot of hardware security features not implemented on other Android devices. They also have higher quality of implementation across the board.

Google will likely require other OEMs start upgrading kernel branches. However, standards for other OEMs are always far lower than the standards met by Pixels. For example, many important hardware security features are recommended in the CDD, not mandatory, or not even listed.

We aren't aware of any OEM trying to keep up with the monthly releases, only OEMs skipping all the monthly/quarterly releases but trying to ship the yearly release around the official launch. Only Samsung tries to keep up with the new security features, but lags quite behind.

Other Android OEMs do the bare minimum required by Google unless their SoC vendor (generally Qualcomm) hands the feature to them on a silver platter with no additional cost. They largely ship the monthly security backports now, but with significant delays or skipping some months.

The reduction of support time for Linux kernel LTS releases from 6 years to 2 years is likely going to become a major problem for non-Pixel Android devices. Google will likely require them to upgrade but probably at a very delayed schedule where they fall out of support first.

Our official hardware requirements are listed here:

https://grapheneos.org/faq#future-devices

You can see support for Linux 6.1 or 6.6 is already a requirement for new devices. We'll be adding a requirement to upgrade the kernel branch because it will be essential with 2 year Linux LTS support.

#GrapheneOS

Not aware of any app doing this

GrapheneOS adds additional fixes to VPN DNS and multicast traffic leaks that Android doesnt have. Can read more about the VPN leak blocking improvements on the VPN page:

https://grapheneos.org/features#improved-vpn-leak-blocking

For some Android traffic discussed in articles like this, they are intentional. For example: connectivity checks are just blank HTTP web pages meant for public networks to forcibly redirect connected users into their login page. On GrapheneOS it's replaced to our own rather than Google's but there's also the option to use Google's (to blend in) or disable it which the article mentions us as having. Disabling it breaks connecting to public Wi-Fi networks with a login page but the connection won't be sent out.

There are other edge cases like VoWiFi for mobile networks when calling.

This was changed upstream 2 major version revisions ago I believe. We haven't really touched these small changes as we're worried the ability to port and maintain them the more some part of the OS is updated upstream can be a problem.

Regular reboots would mitigate an exploit that doesn't have persistence. It's mainly used for data protection rather than an exploit mitigation though. Our other features and hardening are more important.

I do actually use a case that covers back/front cameras, but that's just because I don't want them to scratch or have my fingerprints on the lenses. Free access to the camera would definitely suggest they have other parts of your phone compromised and accessible.

It isn't in scope for us to add FRP currently since it won't guarantee you will get your device back if it was stolen. We haven't implemented it since it could also be a problem that the data forever remains in that device, at least we can encourage whoever has it to inadvertently destroy all the data.

We also had a lot of concerns by users about Find My Device functionality as some users consider being pinged by other phones to help location tracking a huge privacy issue. Both FRP and this would have to be opt-in features.

> If graphene messes up a build, you can't even return to stock because you turned that switch off.

The devices we support use two separate system partitions (A / B) and updates are installed on the other and then swapped to the other when restarted, if the update fails/is corrupt then it rolls back to the previous working install on the last-used partition. Same method is used when Google saves their users with corrupt updates.

We would want the bootloader locked else anyone can flash malicious updates on any OS. Unauthorised person factory resetting by recovery is good for us as that means the user's sensitive data is destroyed. We prefer this data destruction over the Factory Reset Protection the Stock OS wants to have.

Tools like these are used in unlawful search and seizures and in border crossings. They're called forensic kits because they're supposed to be designed to extract device data as forensically sound evidence that can't be tampered with.

The companies are very capable actors that design zero-day exploits, even if their targeting is limited, allowing some company to use exploits and not patch them is unacceptable for us. Other OEMs like Samsung should be humiliated for not trying hard enough. Apple followed us in adding an automatic reboot but we'd want more and Google should add more of the suggestions from us.

This is slightly below something like mercenary spyware but as businesses they both function the same, selling a way to hack a device for money. Intelligence agencies go above both and they would seek something bespoke.

If someone could be $5 wrenched, get rid of the phone or data. No data is worth your life. You're better to post all that data to someone or publicise whatever you was whistleblowing.

SN: https://stacker.news/items/774701

On November 19th, 404Media published a news article with the device support chart for Magnet Forensics GrayKey, a forensic device extraction kit used exclusively by governments and a competitor of Cellebrite's UFED and MSAB XRY. The article contains data on the devices supported by GrayKey and the best extraction type available for the device based on monthly Security Patch Level. The results available from the charts are the same as our expectations made from our insights with other forensic company activities and people who inform us of their capabilities. We also are seeing a domino effect of further publications of leaked capabilities from forensic firms after our publication of the April and July 2024 Cellebrite device support matrix.

From what you can see in the GrayKey documentation, our previous disclosure of vulnerabilities affecting Stock OS Pixel devices that were exploited by forensics firms such as MSAB in the start of the year have disrupted their capabilities. We reported those exploits to Google in January 2024 with multiple proposals on how to stop it. In April 2024, the first two patches for these vulnerabilities were shipped and we can see that since April 2024 the extraction capability for GrayKey on all Pixel devices they supported were downgraded.

We have a good idea of what was happening based on the detailed info we obtained about MSAB's XRY exploit tool. XRY was exploiting littlekernel-based fastboot mode firmware used on Pixels via USB. Many other devices also use littlekernel for this, or the higher attack surface EDK2. CVE-2024-29745 is the identifier for the reset attack vulnerability we reported for the fastboot mode. Google addressed this in April 2024 by implementing our proposal of zeroing memory on boot. Graykey was downgraded from Full access to Partial access in April 2024 and has stayed that way since.

Cellebrite Premium is clearly exploiting the stock Pixel OS via USB rather than using this approach. Therefore, Cellebrite didn't lose any capabilities on the Stock OS because of the improvement - however they lost brute force capability. Our exploit protections have been successfully blocking Cellebrite even before major improvements in 2024 and GrapheneOS is still unaffected by their tools.

The device's data is divided in 2 parts: The vast majority of data is Credential Encrypted (CE) per-profile and a small portion of OS data is Device Encrypted (DE). DE data is available to the OS Before First Unlock (BFU). Exploiting fastboot mode will only give DE data since April 2024. One of our planned features is a boot authentication toggle to request the Owner lock method in early boot. This will protect the small amount of DE data such as installed packages and saved Wi-Fi networks from firmware/hardware exploits. However, it's not sensitive user data.

Partial access means limited access to operating system metadata and the Device Encrypted data and we are not concerned over such a limited data scope.

Cellebrite's approach of exploiting the OS itself is more difficult but they avoided having nearly all their capabilities wiped out by the reset attack mitigation we successfully got Pixels to implement. Other Android devices haven't implemented reset attack mitigation though. The way Google implemented it only covers fastboot mode. We wanted them to cover the OS boot modes too but they haven't shipped it yet. Our zero-on-free feature addresses it for OS reboot/shutdown and we plan to add zero on boot too until we convince them to add it in firmware.

Cellebrite's approach involves attacking the OS itself so all of our generic memory corruption exploit protections and other defenses are there to stop it. We also nearly fully wiped out the USB attack vector for the OS with our 2024 overhaul of our USB attack surface reduction. By default, #GrapheneOS disables new USB-C connections as soon as the device is locked at both a hardware and software level. It then fully disables USB-C data at a hardware level once existing connections end or right away if there weren't any. They'd need another attack vector.

For example, they could still target GrapheneOS via Wi-Fi, Bluetooth or cellular. However, getting into the device from any of those will still be much harder than with the stock OS, and it's more complex than USB in general. There's a reason they have always preferred USB. USB is preferred because it provides little tampering with the OS and maintains forensic soundness.

At this current point in time Cellebrite is certainly the industry leader when it comes to Pixel research. Their research teams follow the same trends and innovations and want to research attacks for #security technologies we desire or have inherited on our platforms when they have become available, such as MTE and PAC. A GrapheneOS extraction capability of any kind is high-demand for any company in the forensics industry and they appear dedicated to want to be first which makes sense as they are certainly the largest. We will continue providing commensurate response to any new threats.

Since 2021, we've had an auto-reboot timer feature which reboots the device after it's locked if it isn't unlocked before the timer expires. iOS recently added this with a hard-wired 72 hour timer. Our default is 18 hours but users can configure it from 10 minutes to 72 hours. If you need maximum protection, using the 10 minute auto-reboot would be ideal. There's also the option to fully disabling USB-C while OS is booted by also disabling charging including USB-PD. You can also enable turning off Wi-Fi and Bluetooth via timers, which we plan to extend to NFC. You should also get any of the 4 currently available 9th gen Pixels to use GrapheneOS. They have more cellular radio hardening and GrapheneOS-specific kernel hardening implemented right now, but 8th gen is likely going to upgrade to the same 6.1 kernel branch soon.

We strongly recommend 8th/9th gen Pixels for greatly improved security on GrapheneOS via hardware memory tagging. It's enabled for the base OS including apps by default and opt-in for user installed apps, whcih we recommend, and then opt-out per app for apps with bugs it catches.

Updates are pushed to Alpha release channel first, then Beta, then Stable. If using Stable it should be available in around 12~ hours to a day later.

GrapheneOS Forum users can now delete their account and anonymize their posts from their forum profile.

#GrapheneOS version 2024111700 released.

This update contains a lot of sandboxed Google Play compatibility later improvements, patches, and fixes upstream issue where Private Spaces are not putting data at rest when stopped. The limit amount of running users have also increased for newer devices.

See the changes:

• Private Space: put data at rest immediately after stopping the profile to match user profile behavior instead of only on reboot

• fix Mock Location on devices without any standard location providers (only Pixel Tablet)

• backport mainline APEX module patches for ART, DNS Resolver, DocumentsUI, Media, Media Provider, Network Stack, PermissionController, Remote Key Provisioning and Wi-Fi

• raise maximum running users from the standard 3 to 4 for 6GB memory, 6 for 8GB memory, 10 for 12GB memory and 14 for 16GB memory

• Settings: disable Bluetooth contact sharing by default

• Settings: fix Private Space handling in Passwords & accounts > Additional services

• Settings: fix multiple cases of missing user profiles handling for added settings

• Dialer: fix RTT related crash from not using the correct theme configuration

• Contacts Provider: work around upstream bug causing deadlock with contact scopes

• temporarily don't report harmless fingerprint-service.goodix crash

• temporarily disable hardened_malloc for vendor audio service due to Pixel Tablet bug

• Sandboxed Google Play compatibility layer: significantly rework client side compatibility layer to avoid deadlocks and to avoid allowing starting apps with no exported components (i.e. not even a launcher activity)

• Sandboxed Google Play compatibility layer: overhaul approach to raising Google Play components to the foreground to avoid it always being considered in the foreground while also solving an issue triggered in a rare edge case at startup

• Sandboxed Google Play compatibility layer: stop Play Store from attempting to auto-install some system component packages, such as "Android System SafetyCore" (com.google.android.safetycore) and "Android System Key Verifier" (com.google.android.contactkeys)

• Sandboxed Google Play compatibility layer: fix Android Auto voice commands not working in some cases

• Sandboxed Google Play compatibility layer: fix one of the Android Auto permission toggle checks for companion devices

• Sandboxed Google Play compatibility layer: extend opt-in Android Auto "Allow permissions for handling phone calls" toggle to allow access to Bluetooth adapter hardware address access for hands-free audio support with wired Android Auto rather than only wireless Android Auto where the baseline toggle already grants access to that

• Sandboxed Google Play compatibility layer: don't stop apps that use Dynamite modules when Play services stops since the new version of the Dynamite client library handles dynamic re-connection without app restart and older ones will handle this by stopping

• kernel (5.10, 5.15, 6.1, 6.6): disable unused TIPC protocol support

• kernel (5.10): update to latest GKI LTS branch revision

• kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.170

• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.115

• kernel (6.6): update to latest GKI LTS branch revision

• System Updater: show failure notification for update_engine errors

• System Updater: add missing UpdateEngine.unbind() to avoid extra callbacks for progress and error reporting

• System Updater: avoid treating non-404 errors such as a connection failure as lack of an incremental update

• System Updater: handle a partially downloaded incremental update being removed from the server by falling back to the full update instead of retrying resuming the incremental download until the next update (this will allow us to remove an incremental for the latest available version to save storage space or work around a potential update_engine bug without it causing download resumption errors)

• System Updater: delete stale update from a failed download of a previous release slightly earlier

• Vanadium: update to version 130.0.6723.102.1

• Vanadium: update to version 131.0.6778.39.0

• GmsCompatConfig: update to version 149

nostr:nevent1qqspxp3g7peq0udsnp9upp9exuzf2m8ak5ys49vsm7wvpftgxx6sh9spzpmhxue69uhkummnw3ezumt0d5hsygz5dz7wad6vudwtg9eaejvhf0w6e85fff6t702yl89gka25vpwfa5psgqqqqqqs6cz6aq

confusing with another app, https://beautyxt.app/