Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

finalizelongtermrental() refunds money to the token owner/ property manager instead of the tenant #44

Closed
c4-bot-3 opened this issue Oct 11, 2024 · 7 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue duplicate-26 🤖_primary AI based primary recommendation 🤖_25_group AI based duplicate group recommendation satisfactory satisfies C4 submission criteria; eligible for awards sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons

Comments

@c4-bot-3
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2024-10-coded-estate/blob/97efb35fd3734676f33598e6dff70119e41c7032/contracts/codedestate/src/execute.rs#L1728

Vulnerability details

Impact

finalizelongtermrental() sends money to the token owner/ property manager instead of the tenant when the rental reservation has been cancelled.

Proof Of Concept

https://github.com/code-423n4/2024-10-coded-estate/blob/97efb35fd3734676f33598e6dff70119e41c7032/contracts/codedestate/src/execute.rs#L1727-L1731

      for (i, item) in token.rentals.iter().enumerate() {
            if item.address == Some(Addr::unchecked(tenant.clone()))
                && item.renting_period[0].to_string() == renting_period[0]
                && item.renting_period[1].to_string() == renting_period[1]
            {
                position = i as i32;
                amount = item.deposit_amount;

                if item.cancelled {
                    target = token.owner.to_string();
                    let fee_percentage = self.get_fee(deps.storage)?;
                    self.increase_balance(deps.storage, token.longterm_rental.denom.clone(), Uint128::new((u128::from(amount) * u128::from(fee_percentage)) / 10000))?;

                    amount -= Uint128::new((u128::from(amount) * u128::from(fee_percentage)) / 10000);
                }

                    
                    ....

        if amount > Uint128::new(0) {
            Ok(Response::new()
                .add_attribute("action", "finalizelongtermrental")
                .add_attribute("sender", info.sender)
                .add_attribute("token_id", token_id)
                .add_message(BankMsg::Send {
                    to_address: target.clone(),
                    amount: vec![Coin {
                        denom: token.longterm_rental.denom,
                        amount: amount,
                    }],
                }))            
        } 

finalizelongtermrental() iterates through the token.rentals array to find a specific rental. If this rental was cancelled by the tenant or token owner, the deposit_amount which is the rent should be refunded back to the tenant, the address which provided the rent amount/made reservation in the first place. But in the logic above, if item.cancelled == true, target is set to the token owner, the token owner is the manager/landlord of the rental property. This means that even if a reservation is cancelled, the deposit_amount still goes to the token owner. item.cancelled is set to true in cancelreservationafterapprovalforlongterm().

So if tenant makes reservation via setreservationforlongterm() and then proceeds to cancel after approval via cancelreservationafterapprovalforlongterm(), the deposit_amount which can be rent paid will not be refunded to the tenant when finalizelongtermrental() is called. It will go to the token owner.

The correct logic should be that if reservation item is marked cancelled, deposit amount should be refunded to tenant. If not marked cancelled then the deposit amount can go to token owner.

Reservation is cancelled, no value is provided but the no refund for the tenant who payed rent.

Recommened Mitigation

if item.cancelled == true make the target to be the tenant or item.address

Assessed type

Context

@c4-bot-3 c4-bot-3 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Oct 11, 2024
c4-bot-4 added a commit that referenced this issue Oct 11, 2024
@c4-bot-11 c4-bot-11 added 🤖_25_group AI based duplicate group recommendation 🤖_primary AI based primary recommendation labels Oct 11, 2024
@OpenCoreCH
Copy link

OpenCoreCH commented Oct 12, 2024

Similar issue as #26 (wrong handling of cancelled reservations when finalizing), but somewhat different causes. Leaving them unduped for now

@c4-judge
Copy link
Contributor

OpenCoreCH marked the issue as primary issue

@c4-judge c4-judge added the primary issue Highest quality submission among a set of duplicates label Oct 12, 2024
@blockchainstar12 blockchainstar12 added the sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons label Oct 14, 2024
@blockchainstar12
Copy link

This is intended logic

@OpenCoreCH
Copy link

For #26 and this, the underlying issue is that the cancellation vector of long term rentals is ignored.

@c4-judge
Copy link
Contributor

OpenCoreCH changed the severity to 2 (Med Risk)

@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value downgraded by judge Judge downgraded the risk level of this issue and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Oct 16, 2024
@c4-judge
Copy link
Contributor

OpenCoreCH marked the issue as duplicate of #26

@c4-judge c4-judge added duplicate-26 and removed primary issue Highest quality submission among a set of duplicates labels Oct 16, 2024
@c4-judge
Copy link
Contributor

OpenCoreCH marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue duplicate-26 🤖_primary AI based primary recommendation 🤖_25_group AI based duplicate group recommendation satisfactory satisfies C4 submission criteria; eligible for awards sponsor acknowledged Technically the issue is correct, but we're not going to resolve it for XYZ reasons
Projects
None yet
Development

No branches or pull requests

5 participants