Boost _ Folks Finance 34150 - [Smart Contract - Low] Failed messages never expire and can be replayed by anyone potentially allowing users to be griefed
Submitted on Tue Aug 06 2024 02:16:38 GMT-0400 (Atlantic Standard Time) by @JCN2023 for Boost | Folks Finance
127:functionreceiveMessage(Messages.MessageReceivedmemory message) externalpayableoverride {...115:// call handler with received payload116:tryBridgeMessenger(handler).receiveMessage(message) {117:// emit message received as suceeded118:emitMessageSucceeded(adapterId, message.messageId);119: } catch (bytesmemory err) {120:// don't revert so GMP doesn't revert121:// store and emit message received as failed122: failedMessages[adapterId][message.messageId] = message; // store failed message123:emitMessageFailed(adapterId, message.messageId, err);
The message can then be retried at anytime via the same BridgeRouter:
127:functionretryMessage(uint16 adapterId,bytes32 messageId) externalpayable {128:// get failed message if known129: Messages.MessageReceived memory message =_getFailedMessage(adapterId, messageId);130:131:// convert handler to address type (from lower 20 bytes)132:address handler = Messages.convertGenericAddressToEVMAddress(message.handler);...140:// clear failure before call to handler141:delete failedMessages[adapterId][message.messageId];142:143:// call handler with received payload144:tryBridgeMessenger(handler).receiveMessage(message) {145:// emit message retry as suceeded146:emitMessageRetrySucceeded(adapterId, message.messageId);147: } catch (bytesmemory err) {148:// store and emit message retry as failed149: failedMessages[adapterId][message.messageId] = message;150:emitMessageRetryFailed(adapterId, message.messageId, err);
As we can see above, the msg.sender of the retryMessage transactions is not validated. Therefore, anyone is able to retry a failed message at anytime.
Impact
Bad actors can retry user's old, failed messages. This will allow the user's loan to potentially be manipulated without their knowledge. For example, an old withdraw or borrow transaction can be retried, forcing the user to redeposit their collateral or repay their unexpected borrow position. Failed messages would likely be a result of user error, but can also be temporal (cap reached). In these cases, users may opt to simply submit a new transaction with more optimal arguments in order to have a successful tx.
The conditions of this exploit requires users to have old failed messages that were never retried. Additionally, the failed message is not guaranteed to succeed at any future time. Based on these pre-conditions, I have chosen to mark the severity of this report as low.
Recommended Mitigation
I would recommend decoding the message.payload during the retryMessage transaction and validating that the msg.sender is an authorized address for the accountId of the message.
Proof of concept
Proof of Concept
To run foundry POC:
add test file to test/ directory of a foundry repo
add AVAX_FUJI_RPC_URL variable as environment var or in .env file
run test with forge test --mc FolksPOC_GriefUserByFailedTransaction