https://appsec.guide/docs/languages/c-cpp/Recent content in C/C++ Security Checklist on Testing HandbookHugoen-ushttps://appsec.guide/docs/languages/c-cpp/lang-c-cpp-bug-classes/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-bug-classes/C/C++ bug classes # Below is a list of common vulnerability types for C/C++ programs. This list does not include comprehensive details; rather, it is intended to be broad and high level. Use it as a starting point during security reviews of C/C++ programs. Buffer overflow and underflow, spatial safety Off-by-one mistakes Invalid computation of object sizes Misunderstanding of data-moving functions’ semantics Data comparison using out-of-bounds lengths Copying of raw memory instead of the object Out-of-bounds iterators Use after free, temporal safety Use after free Example: Two shared_ptrs point to the same object, and one of them decrements its reference count (refcount) to 0 and frees the object.https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-linux-usermode/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-linux-usermode/Linux usermode # This list covers common checks for and footguns of C/C++ standard libraries when used in Unix environments. Run checksec to learn about the executable’s exploit mitigations. Check for uses of NX, PIE, stack cookies, RELRO, FORTIFY_SOURCE, stack clash protector, SafeStack, ShadowCallStack, and other mitigations. Check that production releases do not contain debug information. Check for uses of non-thread-safe functions in multi-threaded programs. Some of these functions—such as gethostbyname, inet_ntoa, strtok, and localtime—may return pointers to static data.https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-linux-kernelmode/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-linux-kernelmode/Linux kernel # This list includes basic checks for Linux kernel drivers and modules. Check that all uses of data coming from the userspace are validated. Look for the __user tag in the code. Not necessarily all userspace data is marked with the tag, but it is a good start. Uses of copy_from_user(to, from, size) should be validated: The length should be validated correctly. There should be no uninitialized to addresses.https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-windows-usermode/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-windows-usermode/Windows usermode # This list covers common checks for and footguns of C/C++ standard libraries when used in Windows environments. Run binskim to check mitigation opt-in and other issues in the application binaries. DEP (NX), ASLR (and HiASLR on x86_64), Control Flow Guard (CFG), and SafeSEH (on x86_32 only) should always be enabled, and executables should be signed. Shadow stack (CET) and Spectre mitigations may be enabled for additional security.https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-windows-kernelmode/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-windows-kernelmode/Windows kernel # This list includes basic checks for Windows kernel drivers and modules. Run CodeQL on the application’s driver. Microsoft has published CodeQL support and security query packs for Windows drivers. If you can build the driver from source, CodeQL is a high-value SAST approach. If you cannot build the driver from source, you may still be able to run CodeQL with --build-mode=none on the CodeQL CLI during database creation, but coverage and accuracy will be significantly diminished.https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-seccomp/Mon, 01 Jan 0001 00:00:00 +0000https://appsec.guide/docs/languages/c-cpp/lang-c-cpp-seccomp/Seccomp # Sandboxing is hard. But if it is needed and seccomp is used, ensure the following is done: The BPF filter checks the architecture (e.g., x86-64 versus i386). The BPF filter checks the ABI/calling convention (e.g., x86-64 versus x32 ABIs for x86-64 architecture). This means checking for syscalls with numbers greater than 0x40000000 (the __X32_SYSCALL_BIT flag). Syscalls implemented in vsyscall and VDSO are handled correctly. This is important only for optimized syscalls like gettimeofday, time, getcpu, and clock_gettime.