Shared Secret Passed on Command Line Possibly Leaks to other Local Users

[mgerstner]

On the sender side a custom shared secret can be specified via the croc send --code <SECRET> command line. On the receiver side the shared secret, custom or not, is typically passed on the command line using the croc <SECRET> command line . The latter invocation variant is actively advocated by the output displayed on the sender side like:

On the other computer run

croc <SECRET>

By passing the shared secret on the command line it will become visible on the host's process list for all local users (on Linux and most UNIX like systems). On a multi user system this might allow other local users to get knowledge of the shared secret and to receive the files instead of the intended recipient.

To fix this, the shared secret should be read from stdin, a local file or an environment variable, even though it will be less intuitive than passing it on the command line.

[furicle]

Isn't that knowledge only available AFTER the intended receiver starts receiving the file?

[mgerstner]

Isn't that knowledge only available AFTER the intended receiver starts receiving the file?

It is a race condition. The command line will be visible in the process list as soon as the process is created by the kernel. The connection to the relay will not have been created yet. A local attacker that knows what to look for can try to be faster in connecting to the relay and thus "steal" the files. There is no guarantee that it works - as usual with race conditions - and there is only one shot available.

It would be worse if custom password is used by the sender and is also reused, because then the obtained information will be valid for multiple transmissions.

[mgerstner]

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

[aspann]

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

[schollz]

continue discussion on #701