Problems using RemoteForward for gpg-agent with multiple sessions

[Brandon Cheng]

Hi Damien,

I was wondering if you had any further thoughts or if this isn't
solvable without significant tradeoffs. I'm still happy to implement any
of the suggestions and submit patches. I think I prefer the most
recently mentioned $SSH_REMOTE_FORWARD_SOCKS_DIR approach.

Thanks for your time.

> On Jun 14, 2022, at 12:48 AM, Brandon Cheng <brandon at brandoncheng.me> wrote:
>
> On Mon, 13 Jun 2022, Damien Miller wrote:
>
>> On Fri, 10 Jun 2022, Brandon Cheng wrote:
>>> To complete this option, how might the server determine the unique
>>> path? I'm leaning towards SetEnv and updating it to understand
>>> %-expansions. (If it doesn't already.)
>>>
>>>  Host example
>>>    RemoteForward /tmp/%R.sock /home/local/.gnupg/S.gpg-agent.extra
>>>    SetEnv SSH_R_EXPANSION=%R
>>
>> I think that could be made to work - we'd need ssh's main() to
>> generate a single random token per connection, though it might be
>> possible for a user to shoot themselves in the foot if they reused
>> the token for multiple things and exposed it to an on-host attacker.
>> We generally avoid leaving footguns around.
>
> I think you're right. Although the random token derived socket paths
> don't need to be secret for this use case, I could see users relying on
> the random token for other use cases requiring secrecy.
>
> Thanks for keeping security in mind. Although this could work, I'd
> be nervous about creating a new common pattern of security
> vulnerabilities.
>
> On Mon, 13 Jun 2022, Damien Miller wrote:
>
>> Another option: remote port-forwarding has a notion of
>> server-allocated ports, that are communicated back to the client. We
>> could do something similar for Unix domain sockets too, but with a
>> server-generated /tmp path instead of a port.
>
>> The downside is that this is only really useful when used in
>> conjunction with ControlPath, and they take a fair bit more connection
>> setup.
>
> Does the server-generated path need to be communicated back to the
> client? Taking a spin on the "Possibility 1: New RemoteForward syntax"
> suggestion from the first email, could the server-generated tmp path be
> placed in an $SSH_REMOTE_FORWARD_SOCKS_DIR environment variable?
>
>  Host example
>    RemoteForward 0:example-foo /home/local/.foo.sock
>    RemoteForward 0:example-bar /home/local/.bar.sock
>
>  $ ssh example
>  $ echo $SSH_REMOTE_FORWARD_SOCKS_DIR
>  /tmp/ssh-UIzrILLqkZ
>  $ ls -l $SSH_REMOTE_FORWARD_SOCKS_DIR
>  example-foo.sock
>  example-bar.sock
>
> Some immediate caveats I can think of:
>
>  - This deviates from the TCP port behavior, which can be surprising.
>  - All forwarded sockets share the same server-generated path. Is this
>    a security concern? I think any unique path -> envvar approach would
>    leak RemoteForward socket paths to on-host attackers anyway, even if
>    each RemoteForward had a unique environment variable. By design this
>    is intentionally available to on-host processes.
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev