2015-08-21 11:35:08 +0200, [email protected]: > Source: openssh > Severity: important > Tags: upstream security > > > According to [1] special crafted filenames containing control characters > can cause scp to execute commands in the current shell. This works also on > copying files from remote (potential untrusted) servers > to local client. > > this works: > remote: > $ touch "ab`tput clear`cd" > > local: > $ scp user@host:"/dir/ab*" . > > which clears the screen in jessie. [...]
To clarify, that does not cause scp to execute commands. That tput command is executed at the time you do $ touch "ab`tput clear`cd" Which just creates a file with a terminal escape sequence in its name. The only "vulnerability" here is that scp will output that file name (in the progress meter) without sanitising those escape sequence. That can only cause commands to be executed if your terminal emulator is vulnerable to code injection via crafted escape sequences (as some were until the mid 2000s (terminology is one that still is AFAICT)). But then, I'd say the vulnerability is in those terminal emulators, not ssh (though, here, the progress meter being meant to be displayed on a terminal, it makes sense for scp to make sure those filenames are displayed in a useful way, so it can be considered as a bug if not an ACE vulnerability). Note that GNU du or find at least doesn't sanitising those escape sequences either (try find . or du -a). ls and a few utilities do when the output goes to a terminal, but not otherwise unless you pass the -q option. So: ls | cat will send those escape sequences to the terminal as well. -- Stephane
