etcd

etcd copied to clipboard

Hi,

This post is about extending fuzzing of etcd and Sahdev Zala asked me to put an issue up here. CNCF has been sponsoring fuzzing of various CNCF projects (see here https://github.com/cncf/cncf-fuzzing) and it would be great if we could extend etcd too.

We have already started some of this work, and etcd integrated into OSS-fuzz in september (https://github.com/google/oss-fuzz/pull/5953) which allows all fuzzers to run continuously. Additionally, a directory for etcd has been created at cncf-fuzzing (https://github.com/cncf/cncf-fuzzing/tree/main/projects/etcd) and preferably this is just a placeholder as it would be best to get fuzzers upstream. All fuzzers are running continuously by OSS-fuzz.

While coverage is currently being improved, the following - mostly administrative - tasks need to be solved, sorted by importance:

1. Add more maintainers to the contact list of etcd in OSS-fuzz: https://github.com/google/oss-fuzz/blob/master/projects/etcd/project.yaml. This will allow maintainers to access bug reports of which some may reflect security issues.
2. Fix bugs that may be found by the fuzzers.
3. Discuss and create a list of code areas of etcd that may be well suited for fuzzing. In particular, we want to make sure that critical parts of etcd are covered by the fuzzers. Involving maintainers and their domain-specific knowledge will be highly beneficial to the final outcome, so if you identify as one, please share any thoughts you might have.
4. Get maintainer feedback on the fuzzers - we could do this in combination with moving the fuzzers from the CNCF fuzzing repo to the upstream repo.
5. Move fuzzers upstream. I would personally prefer this one to happen once the fuzzers are proven to run successfully continuously and a working setup is established.

CC @caniszczyk @spzala @AdamKorcz

The fuzzing integration work is completed, read more here - https://etcd.io/blog/2022/etcd-integrates-continuous-fuzzing/

Keeping the issue open to for the step 5 above.

I would suggest adding this to the robustness statement as well. Currently it reads as if it's not fuzzing. And adding the ossfuzz badge would be good too: https://google.github.io/oss-fuzz/getting-started/new-project-guide/#status-badge

I would not add the badge until fuzzing is properly integrated into the project. Pushing a blogpost is nice and dandy, but as of now most of the fuzzers fail as they were developed outside of the etcd project, thus are vulnerable to code changes. Fuzzing is reports are send privately to etcd maintainers, but due to project minimal activity no-one had time to look at them.

I have passed this feedback to CNCF and fuzzers authors but there have been no response.