https://bugzilla.mindrot.org/show_bug.cgi?id=2283
kpcyrd <kpc...@archlinux.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kpc...@archlinux.org
--- Comment #12 from kpcyrd <kpc...@archlinux.org> ---
There's a writeup on the reproducible-builds mailing list from
September 2023 that (ab-)uses this ssh quirk as an example
underhanded-eval gadget (the rest of that writeup is not relevant to
this issue):
https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/003075.html
There's a missed opportunity in that writeup because even when passing
the output of `git describe` through it's own argument it's going to
get remotely eval'd:
ssh 'some-server' './foo.bin' '--' '$(id>pwned)'
While it's true that ssh is not a programming language, with
command-line interfaces there's usually an assumption that you can
trivially pass opaque strings from one program to another, this is not
the case with ssh however. A user would usually expect this to be
executed as:
./foo.bin '--' '$(id>pwned)'
on the remote server, with all bytes passed as-is to argv and no
shell-eval taking place. In shell scripting, this would be considered
safe-and-sound to pass opaque data:
./foo.bin -- "$@"
However, this is not and might get you hacked:
ssh 'some-server' -- ./foo.bin -- "$@"
> I'm looking for an example of something that could be done with what you're
> asking for but can't be done other ways.
If I made an eval-based json parser I could argue it's the caller's
fault and safe use of my function "can be done" if you try hard enough.
I understand the compatibility concerns, but please reconsider.
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
