Secure Coding in C and C++
Robert C. Seacord
Language: English
Pages: 368
ISBN: 0321335724
Format: PDF / Kindle (mobi) / ePub
"The security of information systems has not improved at a rate consistent with the growth and sophistication of the attacks being made against them. To address this problem, we must improve the underlying strategies and techniques used to create our systems. Specifically, we must build security in from the start, rather than append it as an afterthought. That's the point of Secure Coding in C and C++. In careful detail, this book shows software developers how to build high-quality systems that are less vulnerable to costly and even catastrophic attack. It's a book that every developer should read before the start of any serious project."
--Frank Abagnale, author, lecturer, and leading consultant on fraud prevention and secure documents
Learn the Root Causes of Software Vulnerabilities and How to Avoid Them
Commonly exploited software vulnerabilities are usually caused by avoidable software defects. Having analyzed nearly 18,000 vulnerability reports over the past ten years, the CERT/Coordination Center (CERT/CC) has determined that a relatively small number of root causes account for most of them. This book identifies and explains these causes and shows the steps that can be taken to prevent exploitation. Moreover, this book encourages programmers to adopt security best practices and develop a security mindset that can help protect software from tomorrow's attacks, not just today's.
Drawing on the CERT/CC's reports and conclusions, Robert Seacord systematically identifies the program errors most likely to lead to security breaches, shows how they can be exploited, reviews the potential consequences, and presents secure alternatives.
Coverage includes technical detail on how to
- Improve the overall security of any C/C++ application
- Thwart buffer overflows and stack-smashing attacks that exploit insecure string manipulation logic
- Avoid vulnerabilities and security flaws resulting from the incorrect use of dynamic memory management functions
- Eliminate integer-related problems: integer overflows, sign errors, and truncation errors
- Correctly use formatted output functions without introducing format-string vulnerabilities
- Avoid I/O vulnerabilities, including race conditions
Secure Coding in C and C++ presents hundreds of examples of secure code, insecure code, and exploits, implemented for Windows and Linux. If you're responsible for creating secure C or C++ software--or for keeping it safe--no other book offers you this much detailed, expert assistance.
file system /proc. Mac OS X provides out-of-the-box support for several different file systems, including Mac OS Hierarchical File System Extended Format (HFS+), the BSD standard file system format (UFS), the Network File System (NFS), ISO 9660 (used for CD-ROM), MS-DOS, SMB (Server Message Block [Windows file sharing standard]), AFP (AppleTalk Filing Protocol [Mac OS file sharing]), and UDF (Universal Disk Format). Many of these file systems, such as NFS, AFS (Andrew File System), and the Open
supplemented by static analysis tools that scan source code for security flaws. Developer Guidelines and Checklists Checklist-based design and code inspections can be performed to ensure that designs and implementations are free from known problems. Checklists, for example, are a part of the TSP-Secure process. Although checklists can be useful tools, they can also be misused—most commonly by providing someone with a checklist when that person does not understand the true nature of the items
in-range operations, 301–303 pointer subterfuge, 139–142 race conditions, 461 strings, 72–83 C11 Annex K bounds-checking interfaces, 73–76, 282, 340–341 C++ std::basic_string, 80–81 detection and recovery, 101–102 dynamic allocation functions, 76–80 input validation, 102 invalidating string object references, 81–83 object size checking, 102–106 runtime protection, 101–117 mkstemp function, secure and insecure use of, 461t mkstemp() function, 431–432 mktemp function, secure and
silly code like this: #define S "foo" size_t n = strnlen_s(S, sizeof S); The strnlen_s() function is useful when dealing with strings that might lack their terminating null character. That the function returns the number of elements in the array when no terminating null character is found causes many calculations to be more straightforward. Because the bounds-checking functions defined in C11 Annex K do not produce unterminated strings, in most cases it is unnecessary to replace calls to the
utility. The existing solution is extremely fragile because any changes may result in the sensitive information being reallocated elsewhere in the program and leaked again, resulting in a déjà vul (a vulnerability that has “already been seen”). In cases like the Sun tarball vulnerability, where sensitive information is used, it is important to clear or overwrite the sensitive information before calling free(), as recommended by MEM03-C of The CERT C Secure Coding Standard [Seacord 2008]: “Clear