From f4d5cc5c35565cf4a39dfa0932f5d2358828c76a Mon Sep 17 00:00:00 2001 From: sanket1729 Date: Wed, 20 Apr 2022 12:21:01 -0700 Subject: [PATCH] Add security advisory about miniscript bug --- doc/security_report_2022_04_20.md | 55 +++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 doc/security_report_2022_04_20.md diff --git a/doc/security_report_2022_04_20.md b/doc/security_report_2022_04_20.md new file mode 100644 index 000000000..bada81caf --- /dev/null +++ b/doc/security_report_2022_04_20.md @@ -0,0 +1,55 @@ +### Security Advisory on Miniscript MinimalIF bug (`d:` wrapper is not `u` ) + +_ALl of the affected versions have been yanked_. Users should upgrade to `1.1.0`, +`2.1.0`, `3.1.0`, `4.1.0`, `5.2.0`, `6.1.0` or `7.0.0`. + +Andrew Poelstra recently discovered a vulnerability in miniscript spec that could +potentially allow miners to steal coins locked in certain miniscript fragments. We +recommend all users upgrade to the latest miniscript version as soon as possible. +Details of the vulnerability are mentioned towards the end of the post. + +For ease of upgrade, we have released a bug fix release for versions 1.1.0, 2.1.0, +3.1.0, 4.1.0, 5.2.0, and 6.1.0. All other previous releases have been yanked for +safety. The miniscript website (bitcoin.sipa.be/miniscript) and compiler have +been updated so that they no longer produce the vulnerable scripts. + +### Details of the vulnerability: + +The wrapper `d` (`OP_DUP OP_IF [X] OP_ENDIF`) was incorrectly marked to have the +`u` property. The `u` property states "When [X] is satisfied, this expression will +put an exact 1 on the stack (as opposed to any nonzero value)". However, this is +only true if we have a `MINIMALIF` consensus rule. Unfortunately, this is only a +policy rule for segwitv0 and p2sh scripts. `MINIMALIF` is a consensus rule since +the taproot upgrade. + +In other words, this vulnerability only affects coins with sh, wsh and shwsh. If +your coins are under taproot descriptor, you are not vulnerable. + +### How can this be exploited? + +Certain combinations of `d` wrapper inside `or_c` or `or_d` are innocuous. However, +when combined with thresh, this could allow miners to steal coins from the threshold +provided the underlying condition in `d` wrapper is satisfied. + +Consider the script `thresh(2, pk(A), s:pk(B), sdv:older(2) )` . Semantically, this +means that either A and B can spend this before 2 blocks, or after 2 blocks either +A or B can spend these funds. The `thresh` fragment expects all of its children to +result in either 1/0 (not any other number). However, a miner could malleate the +user-provided OP_1 in `d` wrapper to OP_2, setting empty signatures A and B bypassing +the threshold check. + +### How to check if you are affected? + +If the latest version of miniscript cannot spend your funds, you could be +affected. In particular, if you are using a `thresh` construction like above, +and the timelock has expired, your coins are vulnerable. If the timelock has not +expired, your funds are not at risk if you move them before the timelock activates. + +If you cannot spend funds with the new update, please contact us. We will assist +you with next steps. + +Alekos(@afillini) and Riccardo Casetta scanned the blockchain for all spent outputs since +the miniscript release to check if there were vulnerable. Fortunately, they could +not find any funds that were vulnerable. + +If you have more questions or need any assistance. Feel free to contact us via IRC or email. \ No newline at end of file