Systemd vsock sshd

[Greg Dahlman <dahlman () gmail com>]

This information is to be publicly released on January 6 per requirements
of the distro list.

This most likely impacts all recent VMs on most modern hypervisors.

Thanks,

Greg Dahlman


Overview
********

  **Systemd v256 change** - When the *openssh-server* package is
  installed on a VM with vsock support, systemd now automatically
  starts an *sshd* instance that listens on the **af_vsock** socket in
  the **global network namespace** without any manual configuration.

  **vsock exists in the global namespace** - Unlike "af_inet" sockets,
  vsock connections are not bound to a particular network namespace.
  By default they are visible to every namespace on the host.

  **Violation of namespace isolation** - Users normally expect that
  services bound in one namespace cannot be accessed from another
  namespace. The global‑namespace vsock listener breaks this
  expectation, allowing processes in any namespace to reach the *sshd*
  instance.

  **Enables malware and lateral movement** - Malicious code that runs
  inside a container or sandbox can exploit the exposed vsock listener
  to connect to the host’s SSH daemon, thereby **bypassing
  network‑segmentation rules** and **moving laterally** across the
  host. This creates a powerful attack vector for malware that can
  spread from isolated workloads to the host or other guests without
  needing traditional network exposure.

  **Hard‑to‑audit data path** - vsock provides a low‑level,
  kernel‑backed IPC channel that is opaque to many security tools. It
  can be used by sandboxed programs or containers to send commands or
  data to sandboxed programs or containers in a way that is difficult
  to monitor or audit.

  **vsock ss/netstat invisibility** - The visibility feature is
  isolated in a network namespace, letting processes evade detection
  in an already hard‑to‑audit subsystem.

  **Trivial extension of active threats** - If not already being
  leveraged, it would be trivial to extend [BRICKSTORM] and [shai-
  hulud] to take advantage of vsock as described above. As
  [BRICKSTORM] is already leveraging vsock on VmWare, it is unlikely it
  is not already being used by advanced threats.

[BRICKSTORM]
https://www.cisa.gov/news-events/analysis-reports/ar25-338a#AppC

[shai-hulud]
https://www.wiz.io/blog/shai-hulud-2-0-aftermath-ongoing-supply-chain-attack

Attachment: systemdvsocksshd.pdf
Description: