Valinity security record

In this project, many contracts extend `RegistrarClient.sol` and rely on the `Registrar` to provide the contract address references. These contracts include: 1. `VYToken` 2. `VETHYieldRateTreasury` 3. `VETHP2P` 4. `VETHRevenueCycleTreasury` 5. `VETHGovernance` 6. `VETHReverseStakingTreasury` In contract `Registrar.sol`, function `setContracts()` allows privileged role `AdminAgents` to update the address reference. Any compromise to the `AdminAgents` account may allow the hacker to take advantage of this authority and set incorrect contracts address references. Misuse of this functionality might potentially affecting all users and contracts interacting with those addresses and threaten the integrity of multiple contracts within the project. ```solidity=67 function setContracts(address[] calldata _addresses) external onlyAdminAgents onlyUnfinalized { require(_validContractsLength(_addresses.length), "Invalid number of addresses"); // Loop through and update _prevContracts entries only if those addresses are new. // For example, assume _prevContracts[0] = 0xABC and contracts[i] = 0xF00 // If _addresses[i] = 0xF00 and we didn't perform the check below, then we would overwrite the old // 0xABC with 0xF00, thereby losing whatever actual previous contract address that was. for (uint i = 0; i < _contracts.length; i++) { if (_addresses[i] != _contracts[i]) { _prevContracts[i] = _contracts[i]; } } _contracts = _addresses; emit SetContracts(_addresses); } ```

The function `airdropTokens()` allows BackendAgents to mint arbitrary amounts of tokens when registrar contract has not been finalized. Furthermore, these minted tokens are not included in the calculated circulating supply, leading to an inaccurate representation of the token's total supply and valuation metrics. ```solidity=243 function airdropTokens(address[] calldata _addresses, uint[] calldata _amounts) external onlyBackendAgents { require(_addresses.length == _amounts.length, "Argument array length mismatch"); _requireRegistrarIsUnfinalized(_getMainEcosystemRegistrar()); // Check main ecosystem for (uint i = 0; i < _addresses.length; i++) { super._mint(_addresses[i], _amounts[i]); } } ``` Exploit Scenario: - An attacker with control of a BackendAgent account could mint an excessive number of vyTokens. - They could then transfer these minted tokens into the `VETHRevenueCycleTreasury`, artificially diluting the circulating supply and significantly lowering the yield rate. - Exploiting this artificially lowered yield rate, the attacker could then interact with the `VETHReverseStakingTreasury` to restake a minimal amount of vyTokens and borrow a disproportionally large amount of ETH. - The attacker could drain the ETH treasury with this method, causing substantial financial loss. Unlimited minting presents a major risk as it allows for substantial economic manipulation and exploitation. An attacker can not only devalue the yield rate but can also extract large amounts of ETH from the treasury, thereby compromising the entire ecosystem's financial stability.

In the contract MFCExchangeCap, the role `onlyBackendAgents` has authority over the function `createOffer()`. In the function `createOffer()`, according to the design document the price is supposed to be twice the floor price but this is not enforced in the contract. Any compromise to the `onlyBackendAgents` account may allow a hacker to create an offer with any price, which could potentially lead to decrease in the floor price. For the formal verification, we used an assumption that the price is set correctly.

During testing, the testers found that the AWS EBS volumes for the `My Freedom Coin` project were not encrypted.

During testing, the testers found that `My Freedom Coin` project did not configure the Rotate Access Keys policy.

The mnemonic phrase is a list of words that can be used to recover a wallet account. Obtaining the mnemonic can potentially allow the attacker to gain full control of the wallet. The application neither has a mechanism in place to stop a user from taking the screenshot of the displayed wallet secrets nor display a warning to remind the user of the risk of taking a screenshot.

The passcode retry time limit prevents an attacker from brute-forcing the user's passcode. However, it was found that the time limit can be bypassed by going back to the parent menu and then re-entering the enter passcode screen.

An address is not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=23 _primaryStakeholder = primaryStakeholder_; ``` - `primaryStakeholder_` is not zero-checked before being used.

When analyzing the `AndroidManifest.xml` file, the testers found that the Activity of `com.myfreedomcoin.mfc.MainActivity` was not protected due to the setting of `exported=true`.

The application is signed with v1 signature scheme, making it vulnerable to Janus vulnerability on Android <7.0 The Janus vulnerability stems from the possibility to add extra bytes to APK files and to DEX files. On the one hand, an APK file is a zip archive, which can contain arbitrary bytes at the start, before its zip entries (actually more generally, between its zip entries). The JAR signature scheme only takes into account the zip entries. It ignores any extra bytes when computing or verifying the application’s signature. On the other hand, a DEX file can contain arbitrary bytes at the end, after the regular sections of strings, classes, method definitions, etc. A file can, therefore, be a valid APK file and a valid DEX file at the same time. References: https://www.xda-developers.com/janus-vulnerability-android-apps/