Slashdot Log In
Secure Programming
Posted by
michael
on Sun Sep 14, 2003 10:57 PM
from the self-promotion dept.
from the self-promotion dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Run-on sentence time (Score:5, Insightful)
(Last Journal: Sunday April 11 2004, @07:41PM)
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:5, Insightful)
(Last Journal: Saturday January 31 2004, @05:25PM)
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:5, Insightful)
(http://frymaster.ca/ | Last Journal: Monday September 15 2003, @12:58AM)
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)
(http://www.mindrot.org/)
Moral of the story: stupid programmers will be stupid in whatever language you give them.
I'd love to read the site, but ... (Score:4, Funny)
We really need a different language (Score:1, Interesting)
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 [linuxsecurity.com] over the past 4 years).
It is time for open source to wake up and start using better tools [jurun.org] and better practices.
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 already HAVE the different language. (Score:5, Insightful)
(http://www.mindrot.org/)
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)
(http://david.acz.org/)
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)
(http://www.slamb.org/)
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:5, Insightful)
(http://slashdot.org/)
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)
(http://www.viega.org/)
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)
(http://michael.bacarella.com/ | Last Journal: Friday November 01 2002, @06:19PM)
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.
Secure programming FAQ (Score:5, Informative)
Securing Programming FAQ [mit.edu]
--
Re:Secure programming FAQ (Score:5, Informative)
(http://www.viega.org/)
I blame colleges (Score:3, Troll)
(http://www.mit.edu/)
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)
(http://www.icedearth.com/)
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.
Re:I blame colleges (Score:4, Insightful)
(Last Journal: Thursday October 19 2006, @09:26PM)
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.
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
Schneier's book considered harmful, or passe (Score:2, Informative)
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)
(http://www.viega.org/)
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)
(Last Journal: Monday September 25 2006, @01:19PM)
At last! (Score:1, Offtopic)
(http://harry.blogdns.com/)
oh wait...
By the way, I can't believe nobody made that joke yet.
Interepreted languages help, but aren't a cure-all (Score:3, Insightful)
(http://www.feralmonkey.org/blog)
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)
Variable input == DOS attack hole (Score:5, Insightful)
(http://www.mightyware.com/ | Last Journal: Thursday November 08, @10:18PM)
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.
Strict mode for C++ (Score:3, Interesting)
(http://www.animats.com)
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)
(http://solarrhino.blogspot.com/ | Last Journal: Thursday February 02 2006, @01:05AM)
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....
/. effect1 (Score:2)
(http://slashdot.org/)
Small error in the site (Score:2, Funny)
(http://mrspeaker.webeisteddfod.com/ | Last Journal: Sunday February 06 2005, @10:56PM)
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)
(Last Journal: Tuesday November 16 2004, @01:29AM)
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
The word "Security" is too big (Score:2, Informative)
(http://ghost.hn.org/)
- 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.
Feedback (Score:2)
(http://www.crypt.co.za/)
This site needs some way of posting comments or feedback. For example, I have issues with at least two of the recipes listed so far. Secure programming sites and recipes are no use if they aren't subject to peer review.
wrong assumptions abound (Score:2)
(http://www.jroller.com/page/shareme/Weblog | Last Journal: Tuesday September 03 2002, @07:25AM)
Not only does the author disspove his own conclusion..in fact switching to java does accidently make a program more secure
But other wrong assumptions abound..
Be very carefull of reading the book the author has written if its ful of the same assumptions..you might get burned..
Wow... (Score:1)
Articles like this don't make me want to use C/C++ (Score:3, Interesting)
Security should be part of the design (Score:1)
(http://www.geocities.com/orion_blastar/contact/ | Last Journal: Tuesday April 03 2007, @07:19PM)
I tried to get into that website on security programming, and it said my user name already existed. How many Orion_Blastar accounts are there in the world, or is it a spoofer? So then I thought maybe I joined before and forgot about it, so I went to "Forgot Password" and got an error screen when I submitted it. Secure but buggy.
Microsoft book (Score:1)
typing "security" in MicroSoft Word (Score:2)
"Dictionary_exception_error: word not found"
Microsoft' (Score:1)
SafeStr library (Score:1)
C or C++ is probably great, for writing very special code, such as kernel modules to support new hardware, or scientific software and such.
However, I think there should be a more secure programming language than C for commercial and for networking software.
Implementing things like a webserver, a data warehouse, accounting software, etc. in C/C++ can be extremly dangerous, and experience shows, that most programmers just can't do it the right way with C/C++.
On Mainframes and AS/400s most commercial applications are written in COBOL, and this is probably one of many reasons, why these systems usually don't get hacked.
However, COBOL is somehow unhandy (unconventional syntax)
On Unix you can hardly get something else than a C/C++- or a Java-compiler; there should be an Ada- or a Pascal-Compiler available for every Unix derivate.
SafeStr is a totally broken API. (Score:2)
(http://www.pobox.com/~qed/)
1. Since the library automatically resizes its strings including the base pointer, that means if you have multiple refs of a string, then manipulations of one of them may leave others in an undefined state. For example:2. The use of SAFESTR_TEMP() (a string that automatically disappears after being passed to any safestr function) is clever but necessarily prevents any of the SafeStr functions from accepting const parameters. This has an additional problem that if you write a function which accepts a safestr_t, then if you pass it to
one safestr function its reference might become undefined (you can't know.) For example:********
If you want to use an actually usefully architected string library try mine here:
http://bstring.sf.net/
In a direct comparison with safeStr, it should be pointed out that bstrlib doesn't have any concept of a "tainted" string. However, it does support read-only strings. bstrlib does not have any of the basic architectural weaknesses described above. It also has numerous other important features which are summarized here:
http://bstring.sf.net/features.html
Re:Speed issues aside (Score:5, Funny)
(http://www.cs.utah.edu/~andersbr/)
See, that's why I keep coming to Slashdot. You learn something new every day.
Re:Speed issues aside (Score:5, Funny)
(Last Journal: Thursday April 28 2005, @06:02PM)
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:5, Funny)
(http://www.cs.utah.edu/~andersbr/)
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)
(Last Journal: Monday November 08 2004, @03:43PM)
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:1)
(http://slashdot.org/)
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:Speed issues aside (Score:3, Informative)
(http://www.viega.org/)
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: Not just speed (Score:1)
Re:Speed issues aside (Score:2)
Lazy?
It's far easier to program in Java, but you never know what's happening in the interpreter.
At least with C/C++ you are talking directly to the machine, and it's your fault if it screws up.
What if you're really lazy, and rely on a JVM that you have no control over to provide your safety blanket?
Noone uses assembley any more (except for kudos purposes), but the closer you are to the hardware, the more care you have to take to make things right - interpreted languages make people lazy, and that must be a bad thing.
Re:Speed issues aside (Score:2)
(http://br.geocities.com./lgcdutra/ | Last Journal: Thursday October 07 2004, @05:34AM)
> These security problems are fixed by switching to a modern language
Agreed...
> like Java or C#
These are *not* really modern languages... they are too much of procedural kludges to do OO, their runtimes are too big and they are too complex. They end up creating many problems.
If you want good languages, not just popular ones, go functional (Lisp, ML or their dialects) or pure OO like Smalltalk.
COBOL BABY!!!! (Score:1)
--
Re:Lesson #1: Don't use C or C++ for Secure Progra (Score:2, Insightful)
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.