Monthly Archive:: December 2022

Google is working on upgrading its Nest Audio smart speaker to run on the company’s own Fuchsia operating system. For the last few years, Google has been steadily working on switching its Nest Hub smart displays from running on “Cast OS” to the company’s in-house OS, Fuchsia. The original Nest Hub was the first to make the jump in 2021, and the Nest Hub Max made a similar move earlier this year. In all likelihood, the Nest Hub 2nd Gen should get its Fuchsia update soon too. The slow, deliberate, and calculated rollout of Fuchsia continues.

Intel recently announced a big driver update for their Arc GPUs on Windows, because their DirectX 9 performance wasn’t as good as it could have been. Turns out, they’re using code from the open source DXVK which is part of Steam Play Proton. DXVK translates Direct3D 9, Direct3D 10 and Direct3D 11 to Vulkan. Primarily written for Wine, the Windows compatibility layer, which is what Proton is made from (Proton is what the majority of games on Steam Deck run through). However, it also has a Native implementation for Linux and it can be used even on Windows too. So it’s not a big surprise to see this. Heck, even NVIDIA use DXVK for RTX Remix. Windows gamers benefiting from open source technology for gaming on Linux. My my, the turntables!

End-to-end encryption is coming to most of iCloud with a new optional feature called Advanced Data Protection, according to Apple’s announcement on Wednesday. Previously, 14 data categories within iCloud were protected. This new feature brings that count to 23, including photos, notes, voice memos, reminders, Safari bookmarks, and iCloud backups of the contents of your devices. Not everything is encrypted in this way, though. Critically, calendar and mail are untouched here. Apple says they are not covered “because of the need to interoperate with the global email, contacts, and calendar systems.” Good step, and something every cloud provider ought to be offering.

FreeBSD 12.4 has been released. This is a maintenance release of the older stable branch, and contains the usual package updates, bug fixes, and other relatively minor changes.

Ars Technica: Guess what has happened! Łukasz Siewierski, a member of Google’s Android Security Team, has a post on the Android Partner Vulnerability Initiative (AVPI) issue tracker detailing leaked platform certificate keys that are actively being used to sign malware. The post is just a list of the keys, but running each one through APKMirror or Google’s VirusTotal site will put names to some of the compromised keys: Samsung, LG, and Mediatek are the heavy hitters on the list of leaked keys, along with some smaller OEMs like Revoview and Szroco, which makes Walmart’s Onn tablets. These companies somehow had their signing keys leaked to outsiders, and now you can’t trust that apps that claim to be from these companies are really from them. To make matters worse, the “platform certificate keys” that they lost have some serious permissions. I tend to not really focus on security issues, because more often than not they amount to baseless scaremongering for clicks (or worse, to scare people into buying antivirus software), but this one seems possibly serious enough to warrant attention. I’m just not entirely sure how bad this can actually turn out to be, and the vague statements from Samsung, Google, and other sure aren’t helping in cleaning up the confusion.

Traditionally, updates on Linux systems are controlled by the user. You get an icon in the system tray that looks important; you click on it; it asks you if you want to install updates; you say “yes” or “no”; updates are applied, or not; when you next restart any applications that you have running that were updated, the new version is picked up. Data isn’t lost, because updates don’t restart the application. You can (and do) update the Linux kernel in this way, and your computer just stays up (usually running on the old version of the kernel until you next restart.) Mechanisms have been added over time to allow auto updates to take place for critical security patches (“unattended upgrades”) but these have typically to be opt in. And again, they don’t restart running applications. Snap breaks this contract. The update channel for Snap is independent from the KDE updater (on Kubuntu), and seemingly the Gnome updater (on Ubuntu). If you consent to applying updates from the general system tray “updates needed” notification, Snap updates are not included; they’re not even listed in the pending notifications from the system tray. Snap updates only happen when the Snap updater is running, either if the application is not running or after the period of time required to force updates has expired. Snap updates happen without consent. I would really, really suggest moving away from Ubuntu, and opting for the countless better alternatives instead, like Fedora (the best desktop, in my view), Linux Mint (a great desktop, but a bit more conservative than Fedora), any of the Arch derivatives (for bleeding edge and tons of fooling around with AUR), or Void (for those of us with taste). Or any, any of the others. Ubuntu just does not seem to have its users’ best interests at heart, and Snap is the best example of that.

In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies. These are low-level components that require a systems language which otherwise would have been implemented in C++. To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result. It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production. These numbers don’t lie.

So there you have it: recommending idly Secure Boot for all systems requiring intermediate security level accomplishes nothing, except maybe giving more work to system administrators that are recompiling their kernel, while offering exactly no measurable security against many threats if UEFI Administrative password and MOK Manager passwords are not set. This is especially true for laptop systems where physical access cannot be prevented for obvious reasons. For servers in colocation, the risk of physical access is not null. And finally for many servers, the risk of a rogue employee somewhere in the supply chain, or the maintenance chain cannot be easily ruled out. The author makes a compelling case, but my knowledge on this topic is too limited to confidently present this article as a good one. I’ll leave it to those among us with more experience on this subject to shoot holes in the article, or to affirm it.