VETEOS: Statically Vetting EOSIO Contracts for the “Groundhog Day” Vulnerabilities

VETEOS: Statically Vetting EOSIO Contracts for the “Groundhog Day” Vulnerabilities

Speakers: Levi Taiji Li

Conference: NDSS Symposium

YouTube: (no public video)

Overview

This article delves into VETEOS, a groundbreaking static analysis tool designed to uncover a unique and insidious class of vulnerabilities dubbed "Groundhog Day" attacks within EOSIO smart contracts. Presented by Levi Taiji Li at the NDSS Symposium, this research addresses a critical gap in smart contract security: the ability of malicious actors to repeatedly execute contract code without financial cost, gleaning information from reverted transactions to ultimately achieve deterministic, unauthorized profits. These vulnerabilities pose a severe threat to the integrity of financial applications built on the EOSIO blockchain, including sealed-bid auctions, exchanges, and gaming platforms, where the confidentiality of internal contract states is paramount.

The core problem stems from EOSIO's distinctive rollback mechanism, which allows an entire transaction sequence to be undone. Attackers exploit this by initiating transactions, observing leaked information from the reverted state, and iteratively refining their inputs until they can predict a profitable outcome. Existing security analysis tools for EOSIO contracts, such as EOSAFE, have largely failed to adequately model and detect this sophisticated threat, primarily focusing on the rollback aspect (F1) but neglecting the crucial factors of information leakage (F3) and causal inference (F4) that enable deterministic exploitation.

VETEOS fills this void by introducing a formal model for Groundhog Day vulnerabilities, translating abstract concepts into concrete, low-level detection specifications for EOSIO WebAssembly (WASM) bytecode. By performing context-sensitive, flow-sensitive, and interprocedural dataflow analysis, VETEOS precisely identifies the intricate data and control dependencies that underpin these attacks. The tool's efficacy is demonstrated by its discovery of 735 novel vulnerabilities in real-world EOSIO contracts, outperforming state-of-the-art analyzers with a significant 79.8% reduction in false positives and highlighting a substantial financial impact on the EOSIO ecosystem.

Background

[▶ Watch: Introduction to Groundhog Day attacks and motivation (0:00)]()

To understand Groundhog Day vulnerabilities, it's essential to first grasp the fundamental architecture and operational characteristics of EOSIO smart contracts. Unlike Ethereum's account-based model, EOSIO contracts are C++ programs compiled into WebAssembly (WASM) bytecode, which then executes on EOSIO Virtual Machines (VMs). Each contract is tied to an EOSIO account and triggered by an apply() function when its associated account is invoked. This apply() function acts as a dispatcher, routing external requests to specific actions based on their names.

A critical feature for Groundhog Day attacks is the Inline Action Sequence. Within a single EOSIO transaction, multiple actions can be executed sequentially through inline calls. These are essentially implicit function calls where contract and action names can be dynamically assigned at runtime. Inline actions are "tail calls," meaning prior statements execute first, but crucially, if any action within a transaction fails (e.g., by calling eosio_assert()), the entire transaction and all its preceding actions are reverted. This comprehensive rollback mechanism is central to the "free trial" aspect of Groundhog Day attacks.

EOSIO Payment and Notification systems heavily rely on the eosio.token system contract for token transfers. When eosio.token::transfer() is called, it updates account balances and notifies both the sender and recipient. A malicious recipient can intentionally trigger a rollback by including an eosio_assert() call in their apply() function, effectively undoing the entire transaction while potentially still observing intermediate state changes.

EOSIO Tables provide persistent storage for contract states. These multi-index tables, accessible via the EOSIO Table interface, are vital for financial applications to synchronize states across inherently stateless individual actions. While the WebAssembly Linear Memory Model offers a shared array of bytes for arguments and local variables, its volatile nature makes it less suitable for long-term data persistence compared to EOSIO tables. Authorization Checks, such as require_auth(get_self()), are used to protect actions and table accesses, ensuring only authorized callers can perform specific operations.

