Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Re^2: Blatant security problem in certain CPAN module installs

by adrianh (Chancellor)
on May 03, 2004 at 12:59 UTC ( #349991=note: print w/ replies, xml ) Need Help??


in reply to Re: Blatant security problem in certain CPAN module installs
in thread Blatant security problem in certain CPAN module installs

Still, even with these precautions, the make install step has the possibility of wrecking havoc to your existing Perl installation, and even if your Perl installation is not your system Perl installation, it's not really safe to blindly install modules from CPAN.

True, but at least with modules with a SIGNATURE we have some vague notion of accountability. Modules that download other code from third parties are when it gets scary for me.

Maybe a nice approach with the Alien:: modules would be for the user to specify trusted sources (sunfreeware.com, fink, etc.) for the third party software. So you would have a CPANesque configuration mode that would allow me to say something like "I'll trust anything available in the stable fink section, otherwise ask me".

Of course - much more work for you :-)


Comment on Re^2: Blatant security problem in certain CPAN module installs
Re: Blatant security problem in certain CPAN module installs
by Abigail-II (Bishop) on May 03, 2004 at 13:07 UTC
    True, but at least with modules with a SIGNATURE we have some vague notion of accountability.
    Modules that download other code from third parties are when it gets scary for me.
    The SIGNATURE is basically only used to verify there are no transmit errors. Using it for any form of verification or accountability only gives one a false sense of security, which is worse than no sense of security, IMO.
    Modules that download other code from third parties are when it gets scary for me.
    Any module that has a pre-requisite causes CPAN.pm to download more code, if you have configured CPAN to do so, or if you blindly say "yes" when it asks.

    Let's face it - downloading code, any code, from CPAN is potentially dangerous. You're only safe if you have inspected the code yourself, and didn't make a mistake in your inspection. Of course, just inspecting the code you just downloaded doesn't make you safe. When was the first time you audited the source code of perl? How do you know that doesn't have a backdoor? What about your C compiler?

    Abigail

      The SIGNATURE is basically only used to verify there are no transmit errors. Using it for any form of verification or accountability only gives one a false sense of security, which is worse than no sense of security, IMO.

      It's a little bit more than just a hash. We know that the person who signed it had access to the private key of the individual involved.

      I trust code signed by chromatic's private key more than I would trust arbitrary code because I trust chromatic as a Perl author, I trust that the private key that the code was signed with belongs to chromatic, and I think that he guards his public key well.

      Is this absolute 100% accurate verification/accountability, no. Is it better than just a hash, yes.

      Any module that has a pre-requisite causes CPAN.pm to download more code, if you have configured CPAN to do so, or if you blindly say "yes" when it asks.

      Which is why I don't have my CPAN (PLUS in my case) configured in that way. However, if I did it would have been my choice to make.

      The point that I was trying to make was that CPAN modules than download and install stuff off their own back should ask first as a matter of policy - not that there is any way to enforce this.

      Let's face it - downloading code, any code, from CPAN is potentially dangerous. You're only safe if you have inspected the code yourself, and didn't make a mistake in your inspection. Of course, just inspecting the code you just downloaded doesn't make you safe. When was the first time you audited the source code of perl? How do you know that doesn't have a backdoor? What about your C compiler?

      Yes of course. As Gene Spafford says:

      The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

      So instead we have to (hopefully in an intelligent manner) weigh risks and benefits.

      downloading code, any code, from CPAN is potentially dangerous

      I think that if you remove some parts, it's still true: downloading code, any code, from CPAN is potentially dangerous.

      You can't trust code unless you assess it yourself or trust that other people you trust have done so.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      The SIGNATURE is basically only used to verify there are no transmit errors. Using it for any form of verification or accountability only gives one a false sense of security, which is worse than no sense of security, IMO.
      That argument gets tossed around a lot and it's simply not true. The SIGNATURE file is used to ensure that the person who uploaded a file is one whom you trust. PGP is not MD5.
Re: Re^2: Blatant security problem in certain CPAN module installs
by hardburn (Abbot) on May 03, 2004 at 13:27 UTC

    . . . at least with modules with a SIGNATURE we have some vague notion of accountability.

    To add to what Abigail-II said, SIGNATURE files are not currently a good security system. As things stand now, it is unlikely that you have a sufficient web-of-trust to verify the author's key. It is thus very easy for man-in-the-middle attacks to work. Further, a lot of people don't check the signature until the automatic installation method has already done it for them (usually via a 001_signature.t test). This means the code has already started running by the time the signature is checked.

    Right now, SIGNATURE files are only good as replacements for MD5 digests for verifying that the distribution is intact. IMHO, MD5 was already a perfectly good way to verify distribution integrity, so I don't see an argument for using SIGNATURE instead. (MD5 has its problems for use in cryptographic applications, but that doesn't mean it can't be used for integrity checks. If you're still worried, SHA1 can be used instead, which should still be faster than signature checking.)

    ----
    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      To add to what Abigail-II said, SIGNATURE files are not currently a good security system. As things stand now, it is unlikely that you have a sufficient web-of-trust to verify the author's key. It is thus very easy for man-in-the-middle attacks to work.

      They're certainly not as good a mechanism as they could be with more support for them in the infrastructure - but I'd still argue they're an improvement over straight hashes.

      Further, a lot of people don't check the signature until the automatic installation method has already done it for them (usually via a 001_signature.t test). This means the code has already started running by the time the signature is checked.

      And that's foolish on their part. I don't do that.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (10)
As of 2014-12-19 22:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (93 votes), past polls