What's Dimitro doing now is a SMM payload development. Yes, he has modified the firmware to develop and debug it, but at the end it will be a simple SMM driver, so you only need to add this ready-to-use code into the firmware, which is a different and easier task. At first, you need local privilege escalation to get to physical memory and SPI interface. If it's unprotected - you are done here, dump BIOS region using flashrom, modify it with uefi-firmware-parser to integrate the driver and flash the modified image back into the flash. Bang, you're pwned. If SPI flash is protected from writing, there are numerous attacks on this protection, including S3 BootScript vulnerability (which isn't fixed for like 95% of the current UEFI-based systems) and a ton of SMI handlers vulns (unvalidated buffers that cross SMRAM borders, execution of non-SMRAM code from SMI handler, you name it). Yes, it should be a targeted attack for now, but UEFI is all about code reuse, so if someone really wants to get into your UEFI - there is nothing you can do about it (except BootGuard, maybe, but it's a whole different story).
There is no need to panic and/or blame UEFI developers, but there is also much to be done about UEFI security, starting from patching existing vulnerabilities reported 6 months ago, reducing attack surface for flashing software (Intel PFAT, capsule-based updates, etc.), using hardware root of trust (BootGuard/TrustZone) to measure and/or verify the firmware step by step, and so on.
As for you, normal user of UEFI system: "Please, please, please, go apply BIOS updates" --Xeno Kovah @ CanSecWest 2015.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2015-05-28 05:48 pm (UTC)If SPI flash is protected from writing, there are numerous attacks on this protection, including S3 BootScript vulnerability (which isn't fixed for like 95% of the current UEFI-based systems) and a ton of SMI handlers vulns (unvalidated buffers that cross SMRAM borders, execution of non-SMRAM code from SMI handler, you name it). Yes, it should be a targeted attack for now, but UEFI is all about code reuse, so if someone really wants to get into your UEFI - there is nothing you can do about it (except BootGuard, maybe, but it's a whole different story).
There is no need to panic and/or blame UEFI developers, but there is also much to be done about UEFI security, starting from patching existing vulnerabilities reported 6 months ago, reducing attack surface for flashing software (Intel PFAT, capsule-based updates, etc.), using hardware root of trust (BootGuard/TrustZone) to measure and/or verify the firmware step by step, and so on.
As for you, normal user of UEFI system: "Please, please, please, go apply BIOS updates" --Xeno Kovah @ CanSecWest 2015.