Security Vulnerabilities, CVEs, related to CWE-327

Windows Authentication Elevation of Privilege Vulnerability

IBM MQ Operator 2.0.0 LTS, 2.0.18 LTS, 3.0.0 CD, 3.0.1 CD, 2.4.0 through 2.4.7, 2.3.0 through 2.3.3, 2.2.0 through 2.2.2, and 2.3.0 through 2.3.3 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 283905.

Dell PowerScale OneFS, versions 8.2.2.x through 9.5.0.x contains a use of a broken cryptographic algorithm vulnerability. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to information disclosure.

Vyper is a Pythonic Smart Contract Language for the EVM. There is an error in the stack management when compiling the `IR` for `sha3_64`. Concretely, the `height` variable is miscalculated. The vulnerability can't be triggered without writing the `IR` by hand (that is, it cannot be triggered from regular vyper code). `sha3_64` is used for retrieval in mappings. No flow that would cache the `key` was found so the issue shouldn't be possible to trigger when compiling the compiler-generated `IR`. This issue isn't triggered during normal compilation of vyper code so the impact is low. At the time of publication there is no patch available.

Dell PowerScale OneFS 8.2.x through 9.6.0.x contains a use of a broken or risky cryptographic algorithm vulnerability. A remote unprivileged attacker could potentially exploit this vulnerability, leading to compromise of confidentiality and integrity of sensitive information

Dell Secure Connect Gateway, 5.18, contains an Inadequate Encryption Strength Vulnerability. An unauthenticated network attacker could potentially exploit this vulnerability, allowing an attacker to recover plaintext from a block of ciphertext.

IBM Semeru Runtime 8.0.302.0 through 8.0.392.0, 11.0.12.0 through 11.0.21.0, 17.0.1.0 - 17.0.9.0, and 21.0.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 281222.

Ursa is a cryptographic library for use with blockchains. The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model. Notably, a malicious verifier may be able to generate a unique identifier for a holder providing a verifiable presentation that includes a Non-Revocation proof. The impact of the flaw is that a malicious verifier may be able to determine a unique identifier for a holder presenting a Non-Revocation proof. Ursa has moved to end-of-life status and no fix is expected.

Ursa is a cryptographic library for use with blockchains. The revocation schema that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. A verifier may verify a credential from a holder as being "not revoked" when in fact, the holder's credential has been revoked. Ursa has moved to end-of-life status and no fix is expected.

Gessler GmbH WEB-MASTER user account is stored using a weak hashing algorithm. The attacker can restore the passwords by breaking the hashes stored on the device.

Use of a Broken or Risky Cryptographic Algorithm vulnerability in B&R Industrial Automation Automation Runtime (SDM modules). The FTP server used on the B&R Automation Runtime supports unsecure encryption mechanisms, such as SSLv3, TLSv1.0 and TLS1.1. An network-based attacker can exploit the flaws to conduct man-in-the-middle attacks or to decrypt communications between the affected product clients.   This issue affects Automation Runtime: from 14.0 before 14.93.

DeviceFarmer stf v3.6.6 suffers from Use of a Broken or Risky Cryptographic Algorithm.

Ylianst MeshCentral 1.1.16 suffers from Use of a Broken or Risky Cryptographic Algorithm.

Ember ZNet between v7.2.0 and v7.4.0 used software AES-CCM instead of integrated hardware cryptographic accelerators, potentially increasing risk of electromagnetic and differential power analysis sidechannel attacks.

IBM PowerSC 1.3, 2.0, and 2.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 275129.

IBM PowerSC 1.3, 2.0, and 2.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 275117.

An issue was discovered in blinksocks version 3.3.8, allows remote attackers to obtain sensitive information via weak encryption algorithms in the component /presets/ssr-auth-chain.js.

An issue was discovered in bcoin-org bcoin version 2.2.0, allows remote attackers to obtain sensitive information via weak hashing algorithms in the component \vendor\faye-websocket.js.

HCL DRYiCE MyXalytics is impacted by the use of a broken cryptographic algorithm for encryption, potentially giving an attacker ability to decrypt sensitive information.

IBM WebSphere Application Server 8.5 and 9.0 could provide weaker than expected security for outbound TLS connections caused by a failure to honor user configuration. IBM X-Force ID: 274812.

IBM WebSphere Application Server Liberty 17.0.0.3 through 24.0.0.2 could provide weaker than expected security for outbound TLS connections caused by a failure to honor user configuration. IBM X-Force ID: 274711.

The authentication cookies are generated using an algorithm based on the username, hardcoded secret and the up-time, and can be guessed in a reasonable time.

DataHub is an open-source metadata platform. The HMAC signature for DataHub Frontend sessions was being signed using a SHA-1 HMAC with the frontend secret key. SHA1 with a 10 byte key can be brute forced using sufficient resources (i.e. state level actors with large computational capabilities). DataHub Frontend was utilizing the Play LegacyCookiesModule with default settings which utilizes a SHA1 HMAC for signing. This is compounded by using a shorter key length than recommended by default for the signing key for the randomized secret value. An authenticated attacker (or attacker who has otherwise obtained a session token) could crack the signing key for DataHub and obtain escalated privileges by generating a privileged session cookie. Due to key length being a part of the risk, deployments should update to the latest helm chart and rotate their session signing secret. All deployments using the default helm chart configurations for generating the Play secret key used for signing are affected by this vulnerability. Version 0.11.1 resolves this vulnerability. All users are advised to upgrade. There are no known workarounds for this vulnerability.

crypto-js is a JavaScript library of crypto standards. Prior to version 4.2.0, crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 4.2.0 contains a patch for this issue. As a workaround, configure crypto-js to use SHA256 with at least 250,000 iterations.

CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations.