Bugzilla Bug 119232

Patch on referenced URL.

----

scp currently implements local-to-local copy by constructing a command line
using 'cp' in a string and then using system(). It has the problem that the
file
name is exposed twice to shell expansion. The file name could contain
characters
which need quoting, like $ or spaces. This second expansion must be avoided.

Steps to Reproduce:
1.touch foo\ bar
2.mkdir somedir
3.scp foo\ bar somedir

Actual results:
cp: cannot stat `foo': No such file or directory
cp: cannot stat `bar': No such file or directory

This can be even a security issue although with a fairly low severity:
bress@link:/tmp/josh% ls -l
total 4
drwxrwxr-x  2 bress bress 4096 Sep 19 14:51 a
-rw-rw-r--  1 bress bress    0 Sep 19 14:51 `touch feh`
bress@link:/tmp/josh% scp * a
cp: omitting directory `a'
cp: missing destination file
Try `cp --help' for more information.
zsh: exit 1     scp * a
bress@link:/tmp/josh% ls -l
total 4
drwxrwxr-x  2 bress bress 4096 Sep 19 14:51 a
-rw-rw-r--  1 bress bress    0 Sep 19 14:52 feh
-rw-rw-r--  1 bress bress    0 Sep 19 14:51 `touch feh`

Proposed solution: replace system() with fork+exec()

AFAIR dropbear uses the same code for scp, vapier please advise.

Not sure this should be considered a bug. Sounds like a feature to me.

(In reply to comment #2)
> Not sure this should be considered a bug. Sounds like a feature to me.

This sounds like a feature to me also. I'd say we should wait on upstream and
see if they move on it.

user isnt reporting that expansion is bad, he's reporting that it gets expanded
twice ... which looks like a bug to me

OK, I'll rephrase. That doesn't sound like a vulnerability to me. More a buggy
feature. Quoting Solar Designer: "Anyone passing untrusted input onto scp's
command line is asking for trouble."

Also from vendor-sec, it appears to be the OpenSSH project position as well :
not a vulnerability and scp can't be fixed.

Secunia Advisory: SA18579

TITLE:
OpenSSH scp Command Line Shell Command Injection

SECUNIA ADVISORY ID:
SA18579

RELEASE DATE:
2006-01-24

VERIFY ADVISORY:
http://secunia.com/advisories/18579/

CRITICAL:
Not critical

WHERE:
Local system

IMPACT:
Privilege escalation

SOFTWARE:
OpenSSH 3.x
OpenSSH 4.x

DESCRIPTION:
Josh Bressers has reported a weakness in OpenSSH, which potentially can be
exploited by malicious, local users to perform certain actions with escalated
privileges.

The weakness is caused due to the insecure use of the "system()" function in
scp when performing copy operations using filenames that are supplied by the
user from the command line. This can be exploited to execute shell commands
with privileges of the user running scp.

Successful exploitation requires that the user is e.g. tricked into using scp
to copy a file with a specially crafted filename.

The weakness has been confirmed in version 4.2p1. Other versions may also be
affected.

SOLUTION:
Do not use scp to copy files containing potentially malicious filenames.

Some Linux vendors have issued updated packages.

REPORTED BY CREDITS:
Josh Bressers

ORIGINAL ADVISORY:
Red Hat Bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174026

Secunia Advisory: SA18579

fyi fedora patched their openssh:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168167

base-system please advise.

as i said on irc, i think it's safe to just wait for upstream to either accept
or reject the change

openssh 4.2p1-r1 in portage with patch from upstream cvs

vapier, what about dropbear? afair it uses the same code for scp.

tweaked the patch to work with dropbear and added 0.47-r1

Arches please test and mark stable.

glad this got fixed, finally i can use bash completion again when scp'ing my
mp3s from one box to another ;)

amd64 stable

sparc'em.

x86 done

Stable on hppa

both stable on alpha.

dropbear marked ppc stable

ready for glsa vote, i say yes.

stable on ppc64

I tend to vote YES.

It seems the "scponly" package is also affected (no wonder) ... somebody care
to comment?

Matsuu, you seem to be scponly maintainer, any comment regarding comment #24 ?

mips stable on openssh & dropbear.

scponly looks OK to me. In all cases it would be a different bug/CVE since teh
codebases are quite different. Please submit any evidence into a new bug.

Ready for GLSA

GLSA 200602-11