komodo master: 1 vulnerabilities (highest severity is: 5.3)

[TheComputerGenie]

Vulnerable Library - komodo

Komodo

Library home page: https://github.com/KomodoPlatform/komodo.git

Found in HEAD commit: 0adeeabdd484ef40539d1275c6a765f5c530ea79

Vulnerable Source Files (1)

/src/cryptoconditions/src/include/ed25519/src/ed25519.h

Vulnerabilities

CVE	Severity	CVSS	Dependency	Type	Fixed in (komodo version)	Automated Remediation Possible**
CVE-2024-45193	Medium	5.3	komodo	Direct	N/A	❌

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2024-45193

Vulnerable Library - komodo

Komodo

Library home page: https://github.com/KomodoPlatform/komodo.git

Found in HEAD commit: 0adeeabdd484ef40539d1275c6a765f5c530ea79

Found in base branch: master

Vulnerable Source Files (1)

/src/cryptoconditions/src/include/ed25519/src/ed25519.h

Vulnerability Details

An issue was discovered in Matrix libolm through 3.2.16. There is Ed25519 signature malleability due to lack of validation criteria (does not ensure that S < n). This refers to the libolm implementation of Olm. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Publish Date: 2024-08-22

URL: CVE-2024-45193

CVSS 3 Score Details (5.3)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: None
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

[DeckerSU]

Thanks for bringing this to our attention. The vulnerable ed25519_verify function is only called in chains that use Crypto Conditions (CC), which is already at the end of life (EOL) and currently unsupported. We still keep CC in the codebase for backward compatibility with these chains. Chains that don’t use CC, such as KMD itself and 98% of others, are not affected by CVE-2024-45192.

Regarding the CC library, we are actively working on a fix. One possible solution is switching to libsodium for validating ed25519 signatures. However, this is not set in stone, as the final solution could involve completely removing the CC library from the daemon and discontinuing support for such chains.

Stay tuned for updates with more information, and thank you once again. I also want to explicitly mention that KMD is not affected by CVE-2024-45192, as this code is never executed in chains where CC is disabled.

[TheComputerGenie]

I also want to explicitly mention that KMD is not affected by CVE-2024-45192, as this code is never executed in chains where CC is disabled

Correct, just wanted to pass on what came through the checks in my fork.
The same applies to #631 (CC related and only py tests)

[DeckerSU]

Btw, this code isn’t only present in the CC library or libolm. For instance, if you look at the popular libtorrent project, which serves as the foundation for many torrent clients like Deluge and qBittorrent, it also contains the same code: link to code. This means there’s also nothing in place to prevent signature malleability, but for most protocols, it’s not a significant issue.

As for CC itself, if I recall correctly, Ed25519 signatures aren’t used for anything critical in libcc (though I could be wrong, since the CC-related parts were written by others). Either way, this will be resolved soon, whether through a fix or an explanation of why it’s not critical in this case.

[DeckerSU]

Closed as fixed in #632 .