|
Re: eWeek article: Is a New Vulnerability the Tip of the Perl Iceberg?
by Perl Mouse (Chaplain) on Dec 08, 2005 at 14:36 UTC
|
Is it just me or does Perl seem to be singled out in getting bad PR of late?
Let's face it. Perl does have a security bug. That in general will create publicity, and usually not something that's very positive. Not just in Perl, but if there's a security issue in Firefox or in Windows, or with a certain brand of toasters, people will write about it.
Larry's article is opiniated, and it's clear he isn't Perls biggest fan. However, he isn't blatantly wrong - you might disagree with his opinions and conclusions, but that's a different matter. To some, Perl programs are modem noise (and some Perl program really are, even for me), and Perl did came forward as something between shell, AWK and C. That it was designed to do 'quick hack programming' isn't that far off - and there's certainly no denying that Perl is very suited 'quick hack programming' jobs.
ASP and PHP are mentioned as languages that have succeeded Perl in popularity, but none of their security problems are mentioned.
Yes, and? The article is about the recent security problem with Perl. A list of security issues in other languages is irrelevant. Do you think that if there's a security issue discovered in PHP or Ruby, articles mentioning those should also point out that Perl is insecure as well?
IMHO the author fails to note that insecure code can be written in any language,
Yes, but that's not the point. If car maker X has a model whose gas tank can explode, should an article discussing that mention you can drive any car into a brick wall? The point isn't that an insecure application was written that happen to use Perl. The point is that Perl itself has a security flaw. As Larry rightly writes: Another point about this vulnerability that will serve to confuse is that it is often described as a vulnerability in Webmin, a Web-based system administration tool written in Perl. But some reports, which I have confirmed with Dave Aitel of Immunity Inc., make it clear the underlying problem is in Perl itself.
Whining how cruel the world is by writing disapproving articles about your favourite toy won't make them go away. The bug will be fixed - and that's all that needs to be done. Acknowledge the fact, and act on it. That's what we expect from other products as well, and that's how we should react as well.
| [reply] |
Re: eWeek article: Is a New Vulnerability the Tip of the Perl Iceberg?
by jkva (Chaplain) on Dec 08, 2005 at 11:17 UTC
|
The way I see it there are always some people critisizing the language one codes in. (think COBOL)
PHP and Ruby (Python?) are, if we believe the articles, the successors of Perl, which is old and done for. Now I bet that if I look for articles that criticize those languages, I can certainly find some.
I guess the point that I'm trying to make is that languages will always be criticized. As long as you can write good code in it, that's the way to go. Now assembler, that's a language. ;-)
Just my 2 cents.
-- Detonite -- jkva #force of habit
| [reply] |
Re: eWeek article: Is a New Vulnerability the Tip of the Perl Iceberg?
by zentara (Cardinal) on Dec 08, 2005 at 13:21 UTC
|
We are moving into a "new-age of information", where everything is (or can be pure lies) intended solely for the entertainment of the target audience. The current U.S. administration is leading the way. Tell them what they want to hear, and you'll be popular. When confronted with truth about your lies, smile and say "We are still assessing the facts".Writing about languages is the same. You write articles criticizing Perl, when the target audience is PhP, Java, or Python programmers. And vice-versa when the target audience is Perl programmers.
Oh how I love those Java bashing articles. :-)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
Re: eWeek article: Is a New Vulnerability the Tip of the Perl Iceberg?
by swampyankee (Parson) on Dec 08, 2005 at 16:12 UTC
|
Perl has a potential buffer overflow problem. So does C, and in my opinion, any language based on C.
My major complaint with the line of thinking in this article -- that security should be built in at a fairly high level (and Perl is a high level language) -- is that it, by inference, absolves the O/S of responsibility for not permitting buffer overflows to cause problems. My experience on various flavors of MVS and VM was that any attempt by an application program to access memory outside of its data allocation resulted in immediate termination; data could not be executed as "code" nor could somebody else's memory be accessed.
Should buffer overflows be prevented at the language level? Sure; it's easy in a language without dynamic allocations and doable in a language with dynamic allocations.
| [reply] |
|
|
Perl has a potential buffer overflow problem. So does C, and in my opinion, any language based on C.
Those are two different problems! C, on the language level, doesn't have a buffer overflow problem - it doesn't have anything to overrun. However, given the standard libraries, it's very easy to create programs written in C that have a buffer overflow problem.
In Perl, it's quite the opposite. It's very hard to write a program in Perl that has a buffer overflow problem - because Perl hides all the details that can lead to a buffer overflow problem for you. However, Perl needs perl to be able to run. And perl, being written in C, can suffer from a buffer overflow problem.
My major complaint with the line of thinking in this article -- that security should be built in at a fairly high level (and Perl is a high level language) -- is that it, by inference, absolves the O/S of responsibility for not permitting buffer overflows to cause problems. My experience on various flavors of MVS and VM was that any attempt by an application program to access memory outside of its data allocation resulted in immediate termination; data could not be executed as "code" nor could somebody else's memory be accessed.
Careful here. With languages like Perl, you cannot shift all the responsibility to the OS. Remember that for the OS, the entire Perl program is 'data'. Nothing of it is 'code', the only 'code' the OS knows is perl. With a language that runs on a VM, you can go wrong twice. You can have a buffer overflow in the implementation of the VM (as in the recently discovered bug) - here the OS could have a role in preventing exploits. However, the architecture of the VM itself may allow a buffer overflow, making it possible for an attacker to execute arbitrary code within the VM. It won't violate any rules the OS is upholding, but it can be as damaging to your system.
| [reply] |
|
|
I don't know the guts of the MVS or VM implementations of Perl. From my memory of working on these systems, I believe a Perl program would be run as a user process. As such, the user's Perl program would be data to the Perl interpreter, and the memory used to store the variables would be distinct from the memory used to store the instructions generated from the user's program. Both would be distinct from the perl interpreter, itself. Buffer overflow would almost certainly cause the user's process to be immediately aborted with the dreaded 0C4 error, which was, if I remember, not catchable: control would absolutely not be returned to the application.
added in update The VM to which I'm referring is IBM's mainframe OS.
| [reply] |