[
https://issues.apache.org/jira/browse/GUACAMOLE-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-2291:
-------------------------------------
Component/s: Documentation
(was: guacamole-docker)
> TOFU for RDP certificates not persisted when running guacd in Docker in its
> default config
> ------------------------------------------------------------------------------------------
>
> Key: GUACAMOLE-2291
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2291
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation
> Reporter: Per von Zweigbergk
> Priority: Major
>
> I would like to bring to attention a potential security vulnerability in
> guacd, when deployed in Docker in accordance with official instructions.
> The [Installing Guacamole with
> Docker|https://guacamole.apache.org/doc/gug/guacamole-docker.html] page
> documents how to run guacd. To summarize, it expects you to run guacd and not
> perform any mounts or attach any volumes, effectively treating guacd as a
> stateless application.
> Unfortunately, this isn’t exactly true when running guacd in an environment
> that uses RDP connections and uses the cert-tofu option. In this mode, guacd
> will perform TOFU (Trust On First Use) certificate validation when connecting
> to the backend RDP server. It appears that this is stored as a flat file in
> the path /home/guacd/.config/freerdp/known_hosts2 inside the Docker
> container. (It is very similar in concept to the “known_hosts” file used by
> OpenSSH.) This means that the file ends up only being stored inside of the
> container itself, and it not persisted if the container is re-created.
> The risk here is that, if the guacd container is re-deployed for any reason,
> such as a software upgrade, either of guacd itself, or updating the container
> image to update any dependencies, the known_hosts2 file will be non-existent
> or empty, which means that there is an opportunity for a MITM attack to
> happen if an attacker is in the position to redirect the connection to the
> back-end RDP server. This could lead to compromise of user credentials,
> session hijacking, session sniffing, etc.
> There are a few possible approaches here:
> # The Docker container documentation could be updated to support mounting
> /home/guacd/.config/freerdp/known_hosts2 as a volume or similar, in order for
> this to persist across container re-deployment.
> # The known_hosts2 file could be backed up by guacamole-server and persisted
> in the postgres database.
> # Guacd running in the docker container, or an appropriate startup script,
> could try to detect if the known_hosts2 is externally mounted or not (perhaps
> by checking mtab), and throw up a warning or an error message if it’s not
> connected to an external volume.
> Since this is issue has security implications, including a MITM risk, I
> initially raised this to the private security e-mail list, and I received the
> following response from Nick Couchman:
> {quote}Per,
> Thanks for raising this issue with security implications privately to the
> security@ list. We appreciate your following responsible disclosure practices
> for this.
>
> I definitely see your point, here, and agree that the documentation should be
> updated to document the potential of mounting a FreeRDP known_hosts2 (and
> possibly equivalent files for SSH) so that those known identities persist
> across updates of containers. It may also be worth just putting some stronger
> overall warnings on the TOFU method of certificate/identity trust. This isn't
> necessarily a Guacamole-specific issue - any situation where you have the
> potential to wipe out a known_hosts file and have to start from scratch
> represents a risk that you'll end up connecting to a host that isn't the one
> you think it is. It may be easier in a containerized environment as with
> guacd, but certainly is not limited to it.
>
> Finally, in order for an attacker to use this to compromise a system, they
> would either have to time things just right, knowing the timing of a swap of
> the container, they'd have to have some knowledge of the system(s) to which
> the users are connecting, and they'd have to be able to effectively redirect
> the guacd instance to a MITM system. Certainly these things are _possible_,
> it just becomes very difficult to line up all the required pieces in a window
> without raising suspicion and have several things fall perfectly into place.
>
> Overall, I'd say it is safe to just open a Jira issue for the changes and
> then open a pull request against the manual to update the dumentation.
>
> -Nick
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
