openssh bugs - May 2024 - [Bug 3693] New: Is SFTP local command execution implemented based on an RFC protocol?

https://bugzilla.mindrot.org/show_bug.cgi?id=3693

            Bug ID: 3693
           Summary: Is SFTP local command execution implemented based on
                    an RFC protocol?
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: sftp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: rmsh1216 at 163.com

Hi,
As we all known, we can execute some commands in local shell  or escape
to local shell by using '!'. However, I can't find the description
in
ssh protocols. If this feature is implemented based on an RFC protocol?
Please let me know if it is. Thanks.

Also, is there a security issue involved?

For example, when the expect script is used to implement SFTP automatic
interaction, the server can construct a specific banner to deceive the
expect script and execute the client script.
More specifically, the expect script looks for the password keyword to
enter the user's password.
If there is a executable script named "!test" on the client. The
password of this account on the server is also "!test", the server
allows login to accounts with empty password strings and the keyword
"password" is added to the banner. The password in the banner will be
captured by the expect script and then the password "!test" will be is
entered. In this case, local script willed executed.

I don't know if this is a problem, although it seems to be a normal
function of sftp and the server in this case is not trusted.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3693

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
No, it's not based on the protocol because it's local only.

How could a server exploit this? There's no way for sftp to pass server
output to its command input unless the user explicitly configures it.

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=3693

--- Comment #2 from renmingshuai <rmsh1216 at 163.com> ---
(In reply to Damien Miller from comment #1)
> No, it's not based on the protocol because it's local only.
> 
> How could a server exploit this? There's no way for sftp to pass
> server output to its command input unless the user explicitly
> configures it.
It is not sftp that passes the server output to its command input. The
user's expect script captures the keyword "password" in the
server's
banner, and then input "!test" to sftp command input.
For example:
spawn sftp username at Host
expect {
"*assword*" {send --"! test\r"}
}

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3693

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
I'm still not understanding. How is this an exploit? This looks like
something the user has configured themselves.

-- 
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.

https://bugzilla.mindrot.org/show_bug.cgi?id=3693

--- Comment #4 from renmingshuai <rmsh1216 at 163.com> ---
(In reply to Damien Miller from comment #3)
> I'm still not understanding. How is this an exploit? This looks like
> something the user has configured themselves.
This is really user configured themselves. The user write the expect
script to interact with the sftp. The direct cause of this problem is
that the expect script incorrectly matches the keyword from banner
message. Is the client allowed to provide an new option to allow user
to explicitly disable the display of banners from the server? This is
in accordance with section 5.4 of rfc4252. If it's allowed, I can
provide the new option.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.