mirror of
https://github.com/klezVirus/CVE-2021-40444.git
synced 2024-11-14 09:57:55 +00:00
Updated comments on the vulnerability
This commit is contained in:
parent
7d0e32466e
commit
2d64e9c760
1 changed files with 9 additions and 9 deletions
18
README.md
18
README.md
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue