Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
0.39.00.37.10.38.20.36.10.35.2· Vendor fix available
Issue
Impact The faulty nodes will reject transactions which calls loadcelldata syscall but the input cell is still in the mempool. They also ban other nodes and cause the network separation. Patches 0.35.2, 0.36.1, 0.37.1, 0.38.2
Recommended action: Upgrade to 0.39.0, 0.38.2, 0.37.1 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There's a bug in the pool statistics that when conflicting transactions are removed from the pool, they are not subtracted from the statics. Finally, the transaction pool keeps full and reject all transactions. Patches 0.39.2 Workarounds Restart the CKB node.
Recommended action: Upgrade to 0.39.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Tx-pool verify transaction which inputs' script contains loadcelldatahash is nondeterministic Workarounds Enforce tx-pool ResolvedTrascation inputs' load data is none.
Recommended action: Upgrade to 0.34.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 0.34.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 0.34.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Adversary can initiate DOS attack by broadcasting two consecutive blocks with timestamps in the future. Patches Please upgrade to v0.34.1
Recommended action: Upgrade to 0.34.1 or 0.33.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.33.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The p2p discovery protocol assumes that the peer IP must be valid IPv4 address.
Recommended action: Upgrade to 0.34.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The P2P protocols lack of rate limit. For example, in relay protocol, when a node receives a broadcasted txhashes, it will mark it in memory to avoid duplicated requests. code → . It is easy to establish a DoS attach by generating random tx hashes. Impact It affects all nodes connected to the P2P network. Workarounds Apply rate limit on the data sent to CKB P2P port.
Recommended action: Upgrade to 0.34.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
via bounty@nervos.org There are multiple type conversions in ckb that unsafely cast between byte pointers and other types of pointers. This results in unaligned pointers, which are not allowed by the Rust language, and are considered undefined behavior, meaning that the compiler is free to do anything with code. This can lead to unpredictable bugs that can become security vulnerabilities. Some of the bugs here could potentially lead to buffer overreads in malformed data (it's not clear to me as I haven't investigated the practical impact of these bugs). Two of these (in blockchain.rs) do not create unaligned data. They do though perform an unsafe operation that may not uphold the invariants of the safe function they are in, and could lead to undefined behavior and buffer overreads on malformed input. These are of the same nature as those in my previous report about the molecule crate. Patch attached for commit 1b09e37c8e1b7945495cd18d9782417fbe51e986 that fixes all cases I know of at…
Recommended action: Upgrade to 0.31.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Workarounds forbid request genesis through network request forbid requesting duplicate data through network request
Recommended action: Upgrade to 0.101.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact https://github.com/nervosnetwork/ckb/blob/v0.101.2/script/src/verify.rs#L871-L879 TypeIdSystemScript resume handle is not correct when maxcycles is not enough, ScriptError::ExceededMaximumCycles will be raised directly ranther than suspend as expect, and also because scriptgroup execution order is random, so this will happen randomly.
Recommended action: Upgrade to 0.102.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact fn HeaderChecker#checkvalid skipped main chain checking after this PR: https://github.com/nervosnetwork/ckb/pull/1646/files#diff-c4e017b67c1b3005ca0c446a9b0879571aa36a858b1f7ddd1b9328a884e3214bR171-R176 It will cause network forking if one transaction is using a forked block header which is not exists in local node's storage. Patches 0.101.1 and later versions
Recommended action: Upgrade to 0.101.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a transaction contains a dep group with many cells, the resources required to process it are not linear to the transaction size nor spent script cycles. Patches In 0.43.3, nodes drop the transactions relayed to them when they contain a dep group with more than 64 cells. They do not ban peers who send them such transactions. In 0.100, the consensus disallow transactions using a dep group with more than 64 cells. Peers relaying such transaction must be banned. Blocks committing such transactions must be rejected.
Recommended action: Upgrade to 0.43.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A remote attacker could exploit this vulnerability to exhaust ckb process memory of an affected node. Patches Upgrade to 0.43.1 or later. References After resolving the outpoints of one dep group, we put the corresponding content into a vec ( https://github.com/nervosnetwork/ckb/blob/v0.42.0/util/types/src/core/cell.rs#L600-L617 ), there is a vulnerability to a memory dos attack because there is no determination of whether the outpoints is duplicated. PoC: DoS cost: 25.6 KB 150 + deptx outpoints capacity ( 36 150 100 = 540000 ) = 4380000 CKB Send 50 dostx, memory exhausted: (25.6 KB 150 100) 50 = 19.2 GB
Recommended action: Upgrade to 0.43.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the ckb crate before 0.40.0 for Rust. A getblocktemplate RPC call may fail in situations where it is supposed to select a Nervos CKB blockchain transaction with a higher fee rate than another transaction.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the ckb crate before 0.40.0 for Rust. Attackers can cause a denial of service (Nervos CKB blockchain node crash) via a dead call that is used as a DepGroup.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the ckb sync protocol, SyncState maintains a HashMap called 'misbehavior' that keeps a score of a peer's violations of the protocol. This HashMap is keyed to PeerIndex (an alias for SessionId), and entries are never removed from it. SessionId is an integer that increases monotonically with every new connection. A remote attacker can manipulate this HashMap to grow forever, resulting in degraded performance and ultimately a panic on allocation failure or being killed by the OS, depending on the platform. This is a critical severity security bug. It could be exploited to create a targeted or network-wide denial of service, to reduce the hash power of the network as part of a 51% attack, and perhaps in other creative ways. An attack is trivial: 1. connect to another node 2. send an invalid sync protocol request, such as SendHeaders for non-consecutive blocks 3. disconnect 4. repeat
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The RPC getblocktemplate fails when a cell has been used as a cell dep and an input in the different transactions. Say cell C is used as a dep group in the transaction A, and is destroyed in the transaction B. The node adds transaction A first, then B into the transaction pool. They are both valid. But when generating the block template, if the fee rate of B is higher, it comes before A, which will invalidate A. Currently the RPC getblocktemplate will fail instead of dropping A. Patch First, the getblocktemplate should not fail but dropping the conflict transactions. Then we can propose solution to this issue. Here is an example. When a transaction is added to the pool, the pool must consider it depending on all the transactions which dep cell (direct or indirect via dep group) has been destroyed in this transaction. Because future transactions using the destroyed cells as dep will be rejected, the spending transaction only need to wait for all the existing dep transactions on…
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's easy to create a malign transaction which uses the dead cell as the DepGroup in the DepCells. The transaction can crash all the receiving nodes.
Recommended action: Upgrade to 0.40.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.