develooper Front page | perl.modules | Postings from August 2020

Re: Module::AutoLoad issues

Thread Previous | Thread Next
Joe McMahon
August 1, 2020 17:43
Re: Module::AutoLoad issues
Message ID:
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

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 <> wrote:

> >>>>> On Tue, 28 Jul 2020 21:08:11 -0600, Rob Brown <> 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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About