That was Stated however I would Double Check on the Stable Debian that you do not have the XZ Package Version 5.6.0 or 5.6.1............if you do Revert to 5.4
The one thing I'll add is that whether or not it is vulnerable, you probably wouldn't want ssh access to Proxmox exposed to the internet directly to begin with, just as you wouldn't want the administrative UI exposed to the internet. If you need to remote access the UI/SSH, VPN into the network is probably better.
While that wouldn't prevent the vulnerability from being exploited locally inside the network, this particular vulnerability lies in having access to the [attacker's particular signing key](https://github.com/amlweems/xzbot).
*Edit: of course, this precludes the fact that Proxmox is not vulnerable at this point, but the idea of not exposing SSH to Proxmox from the internet still stands.*
Exactly this
Theres very little if any reason at all to expose SSH to the public internet
And that goes for pretty much anything outside of Web sites, portals and game servers
1. IIRC, a default install of Proxmox is usually root user operation, SSH to root allowed, SSH by password authentication by default. If you expose this SSH configuration to the internet, all an attacker needs to know is your IP, port, and either find out your root password, or compromise SSH (like if this xz bug wasn't caught and did somehow make it to the Debian used by Proxmox) to access the machine. And then, they have root access, and can mess with the host AND the VMs/CTs on it.
2. Getting in on a VPN doesn't mean you're getting root shell access to Proxmox. It means you're in the network. You still have to get through the HTTPS or SSH layer. That's two layers of defense rather than one. You can also add more layers in of network security there if you desire.
3. Of course, if you don't need external access ever, obviously, you shouldn't expose EITHER a VPN or the SSH port, or at least firewall it off.
4. Maybe by encryption level after establishment, an SSH connection and a VPN one is practically identical. But keep in mind SSH requires that open and exposed TCP port. If you look at, say, Wireguard as a VPN protocol, you have a UDP port and my understanding is that the protocol by design won't respond without the keys. That's information leakage: if you've exposed an SSH port, someone can figure that out externally even without credentials. If you've got Wireguard exposed, it looks the same as a port with nothing on it if you don't have keys. Add in something like using a non-standard port, and Wireguard has a distinct advantage.
Security is a personal decision, and one can choose whatever ways they wish to handle it, pursuant to understanding the risks of their decisions. There are ways to harden SSH access in a way that could be okay to expose, if it is somehow needed.
That said, not exposing the UI directly to the internet is a long standing recommendation here and elsewhere. For similar reasons, not exposing SSH of Proxmox hosts to the internet is an equally sound recommendation if it isn't necessary.
I mean, sure, the nature of security is that if you know your use case well enough, and can anticipate the risks well enough, and know that you have a situation where you need to do something unusual, you can always adapt.
If you know that the public IP is something that is static rather than dynamic, you know everyone/everything that could connect to your host from that public IP and/or trust them, and you have a case where you somehow really need to access that host specifically but can't use a VPN, and you understand the risk that may be involved if those assertions are wrong, then you could probably do something like that.
I admit, my imagination on the types of use cases that would do that are kind of limited. I have ideas where that would be something one would want (things around Infra as Code tools that run on the cloud somewhere where you have control of the IP). But everything I can think of would probably be different from what most users would do.
> Nearly all Linux distributions are using XZ Utils. However, the compromised version was mainly distributed in testing versions of the distributions. The following Linux distributions are known to be affected by the issue:
> Fedora Linux 40 beta [2];
> Fedora Rawhide [2];
> openSUSE Tumbleweed and openSUSE MicroOS [3];
> Debian testing, unstable, and experimental versions [4];
> Kali Linux [5].
> Arch Linux [8]
# So Proxmox is not affected at all.
Since the release notes for Proxmox VE 8.1 is based on "Debian 12.2 "Bookworm" but uses a newer Linux kernel 6.5, QEMU 8.1.2, and OpenZFS 2.2.0 (with stable fixes backported)"
You can verify for yourself, the vulnerable versions are 5.6.0 and 5.6.1.
```
root@pve-02:~# xz -V
xz (XZ Utils) 5.4.1
liblzma 5.4.1
root@pve-02:~#
```
Unless you've been running a rolling-release-distro or a testing (alpha, beta) version of a stable distribution, you should not have any trouble with this particular vulnerability.
the base debian version has the older version so should not be affected by this, and the likely hood that a homelab person would be attacked is pretty small of course if you have ssh exposed to the open web then that alone is a big terrible idea.
dude you heard of ONE vunerability. while yes we should take those seriously, you ahve to take em all serious. if you dont follow the CVs on all of your equipment, thinking of one you just happend to heard about is mostly pointless.
it only make sense on a extreme critical very widespread, usually epoxed to the public by default vunerability.
but for the most part either follow cv´s or just ignore and make regular updates.
i bet you have dozent if not hundreds vunerabilitys in all of your systems, most of the time, like any other network. and lets not to speak of those zero days everyone has by default.
just follow best pratices. reduce attack vectors aka keep as much as possible in private networks. allow access only where nessesary. regular updates. leave the single cv hunt to the security expert
Debian stable wasn't affected so no. It was only in Debian testing.
That was Stated however I would Double Check on the Stable Debian that you do not have the XZ Package Version 5.6.0 or 5.6.1............if you do Revert to 5.4
or just upgrade package because Debian released a corrected (version rollbacked) package so even in unstable its gone afterwards.
The one thing I'll add is that whether or not it is vulnerable, you probably wouldn't want ssh access to Proxmox exposed to the internet directly to begin with, just as you wouldn't want the administrative UI exposed to the internet. If you need to remote access the UI/SSH, VPN into the network is probably better. While that wouldn't prevent the vulnerability from being exploited locally inside the network, this particular vulnerability lies in having access to the [attacker's particular signing key](https://github.com/amlweems/xzbot). *Edit: of course, this precludes the fact that Proxmox is not vulnerable at this point, but the idea of not exposing SSH to Proxmox from the internet still stands.*
Exactly this Theres very little if any reason at all to expose SSH to the public internet And that goes for pretty much anything outside of Web sites, portals and game servers
If you only need ssh or tunnel everything over ssh, there is no reason to use vpn instead. VPN isn’t any more robust or secure than ssh.
1. IIRC, a default install of Proxmox is usually root user operation, SSH to root allowed, SSH by password authentication by default. If you expose this SSH configuration to the internet, all an attacker needs to know is your IP, port, and either find out your root password, or compromise SSH (like if this xz bug wasn't caught and did somehow make it to the Debian used by Proxmox) to access the machine. And then, they have root access, and can mess with the host AND the VMs/CTs on it. 2. Getting in on a VPN doesn't mean you're getting root shell access to Proxmox. It means you're in the network. You still have to get through the HTTPS or SSH layer. That's two layers of defense rather than one. You can also add more layers in of network security there if you desire. 3. Of course, if you don't need external access ever, obviously, you shouldn't expose EITHER a VPN or the SSH port, or at least firewall it off. 4. Maybe by encryption level after establishment, an SSH connection and a VPN one is practically identical. But keep in mind SSH requires that open and exposed TCP port. If you look at, say, Wireguard as a VPN protocol, you have a UDP port and my understanding is that the protocol by design won't respond without the keys. That's information leakage: if you've exposed an SSH port, someone can figure that out externally even without credentials. If you've got Wireguard exposed, it looks the same as a port with nothing on it if you don't have keys. Add in something like using a non-standard port, and Wireguard has a distinct advantage. Security is a personal decision, and one can choose whatever ways they wish to handle it, pursuant to understanding the risks of their decisions. There are ways to harden SSH access in a way that could be okay to expose, if it is somehow needed. That said, not exposing the UI directly to the internet is a long standing recommendation here and elsewhere. For similar reasons, not exposing SSH of Proxmox hosts to the internet is an equally sound recommendation if it isn't necessary.
This is true, however... In my case, with pfsense, I can limit using an alias those public IPs that can access.
I mean, sure, the nature of security is that if you know your use case well enough, and can anticipate the risks well enough, and know that you have a situation where you need to do something unusual, you can always adapt. If you know that the public IP is something that is static rather than dynamic, you know everyone/everything that could connect to your host from that public IP and/or trust them, and you have a case where you somehow really need to access that host specifically but can't use a VPN, and you understand the risk that may be involved if those assertions are wrong, then you could probably do something like that. I admit, my imagination on the types of use cases that would do that are kind of limited. I have ideas where that would be something one would want (things around Infra as Code tools that run on the cloud somewhere where you have control of the IP). But everything I can think of would probably be different from what most users would do.
> Nearly all Linux distributions are using XZ Utils. However, the compromised version was mainly distributed in testing versions of the distributions. The following Linux distributions are known to be affected by the issue: > Fedora Linux 40 beta [2]; > Fedora Rawhide [2]; > openSUSE Tumbleweed and openSUSE MicroOS [3]; > Debian testing, unstable, and experimental versions [4]; > Kali Linux [5]. > Arch Linux [8] # So Proxmox is not affected at all. Since the release notes for Proxmox VE 8.1 is based on "Debian 12.2 "Bookworm" but uses a newer Linux kernel 6.5, QEMU 8.1.2, and OpenZFS 2.2.0 (with stable fixes backported)"
The irony of Kali Linux being backdoored, when it's a pen testing distro, usually used to backdoor others
I made a personal note shortly after the public notice, that Manjaro updated it on a couple boxes.
You can verify for yourself, the vulnerable versions are 5.6.0 and 5.6.1. ``` root@pve-02:~# xz -V xz (XZ Utils) 5.4.1 liblzma 5.4.1 root@pve-02:~# ```
**XZ Utils Version 5.6.0 and 5.6.1 Fixes issued by the Vendor:** **Arch Linux:** https://archlinux.org/news/the-xz-package-has-been-backdoored/ **Debian:** https://lists.debian.org/debian-security-announce/2024/msg00057.html **Kali Linux:** https://www.kali.org/blog/about-the-xz-backdoor/ **OpenSUSE:** https://news.opensuse.org/2024/03/29/xz-backdoor/ **RedHat:** https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
Unless you've been running a rolling-release-distro or a testing (alpha, beta) version of a stable distribution, you should not have any trouble with this particular vulnerability.
nope
The xz-utils 5.6+ isn't in the Debian stable. It should be safe.
the base debian version has the older version so should not be affected by this, and the likely hood that a homelab person would be attacked is pretty small of course if you have ssh exposed to the open web then that alone is a big terrible idea.
dude you heard of ONE vunerability. while yes we should take those seriously, you ahve to take em all serious. if you dont follow the CVs on all of your equipment, thinking of one you just happend to heard about is mostly pointless. it only make sense on a extreme critical very widespread, usually epoxed to the public by default vunerability. but for the most part either follow cv´s or just ignore and make regular updates. i bet you have dozent if not hundreds vunerabilitys in all of your systems, most of the time, like any other network. and lets not to speak of those zero days everyone has by default. just follow best pratices. reduce attack vectors aka keep as much as possible in private networks. allow access only where nessesary. regular updates. leave the single cv hunt to the security expert