http://qs321.pair.com?node_id=573546

I have a short and hopefully thought-provoking (if not too overdone) Perl-related story to tell.

This summer I went to the HOPE conference in New York with some friends. One of these friends, Jason, gave a talk there. The night before the talk, we were loitering in a Starbucks. He was desperately preparing for his presentation, mostly by writing slides. Jason mentioned that he needed a quick script to generate MD5 hashes to use as part of a demonstration. Very shortly I wrote him something that ended up as this:

#!/usr/bin/perl use strict; use warnings; use Digest::MD5 qw(md5_hex); unless (@ARGV) { print "perl $0 hashme hashmetoo\n"; exit; } print $_, " = ", md5_hex($_), "\n" for @ARGV; print "\n"; print md5_hex($_), "\n" for @ARGV;
The second round of hash output was so he could conveniently paste into another application.

This is a simple task that was solved very easily, provided the right tools. Anyone with a slight knowledge of Perl and some concept of how to find and use relevant modules could accomplish this very quickly, as I did. Jason used the tool early in his talk, and then moved onto a direct lecture on technical details of his project. After his presentation he was approached by an employee of a certain well-known company that bills itself as the global leader in information security and availability. Among other items brought up, the drone asked for Jason to email him the program used to generate the hashes.

Do you, the Perl Monks community, agree that that is an unnecessary and humbling request? I would think that anyone who needs to ask an independent professional for such a petty tool would be an embarrassment to his company. He has certainly provided enough fodder for my jokes. There really is a lot to consider about the circumstance. Did the large company make a mistake in hiring him, or is he an average bear there? How exactly can he be expected to perform his duties as a security consultant (a title he signs his emails with)? Perhaps he is fluent in some programming languages, such as C (oh, the repetitive example!), and would consider the task of generating his own tool in that too difficult. If so, what does that say about the competitive advantage garnered by using a flexible language with a unified management and code repository?

Replies are listed 'Best First'.
Re: The Importance of Being Earnest
by Tanktalus (Canon) on Sep 18, 2006 at 14:15 UTC

    If you hadn't already posted his story here, I would have suggested that a better course of action would have been to tell the poor guy about this wonderful language with a superb code repository, and then point him at perlmonks to help him with the nitty gritty.

    Here, we don't know where anyone works - we're just helpful. Too bad we couldn't do likewise externally, but that's just life, I suppose. Anyway, we don't know that tye isn't working for a spammer or that Win isn't working for Google. We just are as helpful as we can, given the questions we get. So if this poor guy came upon us by some gentle prodding, he could learn exactly how simple this was and maybe stick around and learn more things he could do with perl. And then evangelise to his work group.

    Instead, you seem (to me) to be suggesting some sort of shunning. That seems very un-monk-like. After all, you didn't shun Jason!

Re: The Importance of Being Earnest
by radiantmatrix (Parson) on Sep 18, 2006 at 15:12 UTC

    There are a couple of considerations.

    Maybe, as others have suggested, he sensed a flaw and wanted to check out the code before making any embarrassing accusations.

    Maybe he was a *NIX guru, and was wondering if this was a program or a thin wrapper around md5sum. I know my first reaction was "why would you write software to do this when it has already been written and compiled for every major OS?".

    Maybe he liked the form of the output and thought "hey, I like that better than what I've been using for some reason".

    Maybe he's new to security and is going through the training period at his company. I know I've worked places where entry-level developers (with little or no training when hired) were "Application Consultants", so one shouldn't read much into the title.

    My point is simple: there is no way you have enough information to determine this person's level of competence or reasons for asking about the code. You certainly didn't seem to think your buddy Jason was incompetent when he asked you to write your tool...

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: The Importance of Being Earnest
by monarch (Priest) on Sep 18, 2006 at 15:36 UTC
    The only stupid question is the question that doesn't get asked.

    All of us have been lacking in our knowledge base - that's how we came to learn so much. This man may be placed in a job he wasn't qualified for, but how much he may have learnt in the last week following the receipt of the code you wrote!

    The most annoying people I find in business are those who are employed in a position they are not qualified for, and who don't ask the humbling questions in order to educate themselves into the role, out of fear for their ego.

    Let this man ask his question, and yes, you may smile briefly knowing that you already know the answer :)

