一个绝妙的 exploit

-
 
 

Oen 通过 Google 阅读器发送给您的内容：

 
 

于 13-5-15 通过 A Geek's Page 作者：王 聪

最近 Linux 内核爆出了一个严重的安全漏洞，非root用户可以通过该漏洞的 exploit 获取root权限。这并不罕见，值得一提的是这个补丁看起来如此平常以至于我们绝大多数人都不会以为这是安全问题。

先看这个问题的补丁，就是下面这个：

   static int perf_swevent_init(struct perf_event *event)  { -	int event_id = event->attr.config; +	u64 event_id = event->attr.config;   	if (event->attr.type != PERF_TYPE_SOFTWARE)  		return -ENOENT;

我们第一眼的感觉就是这大概只是修复了编译器报的一个小警告吧，怎么会引起如此严重的安全问题呢？

在没打补丁的代码中 event_id 是个带符号的整型，而且就在下面不远处的两行代码中只检查了其上界：

C:
  1. if (event_id>= PERF_COUNT_SW_MAX)
  2.                 return -ENOENT;

而如果传递进来的 event->attr.config 值正好设置了符号位，那么 event_id 就会变成负值，而且能躲过上面的检查。

负值意味着什么呢？再继续看后面的代码：

C:
  1. if (!event->parent) {
  2.                 int err;
  3.  
  4.                 err = swevent_hlist_get(event);
  5.                 if (err)
  6.                         return err;
  7.  
  8.                 atomic_inc(&perf_swevent_enabled[event_id]);
  9.                 event->destroy = sw_perf_event_destroy;
  10.         }

意味着数组越界！这时你应该身上开始冒冷汗了。继续，数组 perf_swevent_enabled[] 在 RHEL6 上的定义是：

C:
  1. atomic_t perf_swevent_enabled[PERF_COUNT_SW_MAX];

而 atomic_t 基本上就是int，也就是说 perf_swevent_enabled[] 是整型数组，那么用 event_id 访问该数组时会把 event_id 的值乘以4再加上数组的起始地址。很简单哈！

好，通过 System.map 文件我们可以得到 perf_swevent_enabled 的地址：

 ffffffff81f360c0 B perf_swevent_enabled

那么当 event->attr.config == 0xffffffff （即有符号的-1）时，在 x86_64 上面我们最终会得到：

 0xffffffffffffffff * 4 + 0xffffffff81f360c0 == 0xFFFFFFFF81F360BC

同理，当 event->attr.config == 0xfffffffe 时我们得到：

 0xfffffffffffffffe * 4 + 0xffffffff81f360c0 == 0xFFFFFFFF81F360B8

所以上述的 atomic_inc() 其实增加的是前面两个地址中存放的值，而这俩地址都指向内核空间（参见 Documentation/x86/x86_64/mm.txt）！这时你应该感到紧张了。。。

后面更有趣的事情发生在 sw_perf_event_destroy() 函数中，它是在 perf_event_open() 返回的 fd 被关闭时被调用，RHEL6 上其定义如下：

C:
  1. static void sw_perf_event_destroy(struct perf_event *event)
  2. {
  3.         u64 event_id = event->attr.config;
  4.  
  5.         WARN_ON(event->parent);
  6.  
  7.         atomic_dec(&perf_swevent_enabled[event_id]);
  8.         swevent_hlist_put(event);
  9. }

很明显的不同是，event_id 这次是无符号的类型。那么，同上，当 event->attr.config == 0xffffffff 时我们得到：

 0xffffffff * 4 + 0xffffffff81f360c0 == 0x0000000381F360BC

当 event->attr.config == 0xfffffffe 时我们得到：

 0xfffffffe * 4 + 0xffffffff81f360c0 == 0x0000000381F360B8

所以这里的 atomic_dec() 实际上减小的是用户空间地址内的值。

上面是"基础知识"，带着这些知识我们看 exploit 代码究竟做了什么，代码片段如下：

C:
  1. #define BASE  0x380000000
  2. #define SIZE  0x010000000
  3.  
  4.  
  5.   assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE);
  6.   memset(map, 0, SIZE);
  7.   sheep(-1); sheep(-2);    // sheep will just invoke perf_event_open
  8.                            // syscall with attr.config set to the param
  9.   for (i = 0; i <SIZE/4; i++) if (map[i]) {
  10.     assert(map[i+1]);
  11.     break;
  12.   }

它首先会 mmap() 起始地址是 0x380000000 的一块内存区域。然后分别以 attr.config 为 -1 和 -2 调用两次 perf_event_open()。根据前面的计算，它实际上分别增加了 0xFFFFFFFF81F360BC 和 0xFFFFFFFF81F360B8 两处内存的值，减少了 0x0000000381F360BC 和 0x0000000381F360B8 的值。后面的 for 循环则是找出被减少的内存地址，这样一来也就可以算出 perf_swevent_enabled[] 数组的地址（System.map 并不总是存在，如果存在而且可读我们当然可以直接去读这个值）。

知道这个地址我们就可以操纵内核中某处的32bit的值，把其值加一。正因为如此，作者巧妙地选择了中断描述符表——一个16字节描述符的数组，它的地址可以通过 sidt 指令获取。它其中的描述符结构定义如下：

 Offset 	Size 	Description 0 	2 	Offset low bits (0..15) 2 	2 	Selector (Code segment selector) 4 	1 	Zero 5 	1 	Type and Attributes (same as before) 6 	2 	Offset middle bits (16..31) 8 	4 	Offset high bits (32..63) 12 	4 	Zero

这里最有趣的是 offset 为8 的地方，在 x86_64 上面其值为 0xffffffff。作者选择的中断描述符是 0x4，所以相对于中断描述符表它的偏移实际上是 0x48。现在的任务就成了通过 perf_swevent_enabled[] 来计算出该中断描述符中偏移为8的内存地址，并对其加一！下面的代码就是做的这个工作：

C:
  1. sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16);

i 是我们前面在 for 循环中搜到的 perf_swevent_enabled[] 的一个偏移，idt.addr 是中断描述符表的绝对内核地址，取其低32位并减去 0x80000000 是为了得到低28位作为偏移，除以4是因为数组是int，最后加的16就是 0x4 中断描述符中的偏移（4已经除去了），所以最终sheep()里面的参数就是我们想要的偏移，这样以来内核就替我们把 0x4 中断描述符中的偏移为 8 的 0xffffffff 加上了1，也就成了0，也就成了用户空间的地址！所以后面的 int 0x4 其实就会跳转到用户空间早已经设置好的代码！！！

而这段代码比较生涩，但其意思就是更改当前进程的 uid/gid 为0来提升权限，所以最终取得一个有 root 权限的 shell！整个攻击大功告成！

注：上面的链接可能不能用，exploit 代码也可以在这里看到：https://gist.github.com/onemouth/5625174


 
 

可从此处完成的操作：

 
 

评论

发表评论

此博客中的热门博文

浅析Linux Kernel 哈希路由表实现(一)

