---
title: PRE-CertiK_Oracle-23_09_2020
tags: pre-report, Done, CertiK, solidity, ethereum, AA
author: angelos.apostolidis@certik.org
---
<center>
<h1>
<img src="https://i.imgur.com/728TmOX.png" width="64" />
CertiK Pre-Report for <a href="https://www.certik.foundation/blog/securing-defi-with-certik-security-oracle/">CertiK Security Oracle</a>
</h1>
</center>
| Environment | Languages |
| ----------- | --------- |
| Ethereum | Solidity |
## Summary
The codebase contains the Security Oracle and the Security Oracle Proxy. The former is responsible for aggregating a function's score, meaning its security level (or multiple functions), and saving the result(s). The latter is responsible for delegating calls to other contracts, with proper forwarding of return values and bubbling of failures. Lastly, an example is given on how a DeFi project will use the CertiK Security Oracle.
The team has statically analyzed and manually reviewed the smart contracts of the Unit protocol core repository for security vulnerabilities and compliance with Solidity and Yul language preferred practices and standards. 3 major, 1 minor and 10 informational findings were found. See the [Findings Overview](#Findings) for more information.
The following documents were used as the sources of truth for the intended functionality of the CertiK Security Oracle:
* https://www.certik.foundation/blog/securing-defi-with-certik-security-oracle
* https://github.com/certikfoundation/security-oracle-smart-contracts/blob/d9164fc7dd182b0f2d1dc3286324b9f18c19e55c/README.md
The SHA-1 hash of the audited commit is:
* [d9164fc7dd182b0f2d1dc3286324b9f18c19e55c](https://github.com/certikfoundation/security-oracle-smart-contracts/tree/d9164fc7dd182b0f2d1dc3286324b9f18c19e55c)
**Auditors:**
Alex Papageorgiou
Email: alex.papageorgiou@certik.org
PK: `970b96f66c3e3c77db81c874b3d02048a9cea893ded728f8365264d129490f0b`
Angelos Apostolidis
Email: angelos.apostolidis@certik.org
PK: `44884b45a3308033e3e5050e188fff4f4ebb163596d0dacbbadc5a8c5f645436`
<div style="page-break-after: always"/>
## Findings
| ID | Title | Type | Severity |
|-|-|-|-|
| [CSO-01](#CSO-01) | Unlocked Compiler Versions | Language Specific Issue | Informational |
| [CSO-02](#CSO-02) | `struct` Optimization | Optimization | Informational |
| [CSO-03](#CSO-03) | Uncommon Naming Convention | Coding Style | Informational |
| [CSO-04](#CSO-04) | Use of `memory` Over `storage` | Optimization | Informational |
| [CSO-05](#CSO-05) | Potential High `gas` Operation | Optimization | Informational |
| [CSO-06](#CSO-06) | Check Against the Zero Address | Volatile Code | Informational |
| [CSO-07](#CSO-07) | Different Compiler Versions | Language Specific Issue | Major |
| [CSO-08](#CSO-08) | Malicious Hash Collision | Language Specific Issue | Minor |
| [CSO-09](#CSO-09) | `initialize` Paradigm | Language Specific Issue | Informational |
| [CSOP-01](#CSOP-01) | Unlocked Compiler Versions | Language Specific Issue | Informational |
| [CSOP-02](#CSOP-02) | Uncommon Naming Convention | Coding Style | Informational |
| [CSOP-03](#CSOP-03) | Different Compiler Versions | Language Specific Issue | Major |
| [DFE-01](#DFE-01) | Unlocked Compiler Versions | Language Specific Issue | Informational |
| [DFE-02](#DFE-02) | Different Compiler Versions | Language Specific Issue | Major |
<div style="page-break-after: always"/>
---
### [CertiKSecurityOracle.sol](https://github.com/certikfoundation/security-oracle-smart-contracts/blob/d9164fc7dd182b0f2d1dc3286324b9f18c19e55c/contracts/CertiKSecurityOracle.sol) (CSO)
Implementation of the Security Oracle.
#### <a name="CSO-01">CSO-01</a>: Unlocked Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Informational | L2 |
##### Description:
An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers.
This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
##### Recommendation:
We advise that the compiler version is instead locked at the lowest version possible that the full project can be compiled at.
#### <a name="CSO-02">CSO-02</a>: `struct` Optimization
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Optimization | Informational | L17-L20 |
##### Description:
Each `struct` packs its members in 256-bit chunks. The `Result` struct contains the `score` (`uint8`) and the `expiration` (`uint256`) members, thus reserving two 256-bit chunks in storage.
##### Recommendation:
We advise that the data type of the `expiration` member of the `Result` struct is changed to `uint248`, as the maximum bit-size that a datetime variable reserves are 64-bit, resulting in a one chuck storage reservation for the struct.
#### <a name="CSO-03">CSO-03</a>: Uncommon Naming Convention
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Coding Style | Informational | L25 |
##### Description:
The linked variable is prefixed with an underscore yet is declared as public.
##### Recommendation:
We advise that the underscore is omitted per the Solidity style guide.
#### <a name="CSO-04">CSO-04</a>: Use of `memory` Over `storage`
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Optimization | Informational | L35 |
##### Description:
The linked variable is redundantly stored in `storage`.
##### Recommendation:
We advise the team to store the `result` variable in `memory` instead of the `storage`.
#### <a name="CSO-05">CSO-05</a>: Potential High `gas` Operation
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Optimization | Informational | L72-L74, L105-L112 |
##### Description:
The linked functions iteratively assign values to a `mapping` in `storage`, based on the length of an input array.
##### Recommendation:
We advise the team to set upper boundary to the input array length.
#### <a name="CSO-06">CSO-06</a>: Check Against the Zero Address
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Volatile Code | Informational | L31-L42, L79-L88 |
##### Description:
The linked functions should check the value of their respective `contractAddress` parameter.
##### Recommendation:
We advise the team to add a `require` statement to check against the zero address.
```solidity
require(contractAddress != address(0), "Error Message");
```
#### <a name="CSO-07">CSO-07</a>: Different Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Major | L2 |
##### Description:
If the compiler version is between `0.4.21` and `0.4.26`, then the contract raises a compilation error due to the keyword `payable`.
##### Recommendation:
We advise that compiler versions below `0.5.0` should be avoided.
#### <a name="CSO-08">CSO-08</a>: Malicious Hash Collision
| Type | Severity | Location |
| ----------------------- | -------- | --------- |
| Language Specific Issue | Minor | L44 - L53 |
##### Description:
Since an empty `bytes4` variable, i.e. 0, points to the default score of a contract, it is possible to have the same score applied to a function of the contract as well. The "identifier" of a contract is simply the first 4 bytes of the `keccak256` hash of the signature, meaning that an attacker would simply need to generate a function signature that results in a `keccak256` hash with 4 leading zeroes which is not an impossible achievement.
##### Recommendation:
We advise that the default grade of a contract is either stored in a different data structure or a sanity check is put in place.
#### <a name="CSO-09">CSO-09</a>: `initialize` Paradigm
| Type | Severity | Location |
| ----------------------- | ------------- | ----------- |
| Language Specific Issue | Informational | L117 - L121 |
##### Description:
The `initialize` function of a contract should be invokable only once via sanity checks. Here, it is possible to subsequently call it multiple times.
##### Recommendation:
We advise that a sanity check is imposed whereby the value of `_defaultScore` is ensured to be `0`. Additionally, we would advise a sanity check on the `updateDefaultScore` function that ensures the new `score` is not `0`.
### [CertiKSecurityOracleProxy.sol](https://github.com/certikfoundation/security-oracle-smart-contracts/blob/d9164fc7dd182b0f2d1dc3286324b9f18c19e55c/contracts/CertiKSecurityOracleProxy.sol) (CSOP)
Implementation of the Security Oracle Proxy.
#### <a name="CSOP-01">CSOP-01</a>: Unlocked Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Informational | L2 |
##### Description:
An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers.
This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
##### Recommendation:
We advise that the compiler version is instead locked at the lowest version possible that the full project can be compiled at.
#### <a name="CSOP-02">CSOP-02</a>: Uncommon Naming Convention
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Coding Style | Informational | L8 |
##### Description:
The linked variable is prefixed with an underscore yet is declared as public.
##### Recommendation:
We advise that the underscore is omitted per the Solidity style guide.
#### <a name="CSOP-03">CSOP-03</a>: Different Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Major | L2 |
##### Description:
If the compiler version is above `0.6.0`, then the contract raises a compilation error due to the `fallback()` function in the `Proxy.sol` file.
##### Recommendation:
We advise that compiler versions above `0.6.0` should be avoided or change the following function of the `Proxy.sol` file:
```solidity
function() external payable {
_fallback();
}
```
to:
```solidity
fallback () external payable {
_fallback();
}
```
### [DeFiExample.sol](https://github.com/certikfoundation/security-oracle-smart-contracts/blob/d9164fc7dd182b0f2d1dc3286324b9f18c19e55c/contracts/DeFiExample.sol) (DFE)
Implementation of a DeFi using CertiK Security Oracle.
#### <a name="DFE-01">DFE-01</a>: Unlocked Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Informational | L2 |
##### Description:
An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers.
This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
##### Recommendation:
We advise that the compiler version is instead locked at the lowest version possible that the full project can be compiled at.
#### <a name="DFE-02">DFE-02</a>: Different Compiler Versions
| Type | Severity | Location |
| --------------------------------- | -------- | ------------------------------------------------------------ |
| Language Specific Issue | Major | L2 |
##### Description:
If the compiler version is between `0.4.21` and `0.4.26`, then the contract raises a compilation error.
##### Recommendation:
We advise that compiler versions below `0.5.0` should be avoided.