Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1251247 > unrolled thread

Bug#1108403: cloud-init: CVE-2024-6174

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1108403: cloud-init: CVE-2024-6174 Salvatore Bonaccorso <carnil@debian.org> - 2025-06-27 21:20 +0200
    Bug#1108403: (no subject) Noah Meyerhans <noahm@debian.org> - 2025-06-27 21:40 +0200
      Bug#1108403: (no subject) Jeremy Stanley <fungi@yuggoth.org> - 2025-06-28 02:40 +0200
        Bug#1108403: (no subject) Bastian Blank <waldi@debian.org> - 2025-06-28 10:00 +0200
          Bug#1108403: (no subject) Jeremy Stanley <fungi@yuggoth.org> - 2025-06-28 15:00 +0200
            Bug#1108403: (no subject) thomas@goirand.fr - 2025-06-28 18:30 +0200
              Bug#1108403: cloud-init: CVE-2024-6174 Jeremy Stanley <fungi@yuggoth.org> - 2025-06-29 15:00 +0200
                Bug#1108403: cloud-init: CVE-2024-6174 Bastian Blank <waldi@debian.org> - 2025-06-29 17:40 +0200
                  Bug#1108403: cloud-init: CVE-2024-6174 thomas@goirand.fr - 2025-06-29 18:00 +0200
                    Bug#1108403: cloud-init: CVE-2024-6174 Bastian Blank <waldi@debian.org> - 2025-06-29 18:40 +0200
    Bug#1108403: cloud-init: CVE-2024-6174 Jeremy Stanley <fungi@yuggoth.org> - 2025-06-30 16:10 +0200
      Bug#1108403: cloud-init: CVE-2024-6174 Jeremy Stanley <fungi@yuggoth.org> - 2025-07-07 20:10 +0200
        Bug#1108403: cloud-init: CVE-2024-6174 Noah Meyerhans <noahm@debian.org> - 2025-07-07 21:00 +0200

#1251247 — Bug#1108403: cloud-init: CVE-2024-6174

Source: cloud-init
Version: 25.1.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: carnil@debian.org, Debian Security Team <team@security.debian.org>

Hi,

The following vulnerability was published for cloud-init.

CVE-2024-6174[0]:
| When a non-x86 platform is detected, cloud-init grants root access
| to a hardcoded url with a local IP address. To prevent this, cloud-
| init default configurations disable platform enumeration.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-6174
    https://www.cve.org/CVERecord?id=CVE-2024-6174
[1] https://github.com/canonical/cloud-init/commit/f43937f0b462734eb9c76700491c18fe4133c8e1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

[toc] | [next] | [standalone]

#1251252 — Bug#1108403: (no subject)

zigo@debian.org
Cc: 
Bcc: 
Subject: Re: Bug#1108403: cloud-init: CVE-2024-6174
Reply-To: 
In-Reply-To: <175105165755.1422810.7191493426370949878.reportbug@eldamar.lan>

On Fri, Jun 27, 2025 at 09:14:17PM +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for cloud-init.
> 
> CVE-2024-6174[0]:
> | When a non-x86 platform is detected, cloud-init grants root access
> | to a hardcoded url with a local IP address. To prevent this, cloud-
> | init default configurations disable platform enumeration.

