The function toLower in the contract String.sol has a potential vulnerability because it lacks proper input validation.
It only accounts for basic ASCII uppercase characters (A-Z) and does not appropriately handle multi-byte characters like 'Ö', 'À', or 'Æ'.
It only changes the case for ASCII characters, making it lowercase.
Proof of Concept
for (uint256 i = 0; i < bStr.length; i++) {
// Uppercase character...
if ((uint8(bStr[i]) >= 65) && (uint8(bStr[i]) <= 90)) {
// So we add 32 to make it lowercase
bLower[i] = bytes1(uint8(bStr[i]) + 32);
} else {
bLower[i] = bStr[i];
}
}
Tools Used
Manual Review
Recommended Mitigation Steps
The best approach is to avoid making assumptions about the encoding of string data or individual characters in that data. Developers should add validation to ensure that the string input is what they expect it to be, and handle cases when it is not. This might include using a library or tool that can properly handle multi-byte characters.
In case you want to handle only ASCII characters you can enforce the input to be compliant with your requirements, returning an error or reverting the transaction if non-compliant characters are found.
If it is necessary to support UTF-8 encoded text, it is recommended to use a function or library that properly supports transforming all uppercase characters to their corresponding lowercase versions without assumptions.
Please note that handling the conversion of international characters in a decentralized context (like the Ethereum blockchain) can be a quite demanding task, because the EVM does not natively support string operations, which might result in important gas costs.
Lines of code
https://github.com/reserve-protocol/protocol/blob/master/contracts/libraries/String.sol#L14-L21
Vulnerability details
Impact
The function
toLowerin the contract String.sol has a potential vulnerability because it lacks proper input validation.It only accounts for basic ASCII uppercase characters (A-Z) and does not appropriately handle multi-byte characters like 'Ö', 'À', or 'Æ'.
It only changes the case for ASCII characters, making it lowercase.
Proof of Concept
Tools Used
Manual Review
Recommended Mitigation Steps
The best approach is to avoid making assumptions about the encoding of string data or individual characters in that data. Developers should add validation to ensure that the string input is what they expect it to be, and handle cases when it is not. This might include using a library or tool that can properly handle multi-byte characters.
In case you want to handle only ASCII characters you can enforce the input to be compliant with your requirements, returning an error or reverting the transaction if non-compliant characters are found.
If it is necessary to support UTF-8 encoded text, it is recommended to use a function or library that properly supports transforming all uppercase characters to their corresponding lowercase versions without assumptions.
Please note that handling the conversion of international characters in a decentralized context (like the Ethereum blockchain) can be a quite demanding task, because the EVM does not natively support string operations, which might result in important gas costs.
Assessed type
Invalid Validation