Erlang SSH vulnerability CVE-2025-32433

General
1

HI,

Does ConfD suffer from this vulnerability (CVE-2025-32433)?
If so, when a fix is expected and on what versions?

We are currently using 8.0.6

Thanks

1 Like
2

We are aware of this CVE and are investigating the issue.

3

And there is a specific notice for ConfD that says:

  1. While these products are vulnerable because they accept unauthenticated channel request messages, due to the product configuration they are not vulnerable to RCE.
4

Thanks.

Does it mean that overall anyone using ConfD is not vulnerable?
When stating “due to the product configuration” does it mean confd does not allow remote code execution?
Is there any configuration we need to do in confd.conf to disable remote code execution, or it is blocked anyway?

Thanks again

5

It says that ConfD is not vulnerable to RCE, which was the full potential impact of the vulnerability. And no confd.conf configuration is required to mitigate the potential of RCE. The ‘product configuration’ refers to how OTP is used.

6

@sbarvick, do you know what prevents confd from being vulnerable from the RCE?

All known exploits of the unauthenticated channel request messages are performing erlang function calls in the body of the message. Possible example in proof-of-concepts are to use file:write_file() calls that could write to any filename that is writable by the user the confd is running under. Others call os:cmd() calls that can perform any system OS calls that can include invoking other installed utilities to transfer information (i.e. Call curl to copy off files to controlled server, or to download program or script that can setup reverse call back to controlled server for command and control). Another could be to simply call init:stop() to stop the erlang process.

All of these are exploitable in unpatched erlang/OTP installations with simple example setup of a vulnerable SSH server. None of them seem to work against the unpatched versions of ConfD. One way I have found to make the simple example SSH servers non-vulnerable to the current RCE is to add “{exec, disabled}” as an option to the ssh:daemon(). Since the daemon is told to not allow any execution of commands, none of the commands sent in the unauthenticated channel request messages are run, making them uneffectual. Perhaps this is the reason confd is not vulnerable, or perhaps the confd code is fully specifying the exec or shell implementation to provide the confd CLI or NETCONF parser interfaces, which as a result of their custom implementation do not parse the command passed to them, since their custom processing requires additional steps to authenticate the users though the configured AAA layers before evaluating the NACM rules that apply to limit the CLI/NETCONF commands that could be run.

If confd really is not vulnerable to the RCE, what else could it be vulnerable to that prevented Cisco from just saying it was not vulnerable or lowering the CVSS score as interpreted to the confd implementation that (unless I am still missing something) is NOT a 10.0 without the RCE?

7

Hi Aaron,

You seem to have a very good understanding of Erlang channel handling. It is in the configuration of the channels that would be vulnerable, but aren’t, that Cisco is referring to in the ‘product configuration’ statement that seems to be intended to lessen the effective severity of the CVE in unpatched versions.

I can’t speak for Cisco, but they addressed the severity of unpatched versions and then very quickly delivered patches to mitigate the issue so I’m not surprised that there is no statement about potential issues beyond the important statement that RCE is not possible.

I hope this helps. It is a common question.

Best,
Scott

8

I am still failing to understand WHAT was the reason the non-updated versions of confd are not susceptible to the RCE. Does the confd code already configure the ‘exec’ (and perhaps the ‘shell’) options for the ssh daemon set to be disabled? If so, then it is possible that NONE of the versions of confd have ever been susceptible to attack of the vulnerability disclosed in the default config of the Erlang/OTP ssh code. This would allow for a more clear an concise response for products using confd (regardless of the version of confd in the particular version of the product firmware).

Also, I am failing to understand WHAT was changed in the updated versions, that is supposedly fixing confd (even if it is not susceptible to the attack). If I take the 7.7.19.1 or 8.0.17.1 patch releases, the only difference that was listed in this version versus the previous release was documented as (from 7.7.19.1):

ConfD-7.7.19.1 [April 24, 2025]
===============================
Corrections:

If I take a look a the VERSION file see the following that indicates the the OTP version was 22.3.4.17:

ConfD version 7.7.19.1 for linux on x86_64.
Revision: 46eccc0ca1735aec3ac2586d6b8e9eb8258d0dc9 (GIT)
Date: Sun Apr 27 01:47:52 CEST 2025
DOCUMENTATION_PACKAGE=confd-7.7.19.1.doc.tar.gz
JAVA_PACKAGE=confd-7.7.19.1.java.tar.gz
EXAMPLE_PACKAGE=confd-7.7.19.1.examples.tar.gz
Erlang/OTP version: 22.3.4.17

This is the same Erlang/OTP version used by confd from what I see in all versions from 7.4.4+, 7.5.3+, 7.6+, 7.7+, 7.8+, and 8.0+.

So the fix was not the Erlang OTP update to any of the 25.3.2.20, 26.2.5.11, or 27.3.3 upstream patched versions, and even if the equivalent of the upstream patch was backported and applied to the confd version of the code no change was made to indicate 22.3.4.17 has been modified (i.e. 22.3.4.17.1 or 22.3.4.17-p1, etc).

It is also an interesting observation (I just realized), that although the 7.7 branch got whatever change was made the 7.8 branch was not updated.

9

Hi Aaron,

I see several questions so I will try to answer in a way that makes sense.

  1. I believe it is fair to say (without saying technically how) that Cisco’s response is saying that NONE of the more recent versions of ConfD (7+, we are not looking back at the older versions) were susceptible to the attack of the vulnerability disclosed in the default config of the Elrang/OTP ssh code, even before the patches. This is what they mean with the phrase ‘product configuration’. However that was for the RCE potential, but it is also fair to say that a patch was still a good thing to do to eliminate the code paths that allowed unauthenticated processing to go further than necessary (even though they could not get as far as RCE).

  2. The specifics of the patch are not disclosed in the CHANGES files. CHANGES files have always just been at the level of the user experience, not the details of each code change.

  3. Regarding the OTP version, we maintain a fork of OTP that we patch when we need to and take community updates when we can. OTP 25 and later were patched by the community so those versions are reflected in our SBOM for releases later than 8.1. For releases 8.1 and older, the fork was patched with the appropriate fix but the OTP version was not changed.

  4. Finally ConfD 7.8 is end of support so no change has been made to that release branch.

I hope this helps. I’m sure these are common questions about this important issue.

Best,
Scott

1 Like