ed0e1e4d44
1979 changes to exploits/shellcodes Couchdb 1.5.0 - 'uuids' Denial of Service Apache CouchDB 1.5.0 - 'uuids' Denial of Service Beyond Remote 2.2.5.3 - Denial of Service (PoC) udisks2 2.8.0 - Denial of Service (PoC) Termite 3.4 - Denial of Service (PoC) SoftX FTP Client 3.3 - Denial of Service (PoC) Silverstripe 2.3.5 - Cross-Site Request Forgery / Open redirection SilverStripe CMS 2.3.5 - Cross-Site Request Forgery / Open Redirection Silverstripe CMS 3.0.2 - Multiple Vulnerabilities SilverStripe CMS 3.0.2 - Multiple Vulnerabilities Silverstripe CMS 2.4 - File Renaming Security Bypass SilverStripe CMS 2.4 - File Renaming Security Bypass Silverstripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities SilverStripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities Silverstripe CMS 2.4.7 - 'install.php' PHP Code Injection SilverStripe CMS 2.4.7 - 'install.php' PHP Code Injection Silverstripe Pixlr Image Editor - 'upload.php' Arbitrary File Upload SilverStripe CMS Pixlr Image Editor - 'upload.php' Arbitrary File Upload Silverstripe CMS 2.4.x - 'BackURL' Open Redirection SilverStripe CMS 2.4.x - 'BackURL' Open Redirection Silverstripe CMS - 'MemberLoginForm.php' Information Disclosure SilverStripe CMS - 'MemberLoginForm.php' Information Disclosure Silverstripe CMS - Multiple HTML Injection Vulnerabilities SilverStripe CMS - Multiple HTML Injection Vulnerabilities Apache CouchDB 1.7.0 and 2.x before 2.1.1 - Remote Privilege Escalation Apache CouchDB 1.7.0 / 2.x < 2.1.1 - Remote Privilege Escalation Monstra CMS before 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (2) Monstra CMS < 3.0.4 - Cross-Site Scripting Monstra CMS < 3.0.4 - Cross-Site Scripting (1) Navigate CMS 2.8 - Cross-Site Scripting Collectric CMU 1.0 - 'lang' SQL injection Joomla! Component CW Article Attachments 1.0.6 - 'id' SQL Injection LG SuperSign EZ CMS 2.5 - Remote Code Execution MyBB Visual Editor 1.8.18 - Cross-Site Scripting Joomla! Component AMGallery 1.2.3 - 'filter_category_id' SQL Injection Joomla! Component Micro Deal Factory 2.4.0 - 'id' SQL Injection RICOH Aficio MP 301 Printer - Cross-Site Scripting Joomla! Component Auction Factory 4.5.5 - 'filter_order' SQL Injection RICOH MP C6003 Printer - Cross-Site Scripting Linux/ARM - Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (28 Bytes) Linux/ARM - sigaction() Based Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (52 Bytes)
47 lines
No EOL
3 KiB
Text
47 lines
No EOL
3 KiB
Text
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://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/41218.zip |