The Resource Model in EOSIO is another key enabler for Groundhog Day attacks. Users stake EOS tokens to acquire CPU, NET, and RAM resources. Unlike Ethereum's gas fees, staked tokens are not spent but merely locked and are fully reimbursable. This design choice makes unlimited retries financially feasible and risk-free for attackers, as they incur no actual cost for reverted transactions.

Regarding Secrecy in Smart Contracts, EOSIO contracts can maintain secrets in two primary ways: (1) In-memory secrets, which are dynamic values not stored on the blockchain (e.g., tapos_block_num for pseudo-random numbers, or unforeseen user inputs). (2) Hashing techniques, where a hash of a secret is stored (often in EOSIO tables) instead of the secret itself, commonly seen in sealed-bid auctions. The goal of a Groundhog Day attack is to reveal these secrets prematurely.

Previous research in EOSIO contract security includes tools like EOSAFE, WANA, EOSFuzzer, and WASAI. While these tools have contributed to identifying various vulnerabilities, they primarily focus on basic rollback issues (F1) and lack the sophisticated modeling required to capture the information leakage (F3) and causal inference (F4) aspects that define a true Groundhog Day vulnerability. This deficiency motivated the development of VETEOS to provide a more precise and complete detection method.

Key Findings

[▶ Watch: Limitations of existing tools and problem modeling (1:25)]()

VETEOS's research and implementation yielded several critical findings regarding Groundhog Day vulnerabilities in EOSIO contracts:

• Formal Model for GDVs: The work formally defines a Groundhog Day vulnerability (GDV) based on four essential factors: (F1) Revertable, (F2) Unpredictably profitable, (F3) Information leakage, and (F4) Causal inference. This comprehensive model provides a robust framework for detection that surpasses previous ad-hoc approaches.
• Intrinsic Dependencies: The research revealed that these vulnerabilities stem from intrinsic data and control dependencies among key contract constructs, including user inputs, global states, database tables, API return values, and inline action calls. Understanding these interdependencies is crucial for precise detection.
• VETEOS as a Custom Static Analysis Tool: VETEOS was developed as a custom static analysis tool capable of performing context-sensitive, flow-sensitive, and interprocedural dataflow analysis directly on EOSIO WebAssembly bytecode. This involved designing novel algorithms to overcome EOSIO-specific challenges, such as dynamic entry points, indirect/implicit action calls, reordered dataflow due to delayed inline action execution, cross-action dataflow via database tables, and the unique memory model/calling convention.
• Discovery of Novel Vulnerabilities: VETEOS successfully detected 735 novel Groundhog Day vulnerabilities in real-world EOSIO contracts deployed on the blockchain. This signifies a widespread, previously undetected security flaw impacting a significant portion of the EOSIO ecosystem.
• Superior Accuracy and Reduced False Positives: Compared to state-of-the-art EOSIO contract analyzers like EOSAFE, VETEOS demonstrated significantly higher precision, reducing false positives by 79.8%. In manual verification of 40 randomly selected detected cases, VETEOS achieved zero false positives, confirming its high accuracy. It also successfully identified all 18 known GDVs in benchmark contracts without any false negatives.
• Significant Financial Impact: The 735 identified vulnerable contracts are highly active, including top applications, with 10% generating over 2,000 transactions daily. The total balance of these contracts amounts to approximately 899K USD, with potential additional funds affected reaching up to 4.9M USD for a single lottery game instance, underscoring the severe financial risks posed by these vulnerabilities.
• Practical Exploitability: Analysis confirmed the practical exploitability of GDVs. Attackers can execute contracts tens of millions of times due to EOSIO's low transaction costs and reimbursable staked tokens. Fuzzing experiments on 507 samples showed an average success rate of 19% for triggering winning conditions, demonstrating that these vulnerabilities are not merely theoretical.

Technical Deep Dive

[▶ Watch: VETEOS: Our static analysis tool and contributions (1:45)]()

The core of VETEOS's contribution lies in its rigorous formal definition of a Groundhog Day vulnerability (GDV) and the sophisticated technical methods employed for its detection.

A Groundhog Day vulnerability (GDV) in EOSIO contracts is formally defined as one that allows an attacker to indefinitely re-execute a transaction without cost, enabling them to identify the exact contract input that deterministically maximizes their profits. This hinges on four critical factors:

