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!
Buffer overflows should not happen in the first place. In most languages, they are impossible. 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).
Microsoft is moving to languages with managed types. If they had been using managed types all along, the overwhelming majority of Microsoft security holes would have never happened. In a few years, Microsoft software will be more secure than anything Open Source has to offer.
Open Source developers, on the other hand, arrogantly believe that they are immune to mistakes. They somehow overlook the countless exploits discovered in their own code (more than 500 in Debian over the past 4 years).
It is time for open source to wake up and start using better tools and better practices.
With not quite a million slashdot anonymous cowards, that Bureau of Labor Statistic makes for more than all the software developers, I&T guys, database report wizards and embedded software engineers by twice here in U.S of A (not to mention outside world).
Yes, you may be a lowly I&T worker; but you probably should not be worthy of posting ludicrous assumptions at Slashdot.
And Ah, 95% of slashdot readers are Microsoft involved? Mmmmm. I put money down that this is closer to 85% or less that the readers are deeply involved in Microsoft-specific stuff than they would be deeper in Unix.
Try working 60-80 hours a week as a Sr. Embedded Software Engineer for 22 years at top-notched startup companies, so that experience becomes you.
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
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.
People still use JOVIAL, which as far as I can gather is a version of Algol that has been modified to include threads. In fact, there is an official Air Force website at Jovial Lives!. To quote from the website:
"Some of the more notable weapon systems using JOVIAL include (but are not limited too) the Advanced Cruise Missile, B-52, B-1, and B-2 Bombers, C-130, C-141, and C-17 Transport Aircraft, F-15, F-16, F-18, and F-117 Fighter Aircraft, LANTIRN, U-2 Aircraft, E-3 AWACS Aircraft, Special Operations Forces, Navy AEGIS Cruisers, Army Multiple Launch Rocket System, Army Blackhawk Helicopters, F100, F117, F119 Jet Engines, and RL-10 Rocket Engines."
That's a pretty impressive list of platforms for a language that was developed in the early 1960's!
So, maybe newer is NOT better after all.
A.R. Nemmer
So because the JVM is written in C then that makes your java code more vulnerable to exploits, because you are trusting the implementors of the JVM to have got it correct? By that logic you shouldn't be using a computer because you are trusting the manufacturer that implemented the computer hardware properly which runs an OS which runs the JVM which runs your java code (simply). Eventually your code no matter what it does has to trust someone elses implementation of something at some point in time of its execution.
Agreed. Most of the companies I've been at of course hire college grads I mean who wouldn't, but most of the time it's those of us without degrees who've actually DTFW (done the fscking work) who end up making the big bucks even if it's only temporarily. This is not to say that a college grad isn't skilled hell most would probably clean the floor with my ass (well most compsec students with BA's and better). It's a matter of adapting to where you're at, while one may lack on say programming, they may make up for in networking. Not everyone can know it all (except of course moi... kidding you know...) But for the most part I would blame companies for jumping on the paper bandwagon. Just because someone has a degree doesn't mean that person is going to understand the actual business infrastructure of a company. They may understand the underlying protocols but that shit doesn't impress me when you have to run to a colo @ 3:00am and get shit started yesterday. Nope sorry bookworms your school lessons will not save you.
The fact is, most companies couldn't give half a shit about security on a day-to-day basis, and therefore don't really care if people fresh out of college have a clue about secure programming, or even security in general.
True to an extent. More and more companies are taking compsec more serious, and it helps when the gov, and news agencies go overboard with their 'hacker' stories. Take a look around Dice dot com, or the Security Focus job list, you will see the biggest surge in years.
MoFscker
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.
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.
First of all, if all we had to worry about was DOS attacks, we'd be in a wonderful era compared to today.
Second, I think you've only got half the story. The prevaling attitude is "accept variable input, push the consequences back on the user". That is, programmers were very willing to accept the power of dynamic inputs, but also very willing to share the responsibility.
Unix Culture in particular had the attitude of "Real Men provide Good Input, or Dump Core". In short, it was all the user's problem, and that was reflected almost everywhere.
With micros, it was "Hey, you're the only user. Just reboot!" Same story.
Neither culture mixes very well with a vast, untrusted network.
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.