Re: The Importance of Being Earnest
by Limbic~Region (Chancellor) on Sep 18, 2006 at 14:14 UTC
    zshzn,
    I believe you are leaving some context out of the story. Specifically, why the employee from security company X wanted the code in the first place. Either you are assuming that there is no other reason than incompetency or you have omitted the dialog that would lead you to that conclusion.

    While there could be any number of reasons why the security expert wanted the program, did you consider the possibility that the expert suspected a flaw and was being polite by not asking in front of everyone? This isn't the only possible reason but it is the first alternative that came to my mind.

    Cheers - L~R

Re: The Importance of Being Earnest
by jdporter (Paladin) on Sep 18, 2006 at 14:23 UTC
    Do you, the Perl Monks community, agree that that is an unnecessary and humbling request?

    No; and anyway, the Perl Monks community does not speak with a single voice.

    I think you're making a big deal out of nothing.

Re: The Importance of Being Earnest
by zshzn (Hermit) on Sep 18, 2006 at 19:04 UTC
    Thanks for your thoughtful responses. I fear my post may have come across as a bit too negative. I blame the pessimistic sleep-deprived mood I had at the time. I hoped to be more thought and conversation provoking than outright critical.

    Ultimately, we were kind. I did tell Jason I was fine with him giving out the script, and Jason in turn did go ahead and email the consultant and civilly discussed topics. I would not exactly call this shunning, Tanktalus, just judgement.

    Personally, I don't see where a flaw could be expected from the output of that program. From our interaction with the consultant our impression was that he simply wanted it to use it in the convenient manner that Jason did.

    jdporter, I am simply pondering, and although many questions are presented I'm not forming many answers.

    I am not very critical of Jason. Although he rarely uses Perl, he is competent with other languages. He asked me to help him out because he was pressed for time, and ultimately I tend to code solutions faster in Perl than he does in other languages regardless. There's a difference between that, and asking for it to be made because you can't do it yourself, although as the wise monks here point out that might not be the case.

      Actually, your program has a huge security hole. It relies on Perl's @INC to find Digest::MD5. You have no way of knowing, from your program, what you are actually executing. Without changing your code, an attacker can execute any code by either changing the installed Digest::MD5, putting a different Digest::MD5 somewhere that Perl will find it first, changing perl's @INC, or even replacing perl.

      Taint checking helps slightly by ignoring PERL5LIB, but it doesn't disable -I. Even then, a modified module in the usual @INC isn't caught, and no module in a modified @INC is caught.

      Security isn't a yes-or-no property. It's just a "how much work do I have to do to defeat it" judgement. Locks and safes are rated not on how much security they provide, but how long they can withstand a determined attack.

      If you don't know how to defeat your own program, you don't know enough about security. Your program might seem trivial, but if you are relying on it to verify file integrity, you've staked your security on it working correctly. You should know the various ways it can fail, and it appears that you don't.

      --
      brian d foy <brian@stonehenge.com>
      Subscribe to The Perl Review
        That's an unrealistic criticism. Of course I can defeat my own program with access on my own machine. With the level of access to do any of those things, I can also just change the code. The ability to do so doesn't make this program have a "huge security hole".

        Do you NOT rely on @INC to find modules, brian d foy? If someone has altered and replaced perl itself, then all programs, as you say, have a "huge security hole". At some point you have to have a measure of good faith in the system you're using, because ultimately you are relying on its integrity.

        This program does not verify file integrity. All it does is display hashes of strings. The only issue if they were wrong is an information mistake. Security is also about what you can lose. In this program, it isn't much.

        Some more concrete ways to defend against a malicious Digest::MD5 are to run checksums against the modules themselves, and to run a series of tests to make sure md5_hex() is acting accurately. Still vulnerable to the ever dangerous replaced perl attack, and the critical "attacker modifies your own code" attack.

Re: The Importance of Being Earnest
by dorko (Prior) on Sep 18, 2006 at 14:32 UTC
    I would have gladly emailed the code, with a link to Perl Monks; but yes, it would have bothered me a bit too.

    Cheers,

    Brent

    -- Yeah, I'm a Delt.
Re: The Importance of Being Earnest
by derby (Abbot) on Sep 18, 2006 at 15:14 UTC

    Slightly (just slightly) off-topic - check out NSRL. You're Your security expert should at least know about that site.

    -derby
Re: The Importance of Being Earnest
by brian_d_foy (Abbot) on Sep 19, 2006 at 07:08 UTC

    Do you normally make yourself feel better by making fun of other people? So what if a single person asked for the script? Security doesn't imply programming.

    I suppose we could be equally condescending to Jason for not being able to write it himself, or to you for having to write a script for something that's already a common tool.

    This really has nothing to do with Perl. C or other languages can do the task equally well. Perl shows none of its strengths in your example. You simply use a function defined in a library.

    I think you're an embarrasment to Perl in the same way you consider your victim an embarrasment to his company. It seems to me that you are just a mean person. Even if you did think he was as you say, that's still no reason for him to be the butt of your jokes, or a post here gloating over it.

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
      No, I don't feel better for making fun of people, and I don't in this case. It was funny, not ego-satisfying.

      As I stated above, Jason was completely capable of writing this himself. Additionally, md5sum isn't very useful here.

      The example shows how very quick it is to write something useful in Perl. C can do it equally well, and of course quicker, but it would have taken me longer to write just by time lost in installing an md5 implementation.

      I'm sorry you feel that way. I think you have overestimated the amount of negative intent in my post. It was not posted to gloat (I have nothing to gloat about in the scenario) nor just to criticize. It was posted to start a bit of interesting discussion here.

      I think, perhaps, I am an embarrassment in an entirely different way. Maybe I'm an embarrassment because of being "mean", although I do very kindly help many people learn and use Perl, for free, and almost never turn down a request for help, and those helpful attitudes usually extend beyond Perl. I was at least mean in a way not related to Perl directly. Perhaps this consultant was embarrassing to his company because he doesn't give the impression of them being capable and intelligent consultants as a whole, although, as repeatedly pointed out in this thread, impressions aren't everything.

      I think your two posts here suggest you are a mean person as well. They are no more provoked than I was, yet they are entirely critical, while my post posed questions and tried to start discussion on the topic. I'm sorry for offending or angering you.

      I think you're an embarrasment to Perl in the same way you consider your victim an embarrasment to his company. It seems to me that you are just a mean person.

      I decided not to vote on the above quote. But I'd like to make a comment on it anyway.

      Recently the Pope said something that, to some Muslims, was offensive. A few Muslims responded in a violent manner - including statements to the effect that those who insult the Muslim faith should suffer in some way.

      Any Muslim that made such extreme responses was, actually, insulting his own faith and therefore cursing himself.

      In this situation the original topic poster may have taken a question out of context by an employee of a security firm. But I would caution others to be careful about the possibility of taking the topic poster's post out of context, too, lest one points the finger back at himself unwittingly.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: The Importance of Being Earnest
by Khen1950fx (Canon) on Sep 23, 2006 at 11:33 UTC
    When I read your article, the first thing that came to mind was: What have I gotten myself into? I almost quit Perl. I don't have time for crap, and you wasted my time.

    You say that you weren't being negative and were a little taken aback by the responses. Here's a list of some of the words that you didn't intend to be negative:

    simple

    slight

    drone

    unneccessary

    humbling

    petty

    fodder

    embarrassment

    mistake

    average

    bear

    Sounds negative to me! I'm sorry, but I agree %100 with Brian, and I'm glad someone had the guts to speak out against what has to be the lamest discussion that I've ever read!