andigandhi
Verifying shim SBAT data failed
Hi there, cool Repo! I am currently also trying to get this exploit to work. Loading the Shim fails for me though. This is the Error:
Verifying shim SBAT data failed: Security Policy Violation Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
Did you also encounter this issue? Is my test system perhabs not vulnerable? Maybe we could plan a session on this, there should be newer kernel exploits out there right?
Happy Hacking!
SBAT Violation should mean that whatever is bootet afterwards is either not signed or to old, so that it violates the secure boot shim options. I can not tell you what is the case here. Since I have not looked at the kernel image here and there is no version number given anywhere.
Hi guys, sorry for the currently bad documentation, but I am still in a learning process myself and hope that the exploit will work soon. I have already experienced some problems with shim and SecureBoot myself, but I have not had this error on any system yet. Is your test system a dedicated computer or a VM? The Linux kernel I am using is the same as in the original demo v5.14. I will try to organise and document everything a little over the next few days.
On some laptops you need to use the 15.8 shim, earlier shims have been blacklisted due to an unrelated RCE in the shim. Make sure you use the 15.8 shim. We ran into this error when using the 15.7 shim on one laptop. https://askubuntu.com/questions/1523438/verifying-shim-sbat-data-failed-security-policy-violation#:~:text=The%20shim%20SBAT%20data%20failed%20error%20means%20that
No worries, you clearly stated WIP. What tripped me up is that Th0mas, in his article, links to the old Debian buster release. That shim seems to be to old for me to boot on my test system (dedicated PC). (Its 15.7) Both shims from Bullseye and Bookworm get me booted into your kernel. (Both are 15.8) Thanks for the clarrification @craigsblackie
On a sidenote: Even with the the Bookworm shim the buster version of grub boots fine. This is kind of weird to me...
Thank you very much, I'll update the repository and add the 15.8 shim! Initially I tried to precisely follow the blog post. Now as I am starting to understand more about the exploit, I think I'll try to optimize it :)
Yesterday I pushed some more changes btw. On my system I am now able to successfully scan for VMK needles. However, for some reason, the exploit still does not find a needle with the correct signature :(
Ive seen your changes, but as I am currently on arm I lack the capability to build the initramfs. I will check tomorrow, when I am back at my desktop.
Did you already dump the memory with qemu to verify that the VMK is still present in memory after we bootet into the linux kernel? You should check this before going insane on the exploit.
IT WORKED! I don't know why I did not succeed yesterday (maybe 11pm is not the best time for C code debugging) but I just was able to exfiltrate the VMK. I will try to find the reason why the same code did not work yesterday and keep you guys updated :)
IT WORKED! I don't know why I did not succeed yesterday (maybe 11pm is not the best time for C code debugging) but I just was able to exfiltrate the VMK. I will try to find the reason why the same code did not work yesterday and keep you guys updated :)
I've not had any luck my side. Did you make any recent changes?
Did you make any recent changes?
Not really. I did some random minor changes as I became a bit frustrated, but I think none of them really mattered. However, I just commited some changes regarding the initramfs builder. The initramfs is nowhere near perfect, but it worked for me:
# depmod -a
# exploit
I promise I'll add more information this weekend :)
Interesting, how is your stability with the exploit generally? I find I get a lot fo crashes without a shell on the unmodified original exploit. Wonder if that is playing a part in this.
On my VM there were no issues with the original exploit, on a physical Windows notebook I ran into some kernel problems using the original exploit. But I think these problems originated due to the modprobe path overwrite which does not happen in the modified exploit...