Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863570960

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
Sources:
https://phoenhex.re/2017-06-02/arrayspread
https://github.com/phoenhex/files/blob/master/exploits/spread-overflow

JavaScriptCore will allocate a JSFixedArray for every spread operand of the array literal (in slow_path_spread). As such, roughly 4 billion JSValues will have to be allocated, taking up 32 GiB in RAM. Luckily, this isn’t much of a problem due to the page compression performed by the macOS kernel. It will, however, take roughly a minute to trigger the bug.

What is left to do now is to perform some heap feng-shui to place something interesting on the heap that we will then overflow into. We use the following heap spray to exploit the bug:

- Allocate 100 JSArrays of size 0x40000 and root them (i.e. keep references). This will trigger GC multiple times and fill up holes in the heap.
- Allocate 100 JSArrays of size 0x40000, where only every second one is rooted. This triggers GC and leaves holes of size 0x40000 in the heap.
- Allocate a larger JSArray and an ArrayBuffer of the same size. These end up directly after the spray from step 2.
- Allocate 4 GiB of padding using JSArrays.
- Trigger the bug by concatenating JSArrays with a combined size of 232 + 0x40000 (containing the repeated byte 0x41).

The target buffer will be allocated in the sprayed region from step 2 and the victim buffers from step 3 will be overwritten. This increases the size of the victim array to the sprayed value (0x4141414141414141), so that it overlaps with the victim ArrayBuffer. The final steps immediately yield the fakeobj and addrof primitives described in section 1.2 of the JavaScriptCore phrack paper which can then be used to write code to a JIT page and jump to it.

In our exploit we perform step 5 in a separate web worker, so that we can launch a second stage shellcode immediately after the victim arrays are overwritten. This way we do not need to wait for the full overwrite to finish, and the heap is only left in a broken state for a very short time, so that garbage collection does not crash (which runs concurrently starting from Safari version 10.1). 


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