An issue was discovered in Croc through 9.6.5. A sender can cause a receiver to overwrite files during ZIP extraction.
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.
Interactive File Overwrite Prompt can be Circumvented by Sending ZIP file
This is a GitHub Issue
repo:croc
owner:schollz
Title : Interactive File Overwrite Prompt can be Circumvented by Sending ZIP file
Issue date:

--- start body ---
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.
--- end body ---
