Re: Systemd vsock sshd

[yen-mummify-yeah () duck com]

What did systemd say for the malicious vectors on this change?


Dec 28, 2025, 12:20 by dahlman_at_gmail.com_yen-mummify-yeah () duck 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********
> 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