Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Blatant security problem in certain CPAN module installs

by Corion (Pope)
on May 03, 2004 at 08:22 UTC ( #349959=note: print w/ replies, xml ) Need Help??


in reply to Blatant security problem in certain CPAN module installs

I'm facing a similar problem with my crackpot idea of Alien:: modules, which is why I haven't released them onto CPAN.

My modules (Alien::JavaScript::SpiderMonkey and Alien::MP3::ID3Lib) download and build other Perl modules that rely on third party libraries, like id3lib, the SpiderMonkey javascript engine or other stuff, and since the installation is intended to be completely automatic, they download the libraries and execute code to build them, all from the web. This makes these modules completely unsuitable for an unprotected upload to CPAN, as all CPAN testers will then unknowingly download code from the web that is not on the CPAN - a bad situation indeed.

I haven't found a good way to detect whether my Alien Makefile.PL is run by a CPAN tester instead of a real installation, so I can't skip/fail the download for them - any suggestions are welcome.

For the general solution to prevent CPAN-spawned processes from accessing the web, maybe setting $ENV{HTTP_PROXY} to a local proxy program written with HTTP::Proxy would be a good filter - that proxy should then only allow access to your list of CPAN mirrors, as configured in CPAN::Config.

Of course, a malicious script can still reset $ENV{HTTP_PROXY} and try to access the network directly, and I'm not sure whether it's possible to restrict network access for a single (unix) user to localhost, or better, 127.0.0.2.

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.


Comment on Re: Blatant security problem in certain CPAN module installs
Re: Re: Blatant security problem in certain CPAN module installs
by exussum0 (Vicar) on May 03, 2004 at 11:32 UTC
    You run the same risk with freebsd's /usr/ports, rpm's and deb's, java web start and active x, that you download from various places.

    Update: b10m asked me about md5's and /usr/ports. Just because you have an md5 of an archive doesn't mean someone won't do something evil on the Makefile in the downloaded archive or 9 functions level deep in the actual program. We all trust each other (in the world) to different degrees, which takes time.

Re^2: Blatant security problem in certain CPAN module installs
by adrianh (Chancellor) on May 03, 2004 at 12:59 UTC
    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 :-)

      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.

      . . . 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.

Re: Re: Blatant security problem in certain CPAN module installs
by hardburn (Abbot) on May 03, 2004 at 13:17 UTC

    This makes these modules completely unsuitable for an unprotected upload to CPAN, as all CPAN testers will then unknowingly download code from the web that is not on the CPAN - a bad situation indeed.

    Instead of a full-blown distribution up on CPAN, why not produce a "stub distribution"? It could simply contain the POD and a Makefile.PL/Build.PL that prints out a message saying "this module is just a stub, and the full distro has such and such problems, so get it from this web site if you're still interested". This means that users can still discover the module on CPAN (with full documentation), the namespace is obviously taken for anyone checking, and users of CPAN.pm/CPANPLUS.pm are fully informed of the potential problems of using the module.

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

    Note: All code is untested, unless otherwise stated

      That would be an idea... I'm still of two minds about this, as the modules are simply convenience modules that automate the download and build of modules that rely on third party source code.

      The idea is mostly that I have these modules in my Bundle::Corion so an upgrade to a new Perl version becomes less painfull for me. An installation from CPAN becomes thus unlikely for me, as these modules are already modules in my "default" installation. But for other people, this could be an alternative to the PPM route when the PPM is not yet available...

Re: Blatant security problem in certain CPAN module installs
by Abigail-II (Bishop) on May 03, 2004 at 13:54 UTC
    This makes these modules completely unsuitable for an unprotected upload to CPAN, as all CPAN testers will then unknowingly download code from the web that is not on the CPAN - a bad situation indeed.
    Don't get the thought that if the code is from CPAN, it's secure. It isn't. CPAN is not a site you can trust. The fallacy in this idea is that you treat CPAN as if it were a single site whose owner you can trust. But CPAN is a collection of hundreds of mirror sites, with no central control. How would you know that the mirror you download a module from doesn't give you software that installs a backdoor? "Thousands of eyes" wouldn't help you there - even if there are lots of people doing CPAN code audit checks, a malicious CPAN mirror might give you backdoor software based on your IP address.

    Abigail

      CPAN is not a site you can trust.

      Yet CPAN is often the first thing a Perl advocate trumpets.

        CPAN is not a site you can trust.
        Yet CPAN is often the first thing a Perl advocate trumpets.
        Trumpets by advocates don't create security.

        Just because something isn't secure doesn't mean it can't be useful. CPAN is nothing more than an archive - and an archive with no control. CPAN is made by people. Good coders. Bad coders. Trustworthy coders. Malicious coders. PAUSE is an equal opportunity CPAN portal. Anyone can upload anything. This is CPAN's power. This is also what makes it dangerous. (Just like a motorsaw. Powerful, but dangerous). People should be well aware of the risks. Education is their only safety net.

        Abigail

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (10)
As of 2014-11-24 12:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (141 votes), past polls