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.
Learning the vi and Vim Editors (7th Edition)
100 Ideas that Changed the Web
Penetration Testing with Raspberry Pi
How to Do Everything Samsung Galaxy Tab
Moodle 2.5 Multimedia (2nd Edition)
overflow and unsigned wrapping are described as appropriate. Assignment In simple assignment (=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand. These conversions occur implicitly and can often be a source of subtle errors. In the following program fragment, the int value returned by the function f() can be truncated when stored in the char and then converted back to int width
another value of that type. C was derived from two typeless languages and still shows many characteristics of a typeless or weakly typed language. For example, it is possible to use an explicit cast in C to convert from a pointer to one type to a pointer to a different type. If the resulting pointer is dereferenced, the results are undefined. Operations can legally act on signed and unsigned integers of differing lengths using implicit conversions and producing unrepresentable results. This lack
all resources that require mutual exclusion can be numbered as r1, r2, . . . rn. Deadlock is avoided as long as no process may capture resource rk unless it first has captured all resources rj, where j < k. Thread-Safe Functions In a multithreaded application, it is insufficient to ensure that there are no race conditions within the application’s own instructions. It is also possible that invoked functions could be responsible for race conditions. When a function is advertised to be
to arbitrary code by overwriting the address of the function pointer in the .dtors section. If the target binary is readable by an attacker, it is relatively easy to determine the exact position to overwrite by analyzing the ELF image. Example 3.9. Contents of the .dtors Section Click here to view code image 1 % objdump -s -j .dtors dtors 2 3 dtors: file format elf32-i386 4 5 Contents of section .dtors: 6 804959c ffffffff b8830408 00000000 Interestingly, the .dtors section is present
returns, the allocation function retries the allocation. One action the handler can do is make more memory available. For example, explicitly freeing data structures or running a garbage collector will free memory and allow the allocation function to succeed on the next iteration. Other actions available to the handler include throwing an exception, going to different handlers, or terminating the program. If none of these actions are taken, an infinite loop between the allocation function and
