Exploit Google Android - RKP Information Disclosure via s2-remapping Physical Ranges

[Exploiter]

EDB-ID

41218

Проверка EDB

1. Пройдено

Автор

GOOGLE SECURITY RESEARCH

Тип уязвимости

DOS

Платформа

ANDROID

CVE

null

Дата публикации

2017-02-01

Google Android - RKP Information Disclosure via s2-remapping Physical Ranges

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=982

As part of Samsung KNOX, Samsung phones include a security hypervisor called RKP (Real-time Kernel Protection), running in EL2. This hypervisor is meant to ensure that the HLOS kernel running in EL1 remains protected from exploits and aims to prevent privilege escalation attacks by "shielding" certain data structures within the hypervisor.

In order to protect the information processed and stored within RKP (i.e., RKP's heap and stack or the current control-flow protection key), the physical ranges in which RKP and "physmap" are located are unmapped from the stage 2 translation table upon initialization of RKP. This prevents an attacker in EL1 from accessing any of these memory regions, as such an attempt would trigger an s2 translation fault.

However, RKP provides commands which can be used in order to re-map regions in the stage 2 translation table. Most of these commands correctly perform a validation on the given address range using "physmap". However, the "rkp_set_init_page_ro" command (command code 0x51) can be used to mark a region as read-only in stage 2, and performs no such validation. Here is the approximate pseudo-code for this command:

__int64 rkp_set_init_page_ro(unsigned args* args_buffer)
{
  unsigned long page_pa = rkp_get_pa(args_buffer->arg0);
  if ( page_pa < rkp_get_pa(text) || page_pa >= rkp_get_pa(etext) )
  {
    if ( !rkp_s2_page_change_permission(page_pa, 128LL, 0, 0) )// RO, XN
      return rkp_debug_log("Cred: Unable to set permission for init cred", 0LL, 0LL, 0LL);
  }
  else
  {
    rkp_debug_log("Good init CRED is within RO range", 0LL, 0LL, 0LL);
  }
  rkp_debug_log("init cred page", 0LL, 0LL, 0LL);
  return rkp_set_pgt_bitmap(page_pa, 0);
}

The "rkp_s2_page_change_permission" function makes sure the given page is mapped in stage 2 (and if it isn't, it re-maps it). The arguments passed in by "rkp_set_init_page_ro" in this specific case mark the page as read-only and non-executable.

Regardless, the physical address ranges for RKP are already present in the stage 1 translation table:

   ...
  [424] 0x0b5000000-0x0b5200000 [PXN: 1, UXN: 1, AP: 0]
  [425] 0x0b5200000-0x0b5400000 [PXN: 1, UXN: 1, AP: 0]
  [426] 0x0b5400000-0x0b5600000 [PXN: 1, UXN: 1, AP: 0]
  [427] 0x0b5600000-0x0b5800000 [PXN: 1, UXN: 1, AP: 0]
  [428] 0x0b5800000-0x0b5a00000 [PXN: 1, UXN: 1, AP: 0]
   ...

This means an attacker can simply invoke the "rkp_set_init_page_ro" command to s2-map any wanted page, and will subsequently be able to directly read from that page, even if it resides within RKP's physical address range.

I've verified this issue on an SM-G935F device, build version "XXS1APG3". The RKP version present on the device is "RKP4.2_CL7572479".

Proof of concept for the RKP stage 2 remapping issue.

This PoC s2-remaps RKP's physical address range and reads from it in EL1.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41218.zip