My inclination is to pull in the latest upstream patch release, 25.1.4
(we're currently at 25.1.1 in trixie).  However, the fix for
CVE-2024-6174 does introduce a functionality change that may be
disruptive in some less common environments (notably non-amd64
OpenStack).  There are potential workarounds, but they're not
necessarily trivial for users who are operating a cloud environment that
they don't control.  The primary workaround is to use a datadrive for VM
metadata, rather than a network service, but that's a choice made by the
cloud operator.

Thomas, as OpenStack maintainer, do you have any insight into just how
disruptive this change is likely to be?

Still researching this one...

noah

[toc] | [prev] | [next] | [standalone]

#1251271 — Bug#1108403: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On 2025-06-27 15:36:26 -0400 (-0400), Noah Meyerhans wrote:
[...]
> There are potential workarounds, but they're not necessarily 
> trivial for users who are operating a cloud environment that they 
> don't control.  The primary workaround is to use a datadrive for 
> VM metadata, rather than a network service, but that's a choice 
> made by the cloud operator.
[...]

I was read in on this back early in the year (in my capacity as an 
OpenStack vulnerability manager even though the vulnerability itself 
doesn't really affect typical OpenStack deployments), but sadly the 
LP bug seems to still be private which makes talking about specific 
mitigations for the vulnerability and workarounds for the new 
behavior difficult. Non-amd64 OpenStack environments are not common, 
though they do exist and I have access to some. This is primarily 
arm64 with maybe a smattering of aging ppc64 and s390x, and I've 
heard tell of riscv experiments in some organizations. That said, 
behavior changes in new versions of software necessitate that users 
ask the operators of their cloud services to make certain new 
configurations possible, I don't see this as being all that 
different if it were just coming in a new major Debian version.

The biggest risk I see with shipping it in stable is that an apt 
upgrade of cloud-init could leave some virtual machines in these 
environments unreachable after a reboot. It's very hard to estimate 
the actual impact due to the various factors involved, as well as 
overall lack of knowledge about the number and sizes of those 
environments. The OpenInfra Foundation does run surveys which 
include questions about some of this (architecture, deployment 
scale...) but it's elective self-reporting so at best only an 
indicator of proportion, assuming related biases don't skew 
responses to the point of complete uselessness in this case.
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#1251280 — Bug#1108403: (no subject)

On Fri, Jun 27, 2025 at 11:51:08PM +0000, Jeremy Stanley wrote:
> The biggest risk I see with shipping it in stable is that an apt upgrade of
> cloud-init could leave some virtual machines in these environments
> unreachable after a reboot.

How that?  Most parts of cloud-init are one shot, including the user
setup.

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
		-- Edith Keeler, "The City on the Edge of Forever",
		   stardate unknown

[toc] | [prev] | [next] | [standalone]

#1251299 — Bug#1108403: (no subject)

On 2025-06-28 09:47:36 +0200 (+0200), Bastian Blank wrote:
[...]
> How that?  Most parts of cloud-init are one shot, including the user 
> setup.

If the VM gets its network configuration from metadata instead of 
DHCP/SLAAC+RA and isn't relying on configdrive and isn't falling 
back to using network settings cached into /etc from a prior boot 
(and is running on a non-amd64 arch), then it can come up with no 
reachable network. That combination of factors should be 
exceptionally rare however.

The more likely scenario, you're right, is that updated images fail 
when trying to create and boot a new VM from them for the first 
time, but that's probably far less problematic since users can 
typically roll back to an older version of the image or adjust their 
options to e.g. turn on configdrive when available.
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#1251319 — Bug#1108403: (no subject)

[Multipart message — attachments visible in raw view] — view raw

On Jun 28, 2025 14:59, Jeremy Stanley <fungi@yuggoth.org> wrote:

>

> On 2025-06-28 09:47:36 +0200 (+0200), Bastian Blank wrote: 

> [...] 

> > How that?  Most parts of cloud-init are one shot, including the user 

> > setup. 

>

> If the VM gets its network configuration from metadata instead of 

> DHCP/SLAAC+RA and isn't relying on configdrive and isn't falling 

> back to using network settings cached into /etc from a prior boot 

> (and is running on a non-amd64 arch), then it can come up with no 

> reachable network. That combination of factors should be 

> exceptionally rare however. 

>

> The more likely scenario, you're right, is that updated images fail 

> when trying to create and boot a new VM from them for the first 

> time, but that's probably far less problematic since users can 

> typically roll back to an older version of the image or adjust their 

> options to e.g. turn on configdrive when available. 

> -- 

> Jeremy Stanley 


FYI, I expect most OpenStack operators to configure a config drive by default, as it is the most reliable metadata source.


Thomas Goirand

[toc] | [prev] | [next] | [standalone]

#1251388

On 2025-06-28 18:15:08 +0200 (+0200), thomas@goirand.fr wrote:
[...]
> FYI, I expect most OpenStack operators to configure a config drive 
> by default, as it is the most reliable metadata source.

Yes, the main reason some of them prefer/recommend the network 
metadata source is that it can be updated over time, while the 
configdrive content is (currently) frozen at the time its associated 
server instance is created so things like default gateways, static 
routes and DNS resolver addresses may grow stale as the operator 
makes adjustments to their environment.

But since we're talking about a very small subset of clouds right 
now (specifically those with non-amd64 compute nodes), I think the 
behavior change is probably not a major concern.
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#1251403

On Sun, Jun 29, 2025 at 12:48:20PM +0000, Jeremy Stanley wrote:
> But since we're talking about a very small subset of clouds right now
> (specifically those with non-amd64 compute nodes), I think the behavior
> change is probably not a major concern.

Just one.  Debian does not support config drive on ahci, only virtio,
when using the smaller genericcloud image.

Could someone see if openstack could finally fix that broken default?

Bastian

-- 
You're dead, Jim.
		-- McCoy, "The Tholian Web", stardate unknown

[toc] | [prev] | [next] | [standalone]

#1251406

[Multipart message — attachments visible in raw view] — view raw

On Jun 29, 2025 17:31, Bastian Blank <waldi@debian.org> wrote:

>

> On Sun, Jun 29, 2025 at 12:48:20PM +0000, Jeremy Stanley wrote: 

> > But since we're talking about a very small subset of clouds right now 

> > (specifically those with non-amd64 compute nodes), I think the behavior 

> > change is probably not a major concern. 

>

> Just one.  Debian does not support config drive on ahci, only virtio, 

> when using the smaller genericcloud image. 

>

> Could someone see if openstack could finally fix that broken default? 

>

> Bastian


There's as much as I know, no way to fix the default. Only, operators can add the metadata to the flavor or image. Typically to the image in fact, as the lack of AHCI is really just a Debian specificity. Which is why I filled the bug about re-adding AHCI support in the cloud kernel. I think it is very unfortunate you closed that bug so fast, leaving no room for discution. Because of the we (at infomaniak) switched to the non-cloud kernel fearing some customers trying to boot from server backups would ommit the virtio metadata... :(


Cheers,


Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#1251407

Hi Thomas

Please fix your emails, they are really hard to read.

On Sun, Jun 29, 2025 at 05:55:30PM +0200, thomas@goirand.fr wrote:
> > Could someone see if openstack could finally fix that broken default? 
> There's as much as I know, no way to fix the default.

That's why I ask to get OpenStack upstream to fix the default.  Something like
this, which also removes a lot of special cases.

diff --git a/nova/virt/libvirt/blockinfo.py b/nova/virt/libvirt/blockinfo.py
index e73cc4d..d12a916 100644
--- a/nova/virt/libvirt/blockinfo.py
+++ b/nova/virt/libvirt/blockinfo.py
@@ -247,26 +247,7 @@ def get_disk_bus_for_device_type(instance,
     # Otherwise pick a hypervisor default disk bus
     if virt_type in ("qemu", "kvm"):
         if device_type == "cdrom":
-            guestarch = libvirt_utils.get_arch(image_meta)
-            if guestarch in (
-                    obj_fields.Architecture.PPC,
-                    obj_fields.Architecture.PPC64,
-                    obj_fields.Architecture.PPCLE,
-                    obj_fields.Architecture.PPC64LE,
-                    obj_fields.Architecture.S390,
-                    obj_fields.Architecture.S390X,
-                    obj_fields.Architecture.AARCH64):
-                return "scsi"
-            machine_type = libvirt_utils.get_machine_type(image_meta)
-            # NOTE(lyarwood): We can't be any more explicit here as QEMU
-            # provides a version of the Q35 machine type per release.
-            # Additionally downstream distributions can also provide their own.
-            if machine_type and 'q35' in machine_type:
-                # NOTE(lyarwood): The Q35 machine type does not provide an IDE
-                # bus and as such we must use a SATA bus for cdroms.
-                return "sata"
-            else:
-                return "ide"
+            return "virtio"
         elif device_type == "disk":
             return "virtio"
         elif device_type == "floppy":


Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
		-- Spock, "This Side of Paradise", stardate 3417.3

[toc] | [prev] | [next] | [standalone]

#1251467

On 2025-06-30 10:40:26 +0200 (+0200), Thomas Goirand wrote:
[...]
> https://review.opendev.org/c/openstack/nova/+/953732
> Hopefully, this will be well received.
>
> I however, still think the AHCI driver should be re-added in our 
> cloud kernel though... :/

In particular because, while it may not be all that obvious, it 
takes a *very* long time for upstream changes in OpenStack to 
trickle down to deployments in the wild. There are popular public 
cloud providers running their service on decade-old versions of the 
software. This also means their users are booting the latest Debian 
images on relatively ancient host kernels and KVM versions, old 
libvirt and QEMU, et cetera.

But for this particular bug the concern is with users of non-amd64 
OpenStack clouds (primarily arm64 but looks like there are also 
Debian genericcloud images for ppc64el), which could in theory have 
different drivers selected in the kernel config anyway? Or is that 
sort of divergence intentionally avoided between architectures?
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#1252095

https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607 
has finally been switched to public upstream as of Friday, and 
contains a lot more of the rationale behind their breaking change 
decisions.
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#1252096

On Mon, Jul 07, 2025 at 06:00:15PM +0000, Jeremy Stanley wrote:
> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607 has
> finally been switched to public upstream as of Friday, and contains a lot
> more of the rationale behind their breaking change decisions.

Thanks.  My initial thinking about this issue mirrors what was
expressed by James Page in the launchpad comments. [1]  In a typical
cloud environment, this would not be an issue, as it would not be
possible for a malicious user to hijack one of the link-local IMDS
addresses.  However, as observed elsewhere, not all uses of cloud-init
are in actual cloud environments. [2] We provide downloadable VM images
that are usable with qemu in non-cloud environments.  In those cases, it
is possible that there could be a malicious user on the local network
link with one of the IMDS addresses.  It's an unlikely scenario, and
relies on quite a bit of coincidental network access and configuration,
but it can happen.

Given all of that, I think we should:
1. Update to the latest cloud-init upstream for trixie.  It includes a
   couple of other low-risk bug fixes, too.
2. Update cloud-init in a bookworm point release with a backport of the
   fix.  I haven't looked yet at the complexity involved in backporting
   the fix to 22.4.2 yet, but will do so now.

Given the limited impact of the breaking change, I think documenting it
in debian/changelog is sufficient, and we don't need a NEWS entry.

Does anybody disagree with the above?

noah

1. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/31
2. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2069607/comments/32

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web