| Affected Clients | UID | Bug | Type | Summary | Links | Security Advisory | Reported | Fixed Date | Published | CVSS | Severity | CVE | Bounty Hunter | Bounty Points | Bounty Reward (USD) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Lighthouse | CL-2020-01 | Network agent crashes lighthouse discovery | DoS | A network agent, capable of creating a large number of discv5 sessions, crashed the discovery service on several lighthouse nodes. | ethereum/public-attacknets#4 | 2020-03-27 | 2020-07-21 | 2021-12-01 | Medium | Jonny Rhea | 500 | 1000 | |||
| Prysm | CL-2020-02 | DoS Attack | DoS | Prysm nodes are vulnerable to a DoS attack that prevents them from participating in consensus. | ethereum/public-attacknets#12 | https://groups.google.com/g/golang-announce/c/NyPIaucMgXo/m/GdsyQP6QAAAJ | 2020-07-01 | 2020-08-06 | 2021-12-01 | High | Jonny Rhea | 1250 | 2500 | ||
| Teku | CL-2020-03 | DoS Attack | DoS | Teku nodes are vulnerable to a simple DoS attack that prevents them from participating in consensus. | ethereum/public-attacknets#7 | 2020-07-26 | 2020-07-31 | 2021-12-01 | High | Jonny Rhea | 1250 | 2500 | |||
| Prysm | CL-2020-04 | L4 Distributed Denial of Service attack ruins the P2P connectivity and stops finality | DoS | Prysm nodes are vulnerable to L4 DDoS attacks. The attacker can stop finality for any amount of time. | ethereum/public-attacknets#9 | 2020-07-29 | 2020-07-30 | 2021-12-01 | High | Alexander Sadovskyi | 2500 | 5000 | |||
| Prysm | CL-2020-05 | Remote crash nodes over p2p | DoS | There is (was) a bug in Prysm that made it possible for an attacker to crash arbitrary remote nodes via p2p protocol. | ethereum/public-attacknets#11 | 2020-07-29 | 2020-07-29 | 2021-12-01 | High | Martin Holst Swende | 2500 | 0 | |||
| All clients | CL-2020-06 | DoS Attack due to Discv5 spec | DoS | A DoS attack that exploits an RLP ecoding error (and lack of packet size validation) that eventually causes client crash and reply with a flood of WHOAREYOU messages that are larger than the attackers message. | https://hackmd.io/Bmq_GlVXQtu3Z-YfVVFioA?view | 2020-08-25 | 2020-10-07 | 2021-12-01 | High | Jonny Rhea | 5000 | 10000 | |||
| Teku | CL-2020-07 | DoS Attack via gossipsub | DoS | Teku nodes are vulnerable to a resource exhaustion attack caused by allocating a buffer from an unchecked attacker-controlled length field causing a DoS condition that prevents them from participating in consensus. | ethereum/public-attacknets#15 | 2020-09-04 | 2020-09-04 | 2021-12-01 | High | Tintin | 2500 | 5000 | |||
| Teku | CL-2020-08 | Crash discovery service with malformed WHOAREYOU packet | DoS | Using a malformed RLP packet, we crash the discovery service of Teku permanently. | ethereum/public-attacknets#18 | 2020-09-08 | 2020-09-10 | 2021-12-01 | High | Antoine Toulme | 2500 | 5000 | |||
| Teku | CL-2020-09 | DoS Attack: UDP random 46 bytes packets | DoS | Random UDP packets of 46 bytes, sent over multiple UDP source ports, take down Teku. | ethereum/public-attacknets#16 | 2020-09-08 | 2020-09-09 | 2021-12-01 | High | Antoine Toulme | 2500 | 5000 | |||
| Prysm | CL-2020-10 | Starting gRPC with missing SSL credentials does not fail | Bug | Prysm currently marks the node as unhealthy, but will continue to serve an unsecured gRPC server. This should be changed to a fatal condition on startup. |
prysmaticlabs/prysm#7577 | 2020-10-11 | 2020-10-23 | 2021-12-01 | Low | Stefan Kobrc | 1700 | 3400 | |||
| None | CL-2020-11 | py_ecc arbitrary signature verification bypass | Crypto | In elliptic curves, the most dangerous point is infinity O. This is because xO = O for all x which means that all arithmetic verification becomes trivially satisfied. Therefore, checking for infinity is crucial. py_cc checks for infinity but the check is not accurate | ethereum/py_ecc#107 | 2020-11-13 | 2020-11-16 | 2021-12-01 | High | Quan | 5000 | 10000 | |||
| None | CL-2020-12 | py_ecc signature malleability leads to transaction malleability | Crypto | BLS point (de)compression issue | ethereum/py_ecc#108 | 2020-11-13 | 2020-11-16 | 2021-12-01 | High | Quan | 2000 | 4000 | |||
| None | CL-2020-13 | blst empty message crash Go bindings | Crypto | https://github.com/supranational/blst/commit/64a22698fcfae9845c07c5030adadaab4a258dd3 https://github.com/supranational/blst/commit/9ba7210542a1dd582f0acb8150c60f2caa953ed0 |
2020-11-27 | 2020-12-01 | 2021-12-01 | Medium | Quan | 2500 | 5000 | ||||
| None | CL-2020-14 | herumi empty message/signature crash | Crypto | 2020-11-28 | 2021-12-01 | Medium | Quan | ||||||||
| None | CL-2020-15 | signature bypass for zero public keys | Crypto | 2020-11-28 | 2021-12-01 | High | Quan | ||||||||
| Teku | CL-2020-16 | Subscriptions hashmap CPU pain | DoS | Subscriptions are stored in a Hashmap. Subscriptions are keyed by topic, a byte string. Hashcodes are super weak. Bad actor can make 56000 unique preimages, all 6 bytes, with the same hashcode. This can be amplified with longer pre-images. Then Hashmaps are "optimized" to fallback on "comparable" strings in tree structure for O(log(n)) lookup behavior if bucket exceeds limit. |
https://notes.ethereum.org/MEFRmwGsT3ykoeSfSn21Ig | 2020-12-03 | 2021-12-01 | Low | Proto | 750 | 0 | ||||
| Teku | CL-2020-17 | CPU blowup with message uniqueness | DoS | With the same hashcode trick to make 56000 unique 6 byte preimages with same hashcode, put these in the publish-list (wrapped with protobuf Message type, in Data field). The rest of the message is the same, and uses the data hashcode for its total hashcode, so the different messages will also have the same hashcode. The kicker: protobuf containers are not "comparable", whereas strings are. So these messages, when put in a hash-set (backed by hashmap) will all go into the same bucket, but not get expanded into a subtree for O(log(n)) lookup performance as quickly. The hashmap then resorts to JVM system-level hashcodes, after traversing the full depth of the tree. From tests it appears that a 1 MB crafted gossip container can stall the gossip inbound-messages handler for about 4.5 seconds. This should run on the main gossip routine, thus make the node skip about 6-7 heartbeats. |
https://notes.ethereum.org/MEFRmwGsT3ykoeSfSn21Ig | 2020-12-03 | 2021-12-01 | Low | Proto | 1000 | 0 | ||||
| None | CL-2020-18 | FastAggregateVerify inconsistencies across libraries herumi, py_ecc, milagro_bls and blst using the same test vector | Crypto | 2020-12-05 | 2021-12-01 | High | Quan | ||||||||
| None | CL-2020-19 | py_ecc bad prime_field_inv implementation | Crypto | Reproduction: prime_field_inv(7, 7) prime_field_inv(0, 7) Output: 1 0 |
ethereum/py_ecc#114 | 2020-12-07 | 2020-12-14 | 2021-12-01 | Medium | Quan | 500 | ||||
| None | CL-2020-20 | BLS: keygen.c: enforce limitation on IKM_len. | Crypto | https://github.com/supranational/blst/commit/91f45b6be29ba2d5cc78d95f1642e0c20409c074 | 2020-12-07 | 2020-12-7 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11679 | 0 | |||||
| Prysm | CL-2020-21 | Gossip MsgID with snappy alloc blowup | DoS | Message ID of gossip message uses Snappy block compression. Contains a varint header to define decompressed size. Unchecked in Prysm, enables a single gossip message to alloc 4 GB byte array. Which is then also hashed for message ID, if crafted to be valid. | 2020-12-09 | 2021-12-01 | Medium | Proto | 7000 | 0 | |||||
| Lighthouse | CL-2020-22 | Gossip message cache OOM | DoS | Rust libp2p puts message in cache before user-validation. Crafting ~10 byte messages that decompress to 80x or more is possible. Now use the unbounded publish list to put 100k messages in a single 1 MB gossip RPC container. The messages stay in the cache for 6 heartbeats (4.7 seconds). Send ~12 crafted 1 MB messages in that window for a 1 GB memory spike. | 2020-12-10 | 2021-12-01 | Medium | Proto | 7000 | 0 | |||||
| Spec | CL-2020-23 | Forkchoice selfish mining alike attack | Forkchoice | Due to the fork choice being rooted on a block graph, rather than a (block, slot) graph, an attacker can withhold blocks and some attestations until after committee voting on (empy) and subsequent blocks/slots to purposefully oprhan proposals. When 30%+ cartel, they can cause finality delays with non-trivial probability. | 2020-12-11 | 2021-12-01 | Medium | WINE Academic Workshop | 0 | 0 | |||||
| All clients | CL-2020-24 | Forkchoice proto-array delayed head update edge-case | Forkchoice | The original proto-array algo did two sweeps: one to update weights, one to update node relations (calculating the new head). The translated version only does 1 sweep, combining the two. In a situation where lots of votes move to a different fork, this causes the weights to update after the node relations, leaving the proto-array with consistent weights, but invalid node relations. Thus left with the old (now incorrect) head. The next sweep resolves it, and should be within a slot. Exploiting this within a slot may be possible on epoch boundary, but requires a significant split in forkchoice votes between two contending splits, or a significant amount of votes. |
2020-12-11 | 2021-12-01 | Medium | Saulius Grigaitis (+team). | 9000 | 18000 | |||||
| Teku | CL-2020-25 | Unlimited gossip subscription info OOM | DoS | RPC container can contain a list of ~200.000 unique subscription info updates. JVM libp2p will track subscriptions of all peers, without pruning. Simply fill the subscriptions lists slowly (attack bandwidth <> victim memory ratio of at least 1:2). Then eventually cause the victim to run out of memory. Variant of the subscriptions bug that hit Prysm and Lighthouse a month ago. |
https://notes.ethereum.org/MEFRmwGsT3ykoeSfSn21Ig | 2020-12-12 | 2021-12-01 | Low | Proto | 1000 | 0 | ||||
| Teku | CL-2020-26 | Unlimited gossip RPC size | DoS | Teku does not limit the protobuf RPC container size when decoding. So there is potential to amplify the other attacks by making messages 10 or 100 times as big. A more basic attack, just as effective: send a 100 MB container, with about 100 million 1-byte empty messages. Each of these will have a heap object allocated (pointer, length, type) and get hashed (4 bytes cache + maybe 4 byte system hash in object header). And then referenced in a hashmap (another pointer or two at least). So assuming 1 byte = ~40 bytes memory, streaming a 100 MB malicious gossip can cause teku to bite in 4 GB worth of useless decoding and data, possibly enough for an OOM. |
https://notes.ethereum.org/MEFRmwGsT3ykoeSfSn21Igg | 2020-12-13 | 2021-12-01 | Medium | Proto | 6000 | 0 | ||||
| None | CL-2020-27 | blst maleability from accepting uncompressed signatures | Crypto | 2020-12-13 | 2021-12-01 | Medium | Quan | ||||||||
| Teku | CL-2020-28 | Libp2p identify unlimited protobuf stream | DoS | JVM libp2p has an identify protocol handler that abstracts over a protobuf protocol handler, which does not have any timeouts or limits applied to the stream. To DoS, simply feed Teku with a valid start of a protobuf container on a new identify stream, and a very large protobuf length. Then keep feeding more bytes in bandwidth than it has memory available, until it goes OOM. | https://github.com/ConsenSys/teku/security/advisories/GHSA-r228-46jg-46x8 | 2020-12-14 | 2021-12-01 | Low | Proto | 250 | 0 | ||||
| Prysm | CL-2020-29 | Libp2p identify-delta add-protocols spam - force OOM within a minute | DoS | Prysm upgraded to libp2p 0.12.1, which has identify sub-protocols. The "delta" feature can add protocols to a previous peer. These are added to the peerstore of the host implicitly. Prysm keeps this peerstore in memory. | https://gist.github.com/protolambda/18e7575462a58bf495346fa1db9f1ebe | 2020-12-14 | 2021-12-01 | High | Proto | 12000 | 0 | ||||
| Nimbus | CL-2020-30 | Gossipsub Subscriptions OOM | DoS | Like previously with other clients, but now in Nim: put 100k+ tiny unique subscriptions in a gossipsub RPC container, and each of them will allocate a hashmap, and persist in memory forever. | https://notes.ethereum.org/MEFRmwGsT3ykoeSfSn21Ig | 2020-12-15 | 2021-12-01 | Low | Proto | 0 | |||||
| Nimbus | CL-2020-31 | Gossipsub quadratic topic IDs list | DoS | The topicIDs list in a gossip publishlist entry of an RPC is processed, all items are added to a Table (read: hashmap). Zah says a murmur3 hash is used for strings. This a uint32. Brute or compute 50.000 collisions (6 -> 4 bytes reduction should have them), and put them into the topicIDs list. | https://github.com/nim-lang/Nim/blob/04f8fcfbd06e72eb45f36e487a110316370e47c1/lib/pure/hashes.nim#L220 | 2020-12-15 | 2021-12-01 | Low | Proto | 0 | |||||
| None | CL-2020-32 | BLS: Check that IKM is > 32B in KeyGen | Crypto | IKM should be checked to be at least 32 bytes as per https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-04#section-2.3. | sigp/milagro_bls#45 | 2020-12-17 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11680 | 0 | |||||
| None | CL-2020-33 | BLS: Incomplete key validation | Crypto | Key validation checks group membership, but should also check that the key is not the point at infinity | ChainSafe/blst-ts#24 | 2020-12-18 | 2020-12-18 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11682 | 0 | ||||
| Lighthouse | CL-2020-34 | BLS: Missing check on seed and password length | Bug | This is called in wallet.rs, where a wallet can be created from non-empty seed and password of any size (no length check inWalletBuilder::from_seed_bytes()): | sigp/lighthouse#2102 | 2020-12-18 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11683 | 0 | |||||
| Prysm | CL-2021-01 | Prysm Fast-SSZ containers not monomorphic, can contain junk data | Bug | Prysm uses Fast-SSZ, which was not checking if the first dynamic offset in containers matches the fixed-length part, and skipping over (or before) fixed-length data, to make SSZ decoding not monomorphic, and sneak in junk data on e.g. gossipsub, for different message IDs and such. | https://gist.github.com/protolambda/a60468548ae6a70199961f969ae36327 | 2021-01-09 | 2021-12-01 | Low | Proto | 300 | 0 | ||||
| None | CL-2021-02 | Herumi maleability with extra signature byte | Crypto | 2021-01-18 | 2021-12-01 | Medium | Quan | ||||||||
| Prysm | CL-2021-03 | Mplex unlimited open streams + bad Prysm rate limit + stall on SSZ decode | DoS | First create a normal healthy connection with Go, then hijack the mplex loop to send custom mplex frames. Craft 100.000 streams, each with an open-frame (no title contents required) and a message frame. Totals around 8-10 MB. Each message must contain pro-active protocol negotiation, to avoid traffic back. And then send just the first bytes of the RPC contents: the length prefix. This opens 100.000 go routines, each allocating the length prefix (up to 1 MB due to lacking type based limiting), and stalling at least until decode timeout (at which point go routines clog the CPU and OOM is likely). | https://gist.github.com/protolambda/c45a4d9167fc4b20f2f76c749eeb7105 | 2021-02-12 | 2021-12-01 | Medium | Proto | 7000 | 0 | ||||
| Teku | CL-2021-04 | Mplex unlimited open streams + decode problems, but saved by snappy-frame decoding edge-case | DoS | Teku does not spawn many threads, but does allocate more per basic stream. Due to a snappy-frame decoding bug (if mplex frame is smaller than snappy frame), the payload is silently ignored, and it does not hang on it. But remove the protocol negotiation, and just spawn 100.000 (or many more) open streams, by just sending the create frames. Unsure if it works better with a 1 byte title per frame. Adds min. 2-3 GB of memory to running node, and makes JVM heap go jump up and down multiple gigabytes repeatedly for minutes on end per attack (giving GC a hard time too). | Consensys/teku#3738 | 2021-02-12 | 2021-03-18 | 2021-12-01 | Medium | Proto | |||||
| Teku | CL-2021-05 | Avoid basic authentication credentials from being leaked to log files | Bug | Similarly to Consensys/teku#3622 the authentication credentials might end up being leaked in the log files when voluntary exits are performed | Consensys/teku#3668 | 2021-02-26 | 2021-03-09 | 2021-12-01 | Note | Antonio Sanso | 250 | 500 | |||
| Teku | CL-2021-06 | Discovery uses the same AES/GCM Nonce throughout the session | Bug | https://github.com/ConsenSys/teku/security/advisories/GHSA-vx9f-w7h3-94844 | 2021-03-02 | 2021-12-01 | Medium | Antonio Sanso | 1000 | 2000 | |||||
| None | CL-2021-07 | BLST: Inverse modulo produces wrong result | Crypto | 2021-03-09 | 2021-12-01 | High | Guido Vranken | 11000 | 22000 | ||||||
| None | CL-2021-08 | BLST: NULL pointer dereference (crash) if 'msg' is empty and 'aug' is non-empty | Crypto | 2021-03-11 | 2021-12-01 | Low | Guido Vranken | 500 | 1000 | ||||||
| None | CL-2021-09 | BLST: Using non-standard 'dst' parameter uses uninitialized memory | Crypto | 2021-03-12 | 2021-12-01 | Low | Guido Vranken | 500 | 1000 | ||||||
| None | CL-2021-10 | Golang: Crash in parsing HTTP request | Language | golang/go#45710 | https://groups.google.com/g/golang-announce/c/cu9SP4eSXMc?pli=1 | 2021-03-12 | 2021-05-06 | 2021-12-01 | 5.9 | Medium | CVE-2021-31525. | Guido Vranken | 500 | 1000 | |
| None | CL-2021-11 | BLST: Inverse modulo hangs on i386 if input is 0 or multiple of modulo | Crypto | 2021-03-13 | 2021-12-01 | Medium | Guido Vranken | 1000 | 2000 | ||||||
| None | CL-2021-12 | Herumi/MCL: Different output from HashToG1/G2 when DST > 255 bytes | Crypto | https://github.com/herumi/mcl/commit/b01ef452a5a4acae584c0b27956cbf55b5275607 | 2021-03-14 | 2021-04-21 | 2021-12-01 | Low | Guido Vranken | 250 | 500 | ||||
| Spec | CL-2021-13 | Spec violation in BLS AggregateVerify | Crypto | 2021-04-02 | 2021-12-01 | Low | Antonio Sanso | 500 | 1000 | ||||||
| All clients | CL-2021-14 | Previous epoch attestation list limit overflow | Bug | 2021-04-07 | 2021-12-01 | Medium | Jacek | 0 | |||||||
| Prysm | CL-2021-15 | Prysm missing state root check | Bug | Prysm checks the state root in the transition function that is used by tests, but uses a different transition function during sync and gossip block handling, that missed the validation of the state-root. The function was a "no verify version" that would return a signature set for batch-verification outside of the function, but did not defer the state-root check in the same way. This makes the state-root effectively a graffiti field. The state-transition ignores the state-root when inserting the latest-header, but the block-root is still affected. This causes prysm to run into a bad block, store the resulting hot state with the bad block-root as key, and not find the state in the DB when someone builds a block with a parent-root based on the root of the latest-header of the latest state. The damage is limited because the chain cannot grow beyond one bad block, since the header-validation of the next block would fail against the state, which has a state-root in the header with deferred computation in the start of the next slot, which was still correct. | 2021-04-07 | 2021-12-01 | Medium | Proto | 0 | ||||||
| None | CL-2021-16 | Insufficient Validation on decompress_G2 Deserialization in py_ecc and nimbus | Bug | 2021-04-08 | 2021-12-01 | Medium | Antonio Sanso | 2000 | 4000 | ||||||
| Prysm | CL-2021-17 | BLS: Missing input validation in SecretKeyFromBigNum | Crypto | BLS's SecretKeyFromBigNum is an exported function that creates a BLS private key. It can be misused as follows: SecretKeyFromBigNum("1") will produce a BLS private key consisting of 31 zero bytes. |
prysmaticlabs/prysm#8819 | 2021-04-26 | 2021-04-27 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| None | CL-2021-18 | Launchpad: Doesn't fully validate public key | Bug | The fromBytes implemented for blst does offer the option to validate the public key, but since it is called from verify without the validate parameter set, it won’t verify the public key | https://notes.ethereum.org/UUHf4_MyRvmooxgD11rG-Q | 2021-04-27 | 2021-08-09 | 2021-12-01 | Low | Guido Vranken, Antonio Sanso | 250 | 500 | |||
| None | CL-2021-19 | ChainSafe/bls lack of validation | Crypto | 2021-04-27 | 2021-12-01 | Low | Antonio Sanso | 250 | 500 | ||||||
| None | CL-2021-20 | Point aggregation with the BLST Go bindings | Crypto | 2021-05-01 | 2021-12-01 | Medium | Onur Kılıç | 6000 | 12000 | ||||||
| Prysm | CL-2021-21 | Update go-libp2p-noise to release v0.2.0 | BUG | At the present time, the project is using go-libp2p-noise v0.1.2 based on github.com/flynn/noise package that has two bugs in nonce handling in versions prior to v1.0.0. | prysmaticlabs/prysm#8863 | 2021-05-05 | 2021-06-28 | 2021-12-01 | Low | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||
| None | CL-2021-22 | BLST: POINTonE1_mult_w4/POINTonE2_mult_w4 crash with empty input | Crypto | https://notes.ethereum.org/uqZoHPxPR86cuHW6EVlCAg | 2021-05-07 | 2021-05-08 | 2021-12-01 | Low | Guido Vranken | 250 | 500 | ||||
| Prysm | CL-2021-23 | Prysm integer square root bug | Bug | Prysm computes the integer square root using a float64 intermediate value, which does not have enough precision, and ouputs different results for high enough values. No danger until about 172K validators | https://gist.github.com/protolambda/a89add95e0f8e5acfd3ae79be4cd2cd1 | 2021-05-15 | 2021-05-31 | 2021-12-01 | High | Proto | 0 | ||||
| Prysm | CL-2021-24 | Add HTTP Secure Headers | BUG | The HTTP responses from WebUI do not contain secure headers. At least, WebUI MUST provide an X-Frame-Options header to be protected against Clickjacking attack. At the present, WebUI can be framed and employed by malicious actors to trick users. Other useful headers are described here: https://web.dev/security-headers/ The minimal recommended set: HSTS, X-Frame-Options, and X-Content-Type-Options |
prysmaticlabs/prysm-web-ui#178 | 2021-05-20 | 2021-10-27 | 2021-12-01 | Low | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||
| None | CL-2021-25 | BLS: Incorrect result for zero lengths arrays in aggregateVerify |
Crypto | aggregateVerify doesn't check the size of public keys/messages arrays. A zero-length array is possible. | ChainSafe/blst-ts#43 | 2021-05-24 | 2021-05-27 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11682 | 0 | |||||
| Lodestar | CL-2021-26 | BLS: No BLS public key validation due to validate parameter missing | Crypto | To create a public key BLS spec requires first validate the public key bytes. To validate the input bytes fromBytes must be called as fromBytes(bytes, type, true). The following fragments call fromBytes without validation: https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar/src/chain/bls/multithread/worker.ts#L39 https://github.com/ChainSafe/lodestar/blob/master/packages/lodestar/src/chain/bls/multithread/worker.ts#L53 |
ChainSafe/lodestar#2555 | 2021-05-24 | 2021-09-22 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| None | CL-2021-27 | BLS: BLS secret key validation is missing | Crypto | The BLS spec requires that the secret key (SK) must be a uniformly random integer such that 1 <= SK < r. Where r is the order curve. The last check is missing: fromBytes fromBytes Expected behavior Check that the provided SK < r. |
ChainSafe/bls#96 | 2021-06-02 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11681 | 0 | |||||
| None | CL-2021-28 | BLS: Bit security level < 128 | Crypto | cfrg/draft-irtf-cfrg-bls-signature#42 | 2021-06-16 | 2021-06-23 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11677 | 0 | |||||
| None | CL-2021-29 | BLS: BLS parameters section number fix | Crypto | cfrg/draft-irtf-cfrg-bls-signature#41 | 2021-06-16 | 2021-06-23 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11678 | 0 | |||||
| Teku | CL-2021-30 | BLS: Public key aggregation ambiguous infinite points handling | Crypto | BlstPublicKey.aggregate() will return infinitePublicKey in two cases: If one of the public keys to aggregate is invalid (not in the subgroup or infinity point) If the sum of (valid) public keys happens to be zero |
Consensys/teku#4111 | 2021-06-24 | 2021-09-21 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| Teku | CL-2021-31 | BLS: Detect unsafe coefficients in fast BLS verification | Crypto | In the implementation of https://ethresear.ch/t/fast-verification-of-multiple-bls-signatures/5407, a zero coefficient would allow the verification of signatures including an invalid one (if assigned a zero r_i). If the PRNG behaves correctly, the chance of this happening is negligible, but since a non-crypto PRNG is used, and as defense-in-depth measure (along the same lines as ECDSA checks), I would recommend to enforce non-zeroness in: |
Consensys/teku#4112 | 2021-06-24 | 2021-06-28 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| Prysm | CL-2021-32 | BLS: No length check in AggregatePublicKeys | Crypto | There is no length check in AggregatePublicKeys. If pubs is nil or [][]byte{} the function returns a public key without error. | prysmaticlabs/prysm#9091 | 2021-06-24 | 2021-06-27 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| Prysm | CL-2021-33 | BLS: Detect unsafe coefficients in verifyMultipleAggregateSignatures | Crypto | In the implementation of Fast verification of multiple BLS signatures, a zero coefficient would allow the verification of signatures including an invalid one (if assigned a zero r_i). VerifyMultipleSignature's comments say that r_i must be generated randomly from 1 to max uint64. |
prysmaticlabs/prysm#9098 | 2021-06-25 | 2021-06-28 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| None | CL-2021-34 | BLS: Detect unsafe coefficients in verifyMultipleAggregateSignatures | Crypto | In the implementation of Fast verification of multiple BLS signatures, a zero coefficient would allow the verification of signatures including an invalid one (if assigned a zero r_i). At the same time, 0s are possible in the output of crypto.randomBytes() function. If the PRNG behaves correctly, the chance of this happening is negligible, but as a defense-in-depth measure, we would recommend enforcing a non-zeroness check. |
ChainSafe/blst-ts#45 | 2021-06-28 | 2021-08-28 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11682 | 0 | ||||
| Nimbus | CL-2021-35 | BLS: Insufficient private key validation (covers nim-blscurve) | Crypto | Insufficient private key validation (covers nim-blscurve) | status-im/nimbus-eth2#2693 | 2021-07-02 | 2021-07-06 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| Lodestar | CL-2021-36 | Improper nonce handling in Noise handshake | BUG | There are two issues with nonce handling: Nonces are 32 bits long. The Noise spec requires 64-bit nonce. https://github.com/NodeFactoryIo/js-libp2p-noise/blob/master/src/%40types/handshake.d.ts#L12-L15 Nonce overflow. The spec requires returning an error if the maximum number is reached. This is the same issue as in the flynn package but more realistic due to 32-bit length. https://github.com/NodeFactoryIo/js-libp2p-noise/blob/master/src/handshakes/abstract-handshake.ts#L46-L48 |
ChainSafe/js-libp2p-noise#102 | 2021-07-05 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||||
| None | CL-2021-37 | Improper nonce handling in Go | BUG | There are two issues with nonce handling in Go: Nonces are 32 bits long. The Noise spec requires 64-bit nonce. Nonce overflow. The spec requires returning an error if the maximum number is reached. This is the same issue as in the flynn package but more realistic due to 32-bit length. |
symbolicsoft/noiseexplorer#1 | 2021-07-05 | 2021-07-06 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| Lighthouse | CL-2021-38 | API token can be read from a log file by any user | BUG | A validator client uses two API keys: ".secp-sk" (secret key) and "api-token.txt" (the corresponding public key). The spec suggests that an API token can be obtained (read) from a file or from logs. The second method is highly insecure by design and considered as a very bad practice in web application security (e.g., OWASP Logging). Moreover, an API token can be read from the log file by any user on the host because the file permissions for the logs are 644. |
sigp/lighthouse#2438 | 2021-07-07 | 2021-09-13 | 2021-12-01 | Medium | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11684 | 0 | |||
| Lighthouse | CL-2021-39 | File permissions for validator client API keys are insecure | BUG | A validator client uses two API keys: ".secp-sk" (secret key) and "api-token.txt" (the corresponding public key). Both files are stored in a user directory with 644 permission bits. So any user on the host can read them. |
sigp/lighthouse#2437 | 2021-07-07 | 2021-09-13 | 2021-12-01 | Medium | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||
| None | CL-2021-40 | Libp2p-noise spec | BUG | Static key signature does not depend on a peer's challenge | libp2p/specs#355 | 2021-07-27 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||||
| None | CL-2021-41 | BLST: Branching on uninitialized memory in blst_aggregate_in_gX functions | Crypto | https://notes.ethereum.org/Yo7fDI7XTtmNlbwlRT7Nxg | 2021-08-05 | 2021-08-09 | 2021-12-01 | Low | Guido Vranken | 500 | 1000 | ||||
| None | CL-2021-42 | Golang: x/text/language Parse() panic | Language | https://github.com/golang/text/commit/383b2e75a7a4198c42f8f87833eefb772868a56f | 2021-08-07 | 2021-08-10 | 2021-12-01 | Low | CVE-2021-38561 | Guido Vranken | 500 | 1000 | |||
| Prysm | CL-2021-43 | Use golang-jwt / jwt imlpementation of JWT | BUG | To address Issue 9015 you started to use form3tech-oss/jwt-go package that is archived and unmaintained now. That project is now being maintained at: https://github.com/golang-jwt/jwt. We recommend switching to this one. |
prysmaticlabs/prysm#9357 | 2021-08-11 | 2021-08-11 | 2021-12-01 | Low | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||
| Lighthouse | CL-2021-44 | VC: requests may not contain Authorization header with API token | BUG | According to the Validator Client API documentation, all requests (GET, POST, PATCH) must contain Authorization header with the token. The current implementation only requires the API token in GET requests only, POST/PATCH requests will be processed even if they don't contain the Authorization header. |
sigp/lighthouse#2512 | 2021-08-13 | 2021-08-18 | 2021-12-01 | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | ||||
| All clients | CL-2021-45 | Possible to cause Denial of Service if a client has RPC externally available | DoS | Clients provide clear warnings against doing this. | 2021-08-28 | 2021-08-28 | 2021-12-01 | Note | Jim McDonald | 100 | 200 | ||||
| Prysm | CL-2021-46 | Logout endpoint doesn't require a valid JWT token | BUG | /api/v2/validator/logout doesn't require a valid JWT. If a WebUI is accessible then an adversary can regularly send the logout request, the user's JWT key will be invalidated, and the user will not be able to use the UI. |
prysmaticlabs/prysm-web-ui#187 | 2021-09-02 | 2021-10-21 | 2021-12-01 | Low | Taurus | Part of EF initiated Security Audit: https://arxiv.org/abs/2109.11685 | 0 | |||
| All clients | CL-2021-47 | Block packing bug | An attacker could poison the mempool by slashing and exiting a validator in the same block, which could halt block production as the slashing is processed first which would cause the exit to fail. This happens due to blocks being packed independently of each other. | https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#voluntary-exits https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C&version=3.1 |
2021-10-27 | 2021-12-01 | 6.5 | Medium | Nishant (Prysm) | 4600 | 0 |