Waydou - Use of tx.origin Allows Malicious Contracts to Execute Unauthorized Actions

[sherlock-admin2]

Waydou

Medium

Use of tx.origin Allows Malicious Contracts to Execute Unauthorized Actions

Summary

The use of tx.origin in the protocol's smart contracts introduces a critical vulnerability that allows any contract the user interacts with to impersonate the user and perform unauthorized actions within the protocol. This can lead to a wide range of attacks, including the manipulation of user funds, unauthorized liquidations, or opening and closing positions without the user's consent.
While maybe people might argue this is the user's fault but a good protocol should always check who's the msg.sender to provide more security

Root Cause

https://github.com/sherlock-audit/2024-08-velar-artha/blob/18ef2d8dc0162aca79bd71710f08a3c18c94a36e/gl-sherlock/contracts/core.vy#L166
The root cause is the use of tx.origin instead of msg.sender for user authentication in key protocol functions. tx.origin always refers to the address that originally initiated the transaction, regardless of which contracts were called in between. This means that if a user interacts with a malicious contract, that contract can trigger any function on the protocol with tx.origin still pointing to the user's address, effectively allowing the malicious contract to act on behalf of the user.

Internal pre-conditions

1.The smart contract contains functions (mint, burn, open, close, liquidate, etc.) that rely on tx.origin to verify the identity of the user.
2. The functions perform critical actions such as transferring funds, opening or closing positions, or liquidating assets based on the tx.origin check.

External pre-conditions

1. A user interacts with an untrusted or malicious smart contract.
2. The malicious smart contract initiates a transaction that calls the protocol's functions using the user's tx.origin.

Attack Path

1. An attacker deploys a malicious contract designed to interact with the protocol's smart contracts. This malicious contract could be designed to execute unauthorized actions like opening, closing, or liquidating positions on behalf of any user who interacts with it.
2. A user unknowingly interacts with the malicious contract.
3. The malicious contract, while being executed by the user, calls the protocol's smart contract functions (mint, burn, open, close, liquidate, etc.) using the user's tx.origin.
   4.Since tx.origin returns the user's address, the protocol's contract mistakenly treats the call as if it was directly initiated by the user.
   5.The malicious contract can perform any action that the user is allowed to perform, such as transferring funds, opening or closing positions, or even liquidating assets, without the user's explicit consent.

Impact

1.Unauthorized Access: Any contract the user interacts with can perform actions on behalf of the user in the protocol, leading to unauthorized access and control over user funds and positions.
2.Financial Losses: Attackers can open, close, or liquidate positions without the user's knowledge, potentially leading to significant financial losses(closing a negative position before the asset bounce back up).
3.Loss of User Trust: The protocol could lose user trust due to the ability of third-party contracts to execute actions on their behalf without explicit permission.

PoC

No response

Mitigation

Use msg.sender in the arguments, this way when the api calls the core you have the adress of user in the parameters

Duplicate of #82