Unsafe Environment Handling in MuranoPL

[Jeremy Stanley]

Members of the VMT received the following report by E-mail from "kirualawliet l":

Title: OpenStack Murano Component Information Leakage

Reporter: lawliet and Zhiniang Peng (@edwardzpeng) from Sangfor Security Research Team

Products: OpenStack Murano Component

Affects: All versions of Murano Component

Description:

The Sangfor Security Research Team has identified a critical security vulnerability in the Murano component of OpenStack. This vulnerability allows ordinary users capable of importing and deploying app packages to access sensitive information within OpenStack services. Specifically, through this exploit, unauthorized users can obtain Murano service account credentials, potentially escalating their privileges to an administrator level. Subsequently, unauthorized users can gain complete control over various resources, including user roles, hosts, and networks.

The vulnerability stems from the Murano service's reliance on MuranoPL, an extension of the YAQL language. The YAQL library includes a 'format' function that mirrors Python's 'str.format' method, enabling attribute access.

```python
# code snippet from yaql-2.0.0\standard_library\strings.py:569
@specs.parameter('__format_string', yaqltypes.String())
@specs.extension_method
def format_(__format_string, *args, **kwargs):
    ...
    return __format_string.format(*args, **kwargs)
```

An example of this vulnerability includes:

```
>>> secret_key = "abcd1234"
>>> class Test:
... def __init__(self):
... pass
...
>>> t = Test()
>>> # Exploiting the vulnerability to expose sensitive data:
>>> malicious_format_string = '{0.__class__.__init__.__globals__[secret_key]}'
>>> formatted_output = malicious_format_string.format(t)
>>> print(formatted_output) # This line reveals the value of secret_key
'abcd1234'
```

This exploit allows access to Murano service's oslo configuration storage, thereby exposing critical Murano service account credentials, granting unauthorized users administrative privileges.

We believe no deployment mode is immune to this vulnerability. To ensure system security, we recommend immediate attention and remediation of this vulnerability within the OpenStack Murano component. Our team stands ready to offer assistance and collaboration in addressing and resolving this issue promptly.

Thank you for your prompt attention to this matter.

Sincerely,
kirualawliet
Sangfor Security Research Team

[Jeremy Stanley (fungi)]

Please be aware that reports of suspected vulnerabilities in Murano's deliverables aren't officially overseen by the OpenStack VMT, and so won't be producing any public advisory, but we remain available to assist with coordination on a best effort basis at the Murano team's request. https://security.openstack.org/repos-overseen.html#repositories-overseen

[Jeremy Stanley (fungi)]

I've also subscribed kirualawliet, the original reporter.

[kirualawliet (kirualawliet)]

Hello Jeremy Stanley,
    I wanted to know whether the Murano team has received information
regarding the vulnerability. I haven't seen any progress on the
vulnerability fix on Launchpad and would like to understand the current
situation. Our plan is to disclose the technical details of the
vulnerability publicly one month from now if there are no intentions to
address it.
Best regards,
lawliet

On Sat, 6 Jan 2024 at 00:10, Jeremy Stanley <email address hidden>
wrote:

> I've also subscribed kirualawliet, the original reporter.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2048114
>
> Title:
> OpenStack Murano Component Information Leakage
>
> Status in Murano:
> New
> Status in OpenStack Security Advisory:
> Won't Fix
>
> Bug description:
> Members of the VMT received the following report by E-mail from
> "kirualawliet l":
>
> Title: OpenStack Murano Component Information Leakage
>
> Reporter: lawliet and edwardpeng(@edwardzpeng) from Sangfor Security
> Research Team
>
> Products: OpenStack Murano Component
>
> Affects: All versions of Murano Component
>
> Description:
>
> The Sangfor Security Research Team has identified a critical security
> vulnerability in the Murano component of OpenStack. This vulnerability
> allows ordinary users capable of importing and deploying app packages
> to access sensitive information within OpenStack services.
> Specifically, through this exploit, unauthorized users can obtain
> Murano service account credentials, potentially escalating their
> privileges to an administrator level. Subsequently, unauthorized users
> can gain complete control over various resources, including user
> roles, hosts, and networks.
>
> The vulnerability stems from the Murano service's reliance on
> MuranoPL, an extension of the YAQL language. The YAQL library includes
> a 'format' function that mirrors Python's 'str.format' method,
> enabling attribute access.
>
> ```python
> # code snippet from yaql-2.0.0\standard_library\strings.py:569
> @specs.parameter('__format_string', yaqltypes.String())
> @specs.extension_method
> def format_(__format_string, *args, **kwargs):
> ...
> return __format_string.format(*args, **kwargs)
> ```
>
> An example of this vulnerability includes:
>
> ```
> >>> secret_key = "abcd1234"
> >>> class Test:
> ... def __init__(self):
> ... pass
> ...
> >>> t = Test()
> >>> # Exploiting the vulnerability to expose sensitive data:
> >>> malicious_format_string =
> '{0.__class__.__init__.__globals__[secret_key]}'
> >>> formatted_output = malicious_format_string.format(t)
> >>> print(formatted_output) # This line reveals the value of secret_key
> 'abcd1234'
> ```
>
> This exploit allows access to Murano service's oslo configuration
> storage, thereby exposing critical Murano service account credentials,
> granting unauthorized users administrative privileges.
>
> We believe no deployment mode is immune to this vulnerability. To
> ensure system security, we recommend immediate attention and
> remediation...

