Security
Headlines
HeadlinesLatestCVEs

Tag

#perl

Ubuntu Security Notice USN-6761-1

Ubuntu Security Notice 6761-1 - It was discovered that Anope did not properly process credentials for suspended accounts. An attacker could possibly use this issue to normally login to the platform as a suspended user after changing their password.

Packet Storm
#vulnerability#ubuntu#perl#auth
Understanding Red Hat’s response to the XZ security incident

March 29, 2024 is a day that will hardly be forgotten by the open source community: Andres Freund disclosed his findings about the compromise in the xz compression library, which would enable an attacker to silently gain access to a targeted affected system. How did that coordination work under the hood? In this article we will give a behind the scenes glimpse into what this looked like at Red Hat.DiscoveryOn Wednesday, March 27, Andres contacted the Debian security team via their contact email (security@debian.org) and let them know about the oddities he found in a SSH slowdown when using a n

13.4M Kaiser Insurance Members Affected by Data Leak to Online Advertisers

Tracking code used for keeping tabs on how members navigated through the healthcare giant's online and mobile sites was oversharing a concerning amount of information.

Ubuntu Security Notice USN-6744-3

Ubuntu Security Notice 6744-3 - USN-6744-1 fixed a vulnerability in Pillow. This update provides the corresponding updates for Ubuntu 24.04 LTS. Hugo van Kemenade discovered that Pillow was not properly performing bounds checks when processing an ICC file, which could lead to a buffer overflow. If a user or automated system were tricked into processing a specially crafted ICC file, an attacker could possibly use this issue to cause a denial of service or execute arbitrary code.

CISO Corner: Evil SBOMs; Zero-Trust Pioneer Slams Cloud Security; MITRE's Ivanti Issue

Our collection of the most relevant reporting and industry perspectives for those guiding cybersecurity strategies and focused on SecOps. Also included: security license mandates; a move to four-day remediation requirements; lessons on OWASP for LLMs.

GHSA-ppx5-q359-pvwj: vyper's range(start, start + N) reverts for negative numbers

### Summary When looping over a `range` of the form `range(start, start + N)`, if `start` is negative, the execution will always revert. ### Details This issue is caused by an incorrect assertion inserted by the code generation of the range (`stmt.parse_For_range()`): https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/codegen/stmt.py#L286-L287 This assertion was introduced in https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868 to fix https://github.com/advisories/GHSA-6r8q-pfpv-7cgj. The issue arises when `start` is signed, instead of using `sle`, `le` is used and `start` is interpreted as an unsigned integer for the comparison. If it is a negative number, its 255th bit is set to `1` and is hence interpreted as a very large unsigned integer making the assertion always fail. ### PoC ```Vyper @external def foo(): x:int256 = min_value(int256) # revert when it should not since we have the following assertion...

GHSA-xchq-w5r3-4wg3: vyper performs incorrect topic logging in raw_log

### Summary Incorrect values can be logged when `raw_log` builtin is called with memory or storage arguments to be used as topics. A contract search was performed and no vulnerable contracts were found in production. In particular, no uses of `raw_log()` were found at all in production; it is apparently not a well-known function. ### Details The `build_IR` function of the `RawLog` class fails to properly unwrap the variables provided as topics. Consequently, incorrect values are logged as topics. ### PoC ```vyper x: bytes32 @external def f(): self.x = 0x1234567890123456789012345678901234567890123456789012345678901234 raw_log([self.x], b"") # LOG1(offset:0x60, size:0x00, topic1:0x00) y: bytes32 = 0x1234567890123456789012345678901234567890123456789012345678901234 raw_log([y], b"") # LOG1(offset:0x80, size:0x00, topic1:0x40) ``` ### Impact Incorrect values can be logged which may result in unexpected behavior in client-side applications relying on these logs.

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-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...