Programming

Intro

Programming bugs turned into vulnerabilities since…it feels like forever. With the hacker paper Smashing The Stack For Fun And Profit - which was release somewhere in the 90s - game got more tricky.

As C and C++ are very close to hardware and can mess with memory by design the issue has never been solved properly. And those languages are still around (for good reasons).

The good news: This kind of bugs and similar ones can be avoided, detected, prevented and mitigated. There are tools for that. This chapter covers them.

Requirements for code analysis tools

There is a long list of tools supporting you during the development cycle. Some have specific requirements - and you will not be able to use them in your situation.

Some of my projects are embedded projects - the requirement “compiles on Linux” is quite hard when the release target is a micro controller without an OS.

An option here is to at least test the part of the code that are not hardware depended on Linux.

  • Flawfinder: static code analysis
    • Pro: No code modification required
    • Pro: No Linux compilation required
    • Pro: No execution on Linux required
    • Con: No detailed analysis
  • Assert: debugging tool
    • Pro: No Linux compilation required
    • Pro: No execution on Linux required
    • Pro: Force multiplier for other technologies
    • Con: Code modification required - debug build only
  • Fuzzing: Finding unexpected bugs
    • Pro: No code modification required
    • Con: Linux compilation strongly suggested
    • Con: Linux execution strongly suggested
  • Unit tests
    • Pro: Linux or Windows for execution
    • Pro: Compilation for Linux and Windows
    • Con: Code modification required (modular design of code plus writing of unit tests)
  • CppCheck: static code analysis
    • Pro: No code modification required
    • Pro: No execution required
    • Pro: More detailed analysis than flawfinder
    • Con: Special build target required
  • Clang, static: static code analysis using Clang
    • Pro: Does not require code modification
    • Pro: Does not require execution on Linux
    • Con: Requires special build
    • Pro: Very detailed static code analysis using compiler internal features
  • Valgrind: dynamic code analysis (memory as a speciality)
    • Pro: Does not require code modification
    • Pro: Does not require re-compilation
    • Con: Linux execution only
    • Con: Focus is on memory issues
    • Pro: Can run the release binary !
  • Clang, dynamic: dynamic code analysis using Clang
    • Pro: Does not require code modification
    • Con: Requires re-compilation
    • Con: Linux execution only
    • Pro: Very powerful dynamic code analysis

Some background

There is a large number of fuzzing and dynamic code analysis tools for Linux. Being able to compile at least core parts of the code and execute them on Linux will make your life much simpler.

The two things that require code modification only modify special debug code. This way you will not mess up your release build.

Unit tests can be run on Linux or Windows. They will even run on embedded systems. But there you will have to handle memory space issues (the binary will be huge) and redirect the report to UART. I would define that as a bonus goal after the unit tests run on Linux or Windows.

Up next

Intro