Security
Headlines
HeadlinesLatestCVEs

Tag

#git

GHSA-r56x-j438-vw5m: vyper performs double eval of the slice args when buffer from adhoc locations

### Summary Using the `slice` builtin can result in a double eval vulnerability when the buffer argument is either `msg.data`, `self.code` or `<address>.code` and either the `start` or `length` arguments have side-effects. A contract search was performed and no vulnerable contracts were found in production. Having side-effects in the start and length patterns is also an unusual pattern which is not that likely to show up in user code. It is also much harder (but not impossible!) to trigger the bug since `0.3.4` since the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914). ### Details It can be seen that the `_build_adhoc_slice_node` function of the `slice` builtin doesn't cache the mentioned arguments to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L244 As such, they can be evaluated multiple times (instead of retrieving the value from the stack). ### PoC with Vyper version `0....

ghsa
#vulnerability#git#perl
GHSA-3whq-64q2-qfj6: vyper performs double eval of raw_args in create_from_blueprint

### Summary Using the `create_from_blueprint` builtin can result in a double eval vulnerability when `raw_args=True` and the `args` argument has side-effects. A contract search was performed and no vulnerable contracts were found in production. In particular, the `raw_args` variant of `create_from_blueprint` was not found to be used in production. ### Details It can be seen that the `_build_create_IR` function of the `create_from_blueprint` builtin doesn't cache the mentioned `args` argument to the stack: https://github.com/vyperlang/vyper/blob/cedf7087e68e67c7bfbd47ae95dcb16b81ad2e02/vyper/builtins/functions.py#L1847 As such, it can be evaluated multiple times (instead of retrieving the value from the stack). ### PoC The vulnerability is demonstrated in the following `boa` test: ``` vyper src1 = """ c: uint256 """ deployer = """ created_address: public(address) deployed: public(uint256) @external def get() -> Bytes[32]: self.deployed += 1 return b'' @external def create...

GHSA-m2v9-w374-5hj9: vyper default functions don't respect nonreentrancy keys

### Summary Prior to v0.3.0, `__default__()` functions did not respect the `@nonreentrancy` decorator and the lock was not emitted. This is a known bug and was already visible in the issue tracker (https://github.com/vyperlang/vyper/issues/2455), but it is being re-issued as an advisory so that tools relying on the advisory publication list can incorporate it into their searches. A contract search was additionally performed and no vulnerable contracts were found in production. ### PoC ```vyper @external @payable @nonreentrant("default") def __default__(): pass ``` after codegen: ``` [seq, [if, [lt, calldatasize, 4], [goto, fallback]], [mstore, 28, [calldataload, 0]], [with, _func_sig, [mload, 0], seq], [seq_unchecked, [label, fallback], [seq, pass, # Line 5 pass, pass, # Line 4 stop]]], ``` ### Impact No vulnerable production contracts were found. Additionally, using a lock on a `default` function is a very sparsely used patte...

GHSA-5jrj-52x8-m64h: vyper performs double eval of the argument of sqrt

### Summary Using the `sqrt` builtin can result in multiple eval evaluation of side effects when the argument has side-effects. The bug is more difficult (but not impossible!) to trigger as of 0.3.4, when the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914). A contract search was performed and no vulnerable contracts were found in production. ### Details It can be seen that the `build_IR` function of the `sqrt` builtin doesn't cache the argument to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L2151 As such, it can be evaluated multiple times (instead of retrieving the value from the stack). ### PoC With at least Vyper version `0.2.15+commit.6e7dba7` the following contract: ```vyper c: uint256 @internal def some_decimal() -> decimal: self.c += 1 return 1.0 @external def foo() -> uint256: k: decimal = sqrt(self.some_decimal()) return self.c ``` passes the fol...

GHSA-346h-749j-r28w: PHPECC vulnerable to multiple cryptographic side-channel attacks

### ECDSA Canonicalization PHPECC is vulnerable to malleable ECDSA signature attacks. ### Constant-Time Signer When generating a new ECDSA signature, the GMPMath adapter was used. This class wraps the GNU Multiple Precision arithmetic library (GMP), which does not aim to provide constant-time implementations of algorithms. An attacker capable of triggering many signatures and studying the time it takes to perform each operation would be able to leak the secret number, `k`, and thereby learn the private key. ### EcDH Timing Leaks When calculating a shared secret using the `EcDH` class, the scalar-point multiplication is based on the arithmetic defined by the `Point` class. Even though the library implements a Montgomery ladder, the `add()`, `mul()`, and `getDouble()` methods on the `Point` class are not constant-time. This means that your ECDH private keys are leaking information about each bit of your private key through a timing side-channel.

GHSA-7j7j-66cv-m239: ZITADEL's Improper Lockout Mechanism Leads to MFA Bypass

### Impact ZITADEL provides users the possibility to use Time-based One-Time-Password (TOTP) and One-Time-Password (OTP) through SMS and Email. While ZITADEL already gives administrators the option to define a `Lockout Policy` with a maximum amount of failed password check attempts, there was no such mechanism for (T)OTP checks. ### Patches 2.x versions are fixed on >= [2.50.0](https://github.com/zitadel/zitadel/releases/tag/v2.50.0) ### Workarounds There is no workaround since a patch is already available. ### References None ### Questions If you have any questions or comments about this advisory, please email us at [[email protected]](mailto:[email protected]) ### Credits Thanks to Jack Moran and Ethan from zxsecurity and Amit Laish from GE Vernova for finding and reporting the vulnerability.

GHSA-25w4-hfqg-4r52: Quarkus: authorization flaw in quarkus resteasy reactive and classic

A flaw was found in Quarkus. When a Quarkus RestEasy Classic or Reactive JAX-RS endpoint has its methods declared in the abstract Java class or customized by Quarkus extensions using the annotation processor, the authorization of these methods will not be enforced if it is enabled by either 'quarkus.security.jaxrs.deny-unannotated-endpoints' or 'quarkus.security.jaxrs.default-roles-allowed' properties.

GHSA-9wmf-xf3h-r8pr: Jberet: jberet-core logging database credentials

A vulnerability was found in jberet-core logging. An exception in 'dbProperties' might display user credentials such as the username and password for the database-connection.

GHSA-mv64-86g8-cqq7: Quarkus: security checks in resteasy reactive may trigger a denial of service

A flaw was discovered in the RESTEasy Reactive implementation in Quarkus. Due to security checks for some JAX-RS endpoints being performed after serialization, more processing resources are consumed while the HTTP request is checked. In certain configurations, if an attacker has knowledge of any POST, PUT, or PATCH request paths, they can potentially identify vulnerable endpoints and trigger excessive resource usage as the endpoints process the requests. This can result in a denial of service.

GHSA-x5m7-63c6-fx79: Cluster Monitoring Operator contains a credentials leak

A credentials leak vulnerability was found in the cluster monitoring operator in OCP. This issue may allow a remote attacker who has basic login credentials to check the pod manifest to discover a repository pull secret.