oss-security - Systemd vsock sshd

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAM=PXV50+jaVYFueXFbZpioBX3PMrUG2Ey8WoQ5NT89J9gFwCA@mail.gmail.com>
Date: Sat, 27 Dec 2025 20:46:49 -0700
From: Greg Dahlman <dahlman@...il.com>
To: oss-security@...ts.openwall.com
Subject: Systemd vsock sshd

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

Content of type "text/html" skipped

Download attachment "systemdvsocksshd.pdf" of type "application/pdf" (92045 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.