-
    Han 通过 Google 阅读器发送给您的内容：     浅析Linux Kernel 哈希路由表实现(一) 于 11-3-13 通过 basic coder 作者：levin 1. 路由表 目前Linux内核中支持两种路由表，一种是Hash路由表，另一种是Trie路由表，Trie算法查找效率很高，但它也因极其消毫内存资源而闻名，因此一般用在大型机上，否则在路由项过多时很可能造成内存的耗尽。在一般的机器上最好还是使用Hash路由表，之前有争论说Linux使用Hash路由表相比于二叉树效率太低，不适合商用，其实只要设计良好的哈希算法，尽量减少哈希碰撞，Hash路由表的查找效率也是很高的，在最好的情况下算法复杂算可以达到O(1)，当然，最差也不过是O(n)，我们有理由相信Linux中存在各种优秀的哈希算法，这些都是值得我们学习的。 Linux内核中IPv4路由表采用了分层的结构，第一层是是fib_table，表示路由表，最多可以支持256张路由表，用户可以根据策略路由的需求来创建自己的路由表，系统默认的两张路由表为RT_TABLE_LOCAL和RT_TABLE_MAIN。下面是系统保留的路由表标识符： enum rt_class_t { RT_TABLE_UNSPEC = 0 , /* User defined values */ RT_TABLE_COMPAT = 252 , RT_TABLE_DEFAULT = 253 , RT_TABLE_MAIN = 254 , RT_TABLE_LOCAL = 255 , RT_TABLE_MAX = 0xFFFFFFFF } ; 下面是路由表的定义： struct fib_table { struct hlist_node tb_hlist ; /* 路由表的标识，即为上面提到的类型 */ u32 tb_id ; /* 该路由中默认路由条目在哈希路由表中的索...
阅读全文

通过blktrace, debugfs分析磁盘IO

-
    Han 通过 Google 阅读器发送给您的内容：     通过blktrace, debugfs分析磁盘IO 于 12-11-14 通过 Linux Kernel and Tao 作者：admin 前几天微博上有同学问我磁盘util达到了100%时程序性能下降的问题，由于信息实在有限，我也没有办法帮太大的忙，这篇blog只是想给他列一下在磁盘util很高的时候如何通过blktrace+debugfs找到发生IO的文件，然后再结合自己的应用程序，分析出这些IO到底是谁产生的，最终目的当然是尽量减少不必要的IO干扰，提高程序的性能。 blktrace是Jens Axobe写的一个跟踪IO请求的工具，Linux系统发起的IO请求都可以通过blktrace捕获并分析，关于这个工具的介绍请自行google之，这里推荐我们部门的褚霸同学的 blog ，里面有好几篇文章分别介绍了blktrace, blkparse以及blkiomon等工具的使用。 debugfs是ext2, ext3, ext4文件系统提供的文件系统访问工具，通过它我们可以不通过mount文件系统而直接访问文件系统的内容，它是e2fsprogs的一部分，默认应该都是安装的，详细的说明可以通过man debugfs得到。 下面我来演示一下如何通过这两个工具的配合来找到磁盘IO的源头。 先看一个简单的例子： 在一个终端会输入如下命令： while [ 1 ];do dd if=/dev/zero of=test_file bs=4k count=20 seek=$RANDOM oflag=sync;done 随机的在test_file里面写数据造成较大的IO压力，现在看看如何通过blktrace和debugfs抓到它。 1. 通过iostat观察到有很大的磁盘压力 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sdb ...
阅读全文

ext4 bigalloc 答疑

-
    Han 通过 Google 阅读器发送给您的内容：     ext4 bigalloc 答疑 于 13-2-20 通过 斯巴达第二季 问题都来自 pamirs 的信，感谢他对bigalloc特性的关注。 问：文件分配的时候，ext4文件系统请求的时候是按照blocks来请求,但是ext4文件系统自己会按照cluster来分配（这个的理解是否正确呢？） 答：应该说，不太准确，事实上, ext4文件系统请求分配磁盘空间的时候也是按照cluster来请求的了，ext4_ext_map_blocks() 函数是用来检查文件的逻辑位置对应的物理块的，里面申请新磁盘空间的调用是：         ar.len = EXT4_NUM_B2C(sbi, offset+allocated);         ......         newblock = ext4_mb_new_blocks(handle, &ar, &err); ar.len的单位是cluster，所以实际上申请空间就是以cluster为单位 问：如果cluster为32K(8个blocks), 那么对于一个3k的文件来说,一次就分配了一个cluster,这样就有7个blocks不能在被其他文件使用了。group desc中的block_bitmap中将cluster对应的bit位置1，那么后续这个文件在增加的时候,是否按照增加的blocks数量,以及当前该文件占用的cluster,计算出已经占用的cluster中有多少blocks是空闲的,还可以继续分配呢? 答：是的，需要一些琐碎的计算，这些计算的代码都放在了函数get_implied_cluster_alloc()里 问：ext4_group_desc中的bg_free_blocks_count_lo字段表示当前group中有多少空闲的blocks,使用了bigalloc之后,该字段的意义并没有发生变化吧?好像没有看到有新增一个字段来表示free_clusters数量,这个是否不需要保存这样的变量?通过bitmap查询得知呢? 答：bg_free_blocks_coun...
阅读全文