Re: Systemd vsock sshd

[Greg Dahlman <dahlman () gmail com>]

Hi Alexander,

Note that the systemd socket activated sshd listener was the only really
embargoed information. That information was on this list for a while, so
you should consider it public and feel free to share with those impacted.
I have included the known working, end-user mitigations below in a few
locations and I have shared it with individuals I know in some larger sites.

I am holding off on a comprehensive blog post as I am waiting on a few
other stakeholders. I expect it to be published soon, maybe this weekend,
trying to only publish examples with known fixes.  However as when crun was
developed to replace lxc by the containerd team, there were no constraints
or defaults at the crun level on callers that is proving challenging.

While I can add apparmor rules to crun/runc/podman/bwrap/etc... SElinux has
proven to be more challenging, so those in k8s with mutating inlet
controllers should ensure that they deny address family 40 at the control
plane if possible.

Note: While local execution on a container host is problematic, restricting
access to the vsock loopback and VM bus from containers/sandboxes is
important.

I now have permission to share more information about one attack that I was
informed of, which was internal.

==========
Known attack
==========

A SAAS provider had a singleton container that originally allowed customers
to upload assets for branding via git and rsync, over time they added the
ability to pull assets from external tools which required them to allow
customers to log in to troubleshoot and run python scripts.  Their
expectations was that this container was not shared between tenants, and
that it was isolated.  As this was a tiny container, they just co-hosted it
with their app tier due to budget concerns.

An internal developer was approached by a customer.  That developer then,
claiming to be working on a new reporting engine container, added code to a
chain of notification engines pushing to the vsock proxy.  Any error being
explained away as safe because that new container wasn't in the app layer
pod.

That developer, either handed a time limited ansible key to the customer or
used the customers key to ssh into the customer's container, used
python/paramiko script to ssh to the container host, and launched a
multi-hop proxy as the container host debian built in www-data user.  That
container listens for all customer events and using the vsock proxy and
pushed targeted ones to the customer's asset container, allowing them to
exfiltrate sensitive data.

While the above attack did use the systemd vsock sshd listener for Escape
to Host <https://attack.mitre.org/tactics/TA0005/>, the attacker could have
just directly listened over the vsock loopback. Unfortunately this
orginization was only interested in a fix, and I don't expect more details
to be made public.



==============
Known mitigations
==============


Kernel boot string
==================

Disables systemd sshd vsock listener, will not protect the vsock loopback.

The official way to disable vsock sshd is through a kernel command line
parameters or system credentials logic. [systemd-ssh-generator]

 systemd.ssh_auto=no


Mask systemd socket
===================

This will disable the systemd sshd vsock listener, but will not protect
the vsock loopback.

 sudo systemctl mask sshd-vsock.socket

Note:

 If another unit **explicitly** wants "sshd-vsock.socket" it may
 be started.


AppArmor
========

This will remove access to the vsock loopback, which will also remove
access to the systemd sshd vsock listener for targeted binaries.

Add the following to "/etc/apparmor.d/local/<filename>" for each
high risk command.

 audit deny network vsock,



I will reply to this thread once I do publish a more indepth post and my
time for testing is constrained.

If anyone has found reliable methods of constraining crun with SElinux by
default without breaking the upstream callers it would be appreciated and
accelerate that effort.

Thanks,

Greg

On Thu, Jan 8, 2026 at 2:20 PM Solar Designer <solar () openwall com> wrote:

> Hi Greg,
>
> On Sat, Dec 27, 2025 at 08:46:49PM -0700, Greg Dahlman wrote:
> > This information is to be publicly released on January 6 per requirements
> > of the distro list.
>
> We're past this date now.  Have you already disclosed everything in this
> thread, or do you have anything additional you had shared with distros
> that you're yet to disclose to oss-security?  In the latter case, please
> do this ASAP!  (Sorry I haven't kept track of all the detail.)
>
> Thanks,
>
> Alexander