VIDEO
HIGHLIGHT
Log InSign up
Lecture 10 - Race Condition
SummaryTranscriptChat

Lecture 10 - Race Condition

Introduction

In this lecture, the speaker talks about race condition/re-entrancy vulnerabilities in Near Protocol. The delay between external calls and callbacks can lead to anyone calling any function inside a contract during this period.

Race Condition Vulnerabilities

This section discusses how race conditions can occur due to the delay between external calls and callbacks.

  • A delay of two blocks allows anyone to call any function inside a contract during this period.
  • An example scenario is given where an external swapping contract swaps Near for some tokens. After a user deposits 100 Near and swaps it for 200 tokens, they cannot call swap again without depositing more Near first.
  • If an attacker calls swap twice with 100 Near each time, they can exploit the delay to stake 100 Near and get 100 tokens twice, leaving them with 400 tokens.

Exploiting Race Conditions

This section explains how attackers can exploit race conditions by calling functions multiple times during the delay period.

  • An attacker can call deposit with 100 Near and then call swap twice with 100 Near each time.
  • The smart contract will call the external swapping contract twice, allowing the attacker to stake 100 Near and get 200 tokens each time.
  • After two block delays, both callbacks are executed. The first callback decreases the attacker's balance to zero since they spent 100 Near. However, the second callback fails because their balance is already zero.
  • Since changes were not reverted in the external contract, the attacker still has all their tokens.

Conclusion

In conclusion, this lecture discussed how race condition vulnerabilities can be exploited in Near Protocol by taking advantage of delays between external calls and callbacks.

  • Integration tests can be used to write your own block of code to exploit race conditions.
  • It is important to revert any changes after receiving a panic or seeing that an attacker's balance is already zero.

Deposit Contract Overview

This section provides an overview of the deposit contract and its functions.

User Near Map

  • The user near map lets us track ballet internal balances of users.
  • We use a seeking contract address to make an external call.

Deposit Near Function

  • The deposit near function allows users to deposit some near.
  • We assert that attached deposit is bigger than or equal to one year.
  • If it's the first time a user tries to deposit something, we directly insert it inside of the map.
  • If a user already had some money, we add it on top.

Staking Function

  • Users stake some near for certain validators using this function.
  • We ensure that the user exists and check that the amount is lower or equal to the near deposit so that users do not try to play the system.
  • We make an external call by calling State gain contract and give beneficiaries, validator, and amount as parameters.
  • After everything is done, we call a callback called results taking.

View Functions

  • View functions include view near deposits and withdrawal near.
  • Withdrawal near allows users to withdraw without staking.

Staking Contract Overview

This section provides an overview of the staking contract and its functions.

Allow List

  • The allow list only lets deposit contract calls take place so that users cannot just call stake as they lack in this contract.

Staking Map

  • The staking map keeps track of users and balances so that we can keep track of how much each user has staked for each validator.

Taking Function

  • The taking function lets users stake some near for certain validators.
  • We check if it's the first time a user stakes and directly insert it into a mapping.
  • If it wasn't the first time, we add on top by getting current stake for certain validator and then adding amount on top.

Withdrawal Stake

  • Withdrawal stake allows users to withdraw their stake from a validator.
  • We ensure that the amount that the user chooses is not zero and that beneficiency stake is bigger or equal to the amount so that users cannot play the system.
  • We subtract the amount from beneficiary stake and update current mapping.

View Stake Function

  • View functions include view current stake over user.

Exploitable Contracts Overview

This section provides an overview of how exploitable contracts work.

Vulnerable Contract

  • The vulnerable contract has a function called exploit which exploits everything.

Exploit Contract

  • The exploit contract can be used to call vulnerable contracts automatically or use workspace or res integration tests batch function to batch state calls.

[CUTOFF_LIMIT]

Video description

Welcome back to another video in the NEAR Rust Smart Contract Security series. In this video, we'll discuss how Race Condition/Reentrancy in NEAR Smart contracts Here's what we'll cover: - What is Race condition in NEAR Smart contracts - How to avoid it in smart contracts - How to write integration tests for it - How we can exploit it using an exploit contract - How we can exploit it using batch calls Code and slide deck : https://github.com/timurguvenkaya/near-sc-security-course Don't forget to follow me on: Twitter: https://twitter.com/timurguvenkaya Lenster: https://lenster.xyz/u/timurguvenkaya LinkedIn: https://www.linkedin.com/in/timur-guvenkaya/ GitHub: https://github.com/timurguvenkaya For more Rust and Solidity programming and smart contract security tips and updates.

Lecture 10 - Race Condition | YouTube Video Summary | Video Highlight