Post AcXuhHWFoCwnjVle1A by mttaggart@infosec.town
(DIR) More posts by mttaggart@infosec.town
(DIR) Post #AcXt1PJqJqU5o6QnZo by mttaggart@infosec.town
2023-12-06T21:44:35.576Z
0 likes, 1 repeats
I'm really struggling with the absolute scope of this. But it's...vast. arstechnica.com/security/2023/12/just-about-every-windows-and-linux-device-vulnerable-to-new-logofail-firmware-attack/
(DIR) Post #AcXuhGUnc8BoYi4y6y by just1602@kolektiva.social
2023-12-06T21:58:12Z
1 likes, 0 repeats
@mttaggart my first reaction is that we should've ask ourselves if we really need an image parser there in the first place, and what we could do to avoid this kind of code in UEFI.
(DIR) Post #AcXuhHWFoCwnjVle1A by mttaggart@infosec.town
2023-12-06T22:03:18.698Z
0 likes, 0 repeats
@just1602 One idea I saw: mstdn.mx/@federicomena/111535630108904133
(DIR) Post #AcY0GItbBMmLuOCpii by mausmalone@mastodon.social
2023-12-06T23:00:11Z
0 likes, 0 repeats
@mttaggart @just1602 I'm like 99% sure in the old days BIOS images were fixed-size uncompressed data. We're talking about ONE image - why not just do that?
(DIR) Post #AcY0GLv7w8mfHzwb1E by mttaggart@infosec.town
2023-12-06T23:05:42.165Z
0 likes, 0 repeats
@mausmalone @just1602 I don't know enough about firmware to answer, but I suspect there are many reasons ranging from good to bad.
(DIR) Post #AcY2r5MIfwY4XyIVMW by dalias@hachyderm.io
2023-12-06T23:29:58Z
0 likes, 0 repeats
@mttaggart It's just completely misframed. Nothing is "vulnerable" to this. This is a bug in the layer by which Intel tries to prevent you from actually owning and controlling your own machine, that lets you come closer to actually owning it.
(DIR) Post #AcY2r66jtHhAs01akK by mttaggart@infosec.town
2023-12-06T23:34:43.077Z
0 likes, 0 repeats
@dalias With respect, that seems like pretty rosy take. This is plainly a method by which an attacker can bootkit a device. And it's a flaw in memory management. We have a word for exploitable flaws.I don't love Secure Boot or anything, but this feels entirely orthogonal to that.
(DIR) Post #AcY3Xx5XIgTZLgteFs by dalias@hachyderm.io
2023-12-06T23:40:37Z
0 likes, 0 repeats
@mttaggart It's not. If you have no expectation of boot firmware restricting you from running whatever code you want as early as you want, this is utterly irrelevant.
(DIR) Post #AcY3XxxQ4LZs2o6gF6 by mttaggart@infosec.town
2023-12-06T23:42:29.774Z
0 likes, 0 repeats
@dalias And...do we have that expectation? Or do you have that expectation? Again, I feel like it's pretty reasonable to be concerned about the broad security implications of this, and that can be separate from the debate over liberating hardware.
(DIR) Post #AcY3gZrX1UA3vBSWCe by dalias@hachyderm.io
2023-12-06T23:43:27Z
0 likes, 0 repeats
@mttaggart I most certainly don't. I use classic BIOS, no UEFI partitions.
(DIR) Post #AcY3gabcG91aE71K2C by mttaggart@infosec.town
2023-12-06T23:44:04.738Z
0 likes, 0 repeats
@dalias Right, so I'm kinda saying that two things can be simultaneously true. You can find this irrelevant, but that doesn't make it so for everybody?
(DIR) Post #AcY3ndQ2CMPyyjxk9Y by dalias@hachyderm.io
2023-12-06T23:45:02Z
0 likes, 0 repeats
@mttaggart Well its relevance implies a threat model where your ability to control your own hardware is the threat.
(DIR) Post #AcY3neDJF9pjRZ15xQ by mttaggart@infosec.town
2023-12-06T23:45:20.760Z
0 likes, 0 repeats
@dalias What about someone else controlling it?
(DIR) Post #AcY3zHGQObjNk11GPg by dalias@hachyderm.io
2023-12-06T23:46:33Z
0 likes, 0 repeats
@mttaggart They don't unless they've had physical access or you gave them (intentionally or inadvertently) root.
(DIR) Post #AcY3zI6BIB8CKXEb5M by mttaggart@infosec.town
2023-12-06T23:47:27.269Z
0 likes, 0 repeats
@dalias Both of which can and do happen! As a second stage compromise, this is dangerous.
(DIR) Post #AcY48YjMp9XMWHyzr6 by darkuncle@infosec.exchange
2023-12-06T23:48:59Z
1 likes, 0 repeats
@mttaggart @dalias some of the most long-lived and damaging malware out there is pernicious precisely because of its ability to infect boot sectors in a way that's unkillable
(DIR) Post #AcY4JpHBeHKT1JArTc by dalias@hachyderm.io
2023-12-06T23:49:47Z
0 likes, 0 repeats
@mttaggart If they've had root it's already game over. The domain that matters is comprised. Who cares about lower layers. This recent shift to "assume the OS is already pwned and the hardware is what you're trying to defend" is not well motivated.
(DIR) Post #AcY4Jq6wXqjHbpOC9I by mttaggart@infosec.town
2023-12-06T23:51:09.500Z
0 likes, 0 repeats
@dalias Okay, that position is not worth engaging with. Defense in depth matters, and it's honestly silly to claim otherwise. I suspect this entire argument you're making is motivated reasoning driven by a need to attack firmware vendors. I get the instinct, but this ain't it. Signing off now.
(DIR) Post #AcY4ax5tppK2Bq3qKG by celadonCamellia@sakurajima.moe
2023-12-06T23:54:03Z
1 likes, 0 repeats
@mttaggart Oh no
(DIR) Post #AcY5iARugBZHaiMVsW by lispi314@udongein.xyz
2023-12-07T00:06:11.509487Z
1 likes, 0 repeats
@just1602 @mttaggart >what we could do to avoid this kind of code in UEFIImplemented in Ada SPARK or better only would be a start.None of the bugs reported would've been possible to write without the SPARK compiler screaming at the dev.
(DIR) Post #AcY5owIBiFLTiB2g1w by lewiscowles1986@phpc.social
2023-12-07T00:06:39Z
0 likes, 0 repeats
@mttaggart can we just fire the folks working on this "hardware security" crap, and not have secure-boot?This feels like more and more user footguns are going to be put in place to lock down the hardware we paid for.Oh but it affects the enterprise. Good, then we can charge them (m|b|tr)illions to fix it.Always hated secure boot and hardware security. Just make rom chips removable and then we can "fix" the problem at one site, and verify using checksums from a known good source.
(DIR) Post #AcY5oxJzt0O2u4tdUO by mttaggart@infosec.town
2023-12-07T00:07:59.635Z
0 likes, 0 repeats
@lewiscowles1986 But like...this isn't a problem in Secure Boot, as I understand it? I'm no fan either, but this feels like a different thing, but I'm not doing another ten rounds about it.
(DIR) Post #AcY5vOzxtg2ITmbHnc by lispi314@udongein.xyz
2023-12-07T00:07:46.565541Z
1 likes, 0 repeats
@dalias @mttaggart You do realize just how bad of a history without privilege escalation both Linux and Windows have, right?
(DIR) Post #AcYCbrsLWReJvZfY3s by just1602@kolektiva.social
2023-12-06T22:13:07Z
1 likes, 0 repeats
@mttaggart yeah that would definitely help. Looks like rewriting everything in rust isn't a bad idea, in the end. But as someone point out in another thread, this code could have been fuzzed and fixed years ago.
(DIR) Post #AcYDN4BfZ7gTipDIPY by andthisismrspeacock@mas.to
2023-12-07T01:00:10Z
1 likes, 0 repeats
@mttaggart @lewiscowles1986 Taggart is right, this is not a vulnerability in secure boot. It's a vulnerability in UEFI that allows malicious firmware to bypass secure boot.So whether you like secure boot or not isn't relevant.
(DIR) Post #Acc4z57hJ1ObH0ULtg by justforfun@fosstodon.org
2023-12-08T19:44:29Z
0 likes, 0 repeats
@mttaggart @soller do you know if this would affect Coreboot?
(DIR) Post #Acc4z6k1I1e0I9QTGi by soller@fosstodon.org
2023-12-08T21:26:46Z
1 likes, 0 repeats
@justforfun @mttaggart https://fosstodon.org/@soller/111541432807730403