Welcome to the Zellic Security Roundup, a monthly security-focused newsletter covering valuable security news and analysis in Web3.
Cool Finds at Zellic
What’s the finding? Anyone can become a validator, which could allow anyone to remove other validators or modelers at will, change the performance rating of modelers, overwrite existing challenges, and so forth.
Audit: Spectral Modelers
Timeline: Spectral Labs approached Zellic to perform a security assessment centered around the Spectral Modelers contracts, a trustless solver network leveraging zkML to guarantee the integrity and quality of machine-learning models. During the assessment, eight findings (one critical, two high impact, three medium impact, one low impact, and the remaining finding informational) were uncovered. Below is a look at a specific finding that was uncovered during this security assessment.
Description of the bug: The `registerValidator` function facilitates the registration of validators, a privileged role within the Modeler contract.
The function checks whether the `validatorAddresses.length < MAX_VALIDATORS` and ensures that the required amount of validator tokens is paid for by the to-be validator (i.e., `msg.sender`). It then sets the value of `isValRegistered` (a storage reference of `isValidatorRegistered`) to true, effectively giving the validator role to the `msg.sender`. Technically, all the checks at this point are performing their intended role. The `MAX_VALIDATORS` would be set to 1 in the current version of the codebase, as stated by the Spectral team, which means that only the first to ever call the `registerValidator` will become a validator.
Upon closer examination of the `addValidatorRewardList` function (last line in the `registerValidator` definition), we observe the following issue:
Note that before calling `addValidatorRewardList`, the storage was previously updated `isValRegistered[msg.sender] = true;`. Thus, `if (isValRegistered[_validator])` will always hold true, and therefore the `validatorAddresses.push(_validator);` will never be called.
This, in turn, means that the previous `require(validatorAddresses.length < MAX_VALIDATORS, “Max validators reached”)`; check will always be redundant, allowing for an unlimited amount of users to call `registerValidator` with the only virtual constraint of affording the staking required to do so.
How we found the bug: During each review, we determine the most important invariants the specific target protocol heavily relies on. In this case, it was clear that storage invariants are fundamentally important and therefore require special attention.
Spectral’s architecture involved several important storage variables that needed to be properly transitioned through. One such state was represented by the `validatorAddresses` array, which contains a list of addresses that have the validator role, essentially the most privileged role in the system.
There are several approaches for identifying such vulnerabilities; the one we most often use is the source-to-sink approach. In this approach, we select a specific state that we want to follow through the function calls, find each of the sinks (i.e., wherever that state is updated), and note all the sources (i.e., the function’s call trace). It then quickly became clear that the `validatorAddresses` array is problematic, as even though the `addValidatorRewardList` function is supposed to push values into it, it never gets the chance to do it, due to the early return.
Impact of the bug: Anyone can call `registerValidator` and become a validator, the highest-ranking role in the Spectral Modeler contract. The capabilities of a validator include the removal of other validators or modelers at will, changing the performance rating of modelers, overwriting existing challenges, and so forth.
Fix for the bug: We recommended moving the `addValidatorRewardList` before the `isValRegistered` storage change. For additional assurance, we highly recommended drastically limiting the access to this function by means of setting an admin that would oversee the registration of validators.
Zellic Research & Writing
How Do MPC Wallets Work?
A primer on MPC wallets and their security features and pitfalls.
Groq Demo & Whitepaper Deep Dive Thread
We did a deep dive into Groq’s (surprisingly easy to read!) whitepaper to look into Groq’s recent demo with state-of-the-art LLM inference speed.
How Does Zcash Work?
How does Zcash work? A post on understanding Zerocash and Zcash.
In the News
Zellic was awarded a $1M grant from DARPA for our proposal to develop AI-enabled cyber reasoning systems that automatically find and fix software vulnerabilities at scale. DARPA is collaborating with Anthropic, Google, Microsoft, and OpenAI to provide us with some of the latest advances in AI. For a look into our winning whitepaper and perspectives on the challenge that informed our design, check out our blog post here.
The Zellic cryptography team was featured on the Zero Knowledge Podcast to talk about their participation in ZK Hack IV, what it was like to hack on the puzzles, and which puzzles were their favorites. For a look into the three puzzles solved by the Zellic cryptography team for ZK Hack IV, check out our blog post here.
Google’s cryptography team recently shared their latest thoughts and reasons about the migration from classical cryptographic algorithms to post-quantum cryptography, starting with their threat model.
“Ethereum has blobs. Where do we go from here?”, one of the latest blogs from Vitalik Buterin, covers EIP-4844, aka blobs, and what it offers for scaling, improvement of L2s, and Ethereum improvement more broadly.
Alexey Pertsev was accused of laundering $1.2B at Tornado Cash, according to an indictment by Dutch prosecutors who listed 36 allegedly illicit transactions from decentralized protocols to Tornado Cash. For a breakdown of the mathematical principles of Tornado Cash, check out our blog post here.
The Security Alliance (SEAL) team recently held “War Rooms with SEAL”, a webinar part of the DeFi Security Summit to discuss SEAL 911, Chaos Team, and Wargames.
Worldcoin Foundation has made core components of its Orb’s software open-source in an effort to make “the Orb’s image processing transparent and its privacy claims verifiable.”
The hackers that exploited the Heco Bridge on November 22, 2023, have moved the ~40,000 in stolen ETH through Tornado Cash across the span of eight days.
Munchables, an NFT game built on Blast, was exploited for $62M in ETH on the night of March 26th. As of March 27th, Munchables stated that “a developer attached to the project had ‘agreed to share the keys for the full Munchables funds without any condition’”.
The Remilia project claimed to be hacked and drained of ETH and NFTs potentially worth millions of dollars and, “although the project's treasury used a multi-signature model, the private keys were stored in one password manager, which Fang says was compromised”.
Meet Up With Us
We’ll be at the following conferences in April. If you’d like to set up 1:1 time with our team, then reach out to sales@zellic.io for scheduling!
zkSummit — Athens (April 10)
Sui Basecamp — Paris (April 10–11)
Paris Blockchain Week — Paris (April 9–11)
Recent Zellic Audit Reports
Molend Protocol Audit Report: Molend Protocol is an Aave-like lending protocol on Mode blockchain, which allows users to deposit and borrow crypto assets.
Euler Fee Flow Audit Report: Euler Fee Flow is a contract that runs continuous Dutch auctions to sell a flow of fees of multiple assets.
Biconomy Smart Account Audit Report: The Biconomy SCW project focuses on enhancing modular smart accounts.
ether.fi Audit Report: ether.fi is a decentralized, noncustodial liquid restaking protocol built on Ethereum, allowing users to stake their Ethereum and participate in the DeFi ecosystem without losing liquidity.