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

Re: Module::AutoLoad issues

Thread Previous | Thread Next
From:
Joe McMahon
Date:
August 1, 2020 17:44
Subject:
Re: Module::AutoLoad issues
Message ID:
CAHxkc3TKj27FN+80d75EyX5_sZayNpx2xMoXjpo53Vfp-EMYXw@mail.gmail.com
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.mcmahon@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.7os6VVqR@franz.ak.mind.de> wrote:
>
>> >>>>> On Tue, 28 Jul 2020 21:08:11 -0600, Rob Brown <bbb@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
>>
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About