127:functionreceiveMessage(Messages.MessageReceivedmemorymessage)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:
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