[Jeremy Stanley (fungi)]

Sorry for the delay in responding. There was a bit of a leadership crisis for Murano, and nobody in the existing group authorized to see this report was around to look into the issue you reported. In the past 24 hours, some headway was made in adding an active contributor to that group, so hopefully they'll be able to weigh in on the associated scope and risk for this soon.

[Andy Botting (andybotting)]

Thanks @kirualawliet for reporting this issue.

It does look quite serious if the oslo configuration context is able to be accessed from users own packages.

Your original post shows accessing the YAQL format method via a python shell, but can you demonstrate that the oslo configuration is able to be accessed from a Murano package?

Have you actually developed an app I can run against a running Murano service as a proof of concept?

Thanks,
Andy

[kirualawliet (kirualawliet)]

Okay, please upload and deploy the zip file in the attachment to Murano. The deployment process will encounter errors. Please check the deployment logs. If everything goes smoothly, you should be able to see the leaked Oslo configuration in the deployment logs.

[Andy Botting (andybotting)]

Thanks @kirualawliet. I can confirm it does leak the server's oslo config.

I can see my Keystone auth, database and RabbitMQ passwords in there.

Looks like this is a serious one then.

[Andy Botting (andybotting)]

@jeremy Can you please add launchpad id: waipengyip to this bug?

[Jeremy Stanley (fungi)]

Added, but in future you should feel free to subscribe subject matter experts yourself when their input is needed on such bug reports.

Also, just to reiterate what I stated in comment #3, the VMT doesn't officially oversee or coordinate vulnerability reports for Murano, though we're happy to assist on a best-effort basis when requested.

[kirualawliet (kirualawliet)]

Yes, I have reviewed the announcement and understand that Murano is
currently not overseen by VMT. However, I recently learned that a cloud
platform developed by a certain cloud provider based on OpenStack Murano is
also affected by this vulnerability, we had identified a few case in China.
The vulnerability poses a significant risk, in order to prevent users from
suffering losses, if possible, please apply for a CVE and try to issue a
security advisory to remind users to update security patches promptly.

On Thu, 22 Feb 2024 at 22:40, Jeremy Stanley <email address hidden>
wrote:

