👮
Contract Cops
  • Mastering Ethereum Book
    • What is ethereum?
    • Tokens
    • Oracles
    • Decenralized Applications(DApps)
    • The Ethereum virtual machine
    • Ethereum basics
    • Ethereum clients
    • Cryptography
    • Wallets
    • Transactions
    • Chapter 7 - Smart Contracts & Solidity
    • Side Notes
      • Tokens
      • Smart Contracts and Solidity
  • Cryptography
    • Ethereum Cryptography - Cheatsheet
    • Assymetric vs symmetric cryptography
    • ECDSA vs RSA
    • Elliptic curves and ECDSA
    • Sha-256 Example
    • Sha-256
    • What are the different steps in SHA-256?
  • Ethereum Blocks
    • Block Headers
  • Learning Solidity
    • Storage vs memory
    • Upgradeable contracts
      • Proxy pattern in smart contracts
  • PoS
    • Proof of stake
  • PoW
    • PoW
  • Tokens
    • ERC-1155
    • ERC20
  • Cryptonomics
    • Automated market makers
    • Collateral Tokens
    • Collateralized Stablecoin
    • Fiat currency
    • Liquidity pool
    • Open Position: Meaning and Risk in Trading
    • Slippage
    • Spot price
  • Common Attack Vectors
    • Checking access control
    • Access control issues on critical functions
    • Account Existence Check for low level calls
    • Account Existence Check
    • Common attacks with contract/EOA addresses
    • Arithmetic under/overflow
    • Assert Attack
    • Assert require revert
    • Assert Violation
    • Bad Interface DOS
    • Bad pragma and compiler
    • Block Timestamp Manipulation
    • Bypassing contract check
    • Code With No Effects
    • Code size check vulnerability
    • Constructors with Care
    • Default Visibilities
    • Delegatecall
    • Delegatecall
    • Denial of Service (DoS)
    • DoS with block gas limit
    • Entropy Illusion
    • External contract referencing
    • Flash Loan Attack
    • Floating Point and Precision
    • Function selector abuse
    • Function selector abuse
    • Smart contract gas griefing
    • Hash collision parameters
    • Hash Collisions With Multiple Variable Length Arguments
    • Imprecise arithmetic
    • Improper Array Deletion
    • Incorrect array deletion
    • Incorrect interface
    • Insufficient Gas Griefing
    • Loop through long arrays
    • Message call with hardcoded gas amount
    • Not enough gas for ether transfer
    • Precision Loss in Calculations
    • Oracle Manipulation
    • Public Burn Function
    • Read-only reentrancy
    • Race Conditions/Front Running
    • Reentrancy Attacks
    • Reentrancy
    • Requirement Violation
    • Right-To-Left-Override control character (U+202E)
    • Shadowing State Variables
    • Short Address / Parameter attack
    • Signature Malleability
    • Signature Replay
    • Transaction Order Dependence
    • Tx.Origin Authentication
    • Unchecked CALL Return Values
    • Unexpected ether
    • Uninitialized Storage Pointers
    • Unsafe Ownership Transfer
  • EIP's
    • EIP155
    • EIP55
  • PoW
    • Ethash
    • Scrypt - RFC 7914
  • Questions for self evaluation
    • Questions 23/04/2023 (Nr: 84)
    • Usability guide for questions
  • Frequently asked questions
    • What is the difference between transaction and message?
    • What is the use of a interface or function without implementation?
  • UsefulResources
Powered by GitBook
On this page
  1. Common Attack Vectors

Right-To-Left-Override control character (U+202E)

What is RTLO?

RIGHT TO LEFT OVERRIDE is a Unicode mainly used for the writing and the reading of Arabic or Hebrew text.

The properties of the character are quite unique, in the sense that the operations are switched and instead of going left to right like it usually would, they are switched.

The right to left override attack is when U+202E character is secretly used to maliciously change the context of the code being executed.

This vulnerability is used to disguise the names of files and can be attached to the carrier like email.

For example, the file name with ThisIsRTLOfileexe.doc is actually ThisIsRTLOfiledoc.exe, which is an executable file with a U+202e placed just before “doc.”

Let's see an example

// SPDX-License-Identifier: MIT
pragma solidity 0.7.5;

contract Calculator {

function add(uint256 x, uint256 y) public pure returns (uint256) {
        /* start function*/
        require(x + y >= x);
        return /*first number*/x + y/*second number*/
        /* end function*/;
    }

function sub(uint256 x, uint256 y) public pure returns (uint256) {
        /* start function*/
        require(y <= x);
        return /*bigger number*/x - y/*samller number*/
        /* end function*/;
    }

function subRTL(uint256 x, uint256 y) public pure returns (uint256) {
        /* start function*/
        require(y <= x);
        return /*bigger number‮/*rebmun rellams*/y - x/*
        ‭/*end function */;
    }
}

We see the sub and subRTL functions having the same logic of code. This just seems like the redundant logic of coding, right? But it is not just like that!

if you copy the Calculator smart contract code (Calculator.sol) to your favorite IDE or code editor, you will see something wrong with thesubRTL function.

The [U+202E] is a Right-To-Left Override character that can be used to force writings in the direction of text or even in the smart contract code. Also, the [U+202D] is a Left-To-Right Override character that is used to force the direction of the code back to normal. The subRTL is a subtraction logic reversion.

Solutions and notes

  • This vulnerability can be detected by the solidity compiler 0.7.6 or above

  • Malicious actors can use the Right-To-Left-Override Unicode character to force RTL text rendering and confuse users as the real intent of a contract

  • Reading code from Pastebin or block explorer without trying to copy and paste it to IDE or Code Editor which cannot guarantee the securement of smart contracts.

PreviousRequirement ViolationNextShadowing State Variables

Last updated 2 years ago

Alt text