My vote is with merlyn: security is not a language issue. It's not even just a application programming issue.

SQL Injection attacks are impossible to do against a Perl application ... so long as you use DBI's placeholders. If you don't, then SQL Injection attacks are just as likely against your Perl app as an app written in any other language. Ruby is the exact same way - there's even a section on it in the Ruby on Rails book. It says (and I paraphrase) "Use DBI placeholders to make SQL Injection attacks impossible."

Many things which are insecure are perfectly acceptable programming practices for situations that are known to be secure. For example, Shell. Shell is a great tool for sysadmins, but I would never put any program that uses it on the web - it's a security risk.

Security isn't about programming language - it's about process. It's about assessing the risks vs. the benefits and making a decision accordingly.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

SQL Injection attacks are impossible to do against a Perl application ... so long as you use DBI's placeholders.

Hmm... Let's rephrase that a tad...

Buffer overflow attacks are impossible to do against a C application ... so long as you use malloc and free properly.

...

Ruby is the exact same way - there's even a section on it in the Ruby on Rails book. It says (and I paraphrase) "Use DBI placeholders to make SQL Injection attacks impossible."

But Ruby and SQL don't take a language level approach to security, right? I'm only wondering if there is any evidence to back up the OP's claim that security isn't a language issue (which I read as "security can't be a language issue"). Maybe you can pinpoint your stance on the issue...
1. Security hasn't been incorporated into a popular lanugage yet, so it must be hard or impossible (let's ignore things like Java applets for now).
2. Language based security isn't possible for theoretical reasons X, Y, and Z. (As found out by the creators of lanugages Foo, Bar, and Baz when they crashed and burned. See their research papers).
3. Language based security is possible, but it is really hard or makes a language cumbersome to use (See also the experiences from the Foo Project)
4. Language enabled security is too expensive for some reason. It is almost always cheaper to fix it when it breaks.
5. Other
...of course, I pretty much think that any idea could be made into a language issue, if so desired. See also: The Role of the Study of Programming Languages in the Education of a Programmer.

Security is not a language issue for the same reason that it is not a checkbox that you can put on a feature list.

Security is a process. Many things that help security can become language features. You've mentioned memory management. You go on to mention some of the benefits of capability designs. But even if you have all of those, you don't necessarily have any security.

In this case the fundamental problem was addressed in part 5 of Dan Berstein's description of what he did to make qmail secure. Don't parse!

The Perl bug that the webmin discussion uncovered was due to how Perl parses printf strings. SQL injection attacks are due to Perl programmers unsafely constructing SQL for a database to parse. In short any interface where one side sends formatted text for the other side to parse and do something with is a complex interface that is very vulnerable to bugs if the one side allows slightly wrong data across that interface. And bugs properly exploited lead to security holes.

Capability systems do not change this fundamental fact. What they are better at is making it more difficult to escalate bugs into serious security violations. That is not completely true. It is possible to take a capability system and build an insecure piece of software. If you want, you have the tools to do it right. But having good tools does not guarantee success. As an example I'll point out that one can build a POSIX subsystem out of a capability-based system, use that to port standard Unix software, and then despite your capability based roots you're back to the normal Unix situation. Admittedly only for the data that is in the POSIX subsystem, but if that is the data that you care about, that is a cold comfort.

So one message that you could walk away from this with is that any language that really cares about security should avoid parsing. However if you're going to interact with existing systems, you're quickly going to find yourself having to interact with existing interfaces that are text-based. For instance databases, email, HTTP, and flatfiles. So the natural APIs to build will involve parsing. And that isn't a question of the language that you're using - it is about the legacy systems that you're interacting with.

Now you can build wrappers around those APIs to avoid parsing. People do - for instance they use Class::DBI instead of writing SQL. (A major issue with this kind of thing is that you can then only access features that the API has exposed. If you need more sophistication, then you need to go to the underlying API...) People can also find options to make the parsing interface simpler - for instance using placeholders instead of dynamically constructing SQL. However at some point you have to accept that there is a programmer responsibility to understand the issue and do things right.

Perl offers tools, eg taint mode, to make it easier to do things right. Perl could do more. But no matter what, some of the responsibility must belong to the programmer.

If you are making the point that human made creations will never be perfect, I'm in 100% agreement. But with some (minor? major? moderate?) effort we could reduce the incidence and severity of bugs by factors of thousands if not millions. In my view, that seems like a goal worth striving for. Along with capabilities, and memory management, we can employ better testing strategies and static typing and other lightweight formal methods. Here, I'll mention some of Les Hatton's publications. I'm only railing against the notion that we're already doing a good job at security. We're not. We need all the help we can get. And better languages will make it a lot easier.

Let's do a little rewording...

Concurrency is not a language issue for the same reason that it is not a checkbox that you can put on a feature list. Correctly implementing concurrent program is a process. Many things that help concurrency can become language features.

Would you agree? I for one disagree. Shared state parallelism (threads) is a huge bucket of worms. Humans really aren't smart enough to use it correctly. What we need are new languages to help us manage concurrency. Erlang and Oz spring to mind. To my mind problems like that scream out language issue. Same goes for security.

dragonchild is doing an excellent job, certainly more cogently than I will be able to do. (Thank, you dragonchild).

There is a lot more to security than a language's (say) memory access model or potential race conditions. Many very serious examples of security problems have absolutely nothing to do with software: trusted users doing improper actions which are, nonetheless, well within their security profiles (sysadmins may have legitimate need to get into the bank's account database), careless disposal or loss of hardware with confidential information, users putting their impossible-to-memorize passwords on PostIt™s stuck on their monitors, et al.

Restricting my comments to software: There is no way language selection can prevent something like

&transfer_all_money_from(cat => \$user) if($user eq 'theMice' and &is_
+away('cat'));
[download]

I don't see how E, CaPerl, etc could prevent this.

emc

Netlib

There is no way language selection can prevent something like

&transfer_all_money_from(cat => \$user) if($user eq 
'theMice' and &is_away('cat'));
[download]

Capability-based Financial Instruments

Abstract: Every novel cooperative arrangement of mutually suspicious parties interacting electronically --- every smart contract --- effectively requires a new cryptographic protocol. However, if every new contract requires new cryptographic protocol design, our dreams of cryptographically enabled electronic commerce would be unreachable. Cryptographic protocol design is too hard and expensive, given our unlimited need for new contracts.

If you don't want to read the papers, check out the video.

Many very serious examples of security problems have absolutely nothing to do with software

Just because you can't fix all problems, does that mean we should try to fix any? You can also say seatbelts in cars are potentially dangerous. The buckle could fail to latch, causing a false sense of security. You could potentially strangle someone with the belt. Also, in some instances, the buckle might jam, causing the passenger to be trapped in a burning vehicle.

I don't see how E, CaPerl, etc could prevent this.

That's why links were provided, so you could study up! If nothing else, the next time this topic comes up, you'll be in a position to say "I've read some of the revalent literature and I don't agree, because...". That's a much stronger position to argue from instead of professing a failure of imagination.

Cheers,
Matt

Wasn't Sony recently involved in copy-protected "CD's" (technically, they're not CDs if they're copy protected; it's a violation of the applicable standards) installing malware on people's winboxes?

emc

Multics: 40+ years old, and immune to buffer overflow

Visit Netlib

indeed, swampyankee, this was my point. Labels such as the 'Villanous Cracker' can be very fluid, depending on the viewpoint -- a viewpoint being largely defined by 'media interests' (note: not artists).

Anyway, that aside, Sony's recent 'solution' certainly qualifies from the engineering perspective stated above.

Cheers,
Matt