• (F1) Revertable: A sequence of activities within a single transaction can be entirely reverted, allowing unlimited free retries. This is a fundamental property of EOSIO's inline action mechanism.
• (F2) Unpredictably profitable: Whether a transaction leads to profit is initially unpredictable, relying on a secret condition that evaluates participant inputs against a hidden secret.
• (F3) Information leakage: A state change occurs within the revertable transaction and is visible outside it, even after the transaction has been undone.
• (F4) Causal inference: The change to the visible state is directly caused by the invisible comparison between the user input and the secret, allowing the attacker to infer the comparison result.

The typical Groundhog Day attack model involves at least three transactions:

1. Transaction T1: createSecret(): An initial transaction generates and potentially stores a secret (e.g., a random number, a highest bid) in linear memory or a database table.
2. Transaction T2: payToPlay(): This attacker-triggered transaction contains the core black-box testing logic. It involves the user paying to participate, providing an input, checkCondition() comparing the input with the secret, writeState() updating a global state if the condition is met, and notify() informing the participant. The attacker then intentionally rolls back T2 by invalidating the notification (e.g., via eosio_assert()).
3. Transaction T3: readState(): The attacker executes a third transaction to observe changes to the global state that were leaked from the reverted T2. This information is crucial for the attacker to infer the outcome of their previous attempt and refine their strategy for subsequent free trials.

VETEOS's high-level detection strategy (Algorithm 1) is designed to identify the control and data dependencies that fulfill these four requirements. It operates by:

1. Identifying all instructions (WR) that write to global states.
2. For each wr, determining the global state (gs) it updates and checking if gs is externally readable (e.g., user's eosio.token balance, contract-wide database table).
3. If the state is leaked, tracing back from wr to find its entry point (ep). This ep must be a user-triggerable action that takes user input and can notify the user of results.
4. From ep, obtaining the user input (in) and performing def-use chain analysis to discover all uses (USE) of this input.
5. For each USE statement, checking if it's a conditional statement and a predecessor of the state update wr. If both hold, it indicates that user inputs causally influence the global state change, making the leaked information valuable to attackers.

Implementing this strategy on EOSIO WebAssembly bytecode presented several unique technical challenges:

• C1: Correctly identifying application entry points: EOSIO's apply() function acts as a dynamic dispatcher, making it non-trivial to pinpoint the true user-facing entry points for an attack flow.
• C2: Soundly tracking control flows through implicit and indirect calls: EOSIO uses direct calls, indirect calls (via call_indirect WASM instructions and function tables), and implicit calls (where action names are passed as strings to action().send()). Building a complete callgraph requires handling all these mechanisms.
• C3: Accurately establishing data dependencies due to delayed execution of inline action calls: Inline actions are always executed last within a function. This reordering can mislead traditional dataflow analysis; for instance, a getbalance() call might appear before writeState() in code but access the newer state updated by writeState().
• C4: Tracking dataflow across actions via global database table accesses: EOSIO contracts use persistent multi-index tables to share states. Precisely linking writeState() and readState() operations through these tables requires verifying that multiple table accesses reference the same table and identical table entry.

VETEOS addresses these challenges with custom analysis methods:

• a) Entry Point Discovery (FINDENTRYPOINTS Algorithm 2): This algorithm discovers all contract entry points leading to a point of interest. It employs three types of caller identification:
• Direct Callers (DIRCLR): Identified via conventional callgraph analysis.
• Indirect Callers (INDIRCLR): For call_indirect WASM instructions, VETEOS performs backward dataflow analysis to identify the constant source of the integer index, then consults the function table to determine the target.
• Implicit Callers (IMPCLR): For reflective calls using action name strings, VETEOS builds a flow graph of string operations, transforms it into a context-free grammar, approximates it with a regular grammar using the Mohri-Nederhof algorithm, and extracts automata to resolve the target action. This comprehensive approach ensures accurate discovery of caller-callee relations for C1 and C2.

