Open Ekleog-NEAR opened 5 months ago
@Ekleog-NEAR: is this a duplicate of #22?
It is! I had forgotten about #22, that was in the "ready to be prioritized" column. Going to close #22 in favor of this one, as I wrote more context down in this one :)
Current status: I have an idea of how / where to fuzz, and now need to start actually implementing the fuzzer(s). The project is currently on track.
No progress here since the last update, I spent the two weeks working on catching up on our Hackenproof backlog and fixing the failures that our current fuzzers already found. Fortunately they did not come up with anything security-related yet.
The estimated remaining work is consistent with the initial timeline and the ~1-2 weeks of work already done on this project:
With one week off, I was able to do one week’s worth of work on this project. Part of it has been side-tracked by multiple infrastructure issues, which are now their own project:
This being said, that kind of roadbumps were planned for in the initial estimate, and we’re still on track.
The actual progress made this week is a handshake fuzzer, that due to #56 is not running on the fuzzing infrastructure yet but did run on my development VM long enough for me to say things look reasonably good here.
We are ~2-3 human-weeks into the project, initially planned at 2-3 months. The remaining 1-2 months still seems like a reasonable estimate.
There has been no progress on this project since the last update, due to the ongoing performance work on congestion handling.
Considering this is planned to continue, I’ll put this back into the "prioritized" column for now, until I can resume my activities related to security.
Goals
Background
This is a sub-project of:
Why should NEAR One work on this
We have had a few bug bounty reports around the p2p network layer recently. This costs us quite a lot in bounty amounts, and we should spend time proactively rather than after the fact.
In addition, the Hacken audit did not notice the issues there, which means that they are not obvious to find.
What needs to be accomplished
Most of the infrastructure work has already been completed as part of https://github.com/near/near-one-project-tracking/issues/9. We need to properly fuzz our p2p layer.
Main use case
Security is the main use case. However, reliability will also benefit, as fuzzers can also pinpoint issues that are not security-related.
Links to external documentations and discussions
None
Estimated effort
The security team, and in particular @Ekleog-NEAR, is expected to work on this project. @saketh-are is expected to give support in going around the codebase. The estimated time is 2-3 months-person for understanding the code enough to fuzz it properly, without a full-fledged "this is OK" audit.
Assumptions
None
Pre-requisites
None
Out of scope
A complete "this is OK" audit is currently out of scope, considering that Hacken’s audit did not find the issues. A future project could encompass a full audit, but it would probably take significantly more time, and thus was kept out of scope for this specific project.