容器安全

隔离机制

传统思路

• Machine-level virtualization，通过VM monitor将虚拟化硬件提供给宿主机内核，从而实现容器与主机之间的隔离
• Rule-based execution，通过指定细粒度的、基于用户创建预定义系统调用白名单来限制系统调用，从而实现容器与主机之间的隔离¹
  

gVisor提供的新思路

• 它提供了一个用Go编写的支持大多数Linux系统调用的非特权用户态内核，既可以像Machine-level virtualization一样拥有独立的内核和虚拟设备，也可以像普通的Linux进程一样动态调整自己的资源使用。
  

• 不能简单地认为gVisor只是一个类似runC引擎的存在，因为gVisor除了runC的替代品runsc，还提供了非特权用户态内核Sentry以及9P协议下的独立进程Gofer（与文件系统直接交互）
  

gVisor测试环境搭建

• 安装docker
• 从GoogleStorage下载2018-05-01之后每天官方发布的测试版binary
• 修改/etc/docker/daemon.json为如下

  {
   "runtimes": {
       "runsc": {
           "path": "path/to/latest/runsc"
   },
       "runsc_vuln": {
           "path": "path/to/vulner/runsc"
       }
   },
   "registry-mirrors" : [
       "http://ovfftd6p.mirror.aliyuncs.com",
       "http://registry.docker-cn.com",
       "http://docker.mirrors.ustc.edu.cn",
       "http://hub-mirror.c.163.com"
   ],
   "insecure-registries" : [
       "registry.docker-cn.com",
       "docker.mirrors.ustc.edu.cn"
   ], 
   "debug" : true
  } 

• 然后就可以用runsc作为docker的runtime来测试PoC了

gVisor安全脆弱性

• Rule-based方向：系统调用白名单缺陷
  • 相关漏洞 CVE-2018-16359，通过sys_renameat进行了成功的容器逃逸²
• 宿主机内核方向：内核设计中的逻辑缺陷
  • 相关漏洞 CVE-2018-19333，通过shmctl对共享内存进行连续RM_ID操作时引用计数负溢，导致Sentry panic³
  • 相关漏洞 CVE-2018-20168，多级页表设计缺陷，导致非法物理地址访问⁴
• Golang自身安全性方向：基于语言特性
  • 经syzkaller长期fuzz⁵，gVisor因golang的高并发性产生大量race，疑似存在race导致的内存破坏⁶，这将是接下来的重点工作
  • golang编译器设计缺陷⁷

reference

[1]C0ss4ck gVisor笔记
[2]gVisor runsc guest->host breakout via filesystem cache desync
[3]Privilege Escalation in gVisor, Google's Container Sandbox
[4]gVisor reuses pagetables across levels without paging-structure invalidation
[5]open syzkaller online
[6]Golang data races to break memory safety
[7]an issue in the Go compiler leading to a type confusion.

关于DLL劫持

DLL劫持扫描器

基于静态分析与动态hook编写了DLL劫持威胁扫描器PyAntiDllHijacking

项目进度

• 完成扫描器架构
• 发现安装劫持32起
• 完成安装包打包工具普遍问题测试
• pydbg与pydasm升级

近期计划

• 改进扫描器hook功能
  • 重构pydbg与pydasm适配amd64架构并开源
• 增加扫描器自动report与GUI功能
  • dllmain patcher
• 增加扫描器识别安装包打包工具功能