12,222 karma · joined April 7, 2011
I don't think this is true at all? AOSP is completely open source modulo driver blobs (which Sailfish has too) and Google services.
One can make a fully functional system, modulo drivers, out of only open-source components using AOSP. It's not possible to do this using Sailfish; the compositor, UI libraries (Silica), and most of the "core" apps are still closed source.
Not so sure about this one. HCI (Hyperconverged) rack units (where storage and compute live in the same racked systems) and "blade servers" have been a thing for a really long time now; compute sleds aren't what's novel here.
Rack-level DC conversion is also not particularly novel, although underutilized IMO. It was pretty popular in HPC style density applications for awhile (see HP/SGI Altix 4000 for a good old example).
What's unique about Oxide is that they went all the way down to the firmware and then back up, rather than doing commodity hardware integration or reselling - for example, you can get something like a Supermicro EVO:Rail, but it will be running VMWare, not a fully integrated platform.
> Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot?
This would be pointless and erode the security of the system. Users who care can already remove Microsoft's root keys and enroll their own. There's a small corner case with UEFI Extensions / device firmware, but in this case a lightweight "sign everything" foundation would only serve to erode the security of the system. The problem space is completely orthogonal to website SSL and by and large simply good and not bad when properly configured.
> I also do not see a convincing reason it meaningfully improves security posture.
Secure boot paired with secure boot-sealed disk encryption massively reduces attack surface; with only Secure Boot-sealed keys (ie, BitLocker default), it reduces attack surface for the data on your disk to "post-boot authentication bypass or RCE" from "literally anyone or any piece of software who touches your computer or a disk that came out of it, ever." With keys sealed by Secure Boot and sealed or even just stretched by another mechanism (password, PIN, etc.), it reduces attack surface to "machine unlocked."
> MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)
I've been on Hacker News for an extremely long time and respect the community wish to avoid meta-discourse in general, but this kind of rubbish discourse with weird slurs and unfounded conspiracy theories is getting horrendous lately; I wish this site could more collectively move towards a productive curiosity rather than evidence-free statements based on arbitrary prejudice.
I have the same popular setup (Frigate) although I just use ONNX on an 11th-gen Intel CPU instead of a Coral (unless you are trying to do something fundamentally goofy like use a Raspberry Pi as an NVR, Coral doesn't really perform better than even a several-generations-old iGPU or iNPU).
This is the typical OSS story: you can duct tape a giant leaning tower of janky stuff (Frigate + go2rtc + HomeAssistant + various connectors + some kind of VPN/proxy solution for away-from-home access) together and get something that's fairly close to the commercial solution, where you click a button. The open source solution is fun and more customizable in highly niche ways (you can bring your own image recognition models and tagging, adjust the resolution and encoding for everything in infinite detail, and so on) and the commercial solution is easy and works. Chose your path.
I will say I've liked the Frigate stack, though. I'm making some recognition tweaks for recognizing animals on my property, the software works well enough, and I do like having a really, truly on-prem solution for this specific thing.
And VW didn't single-handedly destroy the diesel market; economics and physics did. Almost every other manufacturer was also fudging the tests results in some way. But more importantly, building a passenger car diesel that meets NOx targets doesn't work; by the time a passenger car diesel meets modern NOx targets honestly, the car contains a ludicrous precious metal loading in the catalyst and is only a few percentage points more efficient in terms of consumption and CO2 emissions than a petrol car and the math doesn't add up. Diesel is just not a practical solution for passenger cars; it never was in most ways, but it took the EU a long time to restrict NOx pollution to a sustainable level and expose the physical issues at hand.
Well, the DC-3 is a fun example, because it wasn't pressurized to start with.
But no, normally converted freight aircraft are fully pressurized; it's more expensive and more intrusive to redesign the plane to have a cockpit pressure bulkhead than it is to just leave the whole thing pressurized. There are some exceptions like the Beluga, usually due to door design constraints (at some point, making a cockpit pressure bulkhead becomes easier than making a giant pressurized door). This trend in retrofits might change; flat aft-pressure-bulkhead retrofits are becoming a thing to increase cubic footage capacity, and at some point someone might decide that the effort required to engineer and certify a cockpit bulkhead would be worth some advantage in door design or cargo capacity in a broader sense. But for now, they're usually fully pressurized.
The main reason why planes get a second life in freight is that freight carriers have _way_ more options for utilization; they fly fewer hours overall, hold the plane until it's completely full, and utilize different airports and routes. A loud, inefficient plane is OK to fly twice a day between two fixed airports with no noise restrictions, but useless to a passenger carrier who wants to make four or five turns between whatever airports are necessary and doesn't have guaranteed utilization to cover the overhead - right back to your original point, which I don't think anyone was really disagreeing with.
Eventually a better vulnerability was discovered where the signature validator didn't work properly:
The vulnerability used there is explained here: https://github.com/jilleb/mib2-toolbox/issues/122 . It's a "classic" mistake in signature validation (iirc the Windows software licensing service had a similar vuln at some point) but is a lot less trivial than this one; basically, the signature validator would stop validating once validation succeeded, so it was possible to take a valid update manifest and just tack more instructions onto the end of it and it would happily run them (the validation would return True, and then the command-runner would happily iterate through everything it got).
There's also a vulnerability on the lower tier models that revolves around a logic error and a signed update which would copy unsigned files into a directory due to some issue with the path validation that I can't completely recall at this point, as used in https://github.com/olli991/mib-std2-pq-zr-toolbox .
Anyway, these were a lot more exciting from a vuln research standpoint than this one (the MIB head units are also _fascinating_; they are not standard Tegra Android devices but a morass of rare and exotic DSP hardware driven by QNX and a giant enterprise IBM Java applicatoin).
> I wish other car makers were as reasonable as Honda here.
I doubt they did this on purpose.
> No "evil valet" with half a brain cell would waste time hacking the head unit if they have physical access to the car.
Keep in mind that head units usually also contain historic data; stuff like left-over synced phone contacts in SQLite databases, historic location data collected either explicitly for telemetry or accidentally in log files etc.
Additionally, head units usually have access to a lot of internal buses in a car; depending on manufacturer there's sometimes some level of firewalling effort, for example through a Gateway module, but these firewalls are usually quite weak when they are present at all (see: the famous thing with Honda unlock and starter release working with no cryptographic material through the same CAN bus as the headlights). This means that the infotainment can usually control some part of the car, and is much more powerful than a tracking device.
Plus, implanting code (or just extracting the data that's already there) from a head unit leaves much less evidence than adding an additional tracker.
> Not to mention that people with Civics are never targets of three letter agencies.
???
A non-default-installation set of AMD tools (Ryzen Master and probably others) had an auto-updater which used HTTP instead of HTTPS. It's clear this is a feature they'd basically forgotten about; it even pointed to an ATI domain. A third-party bug bounty company rejected it because MITM was out of scope. AMD are incompetent at making software (news at 11), kept asking for extensions, and took an incredible amount of time to deal with it. Eventually they removed this updater entirely and replaced it with one in the app (rather than the installer) that uses HTTPS + a CRC32 (for some reason). The initial vuln was very stupid and should have been fixed faster. As for the current system, if you're mad about HTTPS-protected auto-updaters (which is valid), you've probably got a lot of them to go to war against.
For example, previously I used the Frigate web UI over VPN to access my cameras, but I instead had Claude help set up go2rtc to push the video to HomeKit. I used the Eufy app for my doorbell, which I was instead able to integrate into HomeAssistant and then push to HomeKit as well, and I was also able to integrate some TP-Link Kasa plugs with HomeAssistant too.
This is all stuff I could have done relatively easily myself, but I hate nothing more than wading through horribly documented disparate configuration systems (I do that enough all day), so having Claude to do it for me is what unlocked it actually getting done.
I also added on to some custom one-offs like an ESP32-based controller for my kid's RGB LED nightlight for fun, although that stuff was more hand-coded since I find it enjoyable.
What's funny is that Twitter SRE used to be horrible and the app probably would have collapsed entirely (rather than the little bit that it did) without hundreds of manual operators, but in the few years leading up to the "acquisition," massively improved to the point that they literally automated themselves out of a job.
Anyway, Twitter had thousands of engineers, salespeople, support people, and so on. They were working on tens of new products in an attempt to find more revenue (everything from clones of every single social media app you can imagine to becoming a sports TV network), and on the other side (Goldbird), selling and supporting ads, the thing that made Twitter money.
The metric to look at isn't uptime, it makes no sense that people keep parading this metric. The metrics are revenue and revenue growth and surprise! by most available metrics, the Elon strategy torpedoed those.
Twitter was, like almost every "web" company in ~2020, a very "fat" company because they were re-investing free ZIRP money in future growth investment. Elon turned it into a KTLO operation, and didn't even manage to succeed at the standard PE style "fat" company slim-down (where you chop growth initiatives and keep the revenue, like everyone else is doing now), because he also chopped the revenue side.
I also build a ton of household glue stuff; I was never really passionate enough about the whole "homeserver" thing to spend the effort in going beyond basic video recording for my security system, but now I have all of my local-only home automation stuff wired together, mostly into HomeKit, and have been able to ditch a ton of cloud services.
This exploit is cool but there are similar exploits discovered in any given year and nothing really reeks of a backdoor; this one seems to be gaining attention mostly because Microsoft’s robo-call level initial response caused the researcher to dramatically crash out.
For a company, they're also nice for "I want to make an IoT device that's heavier weight than an ESP32 and/or I only want to hire Linux Application People and not Firmware People; what's the cheapest Linux module I can get that's widely supported, backed by a real company, and has regulatory approvals" - Pi Zero W. My understanding is this exact pattern is why it's harder to get them as a hobbyist.
I use them widely in automotive reverse engineering; ESP32 can and does work just as well or better for an end product, but for experiments it's really nice to have a self-contained appliance to SSH into and use SocketCAN on rather than some bespoke firmware project to manage and iterate on.
Given the price and availability issues I suspect the market is "correcting" a bit and companies are hiring Firmware People and switching to true MCUs in places they'd previously have avoided doing so, but it was definitely a thing for a long time.
It's concerning that Intel don't seem to have been responsive to anyone with respect to this issue and it doesn't appear to have an official errata yet, although Raptor Lake was the Intel CPU with voltage issues and basically random bit rot so I suppose it's hard to tell if this is a silicon level errata caused by bad design or by some kind of post-manufacturing damage. Raptor Lake in general causes enough non-reproducible noise that I believe Firefox gave up on automated crash reports from it ( https://bugzilla.mozilla.org/show_bug.cgi?id=1975808 ).
EDIT: I read that Oodle article (which is SO good!) again and realized that their customer-provided reproduction of the bug was directly linked to boost clock speeds (the customer said that overclocking by 5% made it happen entirely reliably), so this is definitely not a "the architecture has a 100% bug in it" but rather some deeper issue with clock propagation that appears at edge cases.
More modern devices are of course more difficult due to layers, feature size, and less visually obvious ROM bit designs.
Anyway, the impressive part of this project was really understanding the undocumented microcode assembly language through inference and trace following; the 1s and 0s look like they were the easy part!
We know how PIN-locked BitLocker works, and it requires unwrapping using a key sealed behind a TPM PIN policy and stretching it using the PIN itself. So we can deduce that this would require that:
* The attacker was able to bypass the TPM PIN sealing policy _and_ brute-force the stretching applied to the decrypted key. Brute-forcing the stretch is plausible on a "lots of expensive stuff" timeline but not an easy attack. Bypassing TPM PIN policy across multiple platforms would be something quite incredible. Given that TPMs are implemented by multiple vendors across multiple fundamental architectural approaches, and aren't based on a universal reference implementation, it would be rather bizarre to find a mistake in many or all of them.
* There is a secret volume key stored on a volume which can be decrypted by another mechanism. This would be a backdoor, but seems vanishingly unlikely given the amount of research which has been applied against BitLocker historically.
* The attacker is at some point able to inject something which allows them to observe the victim applying the PIN. There could be an attack here but it isn't nearly as interesting.
A fun next step would be to look at different fstx versions to see if it’s just something that was patched or refactored out at some point. At that point it could be a patch-door (ie an organic bug where the patch was held back by interference), but again, that would be a crappy setup due to the propensity for Windows vulnerability engineers to use binary diffing - if you had the exploit and the power to hold back the patch, it would be way better to hold it back everywhere.
WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster).
By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.
Whether this is a backdoor or not boils down to whatever your usual proclivities about "bug or backdoor" are; it's not like "if microsoft = 1 hack bitlocker" like the tech press seem to love to report.
This is a bug in the NTFS transaction log replay functionality in the Windows Recovery Environment WinRE, where it will read NTFS transaction logs from an external volume and apply them to the mounted filesystem. This allows the attacker to perform an authentication bypass against WinRE. With BitLocker without PIN or Password, _any_ authentication bypass becomes a disk encryption bypass, since the disk is unsealed by the bootloader (this architectural "flaw" is true for Linux with the same configuration, as well, like Ubuntu installed with their newish Hardware Disk Encryption checkbox in the installer).
In lieu of additional evidence, whether you think the NTFS transaction log issue is a planted backdoor or a simple enumeration bug depends on your conspiracy theory level, like most things in exploit development. To me, it seems like a plausible bug. The weaknesses in boot-time unseal are well known and obvious and this is just one of many, so I don't see it as an earth-shattering revelation, although it is a fun bug.
(as an aside): I'm not trying to say Lockdown Mode is infallible; I am sure phones in Lockdown Mode are or will be compromised. But it's clearly a very powerful tool, and to try to argue that it is some kind of marketing-driven conspiracy, against the body of evidence of its success, using bug bounty payout numbers (???), as the grandparent post did, is ridiculous.