• b) Cross-Action Dataflow Analysis: This component tackles C3 and C4 using a model-constrained permutation-based approach:
• Dataflow Summary: For each action, intra-procedural def-use chain analysis identifies internal data dependencies, categorizing sources (action inputs, database tables) and sinks (inline action calls, database tables).
• Action-flow Model: An action-flow model (Definition 3) is constructed to represent the partial order of action calls, critical for handling inline actions and nested calls. EOSIO VM uses a breadth-first search for nested inline calls, and "must-follow" relations are determined by permission checks and sequential calls, helping to rule out impossible action call combinations (C3).
• Model-Constrained Permutation: Guided by the action-flow model, VETEOS combines dataflow summaries by selecting action pairs, checking for must-follow constraint violations, and searching for linkages between the first action's sinks and the second's sources.
• Cross-action dataflow linkage is established either through argument passing for inline calls or via Database Table Access. For table access, two-level matching (Figure 9) is performed:
• Table Matching: Backward dataflow analysis identifies if multiple table instances originate from the same table object.
• Table Entry Matching: Backward dataflow analysis discovers the origin of accessed table keys. If keys share the same source, a dataflow link exists (C4).

• Memory Model and Calling Convention: VETEOS operates on EOSIO WASM bytecode. While it builds on Octopus to convert WASM to SSA-formed IR, custom implementations were necessary for EOSIO's distinct memory model and calling convention:
• WASM locals don't directly store action arguments but hold addresses to memory regions, with global0 often acting as a stack pointer.
• Action parameters are identified by leveraging signature functions like call_to_action_data_size() and call_to_read_action_data() and their data dependencies.
• Custom SSA transformation is applied for locals, renaming them upon content modification (e.g., tee_local).
• For dataflow through memory, a custom points-to analysis is developed for (local + constant offset) patterns, using a strict policy for alias identification to ensure efficiency.

Implementation Details: VETEOS is implemented in 5,893 lines of Python code. It leverages Octopus 1 for WASM to SSA IR conversion but integrates its custom dataflow analysis techniques to specifically handle the unique memory addressing modes and calling conventions of EOSIO WASM. The entire codebase, documentation, and experimental data are publicly available on GitHub.

Demo / Proof of Concept

[▶ Watch: Background: EOSIO contracts, inline actions, and rollback (2:55)]()

While the talk did not feature a live demo, the evaluation section provides compelling evidence of the practical exploitability of Groundhog Day vulnerabilities and VETEOS's effectiveness in identifying them. The research established that these vulnerabilities are not merely theoretical but have tangible, real-world implications.

• Existing Attacks: The article notes that several contracts, such as dicecenter11 and fairdogegame, have already fallen victim to Groundhog Day attacks, as documented by PeckShield, confirming the historical prevalence and impact of this vulnerability class.
• Attacker Capabilities and Financial Feasibility: The unique resource model of EOSIO is a critical enabler. Users stake EOS tokens for resources, which are reimbursable, making the cost of repeated transactions effectively zero. An average user can execute a contract up to 30 million times without financial penalty, providing ample opportunities for unlimited free trials to discover secrets. Analysis of contracts like EOSBet Casino and EOS.Win indicated that attackers might need around 90 attempts to win, a number easily achievable given the lack of transaction cost.
• Dynamic Verification (Fuzzing): To demonstrate practical exploitability, the researchers fuzzed 507 of the 735 vulnerable samples identified by VETEOS using WASAI. This dynamic analysis revealed an average success rate of 19% for triggering winning conditions, with a minimum of 5%. This empirical evidence strongly supports the real-world exploitability of the GDVs detected by VETEOS, showing that attackers can indeed find profitable inputs by repeatedly testing.

This combination of existing attacks, the financial feasibility of repeated attempts, and successful fuzzing results serves as a robust proof of concept for the Groundhog Day vulnerability and the real-world efficacy of VETEOS.

Defensive Implications

[▶ Watch: Groundhog Day vulnerability: threat model and formal definition (4:05)]()

