Slashdot Mirror
Secure Programming
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
It's a good idea to have resources that are committed to security. Although some will claim that languages such as Java or C# prevent security issues, this is simply not true - there are many avenues to building security weaknesses... and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
Of course, a web site and a few books won't prevent security issues - but the more it gets the word out about good programming practices, the better!
---
Herb Chambers - where my nightmare came true!
Are you somehow recommending a kernel be written in something else than C??? Sure, not all systems software is kernel mode C, but you have to realize that unless the underlying infrastructure is built (on some low level language), you can't have high level languages... in other words, the bottom line is Assembly. You have to build your way to it.
Now that said, the buffer overflow isn't the only security hole in the world, in fact more security holes come from very very high level, very abstract programming fallacies... such as for example the cookie exploit (it's a logical bug) that Hotmail had a while back.
All this being said, I feel like a dirty karma whore right now (feeling the slimey breath of modders down my neck), so I'll say it right out: I'M PRO MICROSOFT.
<runs for cover>
use a language that was specifically designed with security in mind
like say, Ada
oh yeah, let the negative moderation begin
because programmer can't stand being held by the hand
too big ego
They happen because A) most code is written in C or C++, and B) everyone makes mistakes (even the finest open source developers overlook simple buffer overflows).
That's not true. qmail and djbdns do not have security holes. They were written using secure coding techniques that make them immune to things like buffer overflows. You can't "overlook" a buffer overflow with stralloc.
That is the most ridiculous argument ever. It is tantamount to embracing only the most basic building blocks of anything and claiming that any automation or pre-made combination of those blocks as wrong.
I was partially joking. But really, more complex blocks are more likely to be flawed, and this seems especially true when it comes to computers. And the worse part is, you'll never be able to throw away the basic building blocks anyway. After all, what do you think compilers will always end up generating? Machine Code!
By hiding the details behind a curtain, I think it is more likely problems will just get ignored, because "oh, the language is so secure". I would like to avoid that.
So you, um, write software in machine code?
Higher level languages exist because it is tedious and error prone to need to code every last bit (pun intended) of instructon required by the CPU to do any work. The higher level the language, the more insulated you are from the machine code.
True, I like some insulation (it'd be difficult without it), but I like to avoid too much. In the very least, I think it's a good idea to know what's going on behind the magic curtain, and hiding what's going on to much could lead one to ignore what's going on completely.
C isn't always the best language, but it's the most versatile (at least I think so) without sacrificing too much. Hey, it's even somewhat portable (er...well...sometimes).
This is just silly - existing commercial lisps compile to machine code, same as c, or fortran, or ada, etc. Current lisp implementations run on stock hardware, on all the major platforms - Windows (XP,ME, NT, 9x, Dos), Linux (ix86, sparc, ppc), Mac OS X (and Classic), and various Unices.
OS kernels are not written in lisp because Unix was written in C, so everyone mistakenly believed that C was *the* language for OS kernel implementation. However, this is simply not so. Any language compiler that can generate machine code can be used to write an OS kernel.
I see this as a chicken-and-egg problem. Employers don't understand the importance of secure programming because it isn't taught in college. The only other way to learn is by experience, but that's the hard way.
There's really no excuse for teaching poor programming skills (or not teaching good programming skills) in a degree track that requires programming.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
I recommend Python.
Open source, expressive (very short code can achieve a lot), readable (very short expressive code is easily groked -- fewer bugs), no direct pointer manipulation (safe -- fewer bugs), integrates nicely with other languages, runs on a variety of platforms, very easy to learn.
Speaking as a current CS student at a "major" university in the Midwest, I can honestly say that there is a HUGE lack of good programming practices taught. From the beginning you are taught to write code that is potentially buggy at best. I believe that it stems from the fact that a majority of people who are entering CS programs had little interaction with coding before their studies begin. It takes nearly 3 semesters of studies before the student is capable of writing correct, basic C++ code. By that time in their 4 year program they should be preparing to start, if they choose, their Junior co-op. They are for the most part still un-baptisied in the ways of algorithims and data structures and more advanced topics such as networks and operating systems. Within the next 4-5 semesters there is little time for them to learn how to write secure code, because of all the other nessary skills they need to learn before graduation so they are even marketable. It has been my experience that writing secure code is pushed aside, in the pursuit of getting the students in-and-out with the basic skills they need to get a low-level job. In some ways this is a copout because the case could be made that a student shouldn't have to learn what a business doesn't use in order to be marketable. However it should be the coders job to catch the security breaches, because after all it is their code. If the coder doen't know to watch out for a buffer overflow or other potential security breaches, because they never learned about it in their standard studies, then it becomes a problem. But that's just my take on it...
++mse61--
1. Create your own malloc/free new/delete heap. This heap should always have blocks of 0's interspersed throughout and a 1K walled block of 0's at the end of the heap. Any programming errors may result in garbage, but it won't result in injected code vulnerabilities.
2. No direct DB access technology on your web service front ends. If your web UI code has SQL in it, you're doing something wrong. Your Web GUI should access an intermediate layer, instead. UI is notoriously easy to compromise, and the best way to make SQL injection attacks is to not have SQL directly beneath the button your users are playing with.
The basic idea is that everything is reference counted and subscript checked, but by doing some static analysis and type enforcement, most of the overhead for that is eliminated at compile time.
About 95% of subscript checks can be optimized out without too much effort. An optimizing compiler that can hoist expressions out of loops and strength-reduce them can move most subscript checks out of inner loops. Reference counts require more language support, but they, too, can be optimized.
As for pointer arithmetic, the solution is to use iterators, which are checkable, instead of pointers, which are not. Then optimize out the checks, as with subscript checks.
I proposed that there be a way to designate C++ code as "strict", turning on the enforcement. Privileged programs should be 100% strict; others need not be.
This is unlikely to happen, but it is technically possible.
When I read articles in which they explain hundreds of coding techniques to make code secure, I really don't want to get involved with such languages. I am not a very good coder and for this reason, my favorite languages are Lisp, Python and O'Caml, all three languages have garbage collectors which frees me from a lot of work that has nothing to do with the task at hand. I know that I can't (and don't want to) deal with memory problems, so I use modern languages which think the programmer's time is more important than the computer's. Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
Half-truths. Both C and C++ can support strings without buffer overflows through nice string libraries. It's just people don't use them as often as they should. Standard C library is a piece of crap as far as strings and type safety are concerned, not the whole language.