PoC for CVE-2022-26809, analisys and considerations are shown in the github.io.# PoC-CVE-2022-26809
PoC for CVE-2022-26809, analisys and considerations are shown in the github.io.
The PoC has been writtin overriding Impacket functions.
Tested with: impacket version 0.10.0
The PoC has not been fully tested, because it should trigger the vulnerability,
i.e integer overflow, that leads to a buffer overflow on the heap is reached after 1048576 packets sent, because 1048576\*4096 overflow integer of 32 bits.
Did not found any way to cheat on the size, to me seems that fragment len, that is 16 bits, is checked against the real payload size, they must be coherent.
Limitations:
1. Memory - the mem allocation could fail since the requested must reach 4GB before gaining the overflow, at least this is what I
2. Time - Assuming that the memory is not a problem, i.e. there is sufficient memory in the system and so the allocation could not fail, the overflow is reached, anyway, after a lot of time this is due because the packet's number to send is big and because the processing time of the data increase basing to the memory used.
The project contains the vulnerable and patched version of the rpcrt dll and the RPC Server is here: [RPC Server](https://github.com/s1ckb017/basic-rpc-cli-srv/commit/5d343d154ed444978a21c35f5a68aa43d9fe4517)
Finally, I wrote the PoC at the end of an analisys just to challenge my self and learn a bit more about RPC implementation.
The analisys that led me to write this PoC is on my [GithubPages](https://s1ckb017.github.io/)
[4.0K] /data/pocs/b0d901f8b9bb9ca0de554cc61565878245422fb9
├── [7.6K] PoC_CVE_2022_26809.py
├── [1.5K] README.md
├── [1.1M] rpcrt4_patched_d78a9d416a1187da8550fb0d5a4bace48cfa8179.dll
└── [1.2M] rpcrt4_vuln_b35fdb8d452e39cdf4393c09530837eff01d33c7.dll
0 directories, 4 files