Secure Coding in C and C (SEI Series in Software Engineering)
By admin • Aug 5th, 2009 • Category: Uncategorized
Secure Coding in C and C (SEI Series in Software Engineering)
by: Robert C. Seacord
Secure Coding in C and C (SEI Series in Software Engineering)
By Robert C. Seacord
Publisher: Addison-Wesley Professional
Number Of Pages: 368
Publication Date: 2005-09-19
ISBN-10 / ASIN: 0321335724
ISBN-13 / EAN: 9780321335722
Product Description:
"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.
Summary: The best how-to security book
Rating: 5
This is an important book for people that write computer programs and their managers.
It is also very well organized and well written. Seacord reveals how the bad guys take
advantage of bugs in programs to break into a system or damage it. It is the most
complete list of exploitable bug types that I am aware of.
Many examples are given, naming software that have been exploited by bad guys. Some
may protest that this provides the bad guys with a list of easy targets. All of the
vulnerable software has been updated to fix the bug, and the improved version has been
available for a long time.
Everyone that writes software intended to be used by someone else should read this book.
Every organization that writes software should have a copy.
Most of the security flaws are buffer overflows. Secord shows how, from the simple use of
gets() through mistakes triggered by subtle differences in the rules for signed and unsigned
integers of various sizes. There are other ways, and some are quite subtle, but still
preventable. The bad guys are not Jay Leno’s "Dumb crooks."
The primary way to frustrate the bad guys is to not have any of the bugs they exploit.
Seacord admits zero bugs is an elusive goal and recommends defense in depth by the use of
various freeware or commercial packages intended to trap or prevent certain errors.
He lists and describes many, with their strengths and weaknesses.
Read this book and make your code better. Read it again, next year.
The following are my opinions, based on over 40 years writing software, but I doubt
Seacord would disagree. Every security bug is also a bug that can cause a crash or a
wrong output from a program. The major cause of fewer bugs is the attitude of the
programmer. Managers can affect the attitude of the programmers by their choice of
questions. Do not ask "Is it done yet?" Instead try approaches like: "Tell me about how
you validated the inputs and how you identified all the inputs." "Who reviewed your test
cases?" "How did you decide you had tested enough?" The fewer bugs of any kind in your
product, the less likely the bad guys are going to target it, other things being equal.
Summary: Excellent resource!
Rating: 5
This book slipped under my radar, but I recently picked it up and was quite impressed.
This book is fairly unique in that it is accessible and well-written, yet, at the same time, unabashedly technical. It’s quite simply a very good book, and it should prove valuable to readers new to software security, as well as experienced security consultants and vulnerability researchers.
I know the problem domain intimately, and was quite impressed at the level of thoroughness and the technical depth of the coverage. This book isn’t merely a well-written exploration of known insecure programming idioms and attack techniques; there’s actually a considerable amount of original research and material that you won’t find elsewhere. Specifically, the coverage of integer issues goes above and beyond what has been previously written, and it’s incredibly topical given the current trends in vulnerability research. Seacord’s mastery of the C language and his ability to distill the practical rules of thumb out of the somewhat fragmented C standards really results in an excellent resource.
Summary: Great Book!
Rating: 5
I had the honor of taking a short course at a software security summit from Robert Seacord. I would have to say it was one of the most informative security related courses that I have taken. This book encompasses the course that I took and does a great job of explaining what to watch out for when writing code.
I highly recommend this book for any serious developer.
Summary: A book for programmers
Rating: 5
There seem to be three categories of computer security books. The first category is books written for system administrators or computer owners, and explains how to protect the computers under their control. The second category is the "true crime" genre that recounts the exploits of black hat hackers or explains the hacker culture (sometimes as "how-to" books for non-programmers). The third, and rarest, category is books for professional programmers that explain the coding idioms that make programs more secure or more insecure.
This book is an excellent contribution to the third category. It explains how certain ways of programming in C and C make programs vulnerable to security attacks. There are many code examples throughout the book illustrating the issues.
Although everything is explained in great detail, the treatment is not superficial. (No background in computer security is required, but the reader should be at least a journeyman C or C programmer.) Some of the security holes will surprise readers familiar with the basics of computer security. My favorite example: Many programmers know that the gets() function once was involved with compromising 10% of the computers on the Internet in a single day, but did you know that printf can also be a security flaw in some cases? The statement:
printf(s);
can allow an attacker to run any code of his choosing if s is a string provided by the attacker. Even more surprising is the printf attack has been used successfully on popular programs.
This book should be read by any programmer who does I/O across a network, or who writes applications that provide a captive environment for their users (data entry stations, information kiosks), or who writes programs to manipulate sensitive data. Even programmers merely curious about security issues will find this book a readable treatment. I guess the Black Hats can read the book to get more ideas for future attacks.
I can personally vouch for Seacord’s expertise. He is a security analyst as the Computer Emergency Response Team/Coordination Center, and I’ve worked with him on the ANSI/ISO C Programming Language Standards Committee. I’ve found his information on computer security both educational and valuable.
[...]
Summary: disturbing issues
Rating: 5
Seacord gives an unsettling walkthrough of vulnerabilities present in much of C and C coding. Buffer overflows take up a significant portion of the discussion. Which leads into considering how these can be introduced into unwary code. Consider C. The common string functions of strcpy, strcat, gets, streadd() and others are shown to be very exposed to error or attack. C also has similar drawbacks.
The text explains that much of these trace back to some bad usages. Strings are defined to be null terminated. And bounds checking is often not done. While this is often true of code that the programmer writes, it is also true of various common C library functions, like those mentioned above. In fact, Seacord goes so far as to emphatically assert that gets() should never be used in your code. Instead, he suggests fgets() or gets_s().
Seacord also covers other topics, like dynamic memory management, which might have vulnerable heaps. Various 3rd party analysis tools are suggested, to find these errors.
Overall, the book can be quite disturbing, if you are maintaining a large body of C or C code. Might make you want to delve in and replace those gets(), at the very least.
While the text doesn’t mention this, it turns out that recent languages like Java and C# have far more robust string handling abilities. They were written after the above flaws in C and C become apparent.
Please Login or Register to read the rest of this content.
Related Posts
Leave a Reply
You must be logged in to post a comment.
