> For the complete documentation index, see [llms.txt](https://ret2basic.gitbook.io/ctfnote/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ret2basic.gitbook.io/ctfnote/web3-security-research/secureum/epoch-0/slot-7-audit-findings-101/chainlink-sigma-prime.md). # Chainlink - Sigma Prime {% embed url="" %} ## Progress * \[x] \[H-1] Users Can Form Malicious Requests to Steal Tokens From Oracles * \[x] \[H-2] Malicious Users Can DOS/Hijack Requests From Chainlinked Contracts → Not fully understood * \[x] \[M-1] Oracles Can Claim Token Payments Without Processing the Request Callback * \[x] \[M-2] Oracles’ `internalId` Can Be Duplicated, Leading to Unrecoverable Link Tokens ## \[H-1] Users Can Form Malicious Requests to Steal Tokens From Oracles ### Description Malicious users can steal tokens from Oracles by crafting and submitting specific requests. When the `owner` of the Oracle fulfils a request, it performs an external call on line \[118] which is intended to supply the off-chain data to the calling contract. The current implementation is such that a user can manufacture any arbitrary address that the Oracle will call when fulfilling a request, along with any function signature and initial parameter. **Thus a user can craft a malicious request to the Link token contract, which when fulfilled, will transfer Link tokens from the Oracle to the attacker.** To detail this further, the call on line \[118] is: ```solidity return callback.addr.call(callback.functionId, callback.externalId, _data); ``` A malicious user can create a request, which sets `callback.addr` to the address of the Link token contract address. They can set `callback.functionId` to the function signature of `transfer(address,uint)` and they can set `callback.externalId` to be a beneficiary address of their choosing. These variables are set when creating a request. The request’s `data` can be set to ask for a specific value (which is less than or equal to the available Link token balance of the Oracle, i.e. the current price of ether in wei). If an Oracle fulfils such a request and calls `fulfillData()` (line \[101]) with `_data` being a value, i.e. `200e18` (and the Oracle has more than 200 Link tokens), the call on line \[118] will send these tokens to the attacker’s beneficiary address. An example of this attack is given in the tests that accompany this report, specifically test `test_attack_can_steal_oracle_tokens`. Note: This attack is not localized to just Link tokens but to all contracts and functions that do not require more than two parameters. See LNK-02 for a further example. ### Recommendations There are a number of ways to address this issue, some more restrictive (in platform functionality) than others. The least restrictive is to blacklist addresses that `callback.addr` can take. For example, adding a require statement that ensures `callback.addr` is not the Link token address would be one approach. Although this resolves the immediate issue, it is typically dangerous to allow external users to set arbitrary addresses and function calls for a low level call as LNK-02 illustrates. A more restrictive approach would be to only allow callback addresses from the contracts that created the request. This solution would also address LNK-02, LNK-07, and LNK-06. This however may be too restrictive for the purposes of the Chainlink platform. ### Resolution The callback address is now restricted from being the `LINK` address. ## \[H-2] Malicious Users Can DOS/Hijack Requests From Chainlinked Contracts ### Description Malicious users can hijack or perform Denial of Service (DOS) attacks on requests of Chainlinked contracts by replicating or front-running \[2] legitimate requests. The `Chainlinked`(`Chainlinked.sol`) contract contains the `checkChainlinkFulfillment()` modifier on line \[145]. This modifier is demonstrated in the examples that come with the repository. In these examples this modifier is used within the functions which contracts implement that will be called by the `Oracle` when fulfilling requests. It requires that the caller of the function be the `Oracle` that corresponds to the request that is being fulfilled. Thus, requests from `Chainlinked` contracts are expected to only be fulfilled by the `Oracle` that they have requested. However, because a request can specify an arbitrary callback address, a malicious user can also place a request where the callback address is a target `Chainlinked` contract. If this malicious request gets fulfilled first (which can ask for incorrect or malicious results), the `Oracle` will call the legitimate contract and fulfil it with incorrect or malicious results. Because the known requests of a `Chainlinked` contract gets deleted (see line \[147]), the legitimate request will fail. It could be such that the `Oracle` fulfils requests in the order in which they are received. In such cases, the malicious user could simply front-run the requests to be higher in the queue. We further highlight this issue with a trivial example. Consider a simple contract that is using Chainlink to estimate the price of Ether relative to a random token, which users then purchase based off this price. A malicious user could front-run the price request, putting their own request in with a malicious price source that is significantly lower than the actual price. The callback address of the malicious request would be the simple contract, and once fulfilled, would set the price of the simple contract to the malicious one given in the source. An example of this attack is given in the test: `test_attack_can_hijack_request` that accompanies this report. ### Recommendations This issue is related to LNK-01, LNK-07, and LNK-06 in that it arises due to the fact that any request can specify its own arbitrary callback address. A restrictive solution would be the same as given in LNK-01, where callback addresses are localised to the requester themselves. A less restrictive approach may be to include `msg.sender` in the `callbacks` mapping in `Oracle.sol`. Then, when fulfilling the request, the `Oracle` could send the `msg.sender` as an extra parameter. The `checkChainlinkFulfillment()` modifier can then accept or reject the fulfilment based on the original requester, preventing malicious requests from being fulfilled. ### Resolution The `internalId` within an `Oracle` has been modified to `requestId` which is a Keccak hash of the sender with the sender’s `nonce`. This same id is used within the `Chainlinked` contracts which is required to fulfil a request. Thus a malicious user can no longer hijack requests, as doing so would require the malicious request to be sent from the `Chainlinked` contract in order to generate an equivalent `requestId`. ## \[M-1] Oracles Can Claim Token Payments Without Processing the Request Callback ### Description An Oracle can “fulfil” a request without updating state or performing useful calls to the requester. This is due to the lack of gas stipend in the external call made on line \[118]. This means an `Oracle` when submitting a fulfilment request can choose a gas amount which is only enough to perform the operations of changing its own state (that is, lines \[110] through \[114] and approx `52000` gas) and leave little for the external call (the `delete` on line \[113] provides a gas refund meaning some gas will be left for the call). In such a scenario, the external call will fail, however the current transaction will pass, which allows Oracles to withdraw the tokens for the given request. See the `test test_attack_oracle_fulfill_no_callback` for an example. It should be noted, that even if the `Oracle` is assumed to not be malicious, it could still be possible that `estimateGas` may incorrectly determine the gas to be sent in the external call. Thus an `Oracle` can mistakenly be paid without fulfilling the request and as the `callbacks` mapping is deleted, cannot resend the request. If an `Oracle`, blindly follows `estimateGas`, then this leaves an `Oracle` vulnerable to malicious requests which consume large amounts of gas, such as creating Gas Tokens \[3]. ### Recommendations One solution would be to require Oracles to dedicate at least some fixed amount of gas for updating the callback contract. This amount is dependent on how much state/operations are expected for implementations of such callback functions in the Chainlink platform. There are a number of ways this could be implemented in the current code. One such way would be to implement a lower bound on the gas required to send for a callback. This could be done by adding a require statement that ensures the `Oracle` has dedicated at least some constant (here `gasConstant`) amount of gas for the callback contract. For example, adding the following just above line \[118]: ```solidity require (gasleft () >= gasConstant); ``` Alternatively, an upper-bound on gas sent could be set by specifying a fixed amount in the external call itself. This solution would also prevent malicious callback requests from consuming large amounts of gas. ### Resolution A minimum gas limit of `400000` was introduced. This forces `Oracles` to supply at least `400000` gas when fulfilling a request. For malicious contracts trying to exploit excess Oracle gas, it is up to the Oracle to decide whether or not to pay for any extra gas beyond the `400000`, which they can do when performing the transaction. ## \[M-2] Oracles’ `internalId` Can Be Duplicated, Leading to Unrecoverable Link Tokens ### Description The `internalId` is constructed from the keccak hash of `msg.sender` and `_externalId` (which is an arbitrary value sent by the caller). Although the `Chainlinked` contracts increment this value, it is possible for contracts to implement their own versions or call the Oracle directly (via the Link token). In such cases, a repeated `_externalId` from a contract/address will lead to a duplication of `internalId` in the Oracle contract (one example would be an implementation that accidentally sends 0 as the `externalId` many times, or repeats an id). In such cases, the Link tokens that were sent in the previous request (of the same `internalId`) become unrecoverable as the `callbacks` mapping entry gets overridden. This means a user cannot cancel the original request, nor can the Oracle fulfil the original request. As the `withdraw()` function can only withdraw `withdrawableWei` amount of tokens, the original tokens sent to the contract are also non-withdrawable. Please refer to the `test_duplicate_id_lost_tokens` test that accompanies this report for an exploitation example. ### Recommendations This vulnerability can be mitigated by ensuring that an `internalId` does not exist before entering it into the `callbacks` mapping. More specifically, adding a require after line \[76] which ensures that the `internalId` is not currently in use, will prevent overwriting the `callbacks` mapping. Alternatively, a nonce could be introduced in the generation of `internalId`, however this would require modifying the logic of the `cancel()` function to accommodate duplicate `externalId` entries. ### Resolution A require statement has been added on line \[86] which ensures there is no current entry in the `callbacks` mapping, preventing duplication.