spencerdodd/kernelpop

kernel privilege escalation enumeration and exploitation framework

kernelpop's Issues

[Suggestion] Alternative exploit for CVE-2017-7308

https://github.com/bcoles/kernel-exploits/blob/master/CVE-2017-7308/poc.c

I'm maintaining an updated exploit in the cve-2017-7308 branch of my fork of xairy's exploit.

I've added new offsets, new KASLR bypasses, additional pre-exploitation checks, and networking support for post-exploitation.

On debian 11, it tries to install python-pip, when python-pip3 works

Function process_kernel_version unable to handle Linux kali 4.13.0-kali1-amd64 (Kali Linux)

I think the issue is here:

File "/opt/kernelpop/src/kernelpop.py", line 163, in process_kernel_version
k_release = int(kernel_version.split("-")[2])

Please note that for the string "4.13.0-kali1-amd64", the kernel_version.split("-")[2] is "kali1" which cannot be cast to an int.

Please see commands ran below:

root@kali:/opt# git clone https://github.com/spencerdodd/kernelpop.git
Cloning into 'kernelpop'...
remote: Counting objects: 468, done.
remote: Compressing objects: 100% (164/164), done.
remote: Total 468 (delta 305), reused 465 (delta 302), pack-reused 0
Receiving objects: 100% (468/468), 5.62 MiB | 2.51 MiB/s, done.
Resolving deltas: 100% (305/305), done.

root@kali:/opt# cd kernelpop/

root@kali:/opt/kernelpop# ls
constants.py exploits img kernelpop.py playground README.md src test

root@kali:/opt/kernelpop# python3 kernelpop.py

##########################

welcome to kernelpop

let's pop some kernels

##########################

[+] underlying os identified as a linux variant
Traceback (most recent call last):
File "kernelpop.py", line 17, in
main()
File "kernelpop.py", line 7, in main
kernelpop()
File "/opt/kernelpop/src/kernelpop.py", line 362, in kernelpop
kernel_v = get_kernel_version()
File "/opt/kernelpop/src/kernelpop.py", line 207, in get_kernel_version
return Kernel(kernel_version["normal"])
File "/opt/kernelpop/src/kernelpop.py", line 15, in init
self.release, self.architecture, self.uname = self.process_kernel_version(kernel_version, uname=uname)
File "/opt/kernelpop/src/kernelpop.py", line 163, in process_kernel_version
k_release = int(kernel_version.split("-")[2])
ValueError: invalid literal for int() with base 10: 'kali1'
root@kali:/opt/kernelpop# uname -a
Linux kali 4.13.0-kali1-amd64 #1 SMP Debian 4.13.4-2kali1 (2017-10-16) x86_64 GNU/Linux

root@kali:/opt/kernelpop#

Implement CVE-2017-1000405: Huge Dirty Cow

Would you be interested in @giladoved and I adding the Huge Dirty Cow PoC, which causes many running and future programs to crash, to kernelpop?

Add guide how to build for 32 bit

add more exploits

https://raw.githubusercontent.com/InteliSecureLabs/Linux_Exploit_Suggester/master/Linux_Exploit_Suggester.pl

Feature Request - uname -a as a command line argument

It would be fantastic if you could pass uname -a as a command line argument. Like this:

python3 ./kernelpop.py -u "Linux kali 4.14.0-kali3-amd64 #1 SMP Debian 4.14.17-1kali1 (2018-02-16) x86_64 GNU/Linux"

That would allow for use in your script in other script automation that we do while Red Teaming.

ValueError: invalid literal for int() with base 10: 'rc7+'

python3 kernelpop.py

##########################

welcome to kernelpop

let's pop some kernels

##########################

[+] underlying os identified as a linux variant
Traceback (most recent call last):
File "kernelpop.py", line 30, in
main()
File "kernelpop.py", line 10, in main
kernelpop()
File "/tmp/kernelpop/src/kernelpop.py", line 489, in kernelpop
kernel_v = get_kernel_version()
File "/tmp/kernelpop/src/kernelpop.py", line 260, in get_kernel_version
return Kernel(kernel_version["normal"])
File "/tmp/kernelpop/src/kernelpop.py", line 15, in init
self.release, self.architecture, self.uname = self.process_kernel_version(kernel_version, uname=uname)
File "/tmp/kernelpop/src/kernelpop.py", line 185, in process_kernel_version
k_release = int(kernel_version.split("-")[2].replace("kali", ""))
ValueError: invalid literal for int() with base 10: 'rc7+'

Doesn't work on debian 11

--dump in help, not --digest

The help (./kernelpop.py --help) says to use --dump for json...it is actually --digest

[Suggestion] Alternative exploit for CVE-2017-1000112

https://github.com/bcoles/kernel-exploits/blob/master/CVE-2017-1000112/poc.c

I'm maintaining an updated exploit in the cve-2017-1000112 branch of my fork of xairy's exploit.

I've added new offsets, new KASLR bypasses, support for other Ubuntu-based Linux distros (such as Linux Mint), and networking support for post-exploitation.

Error line 10 in CVE20160728.py for Kali Linux 4.13.0 (super() takes at least 1 argument)

root@kali:/opt/kernelpop# ls
constants.py exploits img kernelpop.py playground README.md src test

root@kali:/opt/kernelpop# python kernelpop.py

##########################

welcome to kernelpop

let's pop some kernels

##########################

[+] underlying os identified as a linux variant
[+] kernel Linux-4.13.0-kali1-amd64-x86_64-with-Kali-kali-rolling-kali-rolling identified as:
type: linux
distro: unknown
version: 4.13-1
architecture: x86_64
[*] matching kernel to known exploits
Traceback (most recent call last):
File "kernelpop.py", line 17, in
main()
File "kernelpop.py", line 7, in main
kernelpop()
File "/opt/kernelpop/src/kernelpop.py", line 377, in kernelpop
identified_exploits = find_exploit_locally(kernel_v)
File "/opt/kernelpop/src/kernelpop.py", line 261, in find_exploit_locally
exploit_instance = exploit_module()
File "/opt/kernelpop/exploits/linux/CVE20160728.py", line 10, in init
super().init()
TypeError: super() takes at least 1 argument (0 given)

root@kali:/opt/kernelpop# uname -a
Linux kali 4.13.0-kali1-amd64 #1 SMP Debian 4.13.4-2kali1 (2017-10-16) x86_64 GNU/Linux

from: can't read

./kernelpop.py -e
from: can't read /var/mail/src.kernelpop
from: can't read /var/mail/constants
./kernelpop.py: line 6: syntax error near unexpected token (' ./kernelpop.py: line 6: def main():'

Python3 on redhat/centos distributions

Since kernelpop is written with python3, how is it supposed to work on redhat/centos distributions? e.g CentOS 6.3

Looks like py2installer is the only way around?