The `shortOrder` verification bug on the `RedemptionFacet::proposeRedemption()` allows an attacker to leave a small `shortOrder` on the order book, leading to the protocol's bad debt
Audit: 2024-03-dittoeth-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L81
https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L110-L114
https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L38


# Vulnerability details

## Impact

The `BidOrdersFacet::bidMatchAlgo()` allows a `shortOrder` to be partially matched and leave its `ercAmount` * `price` < `minAskEth` due to the [`DUST_FACTOR` constant](https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/BidOrdersFacet.sol#L190) (as long as its corresponding `shortRecord` is maintaining enough `ercDebt` + `shortOrder`'s `ercAmount` to keep the position >= the `minShortErc` threshold).

The redemption process enables redeemers to redeem their `ercEscrowed` for `ethCollateral` on target `shortRecords`. If a `shortRecord` was partially filled, the `RedemptionFacet::proposeRedemption()` must guarantee that the corresponding `shortOrder` maintains the `ercAmount` >= `minShortErc`. In other words, if the `shortOrder`'s [`ercAmount` is less than the `minShortErc` threshold](https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L111), the [`shortOrder` must be canceled](https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L113) from the order book. Otherwise, the `shortRecord` position will be less than the `minShortErc` threshold when the order is matched again. Subsequently, **the small `shortRecord` (`short` position) will not incentivize liquidators to liquidate it even if it is liquidable, leaving bad debt to the protocol**.

**I discovered that the `proposeRedemption()` improperly verifies the proposer (redeemer)'s inputted [`shortOrderId` param](https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078bb6fe8ce9f55bcb717e5d2d302d22e/contracts/facets/RedemptionFacet.sol#L81), allowing an attacker to specify the `shortOrderId` param to another `shortOrder`'s id that does not correspond to the target redeeming `shortRecord`.** 

**The vulnerability can bypass the `minShortErc` threshold verification process on the `shortOrder` corresponding to the processing `shortRecord`, eventually allowing an attacker to leave a small `shortRecord` position that disincentivizes liquidators from liquidating the position. Furthermore, the small `shortRecord` also disables the redemption mechanism from redeeming it for `ethCollateral`.**

## Proof of Concept

While processing the `proposalInput` param, the `proposeRedemption()` will load the [`shortOrder` from storage according to the attacker-inputted `shortOrderId` param](https://github.com/code-423n4/2024-03-dittoeth/blob/91faf46078