openssh bugs - Jun 2021 - [Bug 3318] New: Read-only mode broken by limits@openssh.com extension

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

            Bug ID: 3318
           Summary: Read-only mode broken by limits at openssh.com extension
           Product: Portable OpenSSH
           Version: 8.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: sftp-server
          Assignee: unassigned-bugs at mindrot.org
          Reporter: marcan at marcan.st

limits at openssh.com is marked as does_write=1, which causes the client
to break when the request is denied, printing a cryptic error message.

$ sftp <server...>
Expected SSH2_FXP_EXTENDED_REPLY(201) packet, got 101

It's really hard to get logs out of the server in internal-chroot mode,
but strace shows:

[pid 133138] write(2, "Refusing limits request in read-only mode\r\n",
43) = 43

I don't see why the extension should be restricted in read-only mode.
The client should probably also not just break and abort when this
happens.

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Marking the limits extension as needing write is indeed a bug, but the
extension should simply not be offered in this case. E.g.
> Refusing limits request in read-only mode
> debug2: compose_extension: refusing to advertise disallowed extension
limits at openssh.com
And the client should therefore never request it.

How is your sftp-server configured?

-- 
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=3318

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
btw you can get more logs from sftp-server by putting "-l debug3" on
it's command-line arguments in sshd_config, though you may need to
adjust your syslog configuration to accept debug messages.

-- 
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=3318

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |3302

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
anyway, I have fixed the server bug that caused limits@ to be
considered a write operation and have made the client degrade
gracefully when the server advertises but fails to accept it.

I'd really like to understand how you hit this condition though, as it
might be an indication of another bug there.


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3302
[Bug 3302] Tracking bug for openssh-8.7
-- 
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=3318

--- Comment #4 from Hector Martin <marcan at marcan.st> ---
Argh, you're right. What happened is the server is 8.5p1. I was very
confused, because limits was mentioned in the release notes fir 8.6. It
seems this is a mistake in the release notes; the feature was already
in the server in 8.5p1, just buggier. 8.5p1 does *not* do the check
before advertising extensions, it just unconditionally advertises them
all, hence the problem.

The 8.6p1 client's new support then made this visible, and I confused
myself with the release notes (and I thought I had upgraded the server
already), since why would a non-8.6 server advertise a feature that the
release notes claim was introduced in 8.6? :-)

Indeed the issue does not happen with 8.6 -> 8.6, just 8.6 -> 8.5.

-- 
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=3318

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
ah, that makes more sense - sftp-server in openssh 8.5 didn't filter
advertisements based on its configuration. Thanks for chasing it down.

Anyway, both the client and server side are fixed now. Updating the
server to 8.6 works around the problem too because it will refuse to
advertise it in read-only mode.

-- 
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=3318

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
closing bugs resolved before openssh-8.9

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