An issue was discovered in Croc through 9.6.5. A sender may place ANSI or CSI escape sequences in a filename to attack the terminal device of a receiver.
Filenames on Linux can contain arbitrary characters except for the path separator '/'. Thus filenames can also contain possibly dangerous characters like ASCII control codes (newline, linefeed, etc.) or even complete ANSI/CSI terminal escape sequences.

On the Croc receiver side the filenames communicated by the sender side are accepted unfiltered and are also output on stdout during transmission. When the latter happens, the escape sequences are interpreted by the receiver's terminal and can lead to colored text, moving the cursor around or - if an [insecure terminal emulator setup](https://www.openwall.com/lists/oss-security/2017/05/01/13) is used - even arbitrary code execution can be achieved.

In particular this issue is a nice addition to issues #593 and #594, since it allows to hide filenames of previously transmitted files on stdout, therefore making the attack less conspicuous. This is an example of how this can be done:

    # this moves the cursor up one line and performs a carriage return, thus
    # overwriting the previous line on the terminal
    sender $ touch "`echo -e '\033[1A\rharmless'`"
    sender $ touch "evil"
    sender $ croc send evil *harmless
    [...]

    receiver $ croc <shared-secret>
    receiver $ Accept 2 files (0 B)? (Y/n) Y

    harmless 100% |████████████████████| ( 0/ 1 B) 2/2

An interactive user will only see the "harmless" file, probably not noticing that a file seems to be "missing" in the output.

To fix this Croc should filter filenames on the receiver side and either reject or replace any unsafe non-printable characters.

Escape Sequences in Filenames are not Filtered
This is a GitHub Issue
repo:croc
owner:schollz
Title : Escape Sequences in Filenames are not Filtered
Issue date:

--- start body ---
Filenames on Linux can contain arbitrary characters except for the path separator '/'. Thus filenames can also contain possibly dangerous characters like ASCII control codes (newline, linefeed, etc.) or even complete ANSI/CSI terminal escape sequences.

On the Croc receiver side the filenames communicated by the sender side are accepted unfiltered and are also output on stdout during transmission. When the latter happens, the escape sequences are interpreted by the receiver's terminal and can lead to colored text, moving the cursor around or - if an [insecure terminal emulator setup](https://www.openwall.com/lists/oss-security/2017/05/01/13) is used - even arbitrary code execution can be achieved.

In particular this issue is a nice addition to issues #593 and #594, since it allows to hide filenames of previously transmitted files on stdout, therefore making the attack less conspicuous. This is an example of how this can be done:

    # this moves the cursor up one line and performs a carriage return, thus
    # overwriting the previous line on the terminal
    sender $ touch "`echo -e '\033[1A\rharmless'`"
    sender $ touch "evil"
    sender $ croc send evil *harmless
    [...]

    receiver $ croc <shared-secret>
    receiver $ Accept 2 files (0 B)? (Y/n) Y

    harmless 100% |████████████████████| ( 0/ 1 B) 2/2

An interactive user will only see the "harmless" file, probably not noticing that a file seems to be "missing" in the output.

To fix this Croc should filter filenames on the receiver side and either reject or replace any unsafe non-printable characters.

--- end body ---
