[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54F60F14-7FDB-4148-AF82-DEAA35B35E5F.1@smtp-inbound1.duck.com>
Date: Sun, 28 Dec 2025 02:55:55 -0500
From: yen-mummify-yeah@...k.com
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Cc: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Systemd vsock sshd
What did systemd say for the malicious vectors on this change?
Dec 28, 2025, 12:20 by dahlman_at_gmail.com_yen-mummify-yeah@...k.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
>
Powered by blists - more mailing lists
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.
