Re: Bug#796314: openssh: copying special crafted filenames executes shell-command

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2015-08-21 11:35:08 +0200, bgrpt3@toplitzer.net:
> 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