14 lines
1.6 KiB
Plaintext
14 lines
1.6 KiB
Plaintext
|
== CryptoCTF smart-contract rewrite
|
||
|
|
|
||
|
|
Key feature: generalization of contest creation, it is possible to run an arbitrary number of independent contests through a single deployment of the smart-contract.
|
||
|
|
|
||
|
|
Known security bugs have been fixed. Key solution: one has to sign his/her own address.
|
||
|
|
|
||
|
|
The correctness has been thoroughly tested. Result: we've also found yet another (new) security bug in the original smart contract:
|
||
|
|
If the signature is garbled, in particular when its last byte is neither one of 0x1b and 0x1c (on the Ethereum mainnet, at least), then the `ecrecover()` function returns a 0 address, which happens to equal the value that is "stored" for challenges that have not yet been added. This would cause the system to believe that a correct answer was submitted. This can be used as an attack in 2 ways:
|
||
|
|
• A contestant can submit seemingly correct answers for an unbounded number of non-existent challenges, thus spamming the logs with "challenge solved" messages.
|
||
|
|
• If challenges are added while submissions are open, then a contestant can solve such challenges before they are added; if this challenge belongs to the class where "only the first solver is credited", then this will prevent others from really solving the challenges. The contestant doesn't get any points for doing this though, because not-yet-existent challenges are worth 0 points per default "storage".
|
||
|
|
|
||
|
|
|
||
|
|
Pending/incomplete feature (would have been): a user-friendly UI that works in conjunction with MetaMask, and where it is sufficient to input a literal flag into a field, as opposed to the need to use unreadable Python scripts and smart-contract code.
|