-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security] Fuzzing and various hardened/sanitized code checks #164
Comments
LLVM has a lot of sanitizers that could be interesting: https://clang.llvm.org/docs/index.html |
Looking into this one. |
I agree with @arnetheduck, LLVM's sanitizers are great as well! You may also want to look at libFuzzer, which is also part of the LLVM ecosystem.
Basically, what I recommend would be this:
|
oh, and another point: make sure your fuzzer generates test cases that you can reuse for future re-verification or regression testing. I very often have radamsa generate files on the file system, and I save the seed and any crashing test cases. In this way, the client can easily see which test case crashed, and re-run the proof of concept. |
Good info, thanks! Some basic work for unguided fuzzing (or lets say slightly guided) with afl has been done on the discovery code and also a bit on the json-rpc code. https://github.com/status-im/nim-eth/tree/master/tests/fuzzing Found quite some bugs already with this simple setup. I was still planning on improving and continuing that on other parts of the code. |
➤ Giovanni Petrantoni commented: LLVM sanitizers are indeed a 1 minute 1 line switch on (ASAN, UBSAN), they work on mac and linux only tho, those should be part of the testing I guess. GAs and fuzzers are nice too but need some setup. Also the good old Valgrind is invaluable. |
https://github.com/status-im/nim-beacon-chain/tree/master/nfuzz is used for differential fuzzing of the beacon chain spec - there's a fuzzer that compares the results of different client implementations - similar is being done via evmc: https://github.com/ethereum/evmone/tree/master/test/fuzzer |
nim-eth also has some fuzzing targets and some code to make setup easier: https://github.com/status-im/nim-eth/tree/master/tests/fuzzing |
Btw something extremely important that I realized only recently is that any GC or allocator should be absolutely disabled when doing this kind of checks ( can have a run with them on to check them too, but not so crucial ). As they completely hide potential huge memory issues, such as even simple issues of alignments. |
I've already mentionned it to @Araq but even beyond Nim GC, Nim internals should be gradually sanitized as they interfere/produce false positives:
|
I don't think false positives are false they always have a meaning in my experience. Anyway, hmm, I was hoping nim did not get on the way anymore but I guess it's still the case. I was having issues even by just disabling the default allocator |
Ironically, some of nim's features hide issues that otherwise would be detected by valgrind / sanitizers: for example, because nim zero-inits everything, valgrind won't catch use of uninitialized fields because it cannot tell the difference between the developer intending to leave default in there and forgetting to set the field explicitly. |
is that because asan requires registers for itself? |
Very curious yes, I have no idea. Edit: likely just some inline asm issue? |
Given the potential fallout of security issues in Nimbus, I'd like to keep track of solutions to make sure we're comfortable with shipping this:
The text was updated successfully, but these errors were encountered: