I've seen the details, and I'm angry with the reporting. The problem is not Perl. The problem is undereducated Perl Programmers.

Sorry you are wrong.

Perl very definately has buffer overrun issues in printf. This is very clear from the p5p activitiy on this subject. While there is no doubt that the original problem is due to not properly vetting printf format strings the fact is that such behaviour also coincides with bugs in Perl that make the problem much much worse. The following are some of the examples from the p5p thread on the subject.

D:\dev\PM>perl -e"printf'%9999999999s' 
(coredump)
D:\dev\PM>perl -w -le "print sprintf 'xxx%n'; print undef"
xxx
3
[download]

Having said this you can expect this issue to be closed in 5.8.8

---
$world=~s/war/peace/g

Seconded. This advisory seems to have the most technical meat on the subject (also posted to the dailydave mailing list this morning). There is a buffer overrun but the only way to exploit is via a format string vulnerability. So this is news regarding a flaw in perl and not just a vulnerability discovered in webmin.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

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

The trouble is, too many people are looking for the silver bullet to slay the Villianous Cracker, when there isn't one, and the Villianous Cracker isn't the only (or even worse) security problem.

There's an engineering adage about this (paraphrasing) "for every problem there is a simple solution: neat, elegant, and wrong"

emc

Visit Netlib

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

Care to elaborate why security is not a language issue? 'Cause that sounds suspiciously like a C++ programmer claiming that memory management is not a language issue. Wouldn't most Perl programmers disagree with that notion? Why shouldn't we want our programming languages to help with security problems? Is there a better argument against this than "Well, you can't always predict what a program in a Turing complete language will do". Even if it can't solve all problems, wouldn't it be nice if it solved some (especially the most often occuring)? See also, the E Language.

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?

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.

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

Well, there's Sony. At least they actually have deep pockets. ;)

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

By the way, I'd want to mention that webmin is a useful tool, and it's written in perl4 style for somewhat good reasons :
1. because it was first written a long time ago when perl4 was de facto standard.
2. because it's supposed to run on operating systems that may provide only perl4 as default (many proprietary Unixen did until recently or perhaps still do even today)
3. because rewriting it entirely using taint mode and separate privileges would be a huge work and will break compatibility for gazillions of existing modules in the wilderness.

However, the real fault would belong to the administrator who'd leave an accessible webmin server on the web ! I wouldn't dare, even a secured, perl5 tainted webmin...

because it's supposed to run on operating systems that may provide only perl4 as default (many proprietary Unixen did until recently or perhaps still do even today)

You may be right, but I would be interested in your listing any platform or distribution that ships a perl earlier than 5.6.1.

Anyway, that's no excuse for the people who develop and maintain Webmin not to produce a secure version, with -T and best current practices. If such is being shipped as a package it should be made dependent on a recent perl package.

However, the real fault would belong to the administrator who'd leave an accessible webmin server on the web ! I wouldn't dare, even a secured, perl5 tainted webmin...

Depends what you mean by leave accessible. Would you entertain having the app available htpassword protected? You could always set it up so that alarm bells are rung if it gets invoked unexpectedly.

--

Oh Lord, won’t you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, won’t you burn me a Knoppix CD ?
(Missquoting Janis Joplin)

Just wanted to point out that even though I agree that there are probably very very very few (or none) unixen that ship today with perl4 as the standard perl, there are lots of them that have in the past. And while it's easy for us to tell someone who uses an old unix box to upgrade, it's not always easy for them to do so.

duff

You may be right, but I would be interested in your listing any platform or distribution that ships a perl earlier than 5.6.1.

Well, let's have a try :)

nox 3% uname -aR
IRIX nox 6.5 6.5.22m 10070055 IP22
nox 4% perl -v

This is perl, version 5.004_05 built for irix-n32
(with 1 registered patch, see perl -V for more detail)

Solaris ships decent perl versions,but I don't know for AIX, Tru64 and HP/UX.

I thought it was still fairly standard to ship 5.005_03 as the standard interpreter. That's from being on a handful of Sun and BSD boxes. I still think its pretty strange that my Linux actually comes with a 5.8.

    because rewriting it entirely using taint mode and separate privileges would be a huge work and will break compatibility for gazillions of existing modules in the wilderness.
I think it makes sense to re-write the entire code, if they won't do it today then anyway they will have to do it tomorrow

I can just *sooo* second this.

---

Ordinary morality is for ordinary people. -- Aleister Crowley