192 karma · joined April 11, 2021
[1] https://web.archive.org/web/20231206074005/https://support.a...
[2] https://web.archive.org/web/20240107224531/https://support.a...
I've never really seen a single example of this. Could you provide some?
I don't believe whether or not someone has adopted a given technology has any kind of clear correlation to their understanding of it or ability to use it were they to elect to. I know plenty of people who are up to date with the latest fads and yet dumb as rocks.
I think the kid will be just fine.
Agreed. A particular pain point for me is Apple's proprietary (or SMS-based, even worse) iCloud 2FA, it's just awful. I would use TOTP/HOTP for it in a heartbeat if given the option.
Well, no, it doesn't, but that's besides the point.
These specific image decoding bugs are indeed a bit of a nothingburger in terms of the implications they give rise to. There's just no reason to overwrite the boot logo graphic and leverage these exploits if another (simpler) method of achieving the same end result exists, and often it does.
For example, many systems to this day are shipped in a configuration such that you can disable write protections for certain ranges (or all) of the SPI EEPROM on which the firmware resides simply by changing some NVRAM variables (typically the variables correspond to (often hidden) 'BIOS settings' in common firmwares such as those from AMI or Phoenix), after which you can write contents of your choosing (eg. using Intel FPT) to the chip which will promptly be executed without any checks upon the next restart. This is by design, not even abusing any exploit or flaw in the software (of which there are plenty). If you want you can try it out on some of your own systems, for instance dump the firmware, extract (for example) the AMI setup menu form and simply run it through something like LongSoft's IFRExtractor[1] to locate the regions and offsets of said NVRAM variables, then try writing to them. It is true that the NVRAM regions for these settings (and others) are sometimes write protected or locked in such a way that you can't overwrite them after the firmware has started another program (eg. your bootloader), but often there are even ways around that. It's clear that firmware security is not always much of a concern for a surprising number of vendors currently shipping consumer computer systems / motherboards today.
It turns out that this is pretty much the case everywhere these days, doesn't seem to be exclusive to a particular country.