Security considerations for discovery mode only

[aleasto]

Hi, thank you for including some security considerations in the README and man-page.

Do I understand correctly that the attack vector here would be RCE, either from a LAN or from the outside?
Is wsdd running in discovery mode only (--no-host --discovery) equally at risk?

GNOME GVFS daemon is now using wsdd to discover Windows machines in the local network.
This is the full command-line: https://gitlab.gnome.org/GNOME/gvfs/-/blob/26e350041dcc5c3dfdad3516c0fdc45a114ed851/daemon/gvfswsddservice.c#L454

Can you comment on the security implications of GNOME's usage of wsdd?

Thanks!

[christgau]

The section from the readme exists from the very beginning, where only host-mode was available in wsdd. And the primary intention was to make clear that this implementation of the WSD protocol does not provide (additional) security features, e.g. support for https. It the time the README was written, there were also no security features, like chroot or privilege dropping, which are implemented for a while already. In that sense, the README deserves an update. RCE was not considered when the README was written. I assume, that (if possible) RCE might be a consequence of the (standard) Python libraries that are employed.

As for security of the host mode: it may be possible to trigger traffic amplification attacks (see #48), but I never followed that up to do an analysis.

Regarding, discovery (only) mode: Essentially, the same as for host mode applies. RCE might be an issue, if any of the underlying libraries is vulnerable to it. In the end, a lot of things happen here: HTTP and XML parsing, If there is anything wrong with that, wsdd will be affected as well. That being said, it would be interesting if somebody volunteers and does a fuzzing test or even an audit.

The command line parameters from GVFS look good as they limit functionality to discovery mode only. chroot may be used to add a (thin) layer of security, but requires the process to have according capabilities. One may even consider to launch a per-system instance of the daemon which is restricted by chroot + runs as a different user. At least, this would limit impact in case a RCE strikes.