Skip to content

Latest commit

 

History

History
53 lines (32 loc) · 4.16 KB

053.md

File metadata and controls

53 lines (32 loc) · 4.16 KB

Jumpy Candy Yeti

Medium

Potential private key exposure due to use of DEPLOYER_PRIVATE_KEY and PROPOSER_KEY env variables in DeployAuctionHouseV3StreamEscrowBase.s.sol and ProposeUpgradeAHV3.s.sol scripts.

Summary

The deployment and upgrade scripts for the DeployAuctionHouseV3StreamEscrowBase and ProposeAHv3UpgradeSepolia contracts expose sensitive private keys DEPLOYER_PRIVATE_KEY and PROPOSER_KEY due to their usage in broadcasting transactions. This exposure compromises the security of the deployer and upgrader accounts, creating a potential attack vector for malicious actors with access to the environment where these scripts are executed.

Root Cause

The private keys used for the deployment and upgrade scripts are retrieved from environment variables using Foundry's cheatcode vm.envUint and passed directly into the vm.startBroadcast. Here are the relevant code snippets for DeployAuctionHouseV3StreamEscrowBase.s.sol and ProposeUpgradeAHV3.s.sol:

    uint256 deployerKey = vm.envUint('DEPLOYER_PRIVATE_KEY');
    vm.startBroadcast(deployerKey);
    uint256 proposerKey = vm.envUint('PROPOSER_KEY');
    vm.startBroadcast(proposerKey);

However, this approach exposes the private keys of the deployer and upgrader accounts to the local environment of the machine running the scripts, potentially compromising these accounts. This exposure includes risks from system-level logging, debugging tools, or other processes that could capture or reveal the private keys, increasing the likelihood of accidental disclosure or unauthorized access. Here is the reference to a similar issue from the past audit.

Internal pre-conditions

The private keys stored in the DEPLOYER_PRIVATE_KEY and PROPOSER_KEY environment variables are accessed via vm.envUint and used to start a broadcast session with Foundry's vm.startBroadcast. For that, the private keys are cached in memory during script execution, making them vulnerable to memory-based attacks, side-channel attacks, exposure by debugging tools or shared memory exploits.

External pre-conditions

No response

Attack Path

A realistic attack path might be as follows:

  1. An attacker (internal or external) determines that the deployment scripts are running on a specific machine, CI/CD pipeline, or shared environment (e.g., cloud-based development environments or containerized systems).
  2. An attacker exploits potential unpatched vulnerabilities on the machine or deployment infrastructure and gains read access to environment variables by directly accessing the environment file (e.g., using the printenv command) or by dumping the process memory of the script execution to look for cached private keys. If private keys are accidentally logged during script execution, the attacker can retrieve them from log files.
  3. The attacker uses the exposed private keys to compromise the accounts.

Impact

If the private keys are exposed or leaked, attackers could gain full control of the associated accounts. For example, if the accounts hold any ETH, direct theft of tokens held by the deployer or proposer accounts is possible. With access to the private keys, an attacker could also potentially propose malicious proposals or perform an upgrade/deployment with malicious logic.

PoC

No response

Mitigation

Configure the deployment and upgrade scripts to generate raw transactions rather than broadcasting them. Use a cold wallet to sign the raw transactions offline and return the signed transaction to the script for broadcasting. Alternatively, use dedicated ephemeral accounts for deployments and upgrades. These accounts should be discarded immediately after the operation.