Info

Sacred Hare
Author
Download ZIP (771.8 KB)

Testing and Issues

You can test this entry and submit issues during the testing period of the TON Trustless Bridge Challenge contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

2

Comments

Sacred Hare Feb 5 at 13:31
Сontinuation about Keen Fox Issue
## transaction-checker
Yes, you are right about the unfinished script. There just wasn't enough time. But as I wrote above, the validator check will remain valid in this case (see above).  We do not need to check the weight again if it is checked on the block verification side, here we only check the validity of the validators themselves relative to the block smart-contract. 
Yes, the remark about impure is true, but the Fift compiler took into account verify_signatures and verify_block_shard_data.
You have not added any comments yet...
by rating

Issues

Keen Fox Feb 5 at 08:51
## lite-client

`check_signatures` functions uses only `total_weight` from actual config34. The code extracts pubkeys, signatures and even data itself from `signatures` parameter that could be totally artificial.

So it looks like both `check_block` and `new_key_block` messages don't check provided block for correctness.

## transaction-checker

Script preparing `check_transaction` message for transaction-checker doesn't look finished.

Again looks like nothing stops me from preparing `check_transaction` with fake key-block signatures and using them to sign fake transaction.

Also some important functions in `checker.fc` (like `verify_signatures`, `verify_block_shard_data`, etc) aren't marked `impure` so I believe they are missing in compiled smc bytecode.

In `verify_signatures` function there is only number of valid signatures considered, not their weight.
Sacred Hare Feb 5 at 13:29
Thanks for issue!
## lite-client
I agree with the vulnerability that has arisen on the side of the smart-contract. But this is not available on the script side, since data about the validator and its weight are taken from real network configs, since Pytoniq is a Native ADNL with a direct connection to the LiteServer. In addition, it can be noted that the signatures are correctly verified by a real validator:
- node_id_short is calculated for each validator from the official list.
- A signature is accepted only if it matches an existing validator.
And validator weight take from real config. In this case, all checks (new_key_block and check_block) are fully valid.Therefore, the risk of tampering with validator weights is reduced to 0. If something wasn't clear, you can take another look Python script 208-259.
The website says that the text is too big, and I can't double reply)
Nobody added any issues yet...

New Issue