note that this is a topic with some security considerations, so first a few remarks:
** there is no security problem with Incus as provided by the project **
** there is no security problem with Incus package provided by Ubuntu with ESM (aka PRO)
indeed, why ? There is no doubt that interrogating esm updates on Ubuntu 24.04 returns the incus package, while the known vulnerabilities for the incus project are related to 6.12 ou 13 while the version distributed by Ubuntu is the stable version; currently 6.0.0-1ubuntu0.2
So what gives ?
It happens that go packages are built statically, and incus includes the sources of many packages. Some of them have been deemed vulnerable at some point.
One of them is gobgp. The problem was that before version 3.35 of this package, a panic could be remotely triggered by sending a crafted packet to the server.
The Ubuntu package included in the vanilla Ubuntu 24.04 (ESM being NOT enabled) is built witn 3.23 and as such is vulnerable.
To be exploited, bgp has to be enabled in Incus, and port 179 (default bgp port) exposed to attackers.
Whatever the workarounds, the lesson is clear: DO NOT USE Incus with the Ubuntu package on any Ubuntu production server without ESM updates. Either use Incus with ESM, OR use the Zabbly PPA.
If you think that using Debian is the solution, think again. Incus can be included as a system package with backports in Bookworm, however it is also vulnerable. If you want to use Incus with system packages, you have better to find a distro that just ships the stable version built straight from the github sources (the stable 6.0 branch has been changed to use the fixed gobgp package 4 months ago, about when it was found).
Yeah, Bookworm current version (6.0.4-2~bpo12+1) is built with gobgp 3.10 (!).
There is another package vulnerable too but I did not take note of it, my goal was understanding why there was an ESM version for Incus Ubuntu system package.
From another investigation on another security problem, I have found that Debian stable follows reasonably well security problems. Debian old stable is not as fast, you could have stayed vulnerable for about 2 weeks in this case. And Bookworm is a month away to becoming old stable. I thought about switching to Debian after looking at this situation where Ubuntu is not acting great at all, but soon changed my point of view after seeing the Debian state of affairs Security is not a strong point at all with old software in Debian.
(Writing this with my Debian Developer hat on, but not officially speaking for Debian.)
To start, Ubuntu != Debian. Yes, Ubuntu imports most of its package from Debian, but then Canonical adds its special sauce, support policies, and offerings like ESM. I donât have any experience with that since I donât use Ubuntu, so I wonât speak to it further.
As far as Debian is concerned, the release notes do mention that Go & Rust packages will have more limited security support as statically-linked languages. This isnât to say no security support; take a look at the latest âBinNMU changelogâ for incus in unstable where the package was recently rebuilt to take advantage of security fixes in an updated release of go. This happens all the time. Once a stable release of Debian is out, the Release and Security Teams can do similar rebuilds of affected packages if warranted. Itâs not as automatic as fixing a dynamically linked library, but also not as dire as you seem to believe.
Specifically looking at the gobgp CVE youâre concerned about, the Debian Security Team has determined it to be a minor issue. I concur, and would go further by calling that specific bug a Curriculum Vitae Enhancer. Of course, Iâd be happy to change my mind if presented with a proof-of-concept showing how Incus could be caused to crash.
Packages installed from backports have no official security support â indeed, they are provided on an âas-isâ basis. If the Security Team considered the gobgp CVE severe enough to warrant a fix in the stable release it would be trivial to rebuild the backported Incus package too.
In conclusion, no the skyâs not falling and Debian isnât a security wasteland. Because Debian rarely includes wholly new versions of a package to fix an issue in a stable release (Firefox/Chrome being notable exceptions), automated security scanners frequently flag false positives. Donât panic just because a package might be affected by a CVE.
if a package is affected by a CVE that cause a panic, if one sends it the crafted packet, it will panic - Incus is then restarted automatically and all seems fine if one donât read the logs, but if one sends the crafted packet again and again and again, then Incus will stay down until restarted manually.
I have written a repro and tested it with Ubuntu 24.04 against standard (not ESM) package, Iâm not going to post it here because, well, itâs not very responsible to do that.
I did not test it with Debian Bookworm because I donât have all the time in the world to test distros that I donât use, but I donât see why it would fare better. If Trixie set Incus in main distro, it would change things but if it stays in backport, Trixie would be fine against this problem, but what about the following one(s) ?
For the record I did not use together the words âDebianâ and âsecurity wastelandâ. I said clearly that people using Debian stable and supported packages are having a decent security situation.
What I object to is the people using in production âfreeâ (as in beer) distros (like Ubuntu without ESM or Debian) that donât have proper security support either because too old and/or using old and unsupported packages and believing that everything will be fine because well, why not. For freedom loving associations they are believing that because Debian is associated with freedom they are fine. Thatâs a sad delusion. They are only fine because nobody much cares to attack them.
Itâs a buffer overflow that causes the service to crash/restart. With some extra care it could be elevated to Remote Code Execution (RCE). Any buffer overflow has the potential to get upgraded into an RCE, the get reported as an RCE, and finally the packages will get fixed by the packagers.