Open c4-bot-5 opened 8 months ago
raymondfam marked the issue as insufficient quality report
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as primary issue
Duplicated submissions come with various POC, but the root cause is the same.
yea this is duplicated from another, but confirmed an issue
rocketman-21 (sponsor) disputed
rocketman-21 (sponsor) confirmed
think this should be medium, it requires that we make the values of the maxheap less than they were inserted at, which isn't possible in CultureIndex (which is upvote only)
rocketman-21 marked the issue as disagree with severity
This is a tough one. First of all I genuinely appreciate the efforts put into this report and many of its duplicates, clearly an underlying bug is shown.
However, no impacts on the function of protocol as a whole are shown. Therefore, it's hard to justify High/Medium
severity for this group of findings.
I have to downgrade to QA for now, but invite the author of this submission or its duplicates to provide a runnable PoC during PJQA which shows impacts through the main entry points of the protocol, i.e. not purely interacting with the MaxHeap
contract.
Thank you for your understanding!
MarioPoneder changed the severity to QA (Quality Assurance)
MarioPoneder marked the issue as grade-a
Hi @MarioPoneder, here is why I believe this issue should be a valid Medium.
Thank you for taking the time to read this.
Hello @MarioPoneder,
I'd like to explain why I think this issue should be considered a valid concern.
The MaxHeap.sol contract is expected to adhere to its full specification, as confirmed by the sponsor. However, this issue clearly highlights a deviation from the specified behavior.
MaxHeap.sol serves as a critical data structure that should remain consistent over time, considering both historical data and ongoing data interactions. If a future version introduces downvoting (possibly by upgrading CultureIndex.sol and changing the admin of MaxHeap.sol), the Max Heap tree could malfunction. This means that even if the team intends to add downvoting as a feature, as mentioned by the sponsor in the provided link, it would be impossible due to this discrepancy. It's essential to emphasize the seriousness of this bug because the data structure should consistently adhere to its standard behavior within its context. Furthermore, as this contract falls within the scope of our responsibilities as auditors, neglecting this issue now may result in MaxHeap.sol being excluded from potential audits in the future. This exclusion could occur because there haven't been any changes, even though a critical bug exists at its core.
Additionally, it's crucial for us to address this issue promptly. Neglecting it at this stage may lead to MaxHeap.sol being omitted from future audits, despite the presence of a critical bug at its core. This omission could happen because there are no planned changes to the file, even though a significant issue persists.
Furthermore, it's worth noting that the sponsor is aware of this issue and is likely to address it. As a result, future updates may not introduce bugs with root in audited code, and there's a possibility that this contract could be excluded from the scope of future audits. This finding is valuable as it not only saves funds for the client in terms of potential audits for upcoming updates but also eliminates a potential source of critical impact.
Thank you for your time and consideration.
Thank you for your comments!
As I agree with many of your points there is an even simpler logic behind upgrading this. I judged this contest with a strict baseline for Medium severity findings. However, I was "forced" to accept a view-only ERC-721 violation as valid Medium due to historical precedence on C4. As the present issue is similarly deviating from spec without severe impacts on the functionality of the protocol at its current state, it seems fair and consistent to move forward with Medium severity and therefore appropriately value the effort behind uncovering this very valid bug.
This previously downgraded issue has been upgraded by MarioPoneder
MarioPoneder marked the issue as satisfactory
MarioPoneder marked the issue as selected for report
@MarioPoneder I would like to add several comments to this discussion:
Thank you for your comment!
What you wrote aligns with what I've discussed with the sponsor, therefore it is appropriate to duplicate the mentioned group of findings.
Lines of code
https://github.com/code-423n4/2023-12-revolutionprotocol/blob/main/packages/revolution/src/MaxHeap.sol#L102 https://github.com/code-423n4/2023-12-revolutionprotocol/blob/main/packages/revolution/src/MaxHeap.sol#L156
Vulnerability details
Impact
MaxHeap.sol#extractMax
function only decreases thesize
variable without initializing theheap
state variable. On the other hand,MaxHeap.sol#maxHeapify
function involves theheap
variable for the out-of-bound index which will contain dirty non-zero value. As a result, uncleared dirty value ofheap
state variable will be used in the process and already extracted tokenId will be extracted again.Proof of Concept
MaxHeap.sol#extractMax
function is following.As can be seen, the above funcion decreases
size
state variable by one, but does not initialize theheap[size]
value to zero. In the meantime,MaxHeap.sol#maxHeapify
function is following.For example, if
size=2
andpos=0
,right = 2 = size
holds true. So theheap[right]=heap[size]
indicates the value of out-of-bound index which may be not initialized inextractMax
function ahead. But inL102
sincepos = 0 < (size / 2) = 1
holds true, the function does not return and continue to proceed the below section of function. Thus, abnormal phenomena occurs due to the value that should not be used.We can verify the above issue by adding and running the following test code to
test/max-heap/Updates.t.sol
.As a result of test code, the return value of the last
extractMax
call is not(itemId, value) = (5, 10)
but(itemId, value) = (3, 20)
which is error. According toREADM.md#L313
, the above result must not be forbidden.Tools Used
Manual Review
Recommended Mitigation Steps
Modify the
MaxHeap.sol#extractMax
function as follows.Since the value of
heap[size]
is initialized to zero, no errors will occur even though the value of out-of-bound index is used inmaxHeapify
function.Assessed type
Math