Re^2: The Importance of Being Earnest

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

Comment on Re^2: The Importance of Being Earnest Select or Download Code

Replies are listed 'Best First'.
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]


Problems? Is your data what you think it is?
	PerlMonks