The discovery and detailed analysis of Groundhog Day vulnerabilities by VETEOS present clear and actionable defensive implications for EOSIO contract developers and the broader blockchain ecosystem. The proposed mitigation strategies focus on disrupting the fundamental enablers of these attacks: the revertable nature of transactions (F1) and information leakage (F3).

1. Separating Funds Transfers from Core Game Logic:

The primary recommendation is to decouple operations that involve value transfer or critical state changes from the core game or application logic. This can be achieved by splitting these activities into multiple, distinct transactions. For instance, the payment and the initial condition checks (e.g., betting against a secret) should be completed in one transaction that, once successful, cannot be reverted by the user. The subsequent notification of the game's outcome, which might be the point an attacker would try to revert, would then occur in a separate, revertable transaction. By doing so, the F1 (Revertable) factor for the crucial, profit-determining logic is effectively disrupted, preventing attackers from gaining "free trials" on the core game mechanics.

1. Hiding Critical Global Contract States:

A second crucial mitigation involves restricting public access to global contract states that could reveal sensitive information. This directly addresses the F3 (Information leakage) factor. Instead of storing game outcomes or intermediate states in publicly accessible database tables or allowing direct querying of internal balances that reflect game results, developers should design contracts to communicate outcomes solely through notifications that do not prematurely reveal underlying secrets. For example, a contract might update an internal state variable, but this variable should not be readable by external parties until the game is officially finalized and the outcome is meant to be public. This prevents attackers from observing changes in a reverted transaction's global state to infer secret conditions.

Broader Lessons for Smart Contract Security:

While VETEOS specifically targets EOSIO, the principles behind Groundhog Day vulnerabilities are generalizable. The logic-level definitions of F2 (Unpredictably profitable), F3 (Information leakage), and F4 (Causal inference) can manifest in any financial application on any smart contract platform. The F1 (Revertable) factor might be achieved differently in other environments, such as through explicit revert() calls in Ethereum's Solidity. Therefore, developers on other platforms should also consider these four factors when designing sensitive financial applications, especially those involving secrets, bids, or unpredictable outcomes.

VETEOS highlights the limitations of existing tools like EOSAFE, which primarily focus on basic rollback issues (F1) but lack the formal modeling and precise dependency analysis for F2, F3, and F4. This underscores the need for more sophisticated, context-aware analysis tools that can capture complex, multi-factor vulnerabilities in smart contract ecosystems.

Key Takeaways

• Groundhog Day Vulnerabilities are a Novel Threat: These vulnerabilities exploit EOSIO's unique rollback mechanism to enable attackers to perform unlimited, cost-free "free trials," learn secret conditions, and achieve deterministic profits in financial applications.
• VETEOS Provides Precise and Complete Detection: The tool introduces a formal model based on four critical factors (Revertable, Unpredictably Profitable, Information Leakage, Causal Inference) and implements sophisticated static analysis techniques to detect these complex vulnerabilities directly from EOSIO WebAssembly bytecode.
• Widespread and Financially Impactful Discoveries: VETEOS successfully identified 735 novel Groundhog Day vulnerabilities in active, real-world EOSIO contracts, impacting applications with significant financial value (over 899K USD directly, and potentially millions more).
• Advanced Technical Solutions for EOSIO-Specific Challenges: VETEOS employs custom entry point discovery (handling direct, indirect, and implicit calls), model-constrained cross-action dataflow analysis (addressing delayed inline execution and two-level table matching), and specialized memory model handling to overcome the unique complexities of EOSIO WASM analysis.
• Superior Accuracy to Existing Tools: VETEOS significantly outperforms prior state-of-the-art analyzers, achieving zero false positives in manual verification and reducing false positives by 79.8% compared to tools like EOSAFE, which lack comprehensive modeling of information leakage and causal inference.
• Actionable Mitigation Strategies for Developers: To defend against Groundhog Day attacks, developers should implement strategies such as separating fund transfers from core game logic into distinct transactions and strictly hiding critical global contract states from public observation.

About the Speaker(s)

The talk "VETEOS: Statically Vetting EOSIO Contracts for the “Groundhog Day” Vulnerabilities" was presented by Levi Taiji Li. Based on the provided transcript and metadata, no further details regarding their title or company affiliation are available.