[
https://issues.apache.org/jira/browse/GUACAMOLE-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reopened GUACAMOLE-2305:
------------------------------------
> Sensitive connection parameter values streamed via "argv" are shown in the UI
> -----------------------------------------------------------------------------
>
> Key: GUACAMOLE-2305
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2305
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
> Reporter: Ciro Iriarte
> Priority: Minor
>
> When the server streams a connection parameter back to the client through an
> "argv" stream, {{ManagedClient}} reflects the received value into the
> UI-visible
> arguments model, which backs the connection parameters panel.
> There is no filtering by parameter name, so when the streamed parameter holds
> a
> secret -- a password, a passphrase, a private key -- the value becomes
> readable
> by any user able to view that connection. This matters most where a
> connection is
> configured centrally with credentials the user is not otherwise meant to see.
> This is a display concern only. Mutating an immutable argument toward guacd is
> already rejected server-side, so the issue is what a user can *read*, not what
> they can send.
> h3. Proposed fix
> Skip reflection for parameter names matching
> {{password|passphrase|private-key|client-key|secret|token}}, case-insensitive.
> Public material ({{host-key}}, {{public-key}}, {{pubkey}}) is deliberately not
> matched, since it is not secret and is useful to display.
> Patch is one file, 20 lines added, applies cleanly to current main.
> h3. Open questions
> # *Is the client the right layer?* Filtering in the web application is
> defence-in-depth. If guacd should not be streaming sensitive values back at
> all,
> the durable fix belongs there and this becomes a belt-and-braces measure. I do
> not know whether any protocol relies on streaming these back.
> # *Name matching is a heuristic.* {{token}} in particular could match a
> parameter
> that is not secret, and a protocol could name a sensitive parameter something
> the
> pattern misses. An explicit per-protocol flag in the protocol descriptor
> would be
> precise rather than heuristic, at the cost of touching every protocol
> definition.
> The regex is the cheap version; happy to do the precise one instead if
> preferred.
> Found while auditing a SPICE protocol implementation built on Guacamole
> (GUACAMOLE-261). The issue is not SPICE-specific -- it is in shared web
> application code and applies to any protocol that streams parameters back via
> "argv".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
