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."
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.
Lesson #1: All Java programs are automatically secure.
:)
See, that's why I keep coming to Slashdot. You learn something new every day.
You want the truthiness? You can't handle the truthiness!
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!
If you RTFA, or even just GATFA (glance at) you'll notice that the book has info on:
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.
Might Java or C# have their own security issues, where if the right set of things occur bad things could happen?
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
I won't given the color scheme.
The really is no excuse to use a language like Java or C# to do your checking when you can do it yourself.
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.
Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
Securing Programming FAQ
--
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
These degrees are handed out like toilet paper these days.
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.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
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.
Now that you've got off your high pony, the problem is not necessarily the tools. As the site points out, buffer overflows can be avoided in C/C++. The whole point of the site is to try and improve coding practices.
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.
"She's a West Texas girl, just like me" - G.W Bush Iraqis
No buffer overflows
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?
Viega's site disses Schneier's book, which everyone else seems to regard as gospel. What's up with that? I like a juicy feud as much as the next guy.
IEEE Standards Associate, IEEE Information Assurance, IEEE Computer Society and IEEE Baseline Operating System Specification Working Group (BOSSWG) has initiated a call for definitions of a new operating systems intended to securely control nearly all aspect of the operating system (including root).
Kinda sounds like Common Criteria, doesn't it; hopefully better.
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
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.
Lesson #2: No matter how obvious it is that you're trying to be funny, someone will mistake your comment for totally serious and sincere (or, in this case, totally sincere in sarcasm). Which leads to...
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?
You want the truthiness? You can't handle the truthiness!
It's more than just speed issues. Interpreted languages have better runtime checking and thus can avoid things like buffer overruns, yes. That's great for a lot of things, don't get me wrong. For backend programs, Java is an absolutely brilliant language, as it encourages some much better object-oriented design philosophies. Even Objective C handles some runtime checking far better than C or C++, though as it is a set of extensions to C it suffers from the same weaknesses in C code.
:) Last I checked, the original Java Virtual Machine was written in C...after all, you can't run Java bytecode without something to interpret it. Similarly, I bet you most Just-in-Time Java compiler/interpreters are also written in C or C++. Even the programs which take Java code and turn it into a binary executable likely are linking it against a library which was written in C or C++.
:)
/do/ solve some problems which traditional lower-level languages are more vulnerable too -- modern interpreted are not a panacea for all programming ills. They aren't suitable for all types of programming, and even for the ones they are well-suited for, they don't automatically solve all security issues.
;)
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.
--Rachel
This isn't true whatsoever. Only the most glaring issues are fixed. Currently, we're working on a Java Secure Programming Cookbook, and we'll get around to C# after that.
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.
By hiding the details behind a curtain, I think it is more likely problems will just get ignored
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. SQL requires you to know table and column names. Each step up requires less and less knowledge of the underlying system. And each step up is safer overall.
But ANY language can be written so it is insecure and/or buggy.
We will reach a day when the Star Trek type of information retrieval and manipulation is done. We are not there yet.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
"Now I'm just a lowly IT worker, managing web servers and crawling under desks"
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!
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.
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).
I agree that they didn't sell that many Lisp machines (maybe a few tens of thousands?). But you are mistaken in your comment about architecture: the Lisp machines only ever had half a dozen instructions that made them different from mainstream CPUs. In fact one of the many reasons for the demise of Lisp machines was that Lisp compilers of mainstream architectures got good enough that they could compete with the Lisp-optimized machines. In principle there's no reason you couldn't run a Lisp kernel on a modern machine -- it's just that there would be no point when 99.9999% of available software is written in non-lisp languages.
Tune in to Bugtraq some time to see a never-ending stream of web-app vulnerabilities. Most of these applications are not written in C.
Moral of the story: stupid programmers will be stupid in whatever language you give them.
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 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.
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?".
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
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 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.
This is my sig.
while(true)
...
//try again
{
try
{
}
catch()
{
}
}
bite my glorious golden ass.
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.
... is any programming job that can't be exported to India!
"Lord, grant that I may always be right, for Thou knowest that I am hard to turn" -- A Scots-Irish prayer
Been in the security game for 10 years...
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....
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.
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 entirely false.
When an error is found in Debian, it is soon fixed.
When an error is found in M$, it gets swept under the rug and ignored. When finally made public (usually via 3rd party press release or some spectacular virus/worm) M$ often denies, then grudgingly releases a patch. This patch may or may not fix the problem and may or may not break something else.
I think I have spotted a small error in your otherwise excellent site.
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.
Just in case the site gets slashdotted, here's a cut-n-paste of the home page. Whew, glad I was able to get in to get this:
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
20+ years ago I used an operating system that was written in Pascal. There have been commercial operating systems written in FORTRAN, PL/I, LISP and other languages.
Mea navis aericumbens anguillis abundat
Are you somehow recommending a kernel be written in something else than C?
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 can't have high level languages.
I'm not sure what you mean by this (you don't mean you can only write a compiler from assembly, right?) but what's the difference between C and another high level language? (except for the fact it's easier to write a C compiler than an Ada95 compiler)
buffer overflow isn't the only security hole in the world
No but they are really "popular". Also don't forget about simple bugs that could be found at compile time by using a more powerful language than C.
Yes, I know you can have good programming practice in C. You can have good programming in assembly too. Unfortunately a programming language comes not only with syntax rules but also with a "culture"... and let's be honnest, C "culture" is not about good programming pratice.
- a program enforcing a division of data,
- ensuring a program doesn't let any bits slip through the cracks, and
- creating a system where people can do only the things they are allowed to do.
"Security" to me is (3). Security is a social construct. You can't have security until there is someone who's not allowed access to something.I see a lot of talk about cryptography, preventing buffer overflows, and so forth. But the combining of these technologies in the design of a real-world security application is seldom discussed. It's a hard messy problem.
I suspect if we had a better understanding of the social aspects of security, more secure technology would follow.
Just because I watched the movie the other night and can therefore quote entire reams from memory:
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Oh, your very own web page cites 5 bugs per 1000 LOC for C/C++, and 1 for Java. That's a factor of 5!
The biggest problem that makes C/C++ less secure than other languages is the fact that errors are not contained locally. Every single line of C/C++ in your project can break any other line of your code, violating all security assumptions.
Sure, you have STL. And what does that buy you when there is a buffer overflow in a third party library you're using?
Right, nothing.
Besides, readable and maintainable code is a security feature in itself, which C/C++ just doesn't have. It lacks a lot of abstraction facilities.
Not seeing C/C++ as a source of many of our security problems is a state of denial.
Unfortunately, in a real world situation (as opposed to the dreams of someone walled in their own ivory tower), a program that crashes regularly is just short of useless. A program which malfunctions in the middle of writing data -- because half the logic got shortcircuited by a RuntimeException that cut straight through the last ditch "catch (Throwable all)" block -- is worse than useless.
For a geek, crashing early might be good coding practice. For a user, it's one e-commerce site they'll never visit again. (Yes, in a recent study, the main criticisms were stuff like the web site having a brain fart AFTER it swallowed the credit card number, leaving the user with no clue as to whether the order was processed or not.) Congrats, your site wasn't hacked, but the company is losing money hand over fist anyway.
Don't get me wrong, I'm not against Java, and I _do_ understand its advantages.
_But_ if using Java is your _only_ security, then you're doing it awfully wrong.
In Java, like in any other language, you _still_ have to do your own checks, and make some effort that the program will still work when confronted with malformed input. Especially when such input is not even a hacking attempt, but some hapless user typing "Jan 23, 74" instead of "23/01/1974" as you would like him to. Or he's included spaces in the credit card number (which causes Long.parseLong() to throw an exception.) Or whatever.
You do _not_ want the program to crash early and safe on the user, you want it to display a clear error message, and give the user plenty of clue as to how to correct the problem. And a chance to do so.
You also have to account for such user deviations as "what if he opens a link in a separate page, so now we have TWO pages sharing the same session id. And the user is doing different things in each." That's absolutely _deadly_ for brain-dead sites which store everything in the session. Just because Java's servlet interface makes it easy to store stuff in the session, doesn't mean it's also _safe_ to do so.
I've seen at least one e-commerce site which ended with products flagged "new user" and users flagged as "sold", because they relied on the session in the wrong way. Yes, noone took over their site, but the cost of that screw-up was very high nevertheless.
Briefly: again, just programming in Java doesn't automatically make your programs bullet-proof. There is no auto-magic substitute for good coding and design.
A polar bear is a cartesian bear after a coordinate transform.
It's easier to eke speed out of C, largely because there's no pesky security ;-)
To start, the parent comment should be modded back up. The parent poster isn't a troll; (s)he just has strong opinions.
Onto the post ...
Geez, how hard can this be? C and C++ are the only two major languages
on the market nowadays which allow array overflows, pointer dereferencing
into code, free creation of unsafe code, and other fun stupidities. As such,
they are easily the WORST LANGUAGES on the market for secure
programming.
This is a common programming fallacy. It's not the programming language that makes it easier to create a secure program; it's the programmer with a thorough understanding of security that makes the (infinitely approaching) secure program.
Sure, people will say oh, yeah, but you can be insecure in any
language. These people should have their CS degrees revoked.
They're right (and if you had your way, I'd have my piddly degree revoked in a few seconds :P)!
There are dozens of popular programs written in C/C++ in which security holes haven't been found, programs that are written carefully and thoroughly debugged by programmers that understand security. Programming languages like Python, Ruby, LISP, [... ad nauseum] make it easier to avoid common pitfalls (i.e. buffer overflows), but there are plenty of security holes that can be introduced into programs written in those languages.
Don't get me wrong. I'm a Python zealot, I like Ruby, and I think Modula-3 has (had?) the potential to be one of the best systems programming languages available (if not for the lack of tools associated with Modula-3). However, that doesn't change the fact that there are great C/C++ programmers out there that will write less buggy code in their lifetimes than many Python/Java/Ruby/[insert your favorite language of convenience] programmers that don't know the first thing about computer security.
I could apply your logic to language interpreters/compilers for some of the languages you mentioned (i.e. Java, Python, Ruby, etc.). Is the Python interpreter less secure than a Python program because the interpreter was written in C? If the interpreter is insecure, then what does that say about Python programs when they're being interpreted by the interpreter? A program is secure if it's behavior is predictable, given a certain set of actions.
Devin
Oh, we have some pseudo-scientific measurements in this regard. Gwydion Dylan comes with a Dylan-to-C-translator. Average performance loss when compared wo writing directly in C is between 10 and 30%, and that's mainly due to garbage collection overhead and some register lossage (we have to pass an extra stack pointer to the generated C functions).
Bounds checking is nearly free on modern CPUs. Branch prediction and superscalar execution buys us that. Measurements show the overhead to be less than 0.1%, for sieve of Erathostenes, which does array access all of the time.
And OCaml shows that you can even beat C in terms of performance once you can do global optimizations like deciding which registers to save and which not on a per-function basis.
Last, but not least, having a real high-level language available means it is easier to implement funky algorithms that reduce algorithmic complexity. It's most often the brain and not the muscle that makes software run fast.
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?
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?
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 ____.
You still have issues of data/input validation, principle of least priviledges, secure (confidential and/or authenticated and robust) communications, sanitizing the enviornment, dropping unnecessary priviledges (and designing the program so it can drop priviledges early on before user/network client interaction), race conditions, error handling, and many many other tedious yet important issues.
> and those that think they're safe merely by using a particular programming language are in for a nasty surprise.
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 hole, etc.)
All of these errors would be impossible to make in a safe language.
Yes, we still need security-conscious developers, and there are still many things to worry about. But if we can get rid of the vast majority of problems, automatically (and as a side benefit get to program in a modern high-level language, which makes many other things easier), why not switch? Just because it's not a complete solution?
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.