Editing Vulnerabilities

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 35: Line 35:
NetworkRequest.BeginGetResponse(AsyncCallback callback) invokes callback with <code>SecurityCritical</code> allowing for a privilege escalation. Unfortunately, Sony closed down the scoreboards feature <ref>http://community.eu.playstation.com/t5/Announcements-Events/PSM-scoreboard-service-is-closing/td-p/21263959</ref> which means that Network.AuthGetTicket() fails and Network.CreateRequest() cannot be invoked. There is no other way of creating a NetworkRequest object.
NetworkRequest.BeginGetResponse(AsyncCallback callback) invokes callback with <code>SecurityCritical</code> allowing for a privilege escalation. Unfortunately, Sony closed down the scoreboards feature <ref>http://community.eu.playstation.com/t5/Announcements-Events/PSM-scoreboard-service-is-closing/td-p/21263959</ref> which means that Network.AuthGetTicket() fails and Network.CreateRequest() cannot be invoked. There is no other way of creating a NetworkRequest object.


<source lang="csharp">
 
using System;
using System;
using System.Security;
using System.Security;
Line 67: Line 67:
}
}
}
}
</source>
 


== System ==
== System ==
Line 75: Line 75:
=== Stack buffer overflow in sceSblDmac5EncDec ===
=== Stack buffer overflow in sceSblDmac5EncDec ===
(16/09/2014)
(16/09/2014)
<pre>
 
might have found one
might have found one
SceSblDmac5Mgr_sceSblDmac5EncDec
SceSblDmac5Mgr_sceSblDmac5EncDec
Line 88: Line 88:
bad news is it got patched in 1.80
bad news is it got patched in 1.80
they also added a isShell check
they also added a isShell check
</pre>
 


'''Consensus''': Confirmed exploitable before 1.80. YEAH!
'''Consensus''': Confirmed exploitable before 1.80. YEAH!


=== GcAuthMgr checks only KeyID > 0x8001 not >= 0x8001 !! ===
allows for a prototype keyset to be used, which is derived from bbmac 0x345
and skips the last step to derive using 0x348. thus instead the master key
gc auth keys are derived using a constant that is obtainable..
<source>
  ret = bigmac_aes256_cmac_to_keyring(key_1,0x21,0x345);
  if (ret == 0) {
    memcpy(&enc_dec_buf,input,0x20);
    ret = bigmac_encrypt_aes128_using_keyslot(bigmac_temp,&enc_dec_buf,0x20,0x21);
    if (ret == 0) {
      memcpy(out,bigmac_temp,0x10);
      if (key_id == 1) {
        memcpy(&enc_dec_buf,out,0x10);
        ret = bigmac_aes128cbc_decrypt_to_keyslot(&enc_dec_buf,iv,0x24,0x348);
        if (ret == 0) {
          *key_id_to_use = 2;
        }
      }
      else {
        *key_id_to_use = 1;
      }
    }
  }
  return ret;
</source>
=== sceIoDevctl does not clear stack buffer ===
=== sceIoDevctl does not clear stack buffer ===
(24/11/2014)
(24/11/2014)
Line 122: Line 97:
Then call devctl and get upto 0x3FF bytes of that stack!
Then call devctl and get upto 0x3FF bytes of that stack!


<source lang="c">
 
     sceIoDevctl("sdstor0:", 5, "xmc-lp-ign-userext", 0x14, WINDOW_BASE+0x10, 0x3FF);
     sceIoDevctl("sdstor0:", 5, "xmc-lp-ign-userext", 0x14, WINDOW_BASE+0x10, 0x3FF);
     store(RET, WINDOW_BASE+0x4);
     store(RET, WINDOW_BASE+0x4);
</source>


Fixed in 3.61.


=== Syscall handler doesn't check syscall number ===
=== Syscall handler doesn't check syscall number ===
Line 133: Line 106:
(03/07/2015) A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.
(03/07/2015) A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.


This was patched in 1.61.
This was patched somewhere >1.60.


=== Heap use-after-free in sceNetSyscallIoctl ===
=== Heap use-after-free in sceNetSyscallIoctl ===
Line 141: Line 114:
When passed proper arguments, sceNetSyscallIoctl will execute a function from the socket's vtable at the end:
When passed proper arguments, sceNetSyscallIoctl will execute a function from the socket's vtable at the end:


<source>
 
       v13 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket + 24) + 28))(
       v13 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket + 24) + 28))(
               socket,
               socket,
Line 147: Line 120:
               flags_,
               flags_,
               mem_);
               mem_);
</source>


Fixed in 3.63.
 
Confirmed exploitable on 3.60 still.


== Non-secure Kernel Loader ==
== Non-secure Kernel Loader ==
Line 156: Line 129:
== Secure Kernel ==
== Secure Kernel ==


=== SMC 0x12F does not validate arguments ===
(01/01/2017) SMC 0x12F (sceSblSmSchedGetStatusMonitorCall) takes two unchecked arguments:  <code>sm_handle</code> and <code>shared_mem_index</code>.
<code>sm_handle</code> is a pointer to TrustZone memory in the form of <code>(tz_addr >> 0x01)</code> and <code>shared_mem_index</code> is an integer value calculated as <code>((shared_mem_blk_addr - shared_mem_base_addr) / 0x80)</code>.
By passing the right value as <code>sm_handle</code>, SMC 0x12F will read 0x08 bytes from <code>(tz_addr + 0x28)</code> and return them at <code>(shared_mem_base_addr + index * 0x80)</code> which translates to a TrustZone arbitrary memory leak (0x08 bytes only).
By passing the right value as <code>shared_mem_index</code> it is also possible to write the leaked data into an arbitrary TrustZone memory region.
The Non-secure Kernel sees the shared memory region at <code>0x00400000</code> (size is 0x5000 bytes) and the Secure Kernel sees the exact same memory region at <code>0x00560000</code>, thus making it possible to plant data inside the Non-secure Kernel's region and having the SMC copy this data somewhere into TrustZone memory (e.g.: SMC table).
This results in TrustZone level arbitrary code execution.
This was patched somewhere around 1.80.


== Hardware ==
== Hardware ==
Line 176: Line 135:
== F00D Processor ==
== F00D Processor ==


=== To be disclosed ===
(18/02/2017) To be disclosed.
https://twitter.com/pomfpomfpomf3/status/832806488221446145
<pre>
octopus exploit
                            .---.        ,,
                ,,        /    \      ;,,'
                ;, ;      (  o  o )      ; ;
                  ;,';,,,  \  \/ /      ,; ;
              ,,,  ;,,,,;;,`  '-,;'''',,,'
              ;,, ;,, ,,,,  ,;  ,,,'';;,,;''';
                ;,,,;    ~~'  '';,,''',,;'''' 
</pre>
(I copied the octopus from an ASCII art page: http://ascii.co.uk/art/octopus)
=== Disclosed by Yifan Lu ===
Yifan Lu has written an article on how to exploit the F00D processor on their personal blog (11/01/2019).
https://yifan.lu/2019/01/11/the-first-f00d-exploit/


== References ==
== References ==
Please note that all contributions to Vita Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see Vita Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)