> Added, but in future you should feel free to subscribe subject matter
> experts yourself when their input is needed on such bug reports.
>
> Also, just to reiterate what I stated in comment #3, the VMT doesn't
> officially oversee or coordinate vulnerability reports for Murano,
> though we're happy to assist on a best-effort basis when requested.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2048114
>
> Title:
> OpenStack Murano Component Information Leakage
>
> Status in Murano:
> New
> Status in OpenStack Security Advisory:
> Won't Fix
>
> Bug description:
> Members of the VMT received the following report by E-mail from
> "kirualawliet l":
>
> Title: OpenStack Murano Component Information Leakage
>
> Reporter: lawliet and edwardpeng(@edwardzpeng) from Sangfor Security
> Research Team
>
> Products: OpenStack Murano Component
>
> Affects: All versions of Murano Component
>
> Description:
>
> The Sangfor Security Research Team has identified a critical security
> vulnerability in the Murano component of OpenStack. This vulnerability
> allows ordinary users capable of importing and deploying app packages
> to access sensitive information within OpenStack services.
> Specifically, through this exploit, unauthorized users can obtain
> Murano service account credentials, potentially escalating their
> privileges to an administrator level. Subsequently, unauthorized users
> can gain complete control over various resources, including user
> roles, hosts, and networks.
>
> The vulnerability stems from the Murano service's reliance on
> MuranoPL, an extension of the YAQL language. The YAQL library includes
> a 'format' function that mirrors Python's 'str.format' method,
> enabling attribute access.
>
> ```python
> # code snippet from yaql-2.0.0\standard_library\strings.py:569
> @specs.parameter('__format_string', yaqltypes.String())
> @specs.extension_method
> def format_(__format_string, *args, **kwargs):
> ...
> return __format_string.format(*args, **kwargs)
> ```
>
> An example of this vulnerability includes:
>
> ```
> >>> secret_key = "abcd1234"
> >>> class Test:
> ... def __init__(self):
> ... pass
> ...
> >>> t = Test()
> >>> # Exploiting the vulnerability to expose sensitive data:
> >>> malicious_format_string =
> '{0.__class__.__init__.__globals__[secret_key]}'
> >>> formatted_output = malicious_format_string.format(t)
> >>> print(formatted_output) # This line reveals ...

[Andy Botting (andybotting)]

With the lack of community participation in Murano, this may not get fixed. I hope to look into the code when I get time, but I'm not sure when that might be.

For our cloud, we're simply going to change the policy to prevent all users from uploading packages and that process will be performed by admins who can check the code first.
L

[Jake Yip (waipengyip)]

Sorry Jeremy, I had mistakenly thought that only you can add people to security bugs, as my previous access to security bugs were all added by you. Now I know anyone already watching can add.
- Jake

[Jeremy Stanley (fungi)]

Given this seems to be a serious confirmed vulnerability for any deployment which allows users to upload apps, and it has been spotted by one independent researcher already, it could easily be known to others with more nefarious intentions as well.

The responsible course of action, if there is currently nobody with time to prioritize immediate development and backporting of a fix, is to switch this report to public and that way at least operators of the service can be informed so that they have the opportunity to disable app uploads or or remove Murano from their networks entirely. Leaving this private in hopes one of the few people who are aware of it will find time to eventually work on a patch is, unfortunately, not a viable strategy. Bringing it to the wider community might also help avoid releasing OpenStack 2024.1 with this known vulnerability.

[kirualawliet (kirualawliet)]

Agreeing with @Jeremy, therefore, if the vulnerability remains unresolved, according to openstack vulnerability management process and our plans, the vulnerability information will be disclosed 90 days after it was submitted, starting from January 4, 2024, namely, after April 4, 2024, to alert users of the Murano project to take preventive actions to avoid potential exploitation by malicious attackers resulting in losses.

[Jeremy Stanley (fungi)]

I've subscribed Jay Faulkner and Dan Smith from the OpenStack Technical Committee, at their request.

[Jay Faulkner (jason-oldos)]

We are planning to take the following actions:
- Coordinate an OSSN, notifying users of a major Murano vulnerability with no immediate intention to fix, and that we recommend uninstalling Murano from the cloud. It will include a date when the bug will be opened and details provided.
- At that date, file an unredacted OSSN, detailing the vulnerability, and open this bug.
- Hope that users took us seriously and uninstalled Murano :(

[Jeremy Stanley (fungi)]

Clark (now subscribed) pointed out to me that Heat and Mistral also appear to allow users to submit custom YAQL. It would be good to loop in representatives from those projects to perform a cursory check for whether they're also affected by similar issues that need addressing before we disclose this.

[Jeremy Stanley (fungi)]

I've subscribed Takashi Kajinami (Heat PTL) and Axel Vanzaghi (Mistral PTL) in hopes they have time to take a look and determine whether those services may have similar unsafe handling of user-supplied YAQL. Please feel free to subscribe other subject matter experts as needed in order to make the determination.

[Takashi Kajinami (kajinamit)]

So I checked the example murano resources and it seems we can reproduce a similar behavior in heat. (example template and the resource show result are being attached).

One key difference is that in heat we explicitly pass a dictionary value[1], which makes yaql create a new frozendict instance[2]. So __globals__ does not get access to code in heat, but only instances available in [2] which do not contain severely sensitive information such as CONF.

[1] https://github.com/openstack/heat/blob/9da45ab44bb985c633d246ba9132f1ccc5831cfd/heat/engine/hot/functions.py#L1238
[2] https://github.com/openstack/yaql/blob/0d63eb1346c829c0ce818dd2e00590af6330a0f3/yaql/language/utils.py#L75-L76

However it still leaks a few system information like python versions or python path. What we can probably attempt here is to update yaql to reject a specific pattern like '{\s+.__\s+__\s+}' to avoid access to built-in functions. It should not break any existing valid usage in heat, at least.

[Jeremy Stanley (fungi)]

I'll readily admit I got a bit lost trying to trace through YAQL's overloaded eval() replacement, but my concern is that making it safe to pass user-supplied strings through eval() is like trying to plug holes in a leaky boat at sea. This article gives some great examples: https://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

[Dan Smith (danms)]

Yeah, agree. I think you might be able to prevent certain behaviors, but I think it would be hard to call this fixed if you're still using eval in any way in code that processes user-supplied input.

[Takashi Kajinami (kajinamit)]

The overall problem is caused by the format method which internally does eval... I'm unsure if we can restrict the behavior in format or replace it without breaking the existing usage such as "{0}_{1}" or "{foo}_{bar}".

As a safe guard we can introduce an option to disable the format function completely. However it may affect any deployment, where a user is using the format yaql function with valid "safe" usage.

https://github.com/openstack/yaql/blob/0d63eb1346c829c0ce818dd2e00590af6330a0f3/yaql/standard_library/strings.py#L567-L596

[Takashi Kajinami (kajinamit)]

So there a few options I can think of

1. Drop format function
 - This breaks existing usage with format function and thus causes user impact
  - If you run public cloud with heat enable, you have to tell all of your users to modify their template when you update yaql

2. Make format function optional and let components enable it with understanding its risk
 - This but enabling the feature is not feasibly possible with the certain vulnerability exist

3. Add validation in format function to prohibit unsafe usage
 - Limiting characters within {} to 0-9a-zA-Z would be the most strict validation I can think of
 - Loosing limitation may still leave certain patterns

4. Any other smart way to replace format with keeping the existing base usage

I'm leaning towards 3, with validation which is as much strict as possible (ex. reject "{[0-9a-zA-Z]*[^0-9a-zA-Z}]" )

[Dan Smith (danms)]

Yep, I think we're clear on the "no suitable replacement" for eval. It's why I think ever using eval for something should be avoided and I'm surprised to see it here.

To me, this is not solved without removing that functionality. Hampering it is mere mitigation. I agree that #3 seems like it should be un-bypassable, but the thing you're trying to gate off is pretty dangerous and once this gets disclosed, anyone who didn't think to try leveraging that vulnerability will surely be on the case.

To me #2 is the minimum mitigation to even proceed, with default to off. Perhaps #2 where enabled gets you #3 would be better. Honestly, #1 is the approach I'd take. Any of the three will require users to modify their templates I think, so you might as well go for the gold.

Just MHO.

[Jay Faulkner (jason-oldos)]

I agree with Dan that #2+#3 is the reasonable route forward if we want to leave this functionality enabled or leave a "soft landing" for people while they work on different results.

I do not thing #3 by itself would be enough to mitigate the concern entirely for all threat models (e.g.; a public cloud).

[Jeremy Stanley (fungi)]

Since Axel hasn't been available, I've also subscribed James Slagle, who's been recommended for looking into the impact of this on Mistral's use of YAQL.

[Jeremy Stanley (fungi)]

If we're going with a backward-incompatible breaking behavior change to YAQL, we should ideally do that in a 3.0.0 release before OpenStack 2024.1 happens. At this point we're already a week into the requirements freeze, and will need a freeze exception, which means merging and tagging the "fix" as soon as possible.

[James Slagle (james-slagle)]

My exposure to Mistral is from a user/deployer perspective given that TripleO used Mistral on the undercloud up through train. TripleO itself does not have any usage of yaql's format function, with either Mistral or Heat templates.

That being said, Mistral does allow users to upload any YAML that may contain yaql, including usage of format. Given that, it will need a similar fix as Heat/Murano, and other services that may allow a similar behavior.

[Takashi Kajinami (kajinamit)]

OK so I created a patch based on #2 and #3. Can anyone here review this or I may need to invite a few heat cores to ask them to review the change.

I'll add a config option to heat to restore the format function, once this is merged and we get this version in u-c.

Note that the latest yaql requires python >= 3.8, so the fix can't be backported to older versions which still support 3.6/3.7 (stable/zed requires python >= 3.8 so this may not be a problem).

[James Slagle (james-slagle)]

I've added Rabi Mishra who can also review from the Heat side

[Takashi Kajinami (kajinamit)]

I discussed this problem with Rabi and we agreed with removing the function now because it's a huge risk to maintain the function, and if we aim to remove it in the future then removing it now does not make much difference.

We also learned that we can replace the format function relatively easily. For example, if you have

 format("{0}-{1}", a b)

then you can replace it by

 str(a) + '-' + str(b)

using + and str function in YAQL.

I've updated the patch to remove the function directly. I'm hoping to hear any feedback from Mistral (or Murano) but if I hear nothing in a few days then I'll push this change and merge it (then request a new release of YAQL)

[Andy Botting (andybotting)]

I like this approach.

With an easy replacement for the format() function, I'll look to update my Murano apps and see how that goes in our environment and I'll post my feedback shortly.

Thanks Takashi and Rabi!

[Rabi Mishra (rabi)]

Takashi,

Thanks for the yaql patch attachment. It looks good to me. I've also proposed patches downstream to replace/fix the usage of it in TripleO.

[Takashi Kajinami (kajinamit)]

Based on the review done by Rabi I'll move ahead to submit and merge the patch later today. Please leave any concerns before that.

One note is that we have an unrelease change which removed Python 3.6/7 support and it will be part of the security fix release we may have. In case someone has opinion about it (especially if anyone think we should remove the change so that users using older releases (<zed) can upgrade yaql) then let me know.

[Jeremy Stanley (fungi)]

Avoiding dropping earlier Python interpreter support in order to be able to use the new YAQL with OpenStack Zed (which does still have an officially maintained stable branch at the moment) would be preferable. For unbranched libraries, it's usually best to avoid dropping support for maintained stable branches of consumers, as without stable branches in the library and care taken with leaving gaps in version numbering we have no way to backport such fixes.

I have no objection to opening this bug immediately if the fix is ready to be pushed, but if anyone else participating in this discussion objects please speak up now.

As soon as the change (and associated reverts to restore Python 3.6/3.7 support assuming you agree to those) merges, we need to request an expedited release and then immediately post a requirements freeze exception request. Since the only services participating in the upcoming 2024.1/Caracal coordinated release with YAQL dependencies are Heat and Mistral, the impact on release efforts will hopefully be minimized.

[Takashi Kajinami (kajinamit)]

Zed no longer supports Python 3.6/7 so the point is whether we want to care yoga and older.

https://governance.openstack.org/tc/reference/runtimes/zed.html

However, I think lowering the minimum bound in setup.cfg does not much harm, so I'll restore Python 3.6/3.7 support temporally when I submit/merge the fix for this bug and then revert it once release is done.

[Jeremy Stanley (fungi)]

Oh, thanks, I missed that it was okay as far back as Zed. While we don't (from an upstream testing perspective) need new YAQL versions to work in the unmaintained/yoga branch (its test constraints are permanently frozen), it's still nice for downstream consumers of that unmaintained release in cases where they don't have someone like a curated distribution to backport the patch to a contemporary YAQL version.

[Jeremy Stanley (fungi)]

As there were no objections raised, I've switched this to Public Security now in preparation for Takashi's YAQL patch upload to Gerrit.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/yaql/+/913228

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/yaql/+/913228
Committed: https://opendev.org/openstack/yaql/commit/83e28324e1a0ce3970dd854393d2431123a909d3
Submitter: "Zuul (22348)"
Branch: master

commit 83e28324e1a0ce3970dd854393d2431123a909d3
Author: Takashi Kajinami <email address hidden>
Date: Tue Mar 12 23:38:54 2024 +0900

    Remove format function

    The format function allowed too arbitrary access to the values being
    formatted, and this behavior caused information leakage in some cases.

    Closes-Bug: #2048114
    Change-Id: Id7ec5f267314bb7166ca64802ab47d768bb5eb89

[Jeremy Stanley (fungi)]

I've proposed a WIP update for OSSN-0093 with details about this bug now that it's public. Please review at your earliest opportunity as I'm hoping to update the canonical copy on the wiki and send it to mailing lists later today: https://review.opendev.org/c/openstack/security-doc/+/913239

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/yaql 3.0.0 release.

[Jeremy Stanley (fungi)]

https://wiki.openstack.org/wiki/OSSN/OSSN-0093 has now been announced to the usual mailing lists.

[Avinash Hanwate (ahanwate)]

Anyone requested a CVE for this issue yet?

[Jeremy Stanley (fungi)]

Normally the OpenStack VMT only reaches out to MITRE for CVE assignments on flaws in repositories we oversee, but as this is a somewhat exceptional case I'm happy to go ahead and begin the CVE request process for it with the details from the OSSN.

[kirualawliet (kirualawliet)]

Sorry for being so late to notice this review request. My bad, I made a
mistake earlier in the bug report mail by mi
sspelling my teammate's name. Can you please change 'edwardpeng' to
'Zhiniang Peng (@edwardzpeng) in OSSN-0093 and any other references'?

On Fri, 15 Mar 2024 at 01:49, Jeremy Stanley <email address hidden>
wrote:

> I've proposed a WIP update for OSSN-0093 with details about this bug now
> that it's public. Please review at your earliest opportunity as I'm
> hoping to update the canonical copy on the wiki and send it to mailing
> lists later today: https://review.opendev.org/c/openstack/security-
> doc/+/913239
> <https://review.opendev.org/c/openstack/security-doc/+/913239>
>
> ** Summary changed:
>
> - OpenStack Murano Component Information Leakage
> + Unsafe Environment Handling in MuranoPL
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2048114
>
> Title:
> Unsafe Environment Handling in MuranoPL
>
> Status in Murano:
> New
> Status in OpenStack Security Advisory:
> Won't Fix
> Status in OpenStack Security Notes:
> Confirmed
> Status in YAQL:
> Fix Released
>
> Bug description:
> Members of the VMT received the following report by E-mail from
> "kirualawliet l":
>
> Title: OpenStack Murano Component Information Leakage
>
> Reporter: lawliet and edwardpeng(@edwardzpeng) from Sangfor Security
> Research Team
>
> Products: OpenStack Murano Component
>
> Affects: All versions of Murano Component
>
> Description:
>
> The Sangfor Security Research Team has identified a critical security
> vulnerability in the Murano component of OpenStack. This vulnerability
> allows ordinary users capable of importing and deploying app packages
> to access sensitive information within OpenStack services.
> Specifically, through this exploit, unauthorized users can obtain
> Murano service account credentials, potentially escalating their
> privileges to an administrator level. Subsequently, unauthorized users
> can gain complete control over various resources, including user
> roles, hosts, and networks.
>
> The vulnerability stems from the Murano service's reliance on
> MuranoPL, an extension of the YAQL language. The YAQL library includes
> a 'format' function that mirrors Python's 'str.format' method,
> enabling attribute access.
>
> ```python
> # code snippet from yaql-2.0.0\standard_library\strings.py:569
> @specs.parameter('__format_string', yaqltypes.String())
> @specs.extension_method
> def format_(__format_string, *args, **kwargs):
> ...
> return __format_string.format(*args, **kwargs)
> ```
>
> An example of this vulnerability includes:
>
> ```
> >>> secret_key = "abcd1234"
> >>> class Test:
> ... def __init__(self):
> ... pass
> ...
> >>> t = Test()
> >>> # Exploiting the vulnerability to expose sensitive data:
> >>> malicious_format_string =
> '{0.__class__.__init__.__globals__[secret_key]}'
> >>> formatted_output = malicious_format_string.format(t)
> >>> print(formatted_output) # This line reveals the value of secret_key
> 'abcd1234'...

[Avinash Hanwate (ahanwate)]

@jeremy, Thanks! If you would like, you can be your own CNA to assign CVEs for Openstack related vulnerabilities under Red Hat as a Root CNA instead of reaching out to MITRE every time. Do let me know your thoughts.

[Jeremy Stanley (fungi)]

MITRE has assigned CVE-2024-29156 for this bug in Murano.

kirualawliet: I have adjusted the reference to your colleague's name as requested in the bug description, OSSN publication, and submitted an update request to MITRE to adjust it in the CVE metadata they have. Note that I can't correct it in mailing list posts which have already been sent, but hopefully this is sufficient.

Avinash Hanwate: The OpenStack VMT prefers to avoid notifying downstream distribution security teams early in the discussion of suspected vulnerabilities under embargo, which is why we follow a process to request CVE assignments for our advisories directly from MITRE when we're drafting them rather than Red Hat or similar CNAs. We've also got consensus among the VMT that we don't issue advisories often enough to warrant becoming our own CNA, though we do revisit that decision from time to time. As mentioned, this isn't an official security advisory issued by the OpenStack VMT anyway, but I followed a similar CVE request process to what we normally use for the sake of consistency. Thanks for the offer of assistance though!