David Pierce:
Google Podcasts is dead. It has been dying for months, since Google announced last fall that it was killing its dedicated podcast app in order to focus all its podcasting efforts on YouTube Music. This is a bad idea and a big downgrade, and I’d be more mad if only I were more surprised.
The Podcasts app is just the latest product to go through a process I’ve come to call The Google Cycle. It always goes the same way: the company launches a new service with grandiose language about how this fits its mission of organizing and making accessible the world’s information, quickly updates it with a couple of neat features, immediately seems to forget it exists, eventually launches a competitor out of some other part of the company, obviously begins to deprecate it and shift focus to the new competitor, and then, years later, finally shuts it down for real. The Google Graveyard is full of apps like Reader, Duo, Inbox, Allo, Wallet, and countless others that have been through The Google Cycle, and it feels just as bad every time.
Via John Gruber:
I haven’t been bitten by Google killing an app or service since Google Reader, because I never again trusted them. I suppose this might be a lot more difficult for Android users, but I honestly don’t even remember the last time I added a new Google app or service to the set of tools I rely upon.
YouTube is irreplaceable. I wouldn’t want to be without Google Maps. Other than that, I use Google Search, Google News, Google Cloud Storage (with Arq), and Google Wi-Fi, all of which have decent alternatives. AdSense doesn’t, but it seems to have gotten a lot worse and isn’t doing much for me these days. I stopped using AdWords a while ago because it seemed untrustworthy. I also have a Nest Cam, which Google hasn’t supported very well.
See also: Sunset.
Update (2024-04-12): Tim Hardwick:
Google One VPN will be discontinued later this year, according to a customer email seen by Android Authority. The service was rolled out for Android in October 2020, before coming to iOS devices and Macs in 2022.
AdWords Google Google AdSense Google Cloud Storage Nearline Google Maps Google News Google Search Google Wi-Fi Nest Cam Podcasts Sunset Virtual Private Network (VPN) YouTube
Paul Ducklin (tweet):
The security vulnerablities themselves turn out to be a single bug, or at least to be covered by a single bug identifier, CVE-2024-1580, which was found and reported by Nick Galloway, a researcher in Google’s Project Zero bug-hunting team[…]
[…]
We’re guessing, from Apple’s purposeful silence when the first fixes came out last week, that the CVE-2024-1580 bug was considered dangerous to document before the patches for other platforms, notably macOS, were published.
We’re further guessing that this implies that even with just basic information on what to look for and where to start, cybercriminals will be able to work backwards from the patches to construct a working exploit.
However, it seems that the details had already been made public in February.
CVE-2024-1580:
An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder.
Previously:
Exploit Integer Overflow iOS iOS 17 Mac macOS 14 Sonoma Quartz Security Video
Howard Oakley:
macOS Sonoma 14.4 and 14.4.1 updates have been prompting some users to create a new FileVault Recovery Key. If you see this as your Mac completes an update, here’s what you should next.
[…]
If your Mac has FileVault turned on, and you opt to use a Recovery Key, check using fdesetup validaterecovery that the Recovery Key is correct whenever it’s changed. Otherwise you could be in for a big disappointment if you ever need to use it.
It’s not clear why some users are being prompted.
Howard Oakley:
The internal SSD in T2 and Apple silicon Macs is connected directly to its Secure Enclave, which performs its encryption and decryption using keys generated and stored within the Secure Enclave.
[…]
All volumes on the internal SSD that are encrypted have a Volume Encryption Key (VEK), protected by two internal keys, one the unique hardware UID from the Secure Enclave, the other from xART and intended to protect from replay attacks. The VEK isn’t exposed outside the Secure Enclave, nor is it handled by CPU cores.
[…]
When a user enables FileVault, a third key becomes involved in protecting the VEK, the Key Encryption Key (KEK), protected by the User Password and the hardware UID. This explains how no decryption and re-encryption is required when changing the User Password, or when enabling or disabling FileVault. Changes to the KEK affect access to the VEK, but don’t change the VEK at all.
[…]
Software encryption, including FileVault, for external storage of Apple silicon Macs may be vulnerable to GoFetch, but there’s no evidence that could affect FileVault encryption performed in the Secure Enclave.
Previously:
Apple T2 FileVault Mac macOS 14 Sonoma Privacy Secure Enclave
GoFetch (PDF, Hacker News):
GoFetch is a microarchitectural side-channel attack that can extract secret keys from constant-time cryptographic implementations via data memory-dependent prefetchers (DMPs).
We show that DMPs are present in many Apple CPUs and pose a real threat to multiple cryptographic implementations, allowing us to extract keys from OpenSSL Diffie-Hellman, Go RSA, as well as CRYSTALS Kyber and Dilithium.
Dan Goodin (via Kim Zetter, Hacker News, MacRumors):
The flaw—a side channel allowing end-to-end key extractions when Apple chips run implementations of widely used cryptographic protocols—can’t be patched directly because it stems from the microarchitectural design of the silicon itself. Instead, it can only be mitigated by building defenses into third-party cryptographic software that could drastically degrade M-series performance when executing cryptographic operations, particularly on the earlier M1 and M2 generations. The vulnerability can be exploited when the targeted cryptographic operation and the malicious application with normal user system privileges run on the same CPU cluster.
[…]
The threat resides in the chips’ data memory-dependent prefetcher, a hardware optimization that predicts the memory addresses of data that running code is likely to access in the near future. By loading the contents into the CPU cache before it’s actually needed, the DMP, as the feature is abbreviated, reduces latency between the main memory and the CPU, a common bottleneck in modern computing. DMPs are a relatively new phenomenon found only in M-series chips and Intel’s 13th-generation Raptor Lake microarchitecture, although older forms of prefetchers have been common for years.
[…]
The breakthrough of the new research is that it exposes a previously overlooked behavior of DMPs in Apple silicon: Sometimes they confuse memory content, such as key material, with the pointer value that is used to load other data. As a result, the DMP often reads the data and attempts to treat it as an address to perform memory access. This “dereferencing” of “pointers”—meaning the reading of data and leaking it through a side channel—is a flagrant violation of the constant-time paradigm.
Bruce Schneier:
Note that exploiting the vulnerability requires running a malicious app on the target computer. So it could be worse. On the other hand, like many of these hardware side-channel attacks, it’s not possible to patch.
Casey Muratori (tweet):
I recorded this video where I walk through what a “DMP” is, what the researchers figured out about Apple M-Series DMP behavior via microbenchmarking, and how a “GoFetch” DMP-enabled attack works in practice.
If you are already familiar with microarchitecture analysis, and would like some deeper reading on the subject, I would suggest reading the original GoFetch paper and three of its references in particular[…]
Paul Ducklin:
Intel, perhaps confusingly, gives the setting that turns this feature off the name DOIT, short for data operand independent timing, which actually tells the CPU, “Don’t do data memory-dependent prefetching.”
[…]
Very simply put, the researchers figured out how to feed in decryption keys that they knew wouldn’t work, but that might trigger DMP if they had guessed one of the bits in the key correctly, because they would have tricked the CPU into thinking it was looking at a pointer of interest.
By testing how quickly they could access the ‘memory address of interest’ immediately afterwards, they could determine whether it had been prefetched by the CPU (fast access) or not (slightly slower access), and therefore decide whether they had guessed correctly at one of the bits in the key.
With enough trials, they could gradually recover more and more bits of the key, to the point that they could then use other, existing attacks, albeit involving additional work based on data collected during the GoFetch stage, to figure out the entire key.
Previously:
Update (2024-04-08): Damien Petrilli:
Still not a word from Apple since this issue was disclosed publicly.
Apple M1 Apple M2 Apple M3 Exploit Mac macOS 13 Ventura macOS 14 Sonoma Processors Security
