In Defense of C/C++ (Part 3)
In this third part of the series on secure programming in C and C++ I will be looking into some of the tooling available to help us create secure code in C and C++. The first article looked at the reasons why there has been a push away from C/C++, the second one investigated how we can use the features of C/C++ to create secure code.
With the tooling focus in this third part, we are leaving the code languages, in favor of 3rdparty tools, that can help us make sure that our code is indeed secure. I will focus on three specific tools:
- Static Analysis
- Dynamic Analysis
- Fuzzing
First up, static analysis.
Static analysis is an automated method of examining source code without executing it, aimed at detecting potential errors, vulnerabilities, coding-standard violations, and quality issues early in the development lifecycle. Static analysis typically integrates into Continuous Integration/Continuous Deployment (CI/CD) pipelines, ensuring ongoing quality checks during software development.
Key Benefits:
- Early Detection: Identifies problems before runtime.
- Security: Finds vulnerabilities (e.g., buffer overflows, SQL injection).
- Code Quality: Improves readability, maintainability, and consistency.
- Compliance: Helps ensure adherence to coding standards and guidelines
Common Issues Detected:
- Syntax and semantic errors
- Potential security vulnerabilities
- Resource leaks (memory, files, sockets)
- Unreachable or dead code
- Incorrect or risky API usage
- Violations of coding standards (MISRA, CERT, etc.) Common Issues Detected:
- Syntax and semantic errors
- Potential security vulnerabilities
- Resource leaks (memory, files, sockets)
- Unreachable or dead code
- Incorrect or risky API usage
- Violations of coding standards (MISRA, CERT, etc.)
Popular Open-Source Tools:
- Cppcheck – C/C++ error and security checker.
- Clang Static Analyzer – Powerful C/C++ analyzer integrated with LLVM.
- VisualCodeGrepper
- FlawFinder
There are many more options in the open-source space, but the above selection works with C/C++ code. When looking into the commercial space, there are even more options. If you are a GitHub user, then the advanced security options in GitHub come with CodeQL, that can be run as part of your GitHub workflows, although at an additional cost.
Dynamic analysis is a testing technique involving the examination of software behavior during execution. Unlike static analysis, which inspects code without running it, dynamic analysis identifies runtime issues by observing a program in action, often using special instrumentation.
Key Benefits:
- Runtime Issue Detection: Finds bugs only evident during execution (e.g., memory leaks, race conditions).
- Security Insights: Identifies exploitable vulnerabilities at runtime.
- Performance Profiling: Measures memory usage, performance bottlenecks, and resource utilization
Common Issues Detected:
- Memory leaks and buffer overruns
- Use-after-free or uninitialized variables
- Thread safety and concurrency issues
- Performance bottlenecks and hotspots
- Incorrect exception handling
- Resource leaks (file descriptors, database connections)
Popular Tools:
- Valgrind: Instrumentation framework for detecting memory leaks and threading issues.
- AddressSanitizer (ASan): Detects memory corruption and leaks.
- ThreadSanitizer (TSan): Identifies threading and concurrency problems.
- Intel VTune / perf: Performance profiling and resource usage monitoring.
Even though VTune is an Intel tool, it is free of charge, and it can be used across Windows, Linux and MacOS.
Fuzzing (or fuzz testing) is an automated software testing technique that feeds randomized or semi-randomized inputs to software, looking for bugs, vulnerabilities, crashes, and unexpected behaviors. It’s especially effective in languages like C and C++, which are prone to memory-related vulnerabilities such as:
- Buffer overflows
- Use-after-free errors
- Memory leaks
- Integer overflows
- Undefined behavior
- Out-of-bounds access
- Logic errors
Key Advantages of Fuzzing:
- Automated discovery of vulnerabilities:
- Quickly finds edge cases and bugs that developers and testers might overlook.
- High coverage:
- Can explore complex input spaces more thoroughly than manual tests.
- Realistic scenarios:
- Reveals practical attack vectors that attackers may exploit.
- Integration with CI/CD:
- Integrates smoothly into automated build pipelines for continuous security testing.
Examples of Popular Fuzzing Tools for C/C++:
- AFL (American Fuzzy Lop): Coverage-guided fuzzer, highly effective and widely used.
- libFuzzer: Built-in LLVM-based fuzzing engine with deep integration into the build environment.
- Honggfuzz: Fast, scalable, and versatile fuzzer with thread support.
- OSS-Fuzz: Google’s continuous fuzzing service, regularly used for open-source projects.
Limitations:
- Doesn’t prove absence of bugs:
- Fuzzing increases your confidence but doesn’t guarantee your software is bug-free.
- Quality depends on input corpus:
- Effective fuzzing requires meaningful seed inputs and continuous refinement.
You can find a free selection of feeds from GitHub for fuzzing here: FuturesLab/fuzzing-seeds: A centralized collection of seed inputs for fuzzing expeditions
All these tools can be, and should be, integrated into the CI/CD pipelines, to automate the security testing of the code. Some of the commercial tools have add-Ins to the various IDE’s out there, that can provide feedback on the code, as it is being written.
My own opinion on continuing the use of both C and C++ is hopefully clear from this series. Personally, I have high hopes for the future of these languages, especially with the call from the creator of C++ Bjarbe Stoustrup to the ISO committee responsible for the languages to prioritize the security features in the coming standards for the languages.
With that, and the continuing strengthening of the external tooling, secure coding in C and C++ is possible, and will become easier in the coming years!
Check out the rest of the series!
Part 1: https://cybersecurity-magazine.com/in-defense-of-c-c-part-1/
Part 2: https://cybersecurity-magazine.com/in-defense-of-c-c-part-2/
Source link