A followup: Adding a requirement that the environment variable I_AM_USING_A_DANGEROUS_MODULE_AND_I_AM_WILLING_TO_RISK_MY_COMPANY_AND_JOB_ON_IT must be set to a true value would be another acceptable safety solution if you insist this module can't be moved.
On Wed, Jul 29, 2020 at 1:01 PM Joe McMahon <joe.mcma...@gmail.com> wrote: > Andreas, I hope you don't think I'm out of line here, but I'm putting on > my security hat from when I was working with WhiteHat and making a comment > about the overall design of the module and specifically about the test > suite. > > Rob, I'm sure that functionally speaking this module is well-meant, but > time and again, we warn people about "curl | bash" as an outstandingly > boneheaded thing to do. One should never simply execute something that > happens to be at the far end of a URL that one does not control, and that > is generally accessible on the Internet, and hope everything will be okay. > > But the reason that this module was pulled earlier was not that it does > this -- though I would argue that even the basic idea of implementing a > security vulnerability as a module is a terrible idea -- it was pulled > because of all the following: > - the test suite accesses a site the installer does not control without > warning them this will happen > - it obscures the site being used > - the code being downloaded is not the minimum possible needed to ensure > that the test passes > - the code being downloaded is deliberately obfuscated to make it > difficult for the installer to vet it for safety > - worst, the code that it currently downloads appears to be malware. > (side note: it *does not matter* if it isn't! The fact that it is not > blindingly obvious is in itself highly suspect). > > The combination of all these is not only unsafe but outright dangerous. > Rob, it's possible that you didn't know this.I'll totally give you the > benefit of the doubt. But if you didn't know that you've been sending out > something that you didn't intend -- well, you've got a mighty fine argument > as to why this module is dangerous. If you did, I question the lack of > transparency. There is absolutely no need to obfuscate this code if this is > simply for a test. > > Consider: if you (Rob) lose control of the site that the test suite uses, > or someone gains access to it without your knowledge, every installer who > reruns the test suite is potentially a victim of any number of attacks - > let's say ransomware, for starters. > > Even if you changed what it's loading to a cleartext dummy "hey look I got > installed" module, you'd still be weakening the security of every > installation that used this module to be only as good as your security is. > Are you prepared to take on that level of responsibility for every random > yahoo who uses Perl and decides this module is a good idea? Even if you > think you are, I do not think this is a good idea. > > I would think that from a legal standpoint you might be on very shaky > ground if there was a successful breakin vectored through your site, and > that CPAN, or Andreas, or the Perl Foundation, might also find themselves > in legal hot water if a court decided that leaving this in place was > negligent. That is playing with fire that we do not need to do. > > My personal opinion is that this module is a potential Trojan and should > be removed, period. > > If it is to be allowed to stay, at a minimum, it should be moved to the > Acme namespace to make it plain that this module is not meant for > production. Its current naming obscures that fact. > > In addition, it needs a huge disclaimer at the top of the POD that > stresses that this module deliberately implements remote code execution, > and that this is inherently dangerous. There should also be a big banner > during CPAN install that says this. > > Last, the test suite must be rewritten to use a `file:` URL or to run a > localhost-only HTTP server which loads unobfuscated, minimal code that > verifies the operation of the module. The linking out to the obfuscated > site and loading of obfuscated code must be removed completely, and the old > versions that did this must be removed. > > In my opinion, this module is dangerous, so much so that it is not > salvageable without some very serious rewriting. If it is meant to load > CPAN modules then it should only be able to do that; a generalized remote > code execution framework is a ridiculously bad idea and should not be > permitted on an official site. > > A footgun that the responsibility of the user to police is one thing. A > footgun that we deliver loaded, with ammunition that might suddenly be > something extremely dangerous, and actually fire during *the test suite* is > wildly inappropriate -- and I for one do not want it to be something > someone potentially ends up in court about. > > On Tue, Jul 28, 2020 at 11:50 PM Andreas Koenig < > andreas.koenig.7os6v...@franz.ak.mind.de> wrote: > >> >>>>> On Tue, 28 Jul 2020 21:08:11 -0600, Rob Brown <b...@cpan.org> said: >> >> > Hey Andreas, >> > I'm getting hounded with complaints about my Module::AutoLoad suddenly >> > not working [...] >> >> Hi Rob, >> >> first of all, please accept my apologies. I was intending to write to >> you immediately, but then got distracted and found the open case again a >> bit late. >> >> I've now brought Module-AutoLoad-0.06.tar.gz back to your directory and >> made your account active again. But the module is not indexed anymore. I >> hope this works for you. >> >> As a way forward I'm leaning to suggest something that protects your >> fellow CPAN users from accidentally running into it again and/or >> something that reduces the potential to get people nervous and maybe >> also reduces the amount of required hacking when things go wrong next >> time. >> >> I think whatever meets such criteria should be good enough. I'm thinking >> of something like a disclaimer like when you sell a heating you're >> required to tell the customer that they have to be careful because the >> device gets hot when deployed. Otherwise *they* get a chance to ruin >> *your* day. In other words, better err on the side of caution. >> >> Sorry for the late answer and I hope this all now works again both for >> you and the rest of the community for at least the next ten years. >> >> Greetings from Berlin, >> -- >> andreas >> >
