openssh unix dev - Jul 2023 - Subsystem sftp invoked even though forced command created

On 05.07.23 18:01, MCMANUS, MICHAEL P wrote:
> It appears the forced command either does not run or runs to completion
> and exits immediately, as there is no process named "receive.ksh"
in
> the process tree.
FWIW, two cents of mine:

-- The script *exiting* should *not* prompt sshd to execute the 
requested subsystem "as a second thought", or else it'd happen all
over
the place.

-- The process' cmdline would state the shell executing the script (ksh, 
I suppose?) rather than the script file.

In the meantime, I received an (off-list) e-mail pointing out that your 
script obviously accepts input from stdin (note the "-T" given to ssh,
so no tty):
>> The actual command is similar to the following (parameters inserted to
protect the source):
>>         (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
>>         ssh -Ti ${EmbeddedPrivateKey} ...
and that it's conceivable that WinSCP might send a command line 
executing sftp-server, just in case the server provides it with a login 
shell instead of calling the SFTP subsystem directly; Hence the theory 
that the script has some command injection vulnerability.

Does the exploit still work when you change the authorized_keys from
	command="/.../receive.ksh"
to, e.g.,
	command="/bin/ksh -c '/.../receive.ksh </dev/null'"
to suppress the client's input?

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20230706/5dcfee75/attachment.p7s>

The forced command actively uses the client's input to feed data to the
server (it constructs a file name from the information supplied by the client).
So changing the forced command as stated will break the application. I would
need to create a test bed to simulate the listener rather than use the server as
is, where is. That may produce false or misleading results.

A pseudocode description of the forced command follows:
	Read one line from stdin and store to $FQDN.
	Read one line from stdin and store to $ENVIRONMENT.
	Construct a temporary and a permanent file name using the system date, process
ID, $FQDN, and $ENVIRONMENT.
	Slurp up (dd) all remaining data from stdin and store in the temporary file
name constructed in the previous step.
	Perform some textual cleanup on the temporary file.
	Save the cleaned-up file to the permanent file name.
	Emit a success message to stdout.

Obviously there is also error handling, which emits error messages to stdout.
But WinSCP is giving no indication that anything has been sent to it during the
session setup.

Oddly enough, the same behavior occurs when the embedded key is used to launch
an interactive sftp session from the host running the legitimate client:
# sftp -i ${embeddedKey} ${user}@${host}
<Standard warning from /etc/issue.net>
Connected to ${host}.
sftp> ls
README              collectors          receive-data.ksh    tmp
sftp> ^D
So we can probably write off any idiosyncrasies of WinSCP and work only with
OpenSSH. Note there is no output from the script whatsoever.

Mike McManus
Principal ? Technology Security
GTO Security Governance Team - Unix
P: He/Him/His

AT&T Services, Inc.
20205 North Creek Pkwy, Bothell, WA 98011
michael.mcmanus at att.com  

-----Original Message-----
From: Jochen Bern <Jochen.Bern at binect.de> 
Sent: Thursday, July 6, 2023 4:20 AM
To: openssh-unix-dev at mindrot.org
Cc: MCMANUS, MICHAEL P <mm1072 at att.com>
Subject: Re: RE: Subsystem sftp invoked even though forced command created

On 05.07.23 18:01, MCMANUS, MICHAEL P wrote:
> It appears the forced command either does not run or runs to completion
> and exits immediately, as there is no process named "receive.ksh"
in
> the process tree.
FWIW, two cents of mine:

-- The script *exiting* should *not* prompt sshd to execute the 
requested subsystem "as a second thought", or else it'd happen all
over
the place.

-- The process' cmdline would state the shell executing the script (ksh, 
I suppose?) rather than the script file.

In the meantime, I received an (off-list) e-mail pointing out that your 
script obviously accepts input from stdin (note the "-T" given to ssh,
so no tty):
>> The actual command is similar to the following (parameters inserted to
protect the source):
>>         (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
>>         ssh -Ti ${EmbeddedPrivateKey} ...
and that it's conceivable that WinSCP might send a command line 
executing sftp-server, just in case the server provides it with a login 
shell instead of calling the SFTP subsystem directly; Hence the theory 
that the script has some command injection vulnerability.

Does the exploit still work when you change the authorized_keys from
	command="/.../receive.ksh"
to, e.g.,
	command="/bin/ksh -c '/.../receive.ksh </dev/null'"
to suppress the client's input?

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH