3 ms·
> 2. CWE-20: scp client missing received object name validation [CVE-2019-6111] > Due to the scp implementation being derived from 1983 rcp [1], the server cho
by jolmg 8y ago
> 2. CWE-20: scp client missing received object name validation [CVE-2019-6111]
> Due to the scp implementation being derived from 1983 rcp [1], the server chooses which files/directories are sent to the client. However, scp client only perform cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example overwrite .ssh/authorized_keys).
I don't understand why this is considered a vulnerability. The user provides scp server-side shell code to describe the files it wants. How's it supposed to verify object names then? Am I the only one that likes to do things like the following?[1]:
scp server:'$(ls -t | head -1)' .
or
scp server:'*.pdf' .
An argument could be made to have scp implement a glob pattern matcher, but that wouldn't be shell agnostic (I doubt we'd get support for zsh-style `*.pdf(oc[1,5])`) and it wouldn't include support for process substitution or any other way the user might want to specify files.
scp already describes the files it's writing to stdout. I don't see what more it can do without sacrificing usability.
The possibility of a compromised server writing things that have nothing to do with what I asked just seems like an acceptable consequence for the power scp provides.
[1] - Please, discussions about parsing ls output are besides the point, right now. Heuristics are useful too, at times, for ad-hoc portable practices.
- rtkwe 8y agoAt the very least the client could perform a check that the files it's receiving match the pattern it sent in the request by using a regular expression replacing * with an non-whitespace+forbidden character. It doesn't even check that if you request a single file like readme.txt that it receives a single file!
- jolmg 8y agoIf you write: scp server:readme.txt . "readme.txt" is still shell code. Most shells will evaluate it to the string "readme.txt", but scp on the client should not make assumptions of the shell used on the server. If you write: scp server:'*.txt(oc[1,10])' . A server that's setup with zsh with extended globs is going to return the newest 10 .txt files. If scp is written with an expectation of basic globs, I imagine it would try to match the files that have a character-by-character literal extension of ".txt(oc[1,10])". That means no file is ever going to match. You could say, "well, add recognition of zsh extended globs". Ignoring how complicated that really is because there are glob options that allow you to embed arbitrary zsh code, you're limiting the implementation of scp to work with only particular shells. scp should not be a barrier to me implementing my own shell, with it's own syntax and using it transparently. The current scp doesn't care about what shells you use where. It makes little to no assumptions of the tools you use, and that's cool.
- blattimwind 8y agoClassic langsec failure.
- jolmg 8y agoCan you expand on that? I can't tell if you're in favor or against a change.
- blattimwind 8y agoWell the language scp uses for selecting files is turing complete and relies on state unavailable to the client therefore it is impossible in the general case for the client to check whether a given file sent by the server was actually requested by itself. That's the langsec failure here. The "correct" (in any case more sane) approach would be to use a stateless, easily recognizable language for specifying files (e.g. something that reduces to REs).
- jolmg 8y agoAnd that's what I meant by saying that I couldn't see what else to do without sacrificing usability. Whatever that language you propose would be, if it doesn't allow use of state from the server, then it's pointless. You may as well use the local shell in scp's invocation.
- teacpde 8y ago> Due to missing character encoding in the progress display, the object name can be used to manipulate the client output, for example to employ ANSI codes to hide additional files being transferred. The server description could be a subset of objects it writes to local.
- jolmg 8y agoOk. For that, I think it would be apt for scp to somehow quote the filename when it contains a non-printable character, escaping the non-printable characters, thereby avoiding their interpretation as ANSI codes.