13518219792
怎么进行Linux内核XFRM权限提升漏洞的分析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
为杨浦等地区用户提供了全套网页设计制作服务，及杨浦网站建设行业解决方案。主营业务为做网站、网站建设、杨浦网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
0x00 背景介绍
2017年11月24日, OSS社区披露了一个由独立安全研究员Mohamed Ghannam发现的一处存在于Linux 内核Netlink socket子系统(XFRM)的漏洞，漏洞编号CVE-2017-16939。
360CERT经过实际验证，确认该漏洞确实存在，但poc作者认为存在UAF漏洞，存在提权的可能性，而我们认为并没有UAF，只是使用未初始化链表造成的crash（空指针引用），并且使用的内存已经被初始化了，实际上无法提前布局，不能进一步利用达到提权的目的。
0x01漏洞概述
Netlink 是一种特殊的 socket，它是一种在内核与用户间进行双向数据传输的一种方式，用户态应用使用标准的 socket API 就可以使用 Netlink 提供的强大功能，内核态需要使用专门的内核 API 来使用 Netlink。
XFRM是 Linux 2.6 内核为安全处理引入的一个可扩展功能框架，用来在数据包经过路由路径的过程中对其进行修改。
漏洞原因是：在调用xfrm_dump_policy_done函数之前，如果不事先调用xfrm_dump_policy，会导致链表没有被初始化，造成空指针引用，产生崩溃。官方修正的补丁添加了xfrm_dump_policy_start函数，确保调用done之前会进行初始化。
0x02漏洞攻击面影响
1. 影响版本
影响Linux Kernel 2.6.28~4.14之间的版本
影响版本链接：
http://www.securityfocus.com/bid/101954
2. 修复版本
漏洞已被作为1137b5e（“ipsec：修复异常xfrm策略转储崩溃”补丁）的一部分解决，在4.14-rc7版本中被修复。
0x03漏洞详情
1. 技术细节
在函数 static int netlink_dump(struct sock*sk) 中：
(/net/netlink/af_netlink.c)
在上面的代码中，我们可以看到当sk->sk_rcvbuf小于等于sk_rmem_alloc（注意我们可以通过stockpot控制sk->sk_rcvbuf）时，netlink_dump（）检查失败，它跳转到函数的结尾并退出，但是cb_running的值不会更改为false。
所以当atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf 时，不应调用 cb->done(cb)，且nlk->cb_running 应设为 false。否则在 static voidnetlink_sock_destruct(struct sock *sk) 函数中：
该函数会在close(socketfd)时触发。该函数检测到 nlk->cb_running 不为 false，就会调用 done() 函数，即 xfrm_dump_policy_done()，导致 crash。
2. poc的验证分析
原作者 poc 中的执行流程如下：
（1）do_setsockopt() ：改小 sk->sk_rcvbuf 值
（2）send_msg(fd,&p->msg)：
第一次发送时，atomic_read(&sk->sk_rmem_alloc) = 0 < sk->sk_rcvbuf，发送之后，sk->sk_rmem_alloc 累加，结果在第一次发送后：
atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf
（3）send_msg(fd,&p->msg)：
第二次发送之后，此时atomic_read(&sk->sk_rmem_alloc)>= sk->sk_rcvbuf，未调用 done()，但 nlk->cb_running 值保持为 true。
（4）close(fd)：调用cb->done(cb)，产生崩溃。
按上述原理，其实即使不调用 “do_setsockopt();”改小 sk->sk_rcvbuf 值，只要多次 send，那么当 sk->sk_rmem_alloc 累加到超过 sk->sk_rcvbuf值，再次 send 后，“close(fd)”或进程退出时，就会导致 crash。
原 poc 改为如下也可触发（不调用do_setsockopt()）：
3. 漏洞分析总结
crash 原因分析：
原本程序理想流程是 xfrm_dump_policy() ->xfrm_dump_policy_done()，
xfrm_dump_policy() 时会检查 callback 中的一个双向链表是否有初始化，若没有，则初始化之（空链）。
而 xfrm_dump_policy_done()时默认上述链表已初始化，不再检查，直接读写。如前文所述，多次 send 就可以造成：
atomic_read(&sk->sk_rmem_alloc)>= sk->sk_rcvbuf
导致 netlink_dump() 中跳过 xfrm_dump_policy() ，即没有初始化链表，所以 close(fd) 时，xfrm_dump_policy_done() 就会操作未初始化内存，导致 crash。
那么若能提前布局这块内存，则可实现任意地址写值（通过双向链表del操作）。但是，无论是否触发初始化链表的操作，在之前这块内存都会被memset(0)：
在__netlink_dump_start函数里 memset(0) 后，才调用netlink_dump。接下来 netlink_dump中做sk_rmem_alloc >= sk_rcvbuf 的检测，失败后就不去xfrm_dump_policy 了。到后面 xfrm_dump_policy_done 用到的就是之前 memset(0) 的内存。这样就是缺少了 xfrm_dump_policy 过程中的初始化链表操作（INIT_LIST_HEAD），最终造成空指针引用。
所以这只是使用未初始化链表造成的crash（空指针引用），并且使用的内存已经被初始化了，实际上无法提前布局，不能进一步利用达到提权的目的。
0x04 修复建议
建议所有受影响用户，及时进行安全更新，可选方式如下：
1、相关Linux发行版已经提供了安全更新，请通过 yum 或 apt-get 的形式进行安全更新。
2、自定义内核的用户，请自行下载对应源码补丁进行安全更新。
补丁链接：
https://github.com/torvalds/linux/commit/1137b5e2529a8f5ca8ee709288ecba3e68044df2
看完上述内容，你们掌握怎么进行Linux内核XFRM权限提升漏洞的分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
