Interactive File Overwrite Prompt can be Circumvented by Sending ZIP file

[mgerstner]

As mentioned in issue #593 there is a check on the receiver side of Croc whether an incoming file path will overwrite an existing file, and Croc will ask the user interactively whether it should be overwritten, if it already exists. This check works reasonably well, even if symlinks are involved. I did not look that deep into this though - due to the following finding I stopped spending time on finding further possible ways around the restriction. There might still be attack surface to be found in the parallelism of the chunk transfer (exploiting race conditions) or by aptly crafting the file metadata.

There is a loophole in conjunction with the transparent ZIP transfer option though (croc send --zip). The sender alone decides if something will be zipped or not (somewhat confusingly flagged by the FileInfo.TempFile flag).

The receiver will take whatever data has been transferred and will try to unzip it. This way even the overwrite check can be overcome, by placing creative paths into the ZIP archive. Even relative paths like ../../.ssh/authorized_keys can be placed in the ZIP archive. The unzip operation will silently overwrite existing files.

When combined with issue #593 then a potential attacker has a lot of freedom to attempt to trick the receiving party into harming its system.

If an isolation technique as outlined in issue #593 is implemented, then the consequences of overwriting files should be less problematic - although it could still be surprising if previously downloaded files are overwritten with something else. As an additional protection measure only the receiver should decide whether ZIP files are handled, or not. Better controlling the unzip process to prevent overwrites would also be helpful. The safest approach would be to use a pristine empty directory for each new file transfer where nothing can be overwritten in the first place.

[schollz]

Thanks, this would be a great PR to have

[mgerstner]

Mitre assigned CVE-2023-43616 to track this issue.

[aspann]

Shouldn't CVE-2023-43616 cover 9.6.6 as well?

[schollz]

continue discussion on #698