[
https://issues.apache.org/jira/browse/VCL-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845351#comment-16845351
]
Andy Kurth commented on VCL-1121:
---------------------------------
I looked through install_perl_libs.pl. The section that installs EPEL contains
a hard-coded http:// link that gets inserted into the yum .repo file. This
won't be a problem. I rewrote the EPEL installation code to install the .rpm
using the current https:// URL.
The CPAN code and its usage in general is more of a problem. I'm not sure how
secure CPAN is in general. It only provides http:// and ftp:// mirrors. It
supports signature checking, but I found this 2016 article that describes some
deficiencies:
[https://www.anishathalye.com/2016/08/21/validity-trust-and-the-design-of-interfaces/]
I think the best course of action would be to eliminate the use of CPAN and
only rely on OS packages released by an official source -- Red Hat, CentOS, or
EPEL.
I looked at the modules that are attempted to be installed via CPAN. There are
a few that are included as core Perl modules going all the way back to 5.8. I
believe these can be eliminated without any problems:
* *CPAN* (listed in install_perl_libs.pl, a core module but can be eliminated)
* *Scalar::Util*
* *Term::ANSIColor*
* *Time::HiRes*
* *Net::Ping::External* (Net:Ping includes this)
There are a few modules that have corresponding packages available via the
_base_ yum repositories for CentOS 6 and 7. I assume these are also available
on Red Hat. They are:
* *DBI* (perl-DBI.noarch, already included)
* *Digest::SHA1* (perl-Digest-SHA1.noarch, already included)
* *URI* (perl-URI.noarch, _*not*_ already included)
* *YAML* (perl-YAML.noarch, already included)
There is 1 module available from EPEL only _(not base)_ for CentOS 6 and 7:
* *Net::SSH::Expect* (perl-Net-SSH-Expect.noarch, already included)
The rest need some more investigating:
* *Mail::Mailer* - This could possible be eliminated. There's a
perl-MailTools.noarch available in the yum base repo for CentOS 6 and 7. I'm
not positive if it includes Mail::Mailer. If not, there are several email
options that could be used from yum packages.
* *Frontier::Client* - This is used in one.pm which provides support for
OpenNebula. I'm not sure if this is being kept up to date. If so, there's a
perl-Frontier-RPC-Client.noarch package available from EPEL for 6 and 7. I'm
not sure if they are the same or some work would need to be done.
* *LWP::Protocol::https* - This may be alright for el7 as there's a
perl-LWP-Protocol-https.noarch available in yum base. It's a problem for el6.
There is no corresponding package AFAIK. We could discontinue el6 support in
the next release.
* *Object::InsideOut* - This may be alright for el7 as there's a
perl-Object-InsideOut.noarch available in EPEL for el7. There's no package
available for el6. This could be eliminated. DataStructure.pm currently relies
on it but it isn't needed. I regret using it many years ago.
* *Net::SSH::Expect* - This may be alright for el6 only as there's a
perl-Net-SSH-Expect available in the el6 EPEL repo. There is no such package
for el7. This is somewhat of a problem but not huge. The feature that relies on
this to maintain a persistent SSH connection isn't enabled by default.
* *Mo::builder* - This isn't available as a package AFAIK. I'm not sure if
it's needed. I don't see any references to it anywhere.
> Review all non-HTTPS dependency URLs
> ------------------------------------
>
> Key: VCL-1121
> URL: https://issues.apache.org/jira/browse/VCL-1121
> Project: VCL
> Issue Type: Task
> Components: database, vcld (backend), web gui (frontend)
> Affects Versions: 2.5
> Reporter: Andy Kurth
> Priority: Major
>
> See the email sent by the Apache Security Team below. We need to review all
> non-HTTPS URLs used in various places.
> One location I know has non-HTTPS URLs is
> *managementnode/bin/install_perl_libs.pl*. It references an EPEL
> *_mirrorlist_* and a CPAN *_urllist_* by http. I could imagine how these
> could be used in a MITM attack. I'm not sure if an HTTPS alternative exists
> for these and don't know if these can be changed. The email only says to
> "_fix them asap_", but gives no guidance for things that don't have an
> alternative.
> *install_perl_libs.pl* is only provided as an example. We need to do an
> exhaustive check and are required to report back by May 31, 2019.
> {noformat}
> Created at: Tue, May 21, 2019 at 7:29 AM (Delivered after 53 seconds)
> From: Apache Security Team <[[email protected]>
> Subject: PRIORITY Action required: Security review for non-https dependency
> urls
> ASF Security received a report that a number of Apache projects have
> build dependencies downloaded using insecure urls. The reporter states
> this could be used in conjunction with a man-in-the-middle attack to
> compromise project builds. The reporter claims this a significant
> issue and will be making an announcement on June 10th and a number of
> press releases and industry reaction is expected.
> We have already contacted each of the projects the reporter detected.
> However we have not run any scanning ourselves to identify any other
> instances hence this email.
> We request that you review any build scripts and configurations for
> insecure urls where appropriate to your projects, fix them asap, and
> report back if you had to change anything to [email protected] by
> the 31st May 2019.
> The most common finding was HTTP references to repos like maven.org in
> build files (Gradle, Maven, SBT, or other tools). Here is an example
> showing repositories being used with http urls that should be changed
> to https:
> https://github.com/apache/flink/blob/d1542e9561c6235feb902c9c6d781ba416b8f784/pom.xml#L1017-L1038
> Note that searching for http:// might not be enough, look for http\://
> too due to escaping.
> Although this issue is public on June 10th, please make fixes to
> insecure urls immediately. Also note that some repos will be moving
> to blocking http transfers in June and later:
> https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/
> The reporter claims that a full audit of affected projects is required
> to ensure builds were not made with tampered dependencies, and that
> CVE names should be given to each project, however we are not
> requiring this – we believe it’s more likely a third party repo could
> be compromised with a malicious build than a MITM attack. If you
> disagree, let us know. Projects like Lucene do checksum whitelists of
> all their build dependencies, and you may wish to consider that as a
> protection against threats beyond just MITM.
> Best Regards,
> Mark J Cox
> VP, ASF Security Team{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
