vncviewer: prevent SSH option injection via -via gateway argument

[acts-1631]

The via parameter (from CLI, GUI, or a loaded .vnc config file) is
passed to ssh as a bare positional argument inside createTunnel()'s
default command template. A value starting with "-" is parsed by
ssh as an option rather than a hostname, so via=-oProxyCommand=
causes ssh to run an arbitrary command through ProxyCommand.

Shell quoting of "$G" only prevents shell metacharacter/word-splitting
issues, it does not stop ssh's own option parsing from treating the
value as an option.

This inserts "--" before the expanded gateway host so ssh stops
parsing options at that point and treats the remainder strictly as
the destination, closing off the option-injection path.

Tested by setting the via value to -oProxyCommand= and
confirming the command executes before the fix and is rejected
by ssh as an invalid hostname after the fix.

[CendioOssman]

Thanks. Good find!

The -via parameter is only available via the command line, though. Which makes this less of an issue.

Could you update the commit message to reflect that?

Isn't there a potential issue with remoteHost as well?

[acts-1631]

Updated the commit message to clarify that -via is CLI-only.

I also checked remoteHost. It is embedded in the single argument to -L, so a leading - is parsed as the forwarding destination hostname, not as an SSH command-line option.

[CendioOssman]

Can't you trick it into splitting the -L argument, though? E.g. if you set remoteHost to something like " -oProxyCommand=foo.

[acts-1631]

I tested that payload. Since $H expands inside an already double-quoted word, quote characters in its value are not reinterpreted by the shell. It remains a single -L argument, e.g. 5000:" -oProxyCommand=foo:5900, which SSH parses as the forwarding destination rather than a command-line option.

[CendioOssman]

Great. Thanks for checking!