aboutsummaryrefslogtreecommitdiffstats
path: root/docs/security-considerations.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/security-considerations.rst')
-rw-r--r--docs/security-considerations.rst8
1 files changed, 6 insertions, 2 deletions
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.