Re: The Importance of Being Earnest

in reply to The Importance of Being Earnest

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.

Comment on Re: The Importance of Being Earnest

Replies are listed 'Best First'.
Re^2: The Importance of Being Earnest by brian_d_foy (Abbot) on Sep 19, 2006 at 19:42 UTC
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	[reply] [d/l] [select]
Re^3: The Importance of Being Earnest by zshzn (Hermit) on Sep 19, 2006 at 19:59 UTC
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.	[reply]
Re^4: The Importance of Being Earnest by radiantmatrix (Parson) on Sep 22, 2006 at 16:22 UTC
If someone has altered and replaced perl itself, then all programs, as you say, have a "huge security hole". Dude, that was kind of his point. Any application which has dependencies has, as a potential security risk, malicious or accidental alteration of those dependencies. Fortunately, since you weren't using the MD5 for anything (except to display it), your particular implementation doesn't represent a significant risk; the point is, you can't ever say "it has no security holes". On a side note, one of my clients uses a digest (Digest::SHA-256, in this case) for file integrity checking. As an extra layer of security, files with known digests are fed to the production tool, and its output is checked against a separate implementation of the algorithm (on an off-network machine): if ever they fail to match, the box will be marked compromised and rebuilt. <–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	[reply]

In Section Meditations