http://www.perlmonks.org?node_id=349910

I always figured that if there were a blatant security violation by a CPAN author, that I would be safe because someone would notice the problem before I got burned by it. That has indeed happened, and now you are being notified, also.

The nature of this security violation is that the module author executes arbitrary code on your computer. Anyone who can spoof the module owner's web server can also execute arbitrary code during the module installation.

The problem is in the Makefile.PL, which gets arbitrary code from the web server at perl.4pro.net and executes the code.

My strategy for installing perl modules is to never do so as root, and to never modify /usr/bin/perl. I think that this strategy has now been vindicated!

Here are modules with the problem:

To check if you have any of these modules, you can search your perl tree for the author name 'Domizio Demichelis'. Here is the current list on CPAN:

Update:A security fix has been proposed by the module author and should be available in a few days.

It should work perfectly the first time! - toma
  • Comment on Blatant security problem in certain CPAN module installs

Replies are listed 'Best First'.
Re: Blatant security problem in certain CPAN module installs
by Corion (Patriarch) on May 03, 2004 at 08:22 UTC

    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.

[reply]
      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

[reply]
        CPAN is not a site you can trust.

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

[reply]

      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

[reply]
[d/l]

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

[reply]
      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 :-)

[reply]
        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

[reply]

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

[reply]
[d/l]
[select]
      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.

      Humma la beeba la seeba la booba la
      Humma la beeba la seeba la bop
[reply]
Re: Blatant security problem in certain CPAN module installs
by perrin (Chancellor) on May 03, 2004 at 04:44 UTC
    Have you contacted the author and asked him to change this practice? He might be perfectly willing to do so if you point out the problem and ask him to fix it.
[reply]

      I did. Or at least I tried. His webform was throwing errors, so I ended up sending it to the email address given with the error message.

      Here is the text of the message that I sent to him:

      Hello,

      Earlier today I noticed that you have code in your Makefile.PLs that inclues and evals code served up from perl.4pro.com. While I am sure that you don't mean any harm in doing this, it nonetheless opens up several security holes.

      For example, if your site were to be cracked, the intruder could insert code that would be run by any person installing your module. and many people install perl modules as root.

      And then there is the issue of trust. How do I know that you are not changing the output of the file based on domain name of the person requesting the file? As a proof of concept, I wrote up a little script which illustrates my point:

      http://www.remotelinux.com/rlippan/irony.cgi
      And to see it in action: http://www.remotelinux.com/rlippan/irony

      If you are not comming from 4pro.net, You can add domains to the list of evil_domains by passing in ?evil_domain=domain.dom

      Thank you for your time,

      Rudolf Lippan.
[reply]
Re: Blatant security problem in certain CPAN module installs
by Abigail-II (Bishop) on May 03, 2004 at 13:14 UTC
    My strategy for installing perl modules is to never do so as root, and to never modify /usr/bin/perl. I think that this strategy has now been vindicated!
    You know, the danger doesn't lie during the perl Makefile.PL && make && make test && make install phase. It's easy to set up a perl-admin user and install perl, and perl modules, under that UID. Sure, the user can wipe out the Perl installation, but that's reasonable quickly restored. The danger lies when the installed modules actually get used - then they might run as priviledged users, users that have access to valuable data or services, or whatever.

    Of course, that's a well known problem, and not at all Perl specific.

    Abigail

[reply]
      I would agree that there is danger during the install and after the install. I don't agree that there is not an increased danger during the install if you are installing modules as root or modifying the version of perl that root uses.

      My primary concern is about attacks that are easy to automate, difficult to detect, and provide root access. So I don't install modules for root to use unless they have been reviewed.

      It is more difficult to exploit the capabilities of other users. Network usage, as sporty points out, is an example. This is relatively easy to detect, though.

      The only data that I can think of that would be accessible to non-root, consistent between machines, and valuable would be found in ms systems. I don't have very high expectations for security in the ms environment, though.

      It should work perfectly the first time! - toma
[reply]
        I don't agree that there is not an increased danger during the install if you are installing modules as root or modifying the version of perl that root uses.
        That sounds obvious, until you rephrase it as "it's gives more security if you install modules as a non-root user". Sure, it might matter if no UID that can cause havoc ever runs the code of the modules installed, but if so, what would be the point of installing them? My point is that the danger doesn't stop that "make install", it's isn't that you can relax if you get a prompt back after typing "make install". That's only when trouble starts.

        The dangerous part of opening a lion cage isn't the act of opening the door - the danger only starts when the lion gets out of the cage.

        Abigail

[reply]
[reply]
Re: Blatant security problem in certain CPAN module installs
by ysth (Canon) on May 03, 2004 at 06:23 UTC
    Thanks for the alert.

    Not sure what the point is of checking if these modules are installed; does the Makefile.PL-fetched code get injected into them or just run at once?

[reply]

      I think the point of checking is that you can't know what code was run when the module was installed (it could have installed a backdoor, whatever). And for some people that is an unacceptable risk, and they will want to know whether they installed any of the above modules, so that they make take appropriate action.

      The Makefile.PL-fetched code gets called only once at the end of the make (assuming that it is the only place the code is called).

[reply]
Re: Blatant security problem in certain CPAN module installs
by runrig (Abbot) on May 03, 2004 at 20:51 UTC
    E.g., this is what is fetched and then eval'd for CGI-Builder:
    #
#
   ; print << "EOS"
I hope you will appreciate CGI::Builder 1.2.
If you have any problem with this installation,
please report it at http:://perl.4pro.net
EOS
#

    [download]
    The eval seems completely unnecessary, it seems like he could just as easily fetch just the message itself, and then print it from Makefile.PL instead of using eval.
[reply]
[d/l]
Module reviews are beneficial
by zby (Vicar) on May 04, 2004 at 10:32 UTC
    I've tried to write about that problem in the CPAN reviews of those modules - but it seems that those modules are removed from CPAN. Is that a result of this discussion?

    By the way I'd like to encourage people to write more reviews on CPAN and report such problems there. It is not very flexible mechanism - but it is the most central and most people searching for the module will see it (if only they click on the bottom not the upper link on the CPAN search engine). There was started a wiki for module reviews and I believe this would be an ideal way of discussing them - but unfortunately after Iain Truskett died it seems to be discontinued.

    2004-05-05 Edit by jdporter: Changed title from 'Reviews'

[reply]
[reply]
Re: Blatant security problem in certain CPAN module installs
by Anonymous Monk on May 03, 2004 at 07:55 UTC
    I never install modules of Domizio Demichelis. To me just seem stupid or sometimes there are betters already. The Makefile.PL is super stupid. How install module off network? Stupid!
[reply]

Back to Meditations