[ 
https://issues.apache.org/jira/browse/VCL-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Kurth updated VCL-1121:
----------------------------
    Description: 
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.

 

??Created at: Tue, May 21, 2019 at 7:29 AM (Delivered after 53 seconds)??
??From: Apache Security Team?? <[secur...@apache.org>
|mailto:secur...@apache.org]??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 
[secur...@apache.org|mailto:secur...@apache.org] by??
 ??the 31st May 2019.??

??The most common finding was HTTP references to repos like 
[maven.org|http://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??

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

 

_*??Created at: Tue, May 21, 2019 at 7:29 AM (Delivered after 53 seconds)??*_
 _*??From: Apache Security Team <secur...@apache.org>??*_
_*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 
[secur...@apache.org|mailto:secur...@apache.org] by??
 ??the 31st May 2019.??

??The most common finding was HTTP references to repos like 
[maven.org|http://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??


> 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.
>  
> ??Created at: Tue, May 21, 2019 at 7:29 AM (Delivered after 53 seconds)??
> ??From: Apache Security Team?? <[secur...@apache.org>
> |mailto:secur...@apache.org]??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 
> [secur...@apache.org|mailto:secur...@apache.org] by??
>  ??the 31st May 2019.??
> ??The most common finding was HTTP references to repos like 
> [maven.org|http://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??



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to