Paranoia, NIH, and Beyond

Certainly, for myself at least, getting modules off of CPAN and installing them "blindly" is something that I do quite often. I don't develop on just one machine, so to keep things managable, I use the "cpan" program, which does exactly what I would do anyway. Examining the source code with a fine-toothed comb on every system is impractical, especially considering how many modules I might need on a given project.

Can you afford the time to check through CGI.pm every time you install it, examining it from top to bottom, looking for "evil" function calls? It's not like you're even going to see them either, as they could be mashed up in some unusual and deceptive format, the dark side of Obfuscated Perl, if you will.

It is true, though, that the possibility of a module as popular as CGI.pm becoming "infected" in this way is slim, it is still non-zero. Fortunately, there is an extremely high possibility that someone else in the Perl community will discover the problem before you do. Someone will take one for the herd, and the rest will survive.

I'm not working on some ultra-top secret military project where paranoia is not just a delusional fantasy, but a job requirement. In that case, I would certainly be curious about just what they are putting in the modules these days, and that is assuming I was bold enough to use "open-source" software in the first place.

The "ftp; tar xvzf; make; make install" routine, and its equivalent on other platforms, is generally accepted as "the way things are done" , at least in the UNIX/"open-source" community. Few question the nature of it on a fundamental level, at least to the extent that any real change is effected.

A non-intrusive, user-friendly, and low-impact addition to this methodology could be embraced, not only to extend the reach of Perl and other similar projects into a broader market, but to boost the confidence of the existing community in the quality and security of code that they are using.

Food for thought:

The CPAN system is about as "official" as you can get wrt. Perl modules, so any "effort" should be focused there. Consider something not altogether unlike what MS is doing with their "COM" objects:

CPAN signs all modules that it "publishes" to ensure that it it arrived on CPAN through proper channels and didn't just curiously appear.
All authors sign their modules with keys that are published through CPAN, or, better yet, a "trusted third-party" such as VeriSign or equivalent.
The modules are examined/tested by a group of trusted code reviewers and are signed only if they pass.

A program/module such as cpan could be extended to include some authentication capability which would allow the user to specify the level of "risk" they are willing to expose themselves to. That is, you would not be able to install untested modules, unsigned modules, or what have you, should you elect to be exceptionally paranoid.

Implementations could also be "paranoid", such as:

    use Module::Security qw(tested signed);    # Example name

    use CGI;

The more casual among us could merely opt out by installing anything anyway, just like they always do, without concern. The paranoid would avoid any unsigned modules, just like they always do, but at least they would be able to use Perl and a selection of its modules that are rigorously checked.

A system such as this could work, assuming Perl itself isn't part of some Illuminati-style global conspiracy.

Which it isn't.

Right?

Comment on Paranoia, NIH, and Beyond

Replies are listed 'Best First'.
Re: Paranoia, NIH, and Beyond by coreolyn (Parson) on Jan 10, 2001 at 19:08 UTC
Where I work security is a huge issue. What I've resolved must be done before CPAN modules can be used in this enviornment is to create an internal CPAN. Which will allow for several things: 1.) Keep track of who has what versions of which modules on what systems. This has several benefits; Internal points of contact for module usage, Back tracking should a security problem be discovered, revision history, and disaster recovery. 2.) Allows for new CPAN releases to 'cook' out in the world without forcing established applications to run on a new module version just because CPAN has released an upgrade and they moved to a new server. 3.) Centralizes perl user's and distribution, which provides internal avenues for problem resolution that is missing from the accepted practices of this organization. (Who does production call when a perl problem arises?) I'm not paranoid about CPAN, but I view it as an I.V. from which a large organization must design it's own needle. What you say about code review is very true, and no matter how important security is, the type of code review you speak of is impractical. But like Perl, it's capriciousness cannot be left completely unchecked except at ones own level of acceptable risk. coreolyn	[reply]
PerlDirect from ActiveState May Help by dave_aiello (Pilgrim) on Jan 10, 2001 at 21:43 UTC
Don't take what I am saying here as a recommendation, but, I know that ActiveState provides a service called PerlDirect which attempts to address some of these issues. From what I have heard, they do QA on Perl as well as popular modules and bundle them into a special, periodic distribution that is aimed at large corporations. I have recommended that this service be evaluated by one of my corporate clients, because they give integration testing tasks to people from a "UNIX Core Group" which knows a great deal more about the core of the Solaris operating system than it does Perl. In situations like the one I am describing, it is often up to the individual development teams to perform extensive unit testing on their finished products because the IT department only certifies the modules that are distributed with Perl itself. Needless to say, this is not an optimal solution. Dave Aiello Chatham Township Data Corporation	[reply]
(Signing modules) Re: Paranoia, NIH, and Beyond by Corion (Patriarch) on Jan 10, 2001 at 15:11 UTC
I really like the idea of having a built-in method of verifying the integrity of a module. This could "easily" be done by using a PGP/GPG-style mechanism or simply a built-in method of checking an appended IDEA (crypto-)hash of the source code and/or any XS used by the module. A really simple way would be to extend the `__DATA__` mechanism to also include a `__SIGNATURE__` section, which contains an (IDEA)(crypto-)hash of the source code, which can then be checked optionally by Perl against the code and (if available) against a local list of "trusted" keys. Of course, if that list of trusted keys is compromised, all security is down, but if that list can be compromised, bets are that everything else already has been as well. So, as I see it, a two-fold protection mechanism would need to be in place. One, a public/private key system with `CPAN` as a central repository for the public keys, so that everybody can check the authenticity of their modules, and a second, global public/private key, owned by `CPAN`, to check the integrity of every module locally at any time.	[reply]


go ahead... be a heretic
	PerlMonks