Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Attack on Perl or Perl's need better PR (again)

by wazoox (Prior)
on Nov 30, 2005 at 17:10 UTC ( #513001=perlmeditation: print w/replies, xml ) Need Help??

Brothers Monks, I just saw this article on C|Net: Danger level rises for Perl app flaws and my blood's boiling. Webmin is insecure (how useful it can be, we all know it's a huge pile of perl4-style insecure crap), a new webmin flaw arose, and what can we see in one of the most prominent news site? Perl is insecure. Argh!

I know journalists (or web-wannabe-journalists) to be clueless, but this one is too much for me to stand. How can we respond to such attacks against our language and community ? I'm still waiting for "Java is insecure" or "C# stinks" on C|Net!

update: according to http://www.webmin.com/security.html, the bug is already corrected anyway. Where are the headlines?

update 2: There is a nasty Perl bug. However, is there any evidence that it presents a major security flaw for some applications around ?

update 3: it seems so at last : Searching for sprintf() bug exploit opportunities in core and CPAN modules

  • Comment on Attack on Perl or Perl's need better PR (again)

Replies are listed 'Best First'.
Re: Attack on Perl or Perl's need better PR (again)
by merlyn (Sage) on Nov 30, 2005 at 17:13 UTC
    Here's what I just wrote for a web-security mailing list that pointed at that article:
    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.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      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

      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"

        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

      A reply falls below the community's threshold of quality. You may see it by logging in.
      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
Re: Attack on Perl or Perl's need better PR (again)
by Ovid (Cardinal) on Nov 30, 2005 at 19:26 UTC

    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).

    Cheers,
    Ovid

    New address of my CGI Course.

      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.

Re: Attack on Perl or Perl's need better PR (again)
by rinceWind (Monsignor) on Nov 30, 2005 at 17:23 UTC

    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.

    --

    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)

      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.

Re: Attack on Perl or Perl's need better PR (again)
by tbone1 (Monsignor) on Nov 30, 2005 at 18:45 UTC
    Don't expect "C# Stinks" from C|Net. Until recently, everything was spun to pro-MS. And I agree with you about journalists, particularly pseudo-journalists. I went to college with the top journalism school in the nation, and the journalism majors were the worst poker players: too stupid to calculate and too easy to bluff. From such timber is the house of journalism made.

    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."

    --
    tbone1, YAPS (Yet Another Perl Schlub)
    And remember, if he succeeds, so what.
    - Chick McGee

Re: Attack on Perl or Perl's need better PR (again)
by Tanktalus (Canon) on Nov 30, 2005 at 19:57 UTC

    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. ;-)

Re: Attack on Perl or Perl's need better PR (again)
by Perl Mouse (Chaplain) on Dec 01, 2005 at 02:11 UTC
    The current consensus on p5p seems to be that there are buffer overrun issues in Perl. And while those are not exactly the same as the webmin bug, they are certainly related. (It's a buffer overrun when using sprintf formats using "%<LARGE_NUMBER>d").

    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.

    Perl --((8:>*

      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:>*
Re: Attack on Perl or Perl's need better PR (again)
by shiza (Hermit) on Nov 30, 2005 at 21:09 UTC
    In my opinion, Webmin is a bad idea anyway and is an obvious target due to its purpose. It's an unnecessary application (if you have competent sys admins) and flaws will be found in applications of its nature, regardless of what language it's written in.

    I understand why people are attracted to it, but they need to understand it's another doorway into their systems. The less doors you have, the less you have to secure.
      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!

Re: Attack on Perl or Perl's need better PR (again)
by Perl Mouse (Chaplain) on Dec 01, 2005 at 00:00 UTC
    I know journalists (or web-wannabe-journalists) to be clueless, but this one is too much for me to stand.
    Man, the web is filled with FUD, clueless stories, wonders, crap and blogs. This time, it's an unfounded claim that Perl is insecure, tomorrow it's a story that now we have PUGS, perl6 will be out before Christmas, and yesterday it was about nanobots taking over.

    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?
    An attack against our language and community? Get a life. This isn't Risk.
    Perl --((8:>*
Re: Attack on Perl or Perl's need better PR (again)
by ysth (Canon) on Dec 02, 2005 at 13:53 UTC
    FWIW, someone involved in finding the perl vulnerability filed a bug report about 3 weeks ago asking where to non-publicly report such vulnerabilities. The p5p hive mind responded with conflicting messages (which it seems he never even got.)

    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.

Report on exploitable code in perl 5.8.7
by diotalevi (Canon) on Dec 02, 2005 at 06:30 UTC
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://513001]
Approved by dorward
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (2)
As of 2020-08-06 22:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Which rocket would you take to Mars?










    Results (43 votes). Check out past polls.

    Notices?