Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-7f32-hm4h-w77q: github-slug-action use of `set-env` Runner commands which are processed via stdout

### Impact This GitHub Action use `set-env` runner commands which are processed via stdout related to GHSA-mfwh-5m23-j46w ### Patches The following versions use the recommended [Environment File Syntax](https://github.com/actions/toolkit/blob/main/docs/commands.md#environment-files). - 2.1.1 - 1.1.1 ### Workarounds None, it is strongly suggested that you upgrade as soon as possible. ### For more information If you have any questions or comments about this advisory: * Open an issue in [rlespinasse/github-slug-action](https://github.com/rlespinasse/github-slug-action)

ghsa
#git
GHSA-q73f-w3h7-7wcc: Nervos CKB Transaction which calls syscall load_cell_data_hash has nondeterministic result

### Impact Tx-pool verify transaction which inputs' script contains `load_cell_data_hash` is nondeterministic ### Workarounds Enforce tx-pool ResolvedTrascation inputs' load data is none.

GHSA-3gjh-29fv-8hr6: Nervos CKB Snappy decompress length can be very large and causes out of memory error

### Impact Adversary can create message which compressed size is less than the package limit but the decompressed length is very large such as 1G. It will cost the node many memories to process the network messages, and on the system with less than 1G memory, the process is killed directly because of out of memory error. ### Patches The node must check the decompress length before allocating the memory for the message. ### References * https://github.com/nervosnetwork/ckb/blob/687d797f1888dd05d1f38ce6d1bef3e5b9b6e38b/network/src/compress.rs#L68 * https://github.com/BurntSushi/rust-snappy/blob/master/src/decompress.rs#L106 * https://github.com/BurntSushi/rust-snappy/blob/6cfb836463b9b3ac48ca7cd15d0a50d030e95769/src/decompress.rs#L30

GHSA-wjxc-pjx9-4wvm: Nervos CKB Panic on malformed input

### Impact CKB process will panic when received malformed p2p message because of snappy, which is used to compress network messages ### References https://github.com/BurntSushi/rust-snappy/issues/29

GHSA-vjg6-93fv-qv64: Etcd auth Inaccurate logging of authentication attempts for users with CN-based auth only

### Vulnerability type Logging ### Detail etcd users who have no password can authenticate only through a client certificate. When such users try to authenticate into etcd using the Authenticate endpoint, errors are logged with insufficient information regarding why the authentication failed, and may be misleading when auditing etcd logs. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committee-psc)

GHSA-pm3m-32r3-7mfh: Etcd embed auto compaction retention negative value causing a compaction loop or a crash

### Impact Data Validation ### Detail The parseCompactionRetention function in embed/etcd.go allows the retention variable value to be negative and causes the node to execute the history compaction in a loop, taking more CPU than usual and spamming logs. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committee-psc)

GHSA-j86v-2vjr-fg8f: Etcd Gateway TLS endpoint validation only confirms TCP reachability

### Vulnerability type Cryptography ### Workarounds Refer to the [gateway documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md). The vulnerability was spotted due to unclear documentation of how the gateway handles endpoints validation. ### Detail Secure endpoint validation is performed by the etcd gateway start command when the --discovery-srv flag is enabled. However, as currently implemented, it only validates TCP reachability, effectively allowing connections to an endpoint that doesn't accept TLS connections through the HTTPS URL. The auditors has noted that appropriate documentation of this validation functionality plus deprecation of this misleading functionality is an acceptable path forward. ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Cont...

GHSA-5x4g-q5rc-36jp: Etcd pkg Insecure ciphers are allowed by default

### Vulnerability type Cryptography ### Detail The TLS ciphers list supported by etcd by default contains weak ciphers. ### Workarounds Provide a desired ciphers using the `--cipher-suites` flag as described with examples in the [security documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/security.md) ### References Find out more on this vulnerability in the [security audit report](https://github.com/etcd-io/etcd/blob/master/security/SECURITY_AUDIT.pdf) ### For more information If you have any questions or comments about this advisory: * Contact the [etcd security committee](https://github.com/etcd-io/etcd/blob/master/security/security-release-process.md#product-security-committee-psc)

GHSA-hjqq-29pw-96wj: Nervos CKB node panics when processing a block which parent timestamp is too new

### Impact Adversary can initiate DOS attack by broadcasting two consecutive blocks with timestamps in the future. ### Patches Please upgrade to v0.34.1

GHSA-r9rv-9mh8-pxf4: Nervos CKB BlockTimeTooNew should not be considered as invalid block

### Impact Currently, when a node receives a block in future according to its local wall clock, it will mark the block as invalid and ban the peer. If the header's timestamp is more than 15 seconds ahead of our current time. In that case, the header may become valid in the future, and we don't want to disconnect a peer merely for serving us one too-far-ahead block header, to prevent an attacker from splitting the network by mining a block right at the 15 seconds boundary. ### Patches Upgrade to v0.33.1 or above. ### Workarounds Don't ban peer serving too-far-ahead block header.