Skip to content
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

Open
mratsim opened this issue Oct 2, 2018 · 5 comments

Comments

@mratsim
Copy link
Member

commented Oct 2, 2018

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:

@arnetheduck

This comment has been minimized.

Copy link
Member

commented Oct 2, 2018

LLVM has a lot of sanitizers that could be interesting: https://clang.llvm.org/docs/index.html

@coffeepots coffeepots referenced this issue Nov 19, 2018
34 of 166 tasks complete
@corpetty

This comment has been minimized.

Copy link

commented Jul 25, 2019

Looking into this one.

@lojikil

This comment has been minimized.

Copy link

commented Jul 25, 2019

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.

  • AFL can be hard to instrument code, but if you can get that working it would be great. I checked out the Nim docs on AFL, and it looks rather straight forward.
  • TIS & Frama-C require a bit of work, but if you can get them running you'll probably have deep insights.
  • Not fuzzing related, but if you're compiling Nim to C, you can use NASA's Ikos, which, like TIS, is an abstract interpreter.
  • I've had great results with very "dumb" (or unguided) fuzzers, like radamsa. I can coördinate with @corpetty on my Radamsa fuzzing rig for both network & local code if you'd like.
  • I'd also recommend Property checkers like QuickCheck for Nim via QuickTest.

Basically, what I recommend would be this:

  • simple static checks (like rats, splint and so on) to catch painfully obvious bugs
  • an unguided fuzzer to find obvious bugs quickly
  • some sort of guided fuzzer to find more subtle bugs that require more involved work
  • verification via symbolic execution or abstract interpretation for very deep bugs or edge cases
@lojikil

This comment has been minimized.

Copy link

commented Jul 25, 2019

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.

@kdeme

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.