From b71144dd537ec0df90c0fc3599d9c5178810a676 Mon Sep 17 00:00:00 2001 From: chriseth Date: Wed, 6 Jul 2016 18:33:38 +0200 Subject: Expanded malleability risks. --- docs/security-considerations.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst index 5520e96c..4eb64593 100644 --- a/docs/security-considerations.rst +++ b/docs/security-considerations.rst @@ -146,7 +146,11 @@ Minor Details Furthermore, it is not enforced by the EVM, so a contract function that "claims" to be constant might still cause changes to the state. - Types that do not occupy the full 32 bytes might contain "dirty higher order bits". - This is especially important if you access ``msg.data`` - it poses a malleability risk. + This is especially important if you access ``msg.data`` - it poses a malleability risk: + You can craft transactions that call a function ``f(uint8 x)`` with a raw byte argument + of ``0xff000001`` and with ``0x00000001``. Both are fed to the contract and both will + look like the number ``1`` as far as ``x`` is concerned, but ``msg.data`` will + be different, so if you use ``sha3(msg.data)`` for anything, you will get different results. *************** Recommendations @@ -218,4 +222,4 @@ it will be better documented soon. Note that formal verification itself can only help you understand the difference between what you did (the specification) and how you did it (the actual implementation). You still need to check whether the specification -is what you wanted and that you did not miss any unintended effects of it. \ No newline at end of file +is what you wanted and that you did not miss any unintended effects of it. -- cgit