Crash when trying to replicate
blackhawk2772 opened this issue · 16 comments
Trying to replicate the exploit in kernel 6.2.0, the terminal prints this and the pc freezes.
Any feedback on what may be wrong?
Could it be that you're running the exploit on a device with a lot of network usage? I tried describing this behaviour in README.md and https://pwning.tech/nftables#62-post-exploitation-stability. It is normal that the exploit causes a kernel panic, but it shouldn't happen so fast that it can't even reach the shell.
I thought that could be the problem but I did try disabling the wifi adapter through BIOS as you suggested on my laptop, tried turning off the wifi in a virtual box machine and also tried disabling through virtualbox the adapter and always got the crash...
Even before the exploit is finished?
This is normal behavior. Please read the documentation before creating GH issues:
The kernel panic (system crash) after running the exploit is a side-effect which deliberately hasn't been fixed to prevent malicious usage of the exploit (i.e. exploitation attempts should now be more noticable, and unpractical in real-world operations). Despite this, it still allows for a working proof-of-concept in lab environments, as the root shell is functional, and persistence through disk is possible.
The exploit never finishes executing though, I understand kernel panic may occur after it's finished executing owing to instability but in all my attempts I have never managed to fully execute it despite following the instructions
That is indeed weird. If it is a tested kernel (based on the table in the blogpost), then I have no clue what causes it. What version did you say it was again? Your comment disappeared on my Github UI for some reason.
So far I've tried 6.1.69, 6.2.0, 5.15 and 6.2.16 and never finished executing, also the issue happens both in a laptop and in a desktop computer in virtual box and qemu, gonna try it natively in the desktop and see if anything changes but kinda lost honestly...
So far I've tried 6.1.69, 6.2.0, 5.15 and 6.2.16 and never finished executing, also the issue happens both in a laptop and in a desktop computer in virtual box and qemu, gonna try it natively in the desktop and see if anything changes but kinda lost honestly...
I suspect that the kernel you're trying it on isn't supported by the exploit. When you run it in QEMU (through TTY), could you share the kernel panic? And which distro are you using?
So I think I found out what the problem is, when I tried to execute the exploit I downloaded a new ubuntu 22.04 LTS and then changed the kernel to one of the supported ones but the problem I mentioned kept ocurring, but I have found out that using an older ubuntu version such as 20.04 makes it possible to run the exploit successfully. Maybe I can make a pr noting in the readme that ubuntu 20.04 is required?
Are you sure the ubuntu 22.04 isn't using Linux v6.5 under the hood, as mentioned in the README.md docs?
Great exploit by the way and congrats on finding it! I'd love to know if there are any plans to stabilize the exploit? I read in the blog pages ways it could be stabilized, unfortunately I'm not too familiar with such techniques, do you know of any colleagues or people who may create or develop a more stabilized versions?
Thank you so much!
It could presumably be stabilized, but I have not done it myself to prevent malicious usage of the exploit (in real-world operations).
I expect that the ethical (pentesting) organizations have the the in-house knowledge to stabilize the exploit, and hence I do not want to create a stabilized public one nor publish ways to stabilize it.
I mean it does come with an unsupported kernel, but I suppose that as long as I downgraded the kernel to one of the supported ones, like I did, the exploit should theoretically work right?
20.04 comes with an unsupported kernel as well but downgrading makes the trick
Yep! That should work. It should still crash after a few seconds of having root-shell, but not before it's done running.
But it doesn't, I guess something changed from ubuntu version to another. What ubuntu version did you test with?
It's listed in the blogpost, as Table 0.2.1.
| Linux | v6.2.? | Ubuntu | Jammy v6.2.0-37 | working | AMD Ryzen 5 7640U | 6 | 32GiB | n/a | final | |
| Linux | v6.5.3 | Ubuntu | Jammy v6.5.0-15 | fail | QEMU x86_64 | 8 | 16GiB | [TCHNQ] bad page: page->_mapcount != -1 (-513), bcs CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y | final | https://raw.githubusercontent.com/Notselwyn/blogpost-files/main/nftables/test-kernel-configs/linux-ubuntu-jammy-v6.5.0-15.config |