Recently a SMAP (Supervisor Mode Access Prevention) Bypass FreeBSD 12 Vulnerability reported by m00nbsd via Twitter was disclosed on the HackerOne.com bug bounty site in a flurry of PlayStation Hacktivity, which according to m00nbsd may also affect the PlayStation 5 although he reports being unable to confirm the SMAP bypass on a PS5 console. 
For those following the PS5 Jailbreak updates and PS5 NFOs in the PS5Scene, this comes proceeding the Talos WebSocket Vulnerability that may be present in the PS5 WebKit... also unconfirmed in part due to the limited console supply as a result of PlayStation 5 Scalpers.
The potential PS5 SMAP Bypass references CVE-2021-29628, which is described as follows:
In FreeBSD 13.0-STABLE before n245764-876ffe28796c, 12.2-STABLE before r369857, 13.0-RELEASE before p1, and 12.2-RELEASE before p7, a system call triggering a fault could cause SMAP protections to be disabled for the duration of the system call. This weakness could be combined with other kernel bugs to craft an exploit.
Finally, below is the SMAP Bypass report summary for those interested to quote:
SMAP is a security feature on x86 CPUs, that forbids ring0 from reading/writing to ring3 pages, making it harder to exploit entire classes of vulnerabilities.
There is a vulnerability in FreeBSD 12 that allows SMAP to be bypassed by userland. There is a very high probability that it affects the PS5 but I was unable to access a PS5 firmware to confirm it.
This vuln downgrades the security properties of the OS, and is a building block for exploitation chains.
Details
With SMAP enabled, when %RFLAGS.AC is cleared the kernel will page-fault if it tries to access a page marked as "user page". When %RFLAGS.AC is set the kernel can access the user pages as if SMAP was not enabled.
In the FreeBSD kernel, a few functions exist that temporarily set %RFLAGS.AC in order to access user pages: the copyin() and copyout() functions.
These functions are used in all syscalls and are the only ways the kernel can copy data from/to userland.
These functions handle faults gracefully, that is, if userland passes an unmapped address and the kernel tries to copy data from it, the functions will simply return an error without kernel panic.
There is a bug in the fault handling of these functions. Typically copyin() is implemented as follows:
The fault handler copy_fault is registered in pcb_onfault at the beginning, then %RFLAGS.AC is set, the copy is made, and %RFLAGS.AC is cleared back.
If the copy faults for whatever reason, an exception is raised, the trap() handler sees that pcb_onfault has a pointer registered, and simply IRETs back to the pointer that was registered.
The problem is, the fault handler copy_fault does not clear %RFLAGS.AC, meaning that it remains set after copyin()/copyout() returns. The rest of the syscall will therefore execute with SMAP effectively disabled, until the kernel returns to userland where the SMAP state gets reset back to normal.
This SMAP disablement survives context switches, so a user that disables SMAP during one of his syscalls can also disable SMAP in other user/kernel threads if a rescheduling happens after/during the syscall (taking a mutex for example).
Fix
Add a clac instruction in copy_fault to clear %RFLAGS.AC:
Impact
Userland can open lage windows where the kernel executes with SMAP disabled.
Lack of SMAP makes exploitation of common vulnerabilities easy/trivial.
some news: smap bug is officially patched on 2.50 ps5, however it should exist on 2.30 and below. unfortunately for me this means that the bug i found cannot be successfully exploited on 2.50, but it can be exploited on 2.30 and below
Published part 2 of the AMD PSP reversing stuff. This one focuses on the Crypto Co-Processor (CCP) and looking at the system for loading firmware and decrypting it.
Scratch that "locked/unreadable key slots" idea
Leak News AMD PSP Bootroms and VMProtect Source
SpecterDev thoughts on the leaked AMD Secure Processor bootroms (for people who don't know what this is about: AMD Zen 2 bootrom has been leaked, the PS5 CPU is also based on Zen 2, reverse engineering the secure processor may lead to a full PS5 jailbreak)
I've just dumped AMD PSP ROM from 4800s Desktop Kit which shares the same APU as used in Xbox Series X (Arden, Sparkman). Now it's a time to explore.
There was some pain to exploit it. I've got PSP code execution a week ago but then got stuck because UART interface was inactive. I've guessed that it's some problem with the PSP bootloader that doesn't configure SuperIO chip properly and looks like I was correct.
On 4800s the Nuvoton chip marked 5565D-M was used as multi-controller. Unfortunately, there is no datasheet for it and its pinout very differs from all public datasheets of similar chips that I can find.
Fortunately, after looking into a lot of pictures on the Internet I was able to find some PC motherboard from MSI that used the same SuperIO chip, and I've found boardview, that's how I've figured out all pins of it. But I still needed datasheet to figure out UART problem.
After a week of guessing, bruteforcing, reflashing BIOS (where I put my PSP payload) and observing LPC bus using Logic Analyzer, I was able to find a combination of register/bits that needed to be toggled to activate UART.
Finally, I have proper read/write/call primitives running via UART server from my PSP payload that works in SVC mode.
Unfortunately I have a little knowledge on boot chain and security parts of Xbox One, so cannot say. I've worked on its userland/kernel parts only.
For those following the PS5 Jailbreak updates and PS5 NFOs in the PS5Scene, this comes proceeding the Talos WebSocket Vulnerability that may be present in the PS5 WebKit... also unconfirmed in part due to the limited console supply as a result of PlayStation 5 Scalpers.
The potential PS5 SMAP Bypass references CVE-2021-29628, which is described as follows:
In FreeBSD 13.0-STABLE before n245764-876ffe28796c, 12.2-STABLE before r369857, 13.0-RELEASE before p1, and 12.2-RELEASE before p7, a system call triggering a fault could cause SMAP protections to be disabled for the duration of the system call. This weakness could be combined with other kernel bugs to craft an exploit.
Finally, below is the SMAP Bypass report summary for those interested to quote:
SMAP is a security feature on x86 CPUs, that forbids ring0 from reading/writing to ring3 pages, making it harder to exploit entire classes of vulnerabilities.
There is a vulnerability in FreeBSD 12 that allows SMAP to be bypassed by userland. There is a very high probability that it affects the PS5 but I was unable to access a PS5 firmware to confirm it.
This vuln downgrades the security properties of the OS, and is a building block for exploitation chains.
Details
With SMAP enabled, when %RFLAGS.AC is cleared the kernel will page-fault if it tries to access a page marked as "user page". When %RFLAGS.AC is set the kernel can access the user pages as if SMAP was not enabled.
In the FreeBSD kernel, a few functions exist that temporarily set %RFLAGS.AC in order to access user pages: the copyin() and copyout() functions.
These functions are used in all syscalls and are the only ways the kernel can copy data from/to userland.
These functions handle faults gracefully, that is, if userland passes an unmapped address and the kernel tries to copy data from it, the functions will simply return an error without kernel panic.
There is a bug in the fault handling of these functions. Typically copyin() is implemented as follows:
Code:
.macro COPYIN smap erms /* ... */ movq $copy_fault,PCB_ONFAULT(%r11) /* ... */ stac // set %RFLAGS.AC, to allow access to user pages do_the_copyin clac // clear %RFLAGS.AC, to forbid access to user pages /* ... */ copy_fault: movq $0,PCB_ONFAULT(%r11) movl $EFAULT,%eax POP_FRAME_POINTER ret
Code:
void trap(struct trapframe *frame) { /* ... */ if (curpcb->pcb_onfault != NULL) { frame->tf_rip = (long)curpcb->pcb_onfault; return; } /* ... */ }If the copy faults for whatever reason, an exception is raised, the trap() handler sees that pcb_onfault has a pointer registered, and simply IRETs back to the pointer that was registered.
The problem is, the fault handler copy_fault does not clear %RFLAGS.AC, meaning that it remains set after copyin()/copyout() returns. The rest of the syscall will therefore execute with SMAP effectively disabled, until the kernel returns to userland where the SMAP state gets reset back to normal.
This SMAP disablement survives context switches, so a user that disables SMAP during one of his syscalls can also disable SMAP in other user/kernel threads if a rescheduling happens after/during the syscall (taking a mutex for example).
Fix
Add a clac instruction in copy_fault to clear %RFLAGS.AC:
Code:
copy_fault: + clac movq $0,PCB_ONFAULT(%r11) movl $EFAULT,%eax POP_FRAME_POINTER retUserland can open lage windows where the kernel executes with SMAP disabled.
Lack of SMAP makes exploitation of common vulnerabilities easy/trivial.
- Glitching the AMD Secure Processor (AMD SP) / 2108.04575.pdf / ACM Conference on Computer and Communications Security (CCS) 2021
some news: smap bug is officially patched on 2.50 ps5, however it should exist on 2.30 and below. unfortunately for me this means that the bug i found cannot be successfully exploited on 2.50, but it can be exploited on 2.30 and below
- AMD-SP-Loader-main.zip / AMD-SP-Loader GIT - Binary Ninja (Binja) loader for AMD Secure Processor (SP) / Platform Security Processor (PSP) firmware binaries. It will try to load AGESA Bootloader (ABL) and Bootloader blobs and will setup the correct load addresses.
Published part 2 of the AMD PSP reversing stuff. This one focuses on the Crypto Co-Processor (CCP) and looking at the system for loading firmware and decrypting it.
Scratch that "locked/unreadable key slots" idea
- 2304.14717.pdf
- ftpm_attack (Code and data artifacts for our paper: "faulTPM: Exposing AMD fTPMs’ Deepest Secrets") via PSPReverse
- bootroms (AMD Zen 2 SP (Secure Processor) Bootroms aka AMD PSP Bootroms) via anonpsp
- VMProtect Source (Partial) via Alukym
Leak News AMD PSP Bootroms and VMProtect Source
SpecterDev thoughts on the leaked AMD Secure Processor bootroms (for people who don't know what this is about: AMD Zen 2 bootrom has been leaked, the PS5 CPU is also based on Zen 2, reverse engineering the secure processor may lead to a full PS5 jailbreak)
I've just dumped AMD PSP ROM from 4800s Desktop Kit which shares the same APU as used in Xbox Series X (Arden, Sparkman). Now it's a time to explore.
There was some pain to exploit it. I've got PSP code execution a week ago but then got stuck because UART interface was inactive. I've guessed that it's some problem with the PSP bootloader that doesn't configure SuperIO chip properly and looks like I was correct.
On 4800s the Nuvoton chip marked 5565D-M was used as multi-controller. Unfortunately, there is no datasheet for it and its pinout very differs from all public datasheets of similar chips that I can find.
Fortunately, after looking into a lot of pictures on the Internet I was able to find some PC motherboard from MSI that used the same SuperIO chip, and I've found boardview, that's how I've figured out all pins of it. But I still needed datasheet to figure out UART problem.
After a week of guessing, bruteforcing, reflashing BIOS (where I put my PSP payload) and observing LPC bus using Logic Analyzer, I was able to find a combination of register/bits that needed to be toggled to activate UART.
Finally, I have proper read/write/call primitives running via UART server from my PSP payload that works in SVC mode.
Unfortunately I have a little knowledge on boot chain and security parts of Xbox One, so cannot say. I've worked on its userland/kernel parts only.
Maybe by 
