| #include <stdint.h> | |
| #include <stdio.h> | |
| #include <stdlib.h> | |
| #include <stdbool.h> | |
| #include <windows.h> | |
| #include "nt_crap.h" | |
| #define ArrayCount(arr) (sizeof(arr)/sizeof(arr[0])) | |
| #define assert(expr) if(!(expr)) { *(char*)0 = 0; } |
| """ | |
| 31-round sha256 collision. | |
| Not my research, just a PoC script I put together with numbers plugged in from the slide at | |
| https://twitter.com/jedisct1/status/1772647350554464448 from FSE2024 | |
| SHA256 impl follows FIPS 180-4 | |
| https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf | |
| """ |
| // Sometimes you have a large file on a small disk and would like to "transform" | |
| // it in some way: for example, by decompressing it. However, you might not have | |
| // enough space on disk to keep both the the compressed file and the | |
| // decompressed results. If the process can be done in a streaming fashion, it | |
| // would be nice if the file could be "drained"; that is, the file would be | |
| // sequentially deleted as it is consumed. At the start you'd have 100% of the | |
| // original file, somewhere in the middle you'd have about half of the original | |
| // file and half of your output, and by the end the original file will be gone | |
| // and you'll be left with just the results. If you do it this way, you might | |
| // be able to do the entire operation without extra space! |
Official patch: https://chromium-review.googlesource.com/c/v8/v8/+/4584248
Patch come from KeyedStoreIC::StoreElementHandler(), it returns fast path code(Turbofan builtin) for keyed store depends on "receiver_map" and "store_mode". Based on the content of this function is all about element STORE, I personally believe that this is an OOB writes vulnerability.
If we divide the PoC exploration into two parts based on this func, they are:
MS Office docx files may contain external OLE Object references as HTML files. There is an HTML sceme "ms-msdt:" which invokes the msdt diagnostic tool, what is capable of executing arbitrary code (specified in parameters).
The result is a terrifying attack vector for getting RCE through opening malicious docx files (without using macros).
Here are the steps to build a Proof-of-Concept docx:
Since monterey update does not allow us to use Xcode previous than 13, let's show how to "install previous SDKs"
Swift toolchains, from https://swift.org/download/
Previous Xcode.xip, from the https://developer.apple.com
| // To compile: clang++ -arch x86_64 -arch arm64 -std=c++20 library_injector.cpp -lbsm -lEndpointSecurity -o library_injector, | |
| // then codesign with com.apple.developer.endpoint-security.client and run the | |
| // program as root. | |
| #include <EndpointSecurity/EndpointSecurity.h> | |
| #include <algorithm> | |
| #include <array> | |
| #include <bsm/libbsm.h> | |
| #include <cstdint> | |
| #include <cstdlib> |