DerivaDEX 2 security record

The function `Registration:register` (L134-180) is of some concern: 1. Front-run attack: the `register` function binds the "signer" address retrieved from an SGX report data to the function caller (`msg.sender`). However, anyone can monitor the transaction mempool and front-run the call with the same data to bind a specific signer to the attacker's custodian. Neither the `_report` nor the `_signature` specifies which custodian to tie to the signer. Also, note the current implementation does not require the caller of the `register` function to be an approved custodian. Thus, anyone can perform this attack. 2. Replay attack: the `releaseHash` from the `extractMetadataFromReport` function relies on `mrEnclave` and `isvSvn`. However, we assume that the team will run multiple environments (e.g., staging and prod) as a common software engineering practice, and the enclave (program) data can be the same. There can be the risk of a replay attack on the same report and signer cross environments. Note that during this audit, we assume the following statements to be correct for the off-chain components: 1. The hard-coded `exponent` and `modulus` in `Registration.sol:L417-420` (function `verifyReportCryptography`) are the public-key data for the Intel Provisioning Certification Key Certificate (PCK Cert). 2. The Intel Provisioning Certification Service will only sign the attestation after verifying the report is from SGX and does not sign on anything else. 3. The first 20 bytes of the field `QE.REPORT.ReportData` of the quote data are of the address format of the attestation key (see: [SGX doc](https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_SGX_ECDSA_QuoteLibReference_DCAP_API.pdf), section 3.8 and A.4) and only the enclave can specify the value of the field. Otherwise, there is no integrity proof that the signer's address is indeed from the enclave.

We found a few concerning points regarding the library `SolRsaVerify`: 1. Clone and Own: this team seems to port this library seems from another repository ([link](https://github.com/adria0/SolRsaVerify)). However, the team did not port the test from the original repository. Also, the original code seems not fuzz-tested as well. 2. Missing validation: According to the RSA spec doc ([RFC 8017 Section 8.2.2](https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2)), "If the length of the signature S is not k octets, output "invalid signature" and stop.". The function `pkcs1Sha256Verify` does not have such validation. Note that we also have other recommendations in the section on code documentation and best practices to improve the quality of this file.

The `LibCollateral.sol:getUnprocessedWithdrawals` function calculates the `(withdrawalReductionAmount, start, end)` by looping through the linked list of the unprocessed withdrawals. The looping brings the out-of-gas risk to the `LibCollateral.sol:commitWithdrawal` function. Although it cannot commit the halfway-processed withdraw due to the atomic nature of the smart contract, the out-of-gas reversion of the `LibCollateral.sol:commitWithdrawal` function will cause `Collateral.sol:withdraw` (L355-397) and `Stake.sol:withdrawDDX` (L165-210) to fail. Those failures will block users from transferring their funds out of the DEX. Note that the current implementation mitigates the concern by resetting the linked-list head on each withdrawal. It sets the head to the subsequent linked-list node after the check-pointed `latestConfirmedBlockNumber`. In other words, as long as the DEX continuously checkpoints the state back to the smart contract, the users will be able to withdraw without the out-of-gas concern. However, this assumes the availability of the DEX operation. If the users accidentally create too many fragment withdrawals, the DEX can lock users' funds by stopping operating. The ability to block users' exit disobeys the non-custodial assumption that the users have ownership of their funds at all times.