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
