| Reporter | Title | Published | Views | Family All 28 |
|---|---|---|---|---|
| Apple iOS < 10.3.2 Multiple Vulnerabilities | 17 May 201700:00 | – | nessus | |
| Safari < 10.1.1 Multiple Vulnerabilities | 18 May 201700:00 | – | nessus | |
| Apple TV < 10.2.1 Multiple Vulnerabilities | 18 May 201700:00 | – | nessus | |
| Apple TV < 10.2.1 Multiple Vulnerabilities | 17 May 201700:00 | – | nessus | |
| Apple iOS < 10.3.2 Multiple Vulnerabilities | 18 May 201700:00 | – | nessus | |
| GLSA-201706-15 : WebKitGTK+: Multiple vulnerabilities | 8 Jun 201700:00 | – | nessus | |
| macOS : Apple Safari < 10.1.1 Multiple Vulnerabilities | 23 May 201700:00 | – | nessus | |
| Linux Distros Unpatched Vulnerability : CVE-2017-2536 | 24 Aug 202500:00 | – | nessus | |
| About the security content of iOS 10.3.2 | 15 May 201700:00 | – | apple | |
| About the security content of Safari 10.1.1 | 15 May 201700:00 | – | apple |
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://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42125.zip
# 0day.today [2018-03-17] #Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation