Closed sherlock-admin closed 6 months ago
1 comment(s) were left on this issue during the judging contest.
takarez commented:
invalid
We consider this issue valid, but not a Medium (low instead):
Not sure if we should mark it as confirmed, or dispute it?
The protocol team fixed this issue in PR/commit https://github.com/arcadia-finance/lending-v2/pull/131.
@Thomas-Smets would this grief any actions within the protocol (i.e. is transferOwnership()
used anywhere else in the protocol)?
No, don't think so.
Only the boughtIn()
also transfers account ownership, but that is via _transferOwnership()
, which is not blocked.
Agree I believe this is low severity given no core functionality is broken.
Escalate
A scenario in which this issue can lead to financial losses for a user:
Escalate
A scenario in which this issue can lead to financial losses for a user:
- A user provides collateral and takes a debt.
- The price of the asset in which the collateral was provided begins to drop.
- The user does not have funds to provide more collateral or repay the debt, which is necessary to improve the account health factor.
- To reduce losses, the user decides to sell the account as an NFT on the marketplace.
- An attacker monitors approval transactions for the marketplace and identifies a user whose account health factor has become low.
- The attacker begins to block the sale (transfer transaction).
- The attacker waits until the price of the collateral asset drops further and then liquidates the account.
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
How does this result in losses? Drops in value of collateral assets are not under anyones control.
The user can sell the account at the current price of the assets to someone who can prevent liquidation.
Again the loss of funds is due to changing market prices, not due to the transfer of the Account.
As far as I know, there were no public information/contest indicating these NFT tracking positions is intended to be traded on secondary exchanges, so I believe this issue to be out of scope and invalid. If users do trade them, then it is between the buyers and sellers discretion.
@nevillehuang I am not saying that the issue is valid, but FYI, there was such info in the docs: https://docs.arcadia.finance/protocol/arcadia-accounts
Each Account is an NFT on itself, and can be displayed in existing portfolio trackers as such (eg. Zapper, OpenSea, DeBank, …). Even more, an Account can be transferred (or sold!) as a whole, including all assets as collateral and all liabilities against the Account. Just like you’re used to transferring NFTs!
@pa-sh0k Thanks for correcting me, then this definitely could cause a explicit DoS in allowing sale of tokens. I am unsure if this qualifies as core contract functionality though, but I am inclined to think otherwise, given funds are still retained by the owner.
I don't know how you determine what the core functionality is. But I believe that the only reason why the account is an ERC-721 token is to be able to trade it.
Also, I want to mention that the target might not be only a user; the target might be the protocol itself.
No incentives + cost for attackers to do it forever
First of all, no one expects a DoS attack to last forever. Incentives might be very simple - to ruin the reputation of the protocol. Costs in L2 networks are low.
Do you think that if an attacker blocks all transfers, at least for a month, will this result in losses for the protocol? Who will lose more?
Again the loss of funds is due to changing market prices, not due to the transfer of the Account.
The potential loss of funds is due to the inability to transfer the account at the current market price.
but unfortunately the price went up so our user gained thanks to the attacker
Of course, the price may not drop further, so this is a potential loss of funds; otherwise, it would be a high issue. And on a bear market, it's quite predictable.
The main reason accounts are an ERC721 is to make them visible in already existing wallet monitoring infrastructure such as zapper, debank, ... Selling accounts on secondary markets is a nice bonus we get from that ERC standard, but nothing core whatsoever. The protocol will work perfectly fine even if accounts couldn't be transferred at all (with the notable exception of the negative flow of the negative flow of an auction).
The potential loss of funds is due to the inability to transfer the account at the current market price.
A user really cannot have a loss of market value due to not being able to sell their account at the time they want. Instead, the user at that point can simply withdraw the assets and sell the assets themselves. The "account" on itself has no value, only the assets within. There is no special "asset" that a user can create within the account which isn't create-able outside of an account. Alternatively the user can close its margin account with its current creditor.
Do you think that if an attacker blocks all transfers, at least for a month, will this result in losses for the protocol? Who will lose more?
I honestly do not think it will cost the protocol anything. There is no "value" in selling or transferring accounts, it's just a gimmick or a handy feature if users want to transfer whole portfolios at once instead of individual asset transfers. We will not even offer any functionality related to transferring account on our dapp.
It seems the user could withdraw a position and create a new one and sell it atomically if they had to. They can always also pay the debt back, as @j-vp mentioned.
Even though it doesn't meet criteria for a Medium severity issue, it's a really nice finding @0xf1b0!
Planning to reject the escalation and leave the issue as is – a low severity one.
it's a really nice finding
@Czar102 thank u sir, appreciate it
Result: Low Unique
Fix looks good. borrow amounts of 0 now revert
The Lead Senior Watson signed off on the fix.
fibonacci
medium
An attacker could prevent the account from being transferred or sold on secondary markets
Summary
Incorrect verification that the caller is the beneficiary allows anyone to trigger the cool-down period and prevent the account from being transferred.
Vulnerability Detail
Arcadia mints an NFT for every account created by the factory.
The
AccountV1::transferOwnership
function uses a cool-down period to prevent any account action that might be disadvantageous to a new owner.It is assumed that actions that trigger the cool-down period can only be performed by either the account owner or beneficiary.
However, the
LendingPool::borrow
function's check thatmsg.sender
is the beneficiary can be bypassed if a zero amount is passed, because it only verifies that the amount is less or equal than the allowances.Therefore, anyone can call this function on behalf of any account and trigger the cool-down period.
There is no need to front-run a transaction; calling it once during a cool-down period is sufficient. Such an attack can persist for a long time and will not incur significant costs on an L2 network.
POC
Add the
POC.t.sol
file to thelending-v2/test/fuzz/LendingPool/
folder. Run the test withforge test --mc POC -vv
.Impact
A user may be unable to transfer the account or sell it on the secondary market, leading to potential financial losses.
Code Snippet
https://github.com/sherlock-audit/2023-12-arcadia/blob/main/accounts-v2/src/accounts/AccountV1.sol#L138-L141 https://github.com/sherlock-audit/2023-12-arcadia/blob/main/accounts-v2/src/accounts/AccountV1.sol#L265-L270 https://github.com/sherlock-audit/2023-12-arcadia/blob/main/accounts-v2/src/accounts/AccountV1.sol#L318 https://github.com/sherlock-audit/2023-12-arcadia/blob/main/lending-v2/src/LendingPool.sol#L426-L431
Tool used
Manual Review
Recommendation