Secure Programming 360
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."
Run-on sentence time (Score:5, Insightful)
Once you have worked 50 hours a week in a corporate setting for 5 years as a developer (2 years) and a run-of-the-mill network/system/any-god-damn-thing-they-can-get-you -to administer(4 years, you will understand.
Re:Run-on sentence time (Score:2, Interesting)
With not quite a million slashdot anonymous cowards, that Bureau of Labor Statistic [bls.gov] 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 th
Re:Run-on sentence time (Score:2, Insightful)
Re:Run-on sentence time (Score:5, Insightful)
Programming securely does not have to cost you a lot of time either. Take the SafeStr library mentioned on the website for instance... a string library that can be used as replacement for the standard C string functions, a notorious source of buffer overruns and bugs. Using this library instead of the standard functions will cost little or no extra time.
Programming securely is just like other good programming practices. Generally they do not cost extra time, they save time. It does take time to learn these practices, and that's where the responsibility of each programmer comes in. Take the time to learn good programming practices and get used to them, stay abreast of new developments, and above all train and encourage your junior team members to use these methods as well.
The team that fails to adhere to good programming practices will turn out unstable and insecure software. Where do you think the bugs in Microsoft products come from? Tight timelines? Perhaps... but a great many of the bugs I come across are generally the result of a sloppy programmer, tight deadlines or no.
Good idea (Score:5, Interesting)
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!
Re:Good idea (Score:3, Interesting)
I agree. Cookie-cutter methods don't teach good secure coding practices. What we really need are more books that discuss how to address security throughout the life of software, beginning at its design. It's kind of sad that even after years of acknowledging this need, there are still only a handful of such books available. This kind of knowledge also would
Re:Good idea (Score:3)
If you look at the book, while there are indeed plenty of pieces of code people can just use, we thoroughly discuss design and implementation issues for each of the examples we give. That is, we're covering
Yet languages make a big difference (Score:3, Informative)
That's true, of course, but nonetheless languages make a huge difference.
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD
Re:Good idea (Score:5, Insightful)
ah, you think it's funny - but it's true! the more a program does, the greater its potential for security flaws. thus, frymaster's first rule of secure programming: "your program shall do no more than what is absolutely required by the spec-n-rec[1]".
1. you got a spec-n-rec from the client? lucky you!
Warding off the inevitable "switch to Java" commen (Score:5, Insightful)
Random numbers
Input validation
Cryptography (e.g. ssh)
Buffer overruns are just one kind of problem you need to deal with when writing secure code. There are also DOS attacks and information theft. Even with Java, it can be quite challenging to ensure that data is properly encrypted and authenticated, and you still need to worry about permissions in the file system.
And let's not even dredge up the standard "why can't you just rewrite 100s of 1000s of lines of working C++ code in Java?" inanity.
Re:Warding off the inevitable "switch to Java" com (Score:4, Insightful)
Moral of the story: stupid programmers will be stupid in whatever language you give them.
actual snippet (Score:3, Funny)
{
try
{
}
catch()
{
}
}
Re:actual snippet (Score:3, Funny)
In that spirit, my favourite was:
while ((var = malloc(sizeof(*var))) == NULL);
Re:Warding off the inevitable "switch to Java" com (Score:2, Flamebait)
Buffer overruns are one of the problems you don't need to deal with when writing secure code because modern languages (not C/C++) can detect that condition for you, leaving you to concentrate on the real bugs.
So much for "warding off". :p
Re:Warding off the inevitable "switch to Java" com (Score:3, Interesting)
I'd love to read the site, but ... (Score:4, Funny)
Secure programming FAQ (Score:5, Informative)
Securing Programming FAQ [mit.edu]
--
Re:Secure programming FAQ (Score:5, Informative)
I blame colleges (Score:3, Troll)
Let's teach future American programmers proper security before they graduate and start writing professional software.
There's no excuse for the fact that in order to write good, clean, secure code, our youngsters have to visit websites like secureprogramming.com in order to just get by.
What a disgrace.
Re:I blame colleges (Score:5, Insightful)
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.
The goal of college, in the context of our current society, is to prepare students to get a job - if employers aren't demanding it, then people aren't going to expect it to be part of a college curriculum.
Don't get me wrong, I fully agree it should be a core part of computer education right from the start, but until the technology industry recognizes it as a day-to-day need (other than the 2 weeks after you've been hacked), it won't be considered an important part of the educational process.
I blame porridge (Score:2, Interesting)
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
Re:I blame colleges (Score:2, Interesting)
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 progra
Re:I blame colleges (Score:2)
Maybe that may be a slight exaguaration. But they learn mathmatics and physics, english, history or other humanities, and maybe 2 or 3 courses with real programming while the rest is theory and calculus.
The industry response was well lets look at India. These students there only focus on programming and not going to school and work for a 1/4th of the price!
Re:I blame colleges (Score:2, Insightful)
Re:I blame colleges (Score:2)
Re:I blame colleges (Score:4, Insightful)
Also:
- the importance of taking the time to do something right the first time as much as possible, instead of always the tiresome updates and tweaks.
- what version control software is and how it is essential to team development (hell, you'd be surprised how many senior programmers don't know about it or use it).
- how to take ownership of a task and see it through, not blaming someone else.
- how to keep busy when the current task is blocked. Find another task, stay busy.
- how to use your own head, and not ask questions about every single thing. If I have to give guidance on what colour your label should be, I might as well do the task myself.
- common design patterns and practical applications of them.
- performance optimization techniques, and why developing everything on a quad Xeon with gigabit ethernet is not always a good idea.
- how calling in sick every week is not acceptable in the real world (not at most places, anyway).
- how good organization techniques can save you a lot of time and keep you on target.
- error handling code should be hilighted more. Books always seem to omit error handling, and that's what students learn from. That leads to really buggy code.
Re:I blame colleges (Score:2, Interesting)
Re:I blame colleges (Score:2)
Re:I blame colleges (Score:2)
Hmmm. You mean that:
Problem
Integer overflows can lead to allocating too little memory, which can often result in an exploitable buffer overflow.
Solution
Before each memory allocation, be sure to check the size you're allocating, to make sure it really is big enough to do what you need.
Should make you respond with 'Well, DUH!', before you get on the job?
I've no idea what 'to be' prog
Re:I blame colleges (Score:2)
the first rule of secure programming club is (Score:3, Interesting)
like say, Ada
oh yeah, let the negative moderation begin
because programmer can't stand being held by the hand
too big ego
Re:the first rule of secure programming club is (Score:2)
Why is C or C++ some sort of a sacred cow. MS is throwing C away and going with C# why isn't the rest of the world throwing C away and going with Java or Python, or Eiffel or Lisp or whatever.
Write in python and then rewrite the critical sections in C if you must. You'll still be more productive in the long run.
Re:the first rule of secure programming club is (Score:2)
Dave
It's About Time (Score:2)
Right now, the most interesting of these better languages looks to be Cyclone (from Cornell) which has some chance of success because it is based on C. Certainly(?), next genration versions of C and C++ ought to prevent such problems unless the programmer explicitly permits them.
And the second rule of secure programming club is (Score:2)
Quoting Bjarne Stroustrup when some moron tried to flame him for C++'s perceived lack of security, "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware." (Emphasis mine.)
So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages are there to help realize a clean design and facilitate debugging. NOT to enforce some kind of real-world security.
The other rules (Score:3, Funny)
Just because I watched the movie the other night and can therefore quote entire reams from memory:
Schneier's book considered harmful, or passe (Score:2, Informative)
Re:Schneier's book considered harmful, or passe (Score:2)
Now his attitude is closer to "no system can ever be made secure, and that goes quadruple for systems which rely on the security practices of users." So Schneider himself isn't totally happy with AP.
Enhance Linux Operating System with BOSS (Score:3, Informative)
Kinda sounds like Common Criteria, doesn't it; hopefully better.
Chapter 1 (Score:3, Funny)
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
Re:Chapter 1 (Score:5, Informative)
Do *what* to get your way to the top? (Score:3, Funny)
Crawling under desks? I know admin'ing IIS servers is bad enough because of the security problems, but to have to blow your boss to keep your job?
Talk about getting fucked in both ends!
The site is pink. (Score:2)
Re:The site is pink. (Score:2)
Interepreted languages help, but aren't a cure-all (Score:3, Insightful)
Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).
This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
2 tips from the hood (Score:4, Interesting)
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.
Re:2 tips from the hood (Score:4, Insightful)
Re:2 tips from the hood (Score:3, Interesting)
No SQL in your UI code? Sure, good move. Instead, move all your SQL into a back end and then call into it from your UI code. This goes as follows:
Re:2 tips from the hood (Score:3, Informative)
Variable input == DOS attack hole (Score:5, Insightful)
The problem is not the language, it's our style of programming.
The whole reason that security issues have proliferated is our stubborn insistence on allowing for variable input. If all input and systems had hard wired capacities, then, there could be no denial of service attacks as program behavior would be bounded.
Even C# and Java have DOS issues becuase of their unbounded nature. A program that reads an input stream and stuffs a link lists will be just as supsectible to denial of service attacks as any others.
Some of us remember gravitating over to C from the old Pascal and FORTRAN and BASIC because of C's penchant for creating dynamic data structures. AS I look back on that era, I wonder if we didn't make something of a mistake.
I wonder if we might borrow some of the practices from that ancient era, and use dynamic allocation as the exception, rather than rule. Programs should have fixed numbers of objects. Programs should have fixed input sizes and maximum capacities. String fields should always have a maximum, fixed, size.
I should note that if we do have less variable length allocations, then, we less likely need programming languages that make variable length easy. A more conservative, almost retro programming technique could make for faster, more secure programming.
Re:Variable input == DOS attack hole (Score:2)
You know what really bug me? Almost all languages have assertions and yet almost nobody uses them. If you are dealing with dynamic elements you should have pre and post conditions as assertions.
Re:Variable input == DOS attack hole (Score:2)
This is my prefered method of programming - the problem lies in convincing users to accept arbitrary restrictions.
The next best thing is to wrap all dynamic allocations in protected functions with paranoid checks built right in. Asserts are not enough, t
Strict mode for C++ (Score:3, Interesting)
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.
My definition of "Secure Programming"... (Score:3, Funny)
Vision of security isnt as bad as ./ make it (Score:3, Informative)
From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.
Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.
Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.
I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.
Nuff said....
Re:Vision of security isnt as bad as ./ make it (Score:2)
I'd definitely say that it's impractic
/. effect1 (Score:2)
Re:/. effect1 (Score:2)
Small error in the site (Score:2, Funny)
I checked out the HTML source and the problem seems to be in the spc.css file.
There are several references to the value #BD3D89 and on the monitors I have here that value appears as a bright pink colour.
Just thought I'd let you know.
Here's the full text (Score:4, Funny)
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, mmessier@secureprogramming.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.28 Server at www.secureprogramming.com Port 80
Articles like this don't make me want to use C/C++ (Score:3, Interesting)
Re:Articles like this don't make me want to use C/ (Score:3, Insightful)
So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____
Re:Speed issues aside (Score:5, Funny)
See, that's why I keep coming to Slashdot. You learn something new every day.
Re:Speed issues aside (Score:5, Funny)
Without throwing an exception and crashing the program.
No dereferencing of null pointers
Without crashing the program (java.lang.NullPointerException).
No object creation failures (all "new"s succeed)
Without crashing the program -- usually as spectacuarly as a C program since an out-of-memory condition will make Bad Things happen with the VM or JIT as well.
Sounds like a great candidate for writing an OS kernel in. Microsoft are you listening?
Re:Speed issues aside (Score:2)
Which makes it unavailable for hacking. No program, no access.
Yes, a DoS will occur, but your site is safe.
Besides, a properly written Java app WILL have a try/catch block at some basic level to do a last ditch effort to intercept (and deal with) a normally fatal exception.
Re:Speed issues aside (Score:3, Insightful)
For a geek, crashing early might be good coding practice. For a user, it's one e-commerce site they'll never visit aga
Re:Speed issues aside (Score:2)
Re:Speed issues aside (Score:5, Funny)
Lesson #3: Don't try and be funny. You'll just end up having to explain it, and--as the Heisenberg Principle attests--an explained joke ceases to be funny.
Seeing how the parent didn't specify which security issues were fixed by switching from C/C++ to Java, and the website is devoted to "secure programming" without regard for language, the parent gives the impression that switching to Java automatically renders an application completely secure.
Despite Java's safer memory usage, an application is still open to a wide variety of attacks. Such grandiose security claims about managed languages are worthless (except for the schmucks trying to get a contract to rewrite a critical application in Java or C#).
See? See how not-funny you made me?
Re:Speed issues aside (Score:3, Insightful)
I'd rather use a language which doesn't give a false sense of security, a language which everyone obviously (well, we hope they do, but, true, not always the case) knows you have to do checks and specify how much space you really have (and so forth).
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself. Except of course, laziness >:P
Re:Speed issues aside (Score:4, Insightful)
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.
No, it is you who is wrong. Why do you use a computer instead of an abacus? Why do you use paper when you could carve notes into stone? Things progress, things get better, and things that once were boilerplate (like manual safety checking) are taken care of so you don't have to do any of the boilerplate stuff anymore.
Embrace the better technology. Don't cling to the past or you will be left behind.
Re:Speed issues aside (Score:2, Interesting)
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 generati
Re:Speed issues aside (Score:3, Insightful)
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.
Assembler required you to know registers, C and C++ require you to free memory resouces. Java requires you to open/close files
Re:Speed issues aside (Score:2, Interesting)
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
Not just speed (Score:5, Insightful)
But what is the JVM written in? I guarantee you it isn't Java.
Similarly, at my old job, I had to write low-level drivers for PCI hardware we were developing. Did I get to write these drivers in Java or C#? Of course not... you can't write low-level hardware calls such as Windows VXD files in an interpreted language; it'd really kill the performance of a system.
Just for a moment try to imagine someone writing, say, a new video driver for the Linux kernel in Python, or rewriting XFree86 in Java.
Ow.
Moreover, while Java makes it a great deal harder to, say, create a remote root exploit through a buffer overrun, it does not automatically fix problems of, say, cryptographic strength. Creating an encryption algorithm for some vital data which can be easily broken is as much a security hole and a flaw as a buffer overrun.
So while you're correct in some places -- Java and Python and C# and other interpreted languages that can do more stringent runtime checking of things really
In general, the lower-level the language, the more easily you can mess it up; ASM is even easier to fry things in than C or C++. It becomes a tradeoff, with the lower-level languages giving you progressively greater efficiency and the ability to access things 'down on the metal', with higher level languages -- while slower and more abstracted -- able to shield you from more mistakes, and more portable between situations.
Each has their place. I wouldn't want to write a web-client that ran database queries in ASM, but Java works great. Conversely, I wouldn't want to write a driver for an AGP graphics card in Python, but ASM or C works pretty well right there.
Re:Not just speed (Score:2)
*SLAP*
There's no such thing as 'interpreted' or (compiled for that matter) language: particular language implementations are.
There are C interpreters and Java compilers around (check out GCJ, which compiles to native code).
And of course, any Turing-complete language interpreter/compiler can be written in any other Turing-complete language, so no, one don't have to implement compilers in C.
Re:Not just speed (Score:3, Insightful)
Perhaps I misunderstood the original post which I was replying to, but the poster seemed to be making the point that Java and C# -- being interpreted -- fixed all security problems. I concede that an interpreted language fixes some problems because the nature of interpreted code makes it possible to catch some things at runtime (a
Re:Speed issues aside (Score:3, Informative)
We do a lot of code auditing, and find about 4-5 serious security problems per thousand lines of code of C and C++ code. In languages like Java, we still usually find 1 or 2 such problems.
Re:Speed issues aside (Score:2)
Also, note that many programming languages are implemented in C, and have had or might have security problems relating to that. I've seen such problems in several common scripting languages. It is like that there are plenty of other problems like that waiting to
Re:We really need a different language (Score:2)
I've heard of it, and I know someone talked about it at DEFCON this year. Has anyone tried it for production applications, or just for proof of concept?
Re:We really need a different language (Score:5, Interesting)
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>
Re:We really need a different language (Score:2)
There is a difference between a programmer error (buffer overflow) and a design problem.
If you can use a language which reduces programmer error, then you can spend more resources working on proper design.
Computers Existed Before C (Score:3, Insightful)
Re:We really need a different language (Score:3, Insightful)
Personally I never understood why C was so popular. In particular I never understood why people thought of C as a powerful language. I don't know about the parent post, but for me I do recommend writing a kernel with something else. A mix of Ada and assembly would be my choice (yes, I know I'll get flamed for saying "Ada").
but you have to realize that unless the underlying infrastructure is built (on some low level language), you
Re:We really need a different language (Score:2)
Um.. why not?
> 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.
Yes, but the next level don't have to be C.
We already HAVE the different language. (Score:2)
(And before anyone says "... but you can't write a kernel in LISP!", there are several LISP Machines out there which beg to disagree with you.)
Re:We already HAVE the different language. (Score:5, Insightful)
Re:We already HAVE the different language. (Score:2)
Who needs to write just a kernel in LISP when there is emacs, a complete OS written in LISP?
Re:We already HAVE the different language. (Score:2, Informative)
Re:We already HAVE the different language. (Score:4, Interesting)
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.
Re:We really need a different language (Score:5, Interesting)
That's not true. qmail [cr.yp.to] and djbdns [cr.yp.to] 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 [cr.yp.to].
Re:We really need a different language (Score:5, Informative)
Bah. That they do not have security holes is implausible, if not actually impossible, to prove. It's hard to even define what a security hole is; a changing threat model has "caused" many security holes. (Is an open relay a security hole? I say yes. Twenty years ago, everyone said no.) I doubt your statement. I can't point at a hole right now, but I have confidence that at least one security hole will eventually be discovered in those programs.
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.
No, they make it easier to avoid buffer overflows. They don't prevent them: I quote from your hyperlink:
If they use sa.s and sa.len directly, they can screw up and increase len inappropriately. The API seems good in that it makes it much harder to do things wrong, but it is hubris to say it makes you invulnerable. Besides, buffer overflows are possible for things other than strings, so this solves only (the most common) part of the problem. And there's still the legacy code that people can use without porting to stralloc.
It does seem like a good library if you're stuck using C. Another alternative is APR, which makes managing all sorts of memory allocations much easier. Pools are handy things when dealing with a language that primitive.
But there are languages in which it actually is impossible to have a buffer overflow. Please don't confuse the issue by saying that this (which makes it somewhat easier to avoid this error) makes the error impossible.
Re:We really need a different language (Score:2)
qmail is very widely used and deployed (they claim it's the second most popular smtp program) and it has never been hacked. If it has held up so far I am pretty sure it's unbreakable.
Re:We really need a different language (Score:5, Insightful)
And don't think that just because Microsoft is switching to managed types that they are all of a sudden going to fix bad coding practices. Sure it may reduce the effect of bad coding but it won't single handedly catapult Microsoft into security heaven.
Go back in your cave troll.
Re:We really need a different language (Score:4, Insightful)
However, C and C++ are a fairly small part of the market these days, too. All the market data I've seen recently suggests that no more than 1/3 of commercial development is in one of these languages. It's probably less.
And, there are plenty of security problems that apply to all languages, such as problems in authentication systems that provide the attacker some kind of leverage (e.g., practical guessing attacks), other misuse of cryptography (e.g., misapplying SSL) and other generic input validation problems (e.g., SQL injection). These things come up in all languages, and are things people frequently get wrong.
Re:We really need a different language (Score:4, Interesting)
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.
Re:We really need a different language (Score:2)
Python is good for some things, but it's hardly a 1:1 replacement for C/C++. While it may be somewhat better in some areas, interpreted languages have certain shortcomings that make them unsuitable as replacements
Re:We really need a different language (Score:2)
I think you exagurate a lot here, when you use the word many to advocate C, and the word some applying to Python and other interpreters. I think that in most of projects (by amount of projects and by a
Re:We really need a different language (Score:2, Informative)
Overlook? Hardly.
Most open source models encourage reporting of exploits so they can be fixed. (more than 500 in Debian over the past 4 years). How many of those are STILL exploitable? How long between when an error is found and a fix is available?
Your argument is common and entirel
Re:At last! (Score:2)
Re:wrong assumptions abound (Score:3, Funny)