Retme的未来道具研究所

世界線の収束には、逆らえない

Trapecho

a note of cve-2013-4738

作者：retme 发布时间：April 21, 2014 分类：AndroidSec No Comments

详情：

https://www.codeaurora.org/projects/security-advisories/stack-based-buffer-overflow-and-memory-disclosure-camera-driver-cve-2013-4738-cve-2013-4739

貌似没有poc，那我就先不放了。。。去年的note 3都有这个问题

又一个典型的栈溢出,ioctl的lenth可控。如果想利用rop转换成任意地址写，可以参考http://retme.net/index.php/2014/03/31/CVE-2013-2597-acdb.html

如果可以将LR指向一个用户态地址，那就不用rop了，这样硬编码少一点

对于这种方法想说的是，我发现这个栈溢出我利用完之后没办法返回去继续执行了。。。原因还不知道【该死的google，没有调试器

那么就让子进程为父进程提权，提权完成后让子进程弄个死循环在里面转悠吧。搜索parent_cred需要一点小技巧

记录完毕，睡觉睡觉

CVE-2013-2094 exploit for Android

作者：retme 发布时间：April 2, 2014 分类：AndroidSec No Comments

漏洞介绍： http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094

http://wangcong.org/blog/archives/2274

漏洞补丁：

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;

patch就这一句，乍一看很难看出有什么利用点。但是其实int 换 uint是很敏感的，很有可能是一个整数溢出，还得往下看。以下分析来源于不爱补漏洞的mtk 源码

static int perf_swevent_init(struct perf_event *event)
{
    int event_id = event->attr.config;

......
    if (event_id >= PERF_COUNT_SW_MAX)
        return -ENOENT;

    if (!event->parent) {
        int err;

        err = swevent_hlist_get(event);
        if (err)
            return err;

        static_key_slow_inc(&perf_swevent_enabled[event_id]);
        event->destroy = sw_perf_event_destroy;
    }

    return 0;
}

这里面，event_id是一个int，但是仅仅校验id是否超过最大值，如果传入一个负值，将造成 perf_swevent_enabled这个全局数组越界

但是即使越界也不一定能使用，还要看是否对越界部分的内存做了修改，但是看这个static_key_slow_inc的名字，显然是做了加法，但是还要看是怎么加的，有没有什么限制。

perf_swevent_enabled这个全局数组的成员结构，就一个4字节的结构，这个api就是单纯的+1.那么就是说，只要我们使用sys_perf_event_open这个系统调用，就能将这个值加1

struct static_key {
atomic_t enabled;
};

static inline void static_key_slow_inc(struct static_key *key)
{
    atomic_inc(&key->enabled);
}

但是要想把它利用成“任意地址写”，还要解决几个问题：

  1. 利用地址范围问题：
    对于写入小于perf_swevent_enabled的地址，可以随意构造，event_id 就是（addr - perf_swevent_enabled）/4
    对于大于perf_swevent_enabled的地址，需要加一个负数位，来绕开PERF_COUNT_SW_MAX的限制，也就是【（addr - perf_swevent_enabled）/4】 | 0x80000000

2.每个进程调用sys_perf_event_open次数的限制
因为每一次调用sys_perf_event_open，都会开一个fd，fd最大就到1000，所以要分子进程调用sys_perf_event_open，每个调用980次
另外，当fd关闭或者进程推出时，会自动调用sw_perf_event_destroy（）进行释放，
这里的event_id是个u64，所以释放的时候还就没这个问题了，那么用户态的某个内存值会遭殃，这也是使用子进程的原因。

static void sw_perf_event_destroy(struct perf_event *event)
{
    u64 event_id = event->attr.config;  
    WARN_ON(event->parent);
    static_key_slow_dec(&perf_swevent_enabled[event_id]);
    swevent_hlist_put(event);
}

3.我们要修改的地方，原始地址必须是0，因为我们只能作加法，不知道修改位置的原始值，所以

可以考虑替换ptmx_fops_fsync 这个指针，这个指针为空，替换后再对ptmx调用fsync

poc实现代码可以参考 https://github.com/android-rooting-tools/android_run_root_shell 的perf_event部分

Android平台上的物理内存暴露漏洞

作者：retme 发布时间：April 1, 2014 分类：AndroidSec No Comments

早期安卓内核漏洞经常是：某个设备被设置成了755/666之类的，造成全局可读写，然后将这些设备mmap出来，就可以操作物理内存了

比如这样的设备有:

/dev/exynos-mem CVE-2012-6422 http://forum.xda-developers.com/showthread.php?p=35469999

/dev/dhcp CVE不详

/dev/msm_camera/config0 （CVE-2013-2595）的 “MSM_CAM_IOCTL_SET_MEM_MAP_INFO” 设置，mmap物理内存

/dev/graphics/fb0 的 FBIOGET_FSCREENINFO获取信息，然后mmap物理内存

安卓某些驱动确实需要提供物理内存映射的接口，比如 /dev/exynos-mem，但是应该仅仅提供给内核使用，应用层能使用的话就坑爹了

又有一些是根本没有必要暴露这种接口，却暴露了。 比如 /dev/msm_camera/config0 ，在 https://www.codeaurora.org/projects/security-advisories/uncontrolled-memory-mapping-camera-driver-cve-2013-2595 的patch中，直接将 msm_mmap_config给注释掉了。可能是没什么用，写程序时照模板抄的？