Since we're on the topic of Cellebrite: #postmarketOS is NOT vulnerable to UFED.

Among devices that police seized from my friend was Xiaomi Poco F1 (xiaomi-beryllium) running postmarketOS build I pmbootstraped in late January 2024 (without LUKS2). Police seized the device 2 weeks after I gave it to said friend.

They tried to exploit it, but gave up. Mainline Linux kernel (6.6 at the time) did not have vulnerabilities in USB HID drivers (at least none in UFED's database).

To mitigate further against tools such as Cellebrite, we could enable USB authentication which prevents kernel modules from loading prior to user's consent.
Problem with that approach is that Desktop Environments have authentication implemented for Thunderbolt, but not for USB.
https://usbguard.github.io/

I really would like to see SELinux implemented as well, but it would be a Herculean effort because rules would need to be hand-written for Alpine.

@elly yay!!!! postmarkitties vs the fedz

@elly SELinux is on my wishlist as well, but we'll have to finish the systemd service upstreaming before I dare looking at packaging SELinux policies :3

@elly i think the police just has no idea what to do with this thing, and for a single occurance implementing something in cellebrite would simply be too much effort for that amount of devices (even if they are easily brickable)

@fossdd Of course. You and I know that you can boot device into pmOS debug shell, mount rootfs if it's not encrypted (or even just expose rootfs partition using mass storage gadget) and bob's your uncle. But they didn't know that :)

@adrianyyy @elly I don't see a reason why the Fedora SELinux policies couldn't be reused/extended for Alpine. They are used on SUSE distributions these days, and I believe Gentoo and Arch Hardened uses them too.

https://github.com/fedora-selinux/selinux-policy

@elly security by obscurity

@elly now I wonder what they did with my Xiaomi Redmi 3S (xiaomi-land) stuck on pmOS splash screen

@neal @elly I thought so too, but seeing how Gentoo's SELinux AFAIK still isn't ready it really makes me wonder how hard keeping it up to date would be. I'll definitely give it a shot

@elly GNOME does have a USBGuard integration, though the last time I looked at it it would need some adjustments to work well on phones (it's clearly made for desktop use cases). All the needed building blocks are already there at least. USBGuard itself is used on the Librem 5 by default to not let the modem firmware impersonate another device, but it's not used for the USB-C port yet (though the user can add any rule they want, of course).

https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/main/plugins/usb-protection/gsd-usb-protection-manager.c

@adrianyyy @neal @elly imho as long as path regexp doesn't change I don't think updating the policy would be a problem

@elly ya we'd like to use usbguard at some point. @dylanvanassche

@craftyguy @elly @dylanvanassche https://pulsesecurity.co.nz/advisories/usbguard-bypass

Not like this, right? :P

@fossdd @elly pmos (post market obscurity security)

@craftyguy @elly Yeah, usb-moded is the first part here. USB gadget will be disabled by default from then, only after unlocking you can enable it, reducing attack surface even further. USBGuard when configured right, can come next.

@elly Cellebrite definitely has exploits which work for mainline Linux kernels. They don't bother to make their exploits compatible with niche Android devices let alone doing it for postmarketOS with negligible usage.

> Mainline Linux kernel (6.6 at the time) did not have vulnerabilities in USB HID drivers.

That's absolutely not the case. Mainline Linux has a massive number of USB vulnerabilities, quite possibly more than the recent LTS branches without so much new USB code.

@elly postmarketOS doesn't have verified boot for the whole OS and other protections needed to prevent data extraction from an After First Unlock state device without exploits. Sophisticated exploits aren't needed to extract data from it. Cellebrite Premium is for exploiting a subset of Android devices they've bothered to support and iOS devices. UFED is not for exploiting locked devices and is what's primarily used. UFED is only for extracting data with the PIN/password via aDB.

@tris @elly @dylanvanassche

Who knew that mis-configured software could behave badly? /s

@elly SELinux as implemented by distributions such as Fedora and RHEL is not at all comparable to the extremely deeply integrate SELinux in Android. Desktop Linux lacks proper app sandboxing, modern exploit protections and widespread use of memory safe code. Desktop Linux isn't deploying type-based CFI let alone hardware memory tagging. It doesn't have verified boot, an essential protection against data extraction for After First Unlock state where without it an exploit is NOT required at all.

@GrapheneOS @elly Can you share a few unfixed CVEs of those?

@fun @elly Linux is the CVE Numbering Authority for Linux and only assigns CVEs to backported patches. There aren't CVEs for unpatched Linux kernel vulnerabilities or even a significant portion of the patched ones. Most open source projects do not assign CVEs themselves at all and try to avoid having them assigned. Going by CVEs does not make sense. Backporting only patches with CVEs assigned is extremely incomplete and problematic. What Linux does is not as bad as most libraries, etc.

@fun @elly Here's the list of Linux kernel CVE assignments:

https://lore.kernel.org/linux-cve-announce/

If you look at them, you can see they're assigned to backported patches rather than vulnerabilities. If others try to get a CVE assigned, the Linux kernel CNA will actively try to get it revoked even if it's a valid vulnerability. They've also decided some vulnerabilities don't count such as an ext4 vulnerability exploited by a maliciously crafted filesystem including from an external drive.

@fun @elly A large portion of Linux kernel bugs are short lived. Being on bleeding edge kernels such as the non-LTS 6.17 stable branch is not really good for security beyond code churn potentially making it hard to keep exploits working. A huge portion of vulnerabilities don't make it past a year. Being on the 2nd most recent LTS branch and moving to the next one is a good balance. Older branches have less attack surface and less non-battle-hardened new code but older means fewer backports.

@fun @elly See the public fuzzing report lists for many examples of unpatched Linux kernel vulnerabilities which are public. Cellebrite has been extending the fuzzers with better USB protocol, USB peripheral and USB gadget support to find vulnerabilities to exploit. They're also doing firmware and hardware level exploits too. We decided blocking new USB peripheral connections wasn't enough and replaced that 2 years ago with blocking connections in the USB controller + expanded software blocking.

@fun @elly Cellebrite is fairly clearly using open source Linux kernel fuzzing tools, extending those and then developing exploits for the vulnerabilities. Several of the people who work on these fuzzing projects have looked into it and found that slightly extending them is enough to find far more USB vulnerabilities. Security bug density is very high in the Linux kernel and without mass rewriting it to Rust, systemic exploit protections including hardware memory tagging are super critical.

@fun @elly GrapheneOS blocking USB connections and disabling USB data when existing connections end as the default while locked is a special case not relevant to attacking the Wi-Fi/Bluetooth/cellular/NFC/UWB/GPU drivers remotely and other attacks. Our generic exploit protections against memory corruption even prior to MTE were what kept Cellebrite out after mid-2022. We plan to replace the Linux kernel allocators and in-kernel MTE usage as we did for userspace to make that much more secure.

@GrapheneOS @elly Have you considered fixing these issues upstream, if you are aware of them and know solutions to them?

@GrapheneOS @elly I'm sure other android distros and even pmOS would benefit a lot from that work

@fun @elly The upstream Linux kernel is not friendly towards a lot of the security work we want to do. The upstream efforts to use Rust for drivers are going quite poorly largely due to people obstructing progress on it.

We're going to be implementing a massive overhaul of Linux kernel security based on a combination of hypervisor-based protections and hardware memory tagging. It needs this to compete with iOS which is increasingly widening the gap of kernel exploit protection with Linux.

@fun @elly Linux has hardware memory tagging support in the allocators but it was designed primarily as a hardware accelerated bug finding feature for production use rather than a security protection. It needs major improvements to make it a better security protection along with more hardened allocators. The kernel also needs a major overhaul of ways those protections can be bypassed via the page tables, physical memory, etc. Linux has bolted on security features instead of systemic protections.

@GrapheneOS @fun @elly

Being on bleeding edge kernels such as the non-LTS 6.17 stable branch is not really good for security beyond code churn potentially making it hard to keep exploits working.

But doesn’t being on latest non-LTS kernel means more vulnerabilities (and bugs that might cause vulns but weren’t found to be yet) gets patched instead of only backported ones?

@Orca @elly @fun A huge portion of vulnerabilities are very short lived. A portion of attempted fixes for vulnerabilities are also not initially correct. A lot end up being incomplete fixes but draw attention to the remaining issues. Some introduce new vulnerabilities. You really don't want to be using the actual mainline releases (release candidate and point zero releases). Everything else is not mainline. Mainline and stable are also not very production suitable due to many regressions.

@Orca @elly @fun The longterm branches are what's actually usable for production. There are still MANY serious regressions in those, especially hardware-related regressions. There have been endless regressions for USB-C DisplayPort alternate mode and the subset of drivers which are upstream. It's in fact quite a lot easier to update to the newer LTS revisions for a production device with out-of-tree drivers because there aren't untested changes breaking those and API changes are very rare.

@Orca @elly @fun The regressions we experience from LTS revisions are nearly entirely in the upstream subset of the code including core code and also drivers. We rarely have issues with the Pixel drivers in terms of regressions from LTS updates. We have plenty of issues with all the drivers whether upstream or downstream with MTE especially the out-of-tree complete Broadcom drivers for Wi-Fi/Bluetooth instead of the incomplete / broken upstream ones which have a fraction of the functionality.

@GrapheneOS @elly could you please elaborate what you mean by "no exploits needed"? How would I get to my data without entering my password?

@DrRac27 @elly Most people won't use a strong passphrase even with a separate passphrase only requested at boot. The data can be copied off the drive and the PIN/password brute forced on a server farm. This is the main issue impacting even Before First Unlock state devices for the vast majority of real world users.

There's no serious attempt at protecting against physical access including preventing modifying what's read from storage. Authenticated encryption only addresses one aspect.

@GrapheneOS @elly well, sure, thats obvious. But if I unlock my good LUKS password, log in and lock the screen. Is it still easy to get to my data? I would guess it would be somehow possible to read the RAM and therefore my LUKS key by opening up the device but other than that?

@DrRac27 @elly Yes, by exploiting the OS or tampering with the device including using debugging functionality. Multiple companies sell tools and services for this to states around the world. Cellebrite is one of those, and Cellebrite Premium is a hardware product running their software which can be used to exploit locked devices to extract data in After First Unlock state. Mobile devices have far better hardware, firmware and software security than laptops/desktops so it's the research focus.

@DrRac27 @elly Macs with macOS are the only desktop platform taking this seriously in the way that Pixels, iPhones and some other devices are doing. However, an iPhone or Pixel has far better security against this than a Mac. Macs have gotten a lot better at a hardware level but the software protection is much weaker and they're missing important iOS features for protecting against data extraction by restricting USB, auto-reboot for devices after being locked for a certain time period, etc.

@GrapheneOS @DrRac27 @elly There is a feature called always ask for accessories connection which is same as the one on iPhone. Perhaps you could start using Mac with latest version again and then reassess its security?

@2babcc @DrRac27 @elly That's not really what we're referring to, that doesn't disable USB as a whole.

@GrapheneOS @elly Nobody said PostmarketOS is secure. In fact most maintainers would tell you to use something else if you need security. No need to go on a rant here

@katzenmann We're not going on a rant, we just can't make more than 500 character posts because we don't want to patch Mastodon. @elly appears fine with talking to us and we've had a friendly/productive conversation.

@GrapheneOS @elly Okay sorry. I've misinterpreted the message then

@katzenmann @GrapheneOS Agreed, it was a really interesting conversation :)

@GrapheneOS @elly Do you see a future where desktop linux has a comparable level of security to android? If so, what would need to be done to get to that point?

@weirdtreething @elly Traditional desktop Linux is getting further away from the security of iOS and the Android Open Source Project. It isn't getting better relative to those, it's getting worse. There's nearly no systemic work being done on privacy and security. There isn't buy in from application developers to having proper sandboxing and the current approach isn't a proper one but rather is moving towards something resembling the much worse approach which existed in Android 4.4.

@weirdtreething @elly QubesOS works around that with virtualization, and also works around the poor security of the Linux kernel which still impacts Android but not as much due to the much leaner configuration. QubesOS exists to work around the insecurity of current platforms. We plan to more heavily use virtualization to take a similar approach to improving the security of isolation in GrapheneOS more than the Linux kernel riddled with holes and having no isolation internally can provide.