r3pek/CVE-2021-40444
1
0
Fork 0
mirror of https://github.com/klezVirus/CVE-2021-40444.git synced 2024-11-21 13:00:48 +00:00
Code Releases Activity

Updated comments on the vulnerability

Browse source
This commit is contained in:
d3adc0de 2021-10-13 00:04:14 +01:00
parent 7d0e32466e
commit 2d64e9c760
1 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
README.md
View file

@ -43,25 +43,25 @@ the HTML should be at least 4096 bytes in size in order to trigger the "Preview"
The CAB file needs to be byte-patched to avoid extraction errors and to achieve the ZipSlip:
* `filename.inf` should become `../filename.inf`
* `filename.inf` should be exactly `<12-char>.inf`
* `CFFOLDER.typeCompress` should be 0 (not compressed)
* `CFFOLDER.coffCabStart` should be increased by 3
* `CFFOLDER.cCfData` should be 2
* `filename.inf` ~~should be exactly <12-char>.inf~~ Not really true, the important bit is to modify `coffCabStart`
* `CFFOLDER.typeCompress` ~~should be 0 (not compressed)~~
* `CFFOLDER.coffCabStart` should be increased by 3 (due to the added '../'')
* `CFFOLDER.cCfData` ~~should be 2~~
* `CFFILE.cbFile` should be greater than the whole `CFHEADER.cbCabinet`
* `CFDATA.csum` should be recalculated (or zeroed out)
* `CFDATA.csum` ~~should be recalculated (or zeroed out)~~ [OPTIONAL]
The reason for these constraints are many, and I didn't spend enough time to deeply understand all of them, but
let's see the most important:
* **TypeCompress**: If the CAB is compressed, the trick to open it within an object file to trigger the INF write will fail
* **TypeCompress**: ~~If the CAB is compressed, the trick to open it within an object file to trigger the INF write will fail~~ False, I managed to achieve the same result with a MSZIP compressed sample
* **CoffCabStart**: CoffCabStart gives the absolute position of the first CFDATA structure, as we added a '../',
we would need to increase this by 3 to point to the file (this is more like a guess)
* **cCfData**: As there is only 1 file, we should have just 1 CFDATA, I'm not too sure why this has to be set to 2
* **cCfData**: ~~As there is only 1 file, we should have just 1 CFDATA, I'm not too sure why this has to be set to 2~~ Indeed, we can leave it as 1
* **cbFile**: Interestingly, if the CAB extraction concludes without any error, the INF file will be marked for deletion
by WORD, ruining the exploit. The only way to prevent this is to make WORD believe the extraction failed. If the
cbFile value is defined as greater than the cabinet file itself, the extractor will reach an EOF before reading
all the bytes defined in cbFile, raising an extraction error.
* Last but not least, the **csum** value should be recalculated. Luckily, as noted by [j00sean](https://twitter.com/j00sean)
* [OPTIONAL] This value seems to not be checked by MS Word. Anyway, to have a correct CAB, the **csum** value should be recalculated. Luckily, as noted by [j00sean](https://twitter.com/j00sean)
and according to [MS documentation](http://download.microsoft.com/download/4/d/a/4da14f27-b4ef-4170-a6e6-5b1ef85b1baa/[ms-cab].pdf),
this value can be 0
@ -83,7 +83,7 @@ script.
As noted by [Max Maluin](https://twitter.com/Max_Mal_), it is possible to interact with several filetypes abusing IE and
the associated file extension based URI. While this is might be a good way to exploit IE, it has limitations.
Indeed, irtshould be noted that the method used in the exploit to download files is based on ActiveX control updates,
Indeed, it should be noted that the method used in the exploit to download files is based on ActiveX control updates,
and cannot be used to download arbitrary files.
As per Microsoft [documentation](https://docs.microsoft.com/it-it/cpp/mfc/upgrading-an-existing-activex-control?view=msvc-160), the `codebase` tag
can point just to a few filetypes: OCX, INF and CAB.