search

near / near-one-project-tracking

A repository for tracking work items that NEAR One is working on.
0 stars 0 forks source link

[MetaProject] Expand our fuzzer coverage #9

Open Ekleog-NEAR opened 11 months ago

Ekleog-NEAR commented 11 months ago

Goals

Background

We currently use fuzzers for ensuring reliability and security of some of our functions. In order to improve security overall, we should expand our fuzzer coverage, and make sure we fuzz most (ideally, all) of the entry points an attacker could consider.

Why should NEAR One work on this

Considering the current size of our security team, fuzzing is currently the most time-efficient way of securing nearcore.

What needs to be accomplished

We need to:

  1. make sure our fuzzer infrastructure is production-ready, to support writing fuzzers more efficiently and easily
  2. change our culture, so that when we add a new entry point for an attacker, we also add fuzzers for it
  3. catch up on our backlog, writing fuzzers for entry points that are currently not fuzzed

Work on 1 has already started a few months ago, and I worked on it on-and-off depending on other issues that took priority.

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. The estimated time is 1-2 quarter-person.

Assumptions

None

Pre-requisites

None

Out of scope

None

Task list

### Tasks
- [x] make sure our fuzzer infrastructure is production-ready, to support writing fuzzers more efficiently and easily
- [ ] change our culture, so that when we add a new entry point for an attacker, we also add fuzzers for it
- [ ] catch up on our backlog, writing fuzzers for entry points that are currently not fuzzed
akhi3030 commented 11 months ago

  • make sure our fuzzer infrastructure is production-ready, to support writing fuzzers more efficiently and easily

  • change our culture, so that when we add a new entry point for an attacker, we also add fuzzers for it

  • catch up on our backlog, writing fuzzers for entry points that are currently not fuzzed

I agree that these three high level tasks would be needed. I suppose the second point is hard to estimate. Do you maybe have a separate estimate for 1 and 3? Maybe we should track these separately?

Ekleog-NEAR commented 11 months ago

So currently my hope is 1 is almost-done (to the exception of the hack introduced in #10276, that we should remove at some point). However, I fear that it’s going to be as it already went once, ie. making progress on 3 will reveal new issues in the current infrastructure.

That’s actually why I didn’t split it up into separate projects, because while I think that 3 is going to be the biggest part of the work, it will probably end up requiring more changes to 1.

akhi3030 commented 11 months ago

Makes sense. Do you already have a list of the work items for item 3 above?

Ekleog-NEAR commented 11 months ago

Well, part of doing item 3 will actually be finding the precise work items. However, I can already list as likely good places to fuzz:

Ekleog-NEAR commented 11 months ago

This project has not made progress since creating it, due to being focused on code and NEP reviews, as well as publishing external crates for internal users.

Ekleog-NEAR commented 10 months ago

Since the last message, I: