Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Escape Sequences in Filenames are not Filtered #595

Closed
mgerstner opened this issue Sep 8, 2023 · 5 comments
Closed

Escape Sequences in Filenames are not Filtered #595

mgerstner opened this issue Sep 8, 2023 · 5 comments
Assignees
Labels

Comments

@mgerstner
Copy link

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 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.

@mgerstner mgerstner added the bug label Sep 8, 2023
@schollz
Copy link
Owner

schollz commented Sep 20, 2023

Thanks, this would be a great PR to have

@mgerstner
Copy link
Author

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

@aspann
Copy link

aspann commented Feb 3, 2024

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

@schollz schollz self-assigned this May 20, 2024
@schollz
Copy link
Owner

schollz commented May 20, 2024

fixed in this commit: a591833

discuss in #697

@schollz schollz closed this as completed May 20, 2024
@mgerstner
Copy link
Author

This problem is still incompletely addressed due to the fact that the offending filename is still written to stdout, even if transmission is then stopped:

    return true, fmt.Errorf("invalid filename detected: '%s'", fi.Name)

This is an example how CSI escape sequences can still trigger on the receiver side:

touch `echo -e "\033[?1047h"`
croc send *1047h

On the receiving side the error text from the line above will appear, and the CSI escape sequence will be executed, causing the terminal to switch to the "alt screen".

Fixing this should be simple: Don't output the problematic path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants