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

{sigh}

We experts can repeat over and over "use taint mode" and "don't let data become code", but if people don't follow the rules, Perl gets smeared as a result. "perldoc perlsec" covers quite a bit of this, and I've also written about Perl security frequently in my columns, such as "Computing Securely", and "Avoiding SQL Injection Attacks".

If anything, the problem is that Perl is too easy to code, and too easy to do something dangerous, so casual programmers can write sophisticated code without also learning about basic rules of dealing with untrusted data.

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.

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

Cheers,
Matt

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)

    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

This issue was raised on the Perl Foundation steering committee list and here are couple of comments from that discussion which might prove of interest.

• The article's original title was "Danger level rises for Perl flaws". Their addition of the word "app" was a small concession to make it clear the problem is not entirely Perl's. I think petdance may have helped with that, but I'm not sure.
• Rafael has stated that the intent is to fix Perl's implementation of printf to prevent this sort of stuff.
• There's a possibility that format strings may be tainted in future versions of Perl (this was mentioned in an offhand manner and I have no other details).

I have to confess, I'm the one responsible for the first comment in the talkback section. I wrote a longer comment, but after proofreading it, I realized that only fellow monks would appreciate it and reduced it to PHB reading level.

I stand by my original claims about webmin. Not only is it poorly-written by today's standards, it leads to even scarier code when in-house development begins. I haven't tested this thoroughly, but if I recall correctly, taint mode is ineffectual because of the way miniserv.pl runs the module code. Another gripe: there is a lot of code that touches critical system data that I would only reluctantly trust to well-respected CPAN modules and does so in ways that lead to easily avoidable errors like duplicate records in system user databases.

converter

Do we need to rally the troops for an NMS style replacement for Webmin? This might answer the immediate question of what the Perl community is doing about it.

It is sad, despite the efforts of Tim O'Reilly and others, that Perl has been getting a bad press. This is despite that Perl underpins many key Internet players - Amazon, Yahoo, and others. It is a fact that as a community, we are lightweight on the PR side; many of us do not perceive that as a problem.

The replacement for webmin already exists, if people would care to look.

There's IMC that looks like being a worthy successor. It even allows you to use existing Webmin plugins.

• another intruder with the mooring in the heart of the Perl

Do we need to rally the troops for an NMS style replacement for Webmin? This might answer the immediate question of what the Perl community is doing about it.

The situation is somewhat different I guess, because Webmin is still actively maintained and evolves regularly. Perhaps we'd better convince the webmin developers to build a new-generation product instead.

And C|Net is pretty obvious in its bias, and at least as clueless as average. To quote Eric Idle in "The Rutles", "It was so widespread that even the press began to hear about it."

Methinks you may just have blinders on. ;-)

Seriously, it's just human nature to notice things that are of interest to you, and not even look at ones that don't.

That said, Java has its own problems... And we can't even blame them on bad Java programmers. ;-)

To add insult to the injury, while this problem exists in other languages like C, they don't exist in all languages. Python seems to catch it.

So there are bugs in Perl? Astounding :) However I regret the way the problem was announced as a major security flaw, while there isn't actually any evidence of this (except the webmin bug, but webmin is notoriously insecure anyway).

However I regret the way the problem was announced as a major security flaw, while there isn't actually any evidence of this (except the webmin bug, but webmin is notoriously insecure anyway).

As pointed out elsewhere in this thread, p5p disagrees with you. There is a nasty buffer overrun in Perl. Webmin isn't free of blame, it does have a security issues itself, but as one person on p5p stated "if there was no bug in perl, the bug in webmin could at most lead to a DOS attack. However, with the overrun bug in Perl, the flaw in Webmin may leave your boxed 0wned".

There is a nasty security bug in Perl, and it took a security bug in Webmin to uncover it.

Perl --((8:>*

It's an unnecessary application (if you have competent sys admins)

Unless you're running a shared webhost and have to give many people access to settings on their accounts.

BCE
--Your punctuation skills are insufficient!

I know journalists (or web-wannabe-journalists) to be clueless, but this one is too much for me to stand.

Ignore it. Noone cares now, and by tomorrow, everyone will have forgotten it because tomorrow it will be .NET who will cause the sky to collapse.

How can we respond to such attacks against our language and community?

Myself, I didn't pay much attention, because the reporter only idenfied himself as "Jack" and used erratic grammar, capitalization, and punctuation. He addressed his message to several perl.org addresses, I think not all of them even valid, perlbug just happening to be one of them.

Oh, well.