You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The scratch buffer is (re)used very often in emit (at least in the substrate target). This might lead to unwanted data leakage, exposing access to bogus data in memory from Solidity. This code:
contractA {
function setVars(address_contract, uint256_num) publicpayablereturns(bytesret) {
(boolok, ret) =_contract.call(abi.encodeWithSignature("setVars(uint256)", _num));
// Oh no, forgot to assert on ok
}
}
Results in the following behaviour, if the input to the setVars function is invalid:
While sema does emit a warning about the unused variable. It can still be ignored, or it the check can be erroneous.
We can do better here. We should identify all locations in emit with this issue (the problem might be in other places too). Possible solutions inlcude
using alloca wherever the buffer size is small or known beforehand (performance overhead should be negligible)
bzero8ing out the buffer before using it (costly).
only clear it if the call failed. But: On 2 subsequent scratch buf usages, where both were "successful" and hence the scratch buf is not cleared. Given during one usage, less data was written. Then we still end up with bogus data in the scratch buf. I'm not yet convinced that this is ultimately secure in all cases.
The text was updated successfully, but these errors were encountered:
The scratch buffer is (re)used very often in emit (at least in the substrate target). This might lead to unwanted data leakage, exposing access to bogus data in memory from Solidity. This code:
Results in the following behaviour, if the input to the
setVars
function is invalid:While sema does emit a warning about the unused variable. It can still be ignored, or it the check can be erroneous.
We can do better here. We should identify all locations in emit with this issue (the problem might be in other places too). Possible solutions inlcude
alloca
wherever the buffer size is small or known beforehand (performance overhead should be negligible)bzero8
ing out the buffer before using it (costly).The text was updated successfully, but these errors were encountered: