kernel pwn

本文介绍了kernel pwn的基本概念,包括在比赛中遇到的文件分析,如bzImage、core.cpio和core.ko。讲解了内核、ioctl、cred结构体的作用,以及用户态与内核态的转换。提到了利用commit_creds(prepare_kernel_cred(0))进行权限提升,并讨论了调试技巧和获取shell的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

比赛中的kernel pwn

比赛中我们会得到下面几个文件

  • bzImage 这是一个内核编译生成的压缩内核映像
  • core.cpio这是一个文件管理系统

针对core.cpio会有一系列常规操作

mkdir core
cd core
mv ../core.cpio core.cpio.gz   //  cp ../core.cpio core.cpio.gz
gunzip core.cpio.gz
cpio -idmv < core.cpio
 

然后我们在core这个目录下我们可以看见

这里有一个init文件,我们用文本编辑器打开

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs none /dev
/sbin/mdev -s
mkdir -p /dev/pts
mount -vt devpts -o gid=4,mode=620 none /dev/pts
chmod 666 /dev/ptmx
cat /proc/kallsyms > /tmp/kallsyms
echo 1 > /proc/sys/kernel/kptr_restrict
echo 1 > /proc/sys/kernel/dmesg_restrict
ifconfig eth0 up
udhcpc -i eth0
ifconfig eth0 10.0.2.15 netmask 255.255.255.0
route add default gw 10.0.2.2 
insmod /core.ko

#poweroff -d 120 -f &
setsid /bin/cttyhack setuidgid 1000 /bin/sh
echo 'sh end!\n'
umount /proc
umount /sys

poweroff -d 0  -f

这些就是内核启动时候的一些环境信息,其中

insmod /core.ko

这个core.ko文件就是我们主要分析的文件,这个系统挂载了core.ko这么个文件,往往漏洞就出现在这里,针对这个内核文件我们会写一个c语言的程序来完成我们的攻击

setsid /bin/cttyhack setuidgid 1000 /bin/sh 这句话代表着我们是用什么用户,我们往往在本地中会将这句话改为

setsid /bin/cttyhack setuidgid 0 /bin/sh

  • start.sh这是一个启动Linux的脚本
#!/bin/bash
qemu-system-x86_64 \
-m 128M \          //128m 的大小
-kernel bzImage \  //选择bzImage这个内核
-initrd core.cpio \    //选择core.cpio这个文件管理系统
-append 'console=ttyS0 kaslr quiet' \  //kaslr就是开启了地址随机化
-monitor /dev/null \
-cpu kvm64,+smep,+smap \ //内核保护措施
-smp cores=1,threads=1 \  
-nographic
  • vmlinux是 编译生成的最原始的文件,里面是有符号表与一些gadget,常用于debug

执行启动脚本之后我们会得到这样一个有普通用户权限的虚拟机环境

在比赛中我们要把普通用户变成特权用户,flag就在特权用户的目录下

我们编写脚本完成之后,打远程时一般通过一些方式将脚本发送到服务端。

原理

内核

百度一下

ioctl

ioctl 也是一个系统调用,用于与设备通信。

linux的内核我们是可以拓展的,对于一些我们写的驱动我们可以通过这个系统调用来完成。

cred结构体

内核会将各个进程的权限用一个cred结构体保存着,通过这个结构体,内核就知道这个进程的权限。

struct cred {
    atomic_t    usage;
    #ifdef CONFIG_DEBUG_CREDENTIALS
    atomic_t    subscribers;    /* number of processes subscribed */
 
### PWN Syscall Usage and Techniques In the context of exploit development, syscalls play a crucial role in interacting with the operating system's kernel directly from user space applications. For exploiting purposes within pwn challenges or real-world scenarios, understanding how to invoke these calls manually can be beneficial. Syscalls allow attackers to bypass certain layers of abstraction provided by standard libraries like glibc when executing low-level operations such as reading files, writing data, creating processes, etc.[^1] To perform a syscall in an exploited program, one typically needs to know three things: - The number associated with each specific operation (e.g., read is 0; write is 1). - Arguments required for that particular function call. - Register conventions used on different architectures (for example, x86 vs ARM). For instance, here’s how you might craft code to make a `write` syscall using Python under Linux/x86_64 architecture: ```python from ctypes import CDLL, c_char_p, c_int # Load libc shared object file into memory libc = CDLL('libc.so.6') def execute_write_syscall(fd, buf, count): """Executes a direct 'write' syscall.""" # Define argument types explicitly libc.syscall.argtypes = [c_int, c_int, c_char_p, c_int] result = libc.syscall(1, fd, buf.encode(), count) # Call syscall with appropriate arguments return result ``` This snippet demonstrates invoking the `write` syscall through the C library interface rather than going fully bare metal which would involve assembly language instructions tailored specifically towards making raw hardware requests without any high-level abstractions involved at all levels between application logic down until reaching actual CPU instruction sets being executed physically inside processor cores during runtime execution flow control sequences managed internally within modern CPUs today[^2]. However, it should also be noted that manipulating registers directly via shellcode may sometimes become necessary depending upon what kind of vulnerability exists and whether there are protections against more straightforward methods available elsewhere throughout target binaries themselves along their supply chains leading up toward final deployed versions running somewhere out across various networks around globe potentially vulnerable enough given right conditions met simultaneously together just so perfectly aligned stars above us tonight shining brightly over this very moment now passing away ever so quickly into history books written long after our time has passed... --related questions-- 1. What are common register conventions for performing syscalls on x86 versus ARM architectures? 2. How do protection mechanisms affect the use of syscalls in exploitation? 3. Can you provide examples where crafting custom shellcode was essential due to limitations imposed by existing vulnerabilities? 4. In what ways does knowing the exact syscall numbers benefit exploit developers working on Unix-like systems?
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值