Account random seed calculation has UB

[ProgramCrafter]

Code track

• Account::addr_rewrite https://github.com/ton-blockchain/ton/blob/4cfe1d1a96acf956e28e2bbc696a143489e23631/crypto/block/transaction.h#L248 is BitArray<32> — that is, 32-bit array https://github.com/ton-blockchain/ton/blob/4cfe1d1a96acf956e28e2bbc696a143489e23631/crypto/common/bitstring.h#L461-L463
• it's initialized in Account::unpack_address https://github.com/ton-blockchain/ton/blob/4cfe1d1a96acf956e28e2bbc696a143489e23631/crypto/block/transaction.cpp#L237 by addr_rewrite = addr.bits(), but it works here OK because left-hand side pulls exactly 32 bits it needs out of 256 available;
• but when calculating random seed https://github.com/ton-blockchain/ton/blob/4cfe1d1a96acf956e28e2bbc696a143489e23631/crypto/block/transaction.cpp#L1288, there are 256 bits of data copied from addr_rewrite field, so read is mostly out-of-bounds and accesses addr field: (data.bits() + 256).copy_from(account.addr_rewrite.cbits(), 256).

Proof

Consider the following FunC code.

int prefix_of(slice, slice) asm "SDPFX";
int claimed_seed(slice block_seed, builder my_addr) asm "TWO HASHEXT_SHA256" "s0 DUMP";
int actual_seed() asm "RANDSEED" "s0 DUMP";

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

() main() {
  throw(65535);
}

;; extern "wallet-v5"
cell process_external(int my_id, cell my_storage, slice in_msg_body) method_id(89430) {
  ;; #_ block_seed:uint256 bounty:MsgAddressInt = InMsgBody;
  throw_if(100, my_storage.begin_parse().prefix_of(in_msg_body));

  slice block_seed = in_msg_body~load_bits(256);
  slice me = my_address(); me~skip_bits(11);
  ;; VVV  bug demonstration  VVV
  builder hashed = begin_cell().store_slice(me.preload_bits(32)).store_slice(me.preload_bits(224));
  throw_if(101, claimed_seed(block_seed, hashed) ^ actual_seed());

  slice dest = in_msg_body~load_msg_addr();

  accept_message();

  send_raw_message(begin_cell()
    .store_uint(0x18, 6)
    .store_slice(dest)
    .store_coins(40000000)   ;; 0.040 TON per seed delivered
    .store_uint(0, 107)
    .end_cell(), 2);

  return begin_cell()
    .store_slice(block_seed)
    .end_cell();
}

It succeeds when emulated with certain block seed and the same block seed provided in external message. Thus, random seed of account is calculated from block seed, first 32 and first 224 bits of address.

Expected behavior

The random seed of account is hash of block seed and whole address. In particular, there are no out-of-bounds reads when creating a transaction.

[ProgramCrafter]

If you deem this worthy of a bug bounty, my address is UQCyoez1VF4HbNNq5Rbqfr3zKuoAjKorhK-YZr7LIIiVrX0-.

[EmelyanenkoK]

Hi, thank you! This peculiarity was first time noted by Alex Gapak in February. We have https://github.com/ton-blockchain/ton/compare/testnet...SpyCheese:ton:trans-rand-seed?expand=1 this patch but decided to put it off for now.

[ProgramCrafter]

I believe it's possible to retain current behavior but do so explicitly? Because now it creates a technical debt - requirement that fields addr_rewrite and addr remain in this order.