bzt wrote:
Ethin wrote:
I must clear up a misconception you seem to have here, bzt. Your misconception is that if a kernel hunts down the appropriate bit or byte, they can do anything with UEFI. This is not so.
The TianoCore source says otherwise. It is not a "misconception", rather the result of the analysis of the TianoCore source code. You've been warned not to fall for the propaganda and marketing bs, I wrote: "Obviously Intel and M$ do not want you to know this, but in reality it is that simple."
Sighs* Here we go again, more of your conspiracy theories that you can't prove. If MS and friends didn't want you to know about it, it wouldn't be in the damn code! Obviously!
bzt wrote:
Ethin wrote:
Additionally, you make the false assumption that every UEFI implementation is EDK2.
Nope, I've never said that. Read my post carefully, I've specifically talked about TianoCore UEFI only.
This is the only time where I can agree with you on this matter, and the only point in your entire post that is correct.
bzt wrote:
Ethin wrote:
the probability that manufacturers of computers just threw EDK2 on them is highly unlikely.
Quite the contrary, it is extremely very likely. Manufacturers are only interested in profit, not in a properly written firmware, which means they just add the minimum necessary drivers to TianoCore for their boards and get on with it. No manufacturers will spend money on implementing and testing a completely new firmware from ground up unless they really really have to.
You can't actually prove that. That's an assumption. By that logic, all the BIOS implementations are most likely the same, which clearly isn't the case. UEFI may be more complicated, but firmware is firmware.
bzt wrote:
Ethin wrote:
Also, secure boot is most likely going to prevent you as well, as is the UEFI runtime services.
That's not so, empirically proven by many UEFI rootkits. Secure boot can't stop you from modifying the run-time services (either data or code), and I've already shown two ways how to circumvent the run-time service checks, so that is doable as well. (And here's a third one: with a UEFI driver,
hijack ExitBootServices to patch SetVariable not to check AtRunTime or use a different variable). I'd advice you to study sources of rootkits (many are available on github and in MSF) and CVE tickets to learn about the many many ways how you can circumvent run-time checks.
If you expect security from UEFI, then you're the one who is mistaken. Not only it was written by non-security experts, never actually verified to be correct, but even the U.S. government forces it to be unsecure and law mandates backdoors to be placed in it. Which is conceptually wrong, because anybody can use those backdoors, not just the CIA.
Cheers,
bzt
More stuff you can't prove (and more stuff you completely and (probably deliberately) misinterpret). If secure boot wasn't made by security experts and your the security expert who knows all about firmware security, then please write me a UEFI application that I can successfully run when secure boot is enabled. I'll only load my own certificates into the secure boot databases. Your application may or may not be signed, and in either case, it needs to successfully trick the firmware into loading it and running it, even if the embedded digital signature is not within the secure boot database. You are only allowed to use exploits of your own creation; exploits designed to hijack ExitBootServices() or other UEFI boot or runtime services will be counted against you. If you can manage to do this, then you will have proven that secure boot isn't secure. But until then, I, along with anyone else who knows more about this than you do, and who can actually debate rationally, will continue to dismiss your points because all your points regarding the insecurity of secure boot are invalid because they are vulnerabilities that are exploited
after the secure boot stage has already concluded and the application/driver has already been loaded and executed. It really makes one wonder if you actually understand what secure boot really is. The more you talk about it, the less it appears you seem to actually understand. I'd strongly encourage you to re-read chapter 32, "Secure Boot and Driver Signing," of the UEFI specification, version 2.9. In particular, I point you to sections 32.2 (UEFI Driver Signing Overview), 32.3 (Firmware/OS Key Exchange: creating trust relationships), 32.4 (Firmware/OS Key Exchange: passing public keys), and 32.5 (UEFI Image Validation).