A wide range of Android phones are vulnerable to attacks that fully compromise the devices at their deepest level: the baseband. Fixes have yet to be delivered, except to a subset of vulnerable Pixels. In the meantime, Google and Samsung advise, users should do something that's not possible for most vulnerable devices: turn off VoLTE. Both Google and Samsung declined to provide further, actionable guidance to at-risk customers. Worse, even if/when it's possible to turn off VoLTE, this advice completely neuters most phones of any kind of voice calling capability.

This incident once again underscores the security mess of the Android ecosystem. It also demonstrates the lack of cooperation Google and Samsung regularly exhibit in keeping their customers safe.

Super sad.

https://arstechnica.com/information-technology/2023/03/critical-vulnerabilities-allow-some-android-phones-to-be-hacked/

Google tells users of some Android phones: Nuke voice calling to avoid infection

If your device runs Exynos chips, be very, very concerned.

Ars Technica

This incident involving the zero-click baseband vulnerability also underscores Google's continuing struggle to deliver timely updates to its Pixel customers. Delays like this one completely undermine the main selling of Pixel devices. What's more, the Project Zero advisory said that "affected Pixel devices have already received a fix." In fact, users of Pixel 6 devices still haven't received a patch, more than 4 days later.

Can someone tell me why Apple can deliver updates for all its iOS customers at once but Google still rolls out Pixel updates piecemeal?

@dangoodin perhaps the recent mass layoff of Google employees made a bad situation worse.

@dangoodin my bet: carrier ROMs are slowing things down

if you're running 100% stock Google-supplied Android, Google can handle the full update path. but if you bought your phone on contract there's a decent chance that your phone came with a carrier ROM with bundled apps and a SIM lock. the carrier has to pull from upstream and rebuild their ROMs for update delivery - Google can't just do that for them. and the carriers are not very good at doing any of this.

@gsuberland Why can't Google do whatever Apple does with iPhones on contract?
@dangoodin @gsuberland Frustratingly Samsung is supposed to be best at this (or at least they troubled to get theirs certified for US government use) and they still suck. It’s to a point where I recommend against the entire platform for security sensitive persons, and have for years
@dangoodin @gsuberland Google moving more hardware first party was supposed to help with this but clearly we’re not there yet
@dangoodin AIUI the whole system for iOS carrier ROM production is in-house at Apple, because they vertically integrate OS and hardware, so carrier mods can just be handled by Apple as a standard deployment process. Whereas with Android it's delegated to both the manufacturers and carriers, so for a given Android OS update it has to go to the manufacturers (to ship hardware-specific KMs and such) and then to the carriers before it can be deployed.
@dangoodin and the extent of iOS carrier mods is basically app installs, configuration defaults, and branding materials. whereas with Android the manufacturer is often maintaining an entirely custom source tree based on Android with tons of their own features and a lot more hardware support code, so by the time you get to the carrier ROMs there's a geometric growth in the number of ROM images that need patch backports & deployment builds.
@dangoodin @gsuberland well, Apple doesn’t let carriers do custom ROMs at all. All they get to do is make a config file. (Good.)

@gsuberland @dangoodin I have a stock pixel 6 purchased from google. It hasn't been updated since February 5th and shows no updates available.

That said, I'd appreciate if they'd thoroughly test any updates to the baseband. I can turn off wifi calling for a few days.

@gsuberland @dangoodin Got a patch today.
@gdbassett @dangoodin my wife's 6a got patched yesterday. so looks like the rollout is proceeding :)
@gsuberland @dangoodin This makes sense for general delay, but Dan's original point is about the Pixels specifically, for which this latency is directly under Google's control.
@tychotithonus @dangoodin Pixels sold by Google, yes. but they're still reliant on carrier image rollouts for phones purchased under contract, which is a lot of them. it won't be the only factor for sure (my suspicion is that regression testing is trickier on newer devices due to greater global variances in the baseband hardware & config) but it does slow things down.
@gsuberland @dangoodin I wish people wouldn't call this stuff a ROM. If it was an actual ROM then it would explain why upgrades were challenging, but it's not, so calling it a ROM just obscures what's going on.

@DrHyde @gsuberland Can you say more? If ROM is the wrong word, what's the right word? Also, can you spell out what makes this word different from a ROM?

Genuine questions intended to educate me on a topic I don't know enough about.

@dangoodin @gsuberland It's just software installed by the manufacturer. A ROM is a Read Only Memory.
@DrHyde @dangoodin that's the root, for sure, but over the years the term has also become used to refer to any image that is read-only (either by intent or by some technical measure). hence why a signed OS image is referred to as a ROM.

@DrHyde @dangoodin if we were pedantically prescriptive about the term, we wouldn't use "ROM" for almost anything any more, since almost nothing uses OTP fuse style programming these days and the few devices that do are for things like config straps rather than data.

and if you're going to argue about this use of ROM, you definitely need to start sending letters to IC manufacturers, because EEPROM is not read only. or just accept that terms have a rich history 🤷

@dangoodin @DrHyde @gsuberland Firmware. Non-user-modifyable "software" stored in non-volatile memory heavily tied to the hardware. In decades past, yes that was a ROM (usually EPROM) chip, but later flash memory was used.

The fact that the firmware is Linux-based & several GiB in size is irrelevant.

@DrHyde @dangoodin *shrug* it's a standard term in the smartphone world, I'd rather pick that than some other term that is more technically correct but less immediately recognisable.

@gsuberland @dangoodin

Unfortunately Google has not yet delivered an update to the 100% stock Google-supplied Android.

@Silv @gsuberland @dangoodin the march update just appeared now for my Pixel 6 Pro, finally.
@gsuberland @dangoodin this is a substantial portion of it. The rest of this is Florida Man syndrome. You're seeing more detail about Google's process and therefore have more to judge. You're making an errant assumption that you know when the Apple vulnerabilities were disclosed to Apple. That they all get updates simultaneously also means some get updates artificially late.

@dangoodin >Google still rolls out Pixel updates piecemeal

Not being a Google apologist, but Apple has about 4 models per year, and controls almost all of it front to back. Google has 3 models per year, but Samsung and friends add hundreds more. When you release an update, it needs to be known to work (or at least not bork) all those models... It's a testing matrix nightmare to be sure. I presume that's why they've stuck with the statistical rollout model they have... fail early and rewind

@PHolder Google even released updates for pixels piecemeal, with pixel 6 updates, not being available until a few hours ago. Pixel 7 updates, meanwhile, were available late last week. This is a single product line that Google controls 100% and even then update distribution is a train wreck.