What did systemd say for the malicious vectors on this change?
Dec 28, 2025, 12:20 by [email protected]: > 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******** > DuckDuckGo> did not detect any trackers. > > More > <https://duckduckgo.com/-yPPlCVssOmY70ZnFvF-Wddd1QVblRSWUzjDgQW0TwaWlOck8n8Ygc4uUWFOC0MIJjOCjbYQbaDnBbkZETdwzuTGuVfdqEg6gB0ZExR5xaWYrVcTRoiFA6TclKbZ_wAFTyPnXg5X0PS0OyyEtjYQBJHEzpeSU-hRarcRIWDBFrNec0XCuV8O59Dplp9litlpyij8AzA8uvCO2V_QI07SH4enlMeH4OCVIQSCgUfYvHtKDDZ9v0NuPkhurpI4yN5xx-Ac> > Unable to verify sender identity > Deactivate <https://duckduckgo.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 >
