Of course I had nothing to do with the Free Software Foundation attack, which Joab Jackson of IDG News goes into more details in his article Free Software Foundation's Software Repository Hacked. However the subject line gives me the opportunity to talk about Full Disclosure and the collectively pathetic job we are all doing in learning from past mistakes when it comes to Secure Coding.
The Federal Trade Commission (FTC) has in place their Endorsement Guides that require all blogger's to fully disclose any compensation a blogger receives from an other party. The FTC Business Center Blog tells us how these new rules came about, and why I'm bring them up now.
If you want more information, read The FTC’s Revised Endorsement Guides: What People are Asking or watch this video.My current earnings from this blog are, as of moments ago, $9.73 via Google Ad Sense, and earnings from the Amazon Book Associate program so far has been nothing (No one wants to read books anymore?). You can see that I'm not going to be giving up my day job anytime soon to become a full time blogger, unless someone does come up with some great largesse to do so, which I'd disclose here.
The products I've mentioned here are ones I've used in some manner, or have hopes of using in the future, and no one has paid me to mention them.
The one priceless item for my blog here is Michael Barr's gracious linking to us from his Embedded Gurus site, which I link back to over on that menu to your right (if you using a web browser and not the RSS feed), hope you have checked out those resources.
Now with the legal like stuff out of the way lets move on to something usable in our products.
According to the FSF, attackers breached the FSF server Nov. 24 by using SQL injection attacks against the Savane bug tracking application.
On Black Friday (For our international readers: Black Friday is the day after the US Thanksgiving Holiday, when merchants hope people buy enough stuff to put them into black ink, verses red ink meaning loss, to have a profitable year), I coincidentally picked up the book SQL Antipatterns: Avoiding the Pitfalls of Database Programming by Bill Karwin, from The Pragmatic Bookshelf. Yearly on Black Friday they have a very generous discount for the frugal among us.
"Bill Karwin has helped thousands of people write better SQL and build stronger relational databases. Now he's sharing his collection of antipatterns—the most common errors he's identified in those thousands of requests for help.
Most developers aren't SQL experts, and most of the SQL that gets used is inefficient, hard to maintain, and sometimes just plain wrong. This book shows you all the common mistakes, and then leads you through the best fixes. What’s more, it shows you what’s behind these fixes, so you’ll learn a lot about relational databases along the way."
Chapter 21 is devoted exclusively to how SQL Injection work, and what is needed to do to stop them from happening. In a nutshell someone enters an SQL fragment into a web form on a site, and that site accepts the data without proper sanitizing of the inputs. This problem has existed for years, yet we still allow it to happen. Why? The other, related, and most common attack is some type of buffer overflow exploit. Again a problem that has been around for decades, and we still have not learned that it needs prevented in our code. Bill goes into great detail of the proper way to prevent a SQL injection.
The XKCD Carton on how Mom legally named her son "Robert`); Drop Table" to crash any database that tried to collect his identity.
Even if you have no reason to be interested in SQL Bill's book is still worth checking out because of some of the other chapters, such as the one on readable passwords and social engineering to get them, and what needs done to prevent such attacks. Like 'salting' a password. That is append random data to what they user enters so that dictionary attacks will not work. The random string is saved in the users account, the user has no knowledge of such a string.
As the issue of buffer overflows have been around a long time, there are already organizations like CERT (CERT is not an acronym; it is a name and a registered trade mark of Carnegie Mellon University) that have developed best practices Secure Coding Standards, for C, C++ and Java.
"Easily avoided software defects are a primary cause of commonly exploited software vulnerabilities. CERT staff has observed, through an analysis of thousands of vulnerability reports, that most vulnerabilities stem from a relatively small number of common programming errors. By identifying insecure coding practices and developing secure alternatives, software developers can take practical steps to reduce or eliminate vulnerabilities before deployment.
As part of the CERT Secure Coding Initiative, members of the Secure Coding team work with software developers and software development organizations to reduce vulnerabilities resulting from coding errors before they are deployed. We strive to identify common programming errors that lead to software vulnerabilities, establish standard secure coding standards, educate software developers, and to advance the state of the practice in secure coding."
CERT is currently researching survivable systems engineering that includes analyzing how susceptible systems are to sophisticated attacks and finding ways to improve the design of systems.
We can find a good introduction to the problem of buffer overflows and injection attacks in Robert C. Seacord's 2006 paper Safer Strings in C: Using the Managed String Library.
CERT has a few libraries that you can use to make your code more secure, such as the Managed String Library:
The managed string library was developed in response to the need for a string library that can improve the quality and security of newly developed C-language programs while eliminating obstacles to widespread adoption and possible standardization. As the name implies, the managed string library is based on a dynamic approach; memory is allocated and reallocated as required. This approach eliminates the possibility of unbounded copies, null-termination errors, and truncation by ensuring that there is always adequate space available for the resulting string (including the terminating null character). The one exception is if memory is exhausted; that is treated as an error condition. In this way, the managed string library accomplishes the goal of indicating either success or failure. The managed string library also protects against improper data sanitization by (optionally) ensuring that all characters in a string belong to a predefined set of "safe" characters.
Many software vulnerabilities in C programs arise through the use of the standard C string manipulating functions. String manipulation programming errors include buffer overflow through string copying, truncation errors, termination errors and improper data sanitization.
Buffer overflow can easily occur during string copying if the fixed-length destination of the copy is not large enough to accommodate the source of the string. This is a particular problem when the source is user input, which is potentially unbounded. The usual programming practice is to allocate a character array that is generally large enough. However, this fixed-length array can still be exploited by a malicious user who supplies a carefully crafted string that overflows the array in such a way that the security of the system is compromised. This remains the most common exploit in fielded C code today.
In attempting to overcome the buffer overflow problem, some programmers limit the number of characters that are copied. This can result in strings being improperly truncated, which in turn results in a loss of data that may lead to a different type of software vulnerability.
A special case of truncation error is a termination error. Many of the standard C string functions rely on strings being null terminated. However, the length of a string does not include the null character. If just the non-null characters of a string are copied, the resulting string may not be properly terminated. A subsequent access may run off the end of the string, corrupting data that should not have been touched.
Finally, inadequate data sanitization can also lead to software vulnerabilities. In order to properly function, many applications require that data not contain certain characters. Ensuring that the strings used by the application do not include illegal characters can often prevent malicious users from exploiting an application.
Take a look at 07. Characters and Strings (STR) for some specific examples.
Alas the String Library uses errno and depends on malloc()and realloc(), which are not MISRA compliant. So it becomes a design decision on how to best proceed with any given project.
Vulnerabilities are not limited to Strings. Integer overflows are a security issue as well. To that end CERT also provides the secure integer library IntegerLib, which was developed by the CERT/CC and is freely available.
While the CERT information is invaluable the presentation of it is hideous. Popup links that are impossible to click on, most pages start with the top half of the page with a completely useless blue box that you must scroll over to see the Interesting Stuff, then once on the blue pages have to click the top bold link to really get to what you want to see.
Posts
No comments:
Post a Comment