Comment Maybe because this is a _really_ bad idea? (Score 1) 8
I am a bit surprised. I though at this time only complete idiots were still into crapcoins and irrational awe of the blockchain. Apparently not.
I am a bit surprised. I though at this time only complete idiots were still into crapcoins and irrational awe of the blockchain. Apparently not.
Any automaker not in EVs will not survive. I guess they finally accepted reality.
That really depends on a few things. A general statement like yours is not accurate.
So, skill-issue on the side of Apple. Interesting. Obviously, the cult-follower will deny their cult leaders could do anything wrong.
I looked at a few write-ups of CVE-2026-97631, but while they all mention PXE (and PXE uses DHCP, depending on configuration), none mentions ICMP. It would not make a lot of sense for the UEFI boot process to process ICMP packets either. Not ruling it out, people have done a lot of really stupid things with UEFI, but it does not seem to make a lot of sense here.
Does anybody know whether this is really ICMP? ICMP would could make this an attack potentially not local to the network segment, while DHCP and PXE make it network-segment local.
And put that below some factory in China?
Sorry for the joke, but the Headlines have gotten pretty bad here recently.
I agree. The "making everything scare" type of messaging (I will not elevate it by calling it "journalism") is a plague of our times. Essentially a form of slop.
That said, I do not think UEFI even processes ICMP. This is more likely about DHCP and that makes it a local-net only attack.
It is not ICMP. It is DHCP. And DHCP does broadcast to find the DHCP servers, so every machine in the local network sees it. If you do remote booting without DHCP (I used to do that via floppies wayyy back, but this requires the booting machine to get the IP of the boot server in some way), you are probably a lot harder to attack.
Sure. But with this, the attacker owns every machine in the local network that they can get to boot. The problem is this is a generic attack.
Ah, no. When Windows (or Linux) is running and attacker manages to get to the level of hardware access to write the BIOS chips, you are screwed, no connection to this vulnerability. They can simply add a key for their own kernel or switch secure boot off. What this vulnerability does is that if you use remote boot (PXE), they can get you to bute an unsigned kernel via a an attack coming from the local network.
Why would I do that "frantically"? Most do not impact me, this one here is an example. Incidentally, my job is to teach that stuff, and it is perfect for explaining to students why they need to understand secure coding and secure systems, because AI cannot do that.
Yes. The problem is that these days, remote booting can and typically uses DHCP. And DHCP does broadcast-type requests that every machine in the network segment sees. Of course, an attack has to come from the same network segment or rather broadcast domain (which are typically the same) so this is not a regular "long-distance" remote vulnerability, but essentially a "network local" remote vulnerability. Still pretty bad.
To be fair, most regular systems will not boot over the network.
And it is, incidentally, not even about security of the machine. It is DRM - Digital Restriction Management. And it is off on all my systems.
They use TSMC and Samsung, so South Korea, Taiwan, or, theoretically, the US.
Components sourced from U.S. and allied-country suppliers account for more than 90% of the BlueChip prototypes’ component procurement cost.
Both South Korea and Taiwan are US allies.
The more interesting question is what are the 10% that they aren't sourcing from allies?
Measure twice, cut once.