Re: [onap-tsc] Known vulnerability analysis of CLI

[Kanagaraj Manickam]

Thanks Amy. I updated the wiki with reference to this discussion.


Regards
Kanagaraj M
-
Be transparent! Win together !!

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!


From: ZWARICO, AMY [mailto:az9...@att.com]
Sent: Thursday, April 05, 2018 12:07 AM
To: Kanagaraj Manickam
Cc: onap-sec...@lists.onap.org; onap-tsc
Subject: RE: [onap-tsc] Known vulnerability analysis of CLI

Thank you for the update. Please update the vulnerability analysis for CLI at 
(https://wiki.onap.org/pages/viewpage.action?pageId=28377287)
 with this information.

From: Kanagaraj Manickam [mailto:kanagaraj.manic...@huawei.com]
Sent: Monday, April 02, 2018 2:07 AM
To: ZWARICO, AMY mailto:az9...@att.com>>
Cc: onap-sec...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: RE: [onap-tsc] Known vulnerability analysis of CLI

Hi Amy,

Pls find my answers inline and let me know if additional details required. 
Thanks


Regards
Kanagaraj M
-
Be transparent! Win together !!

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!

From: ZWARICO, AMY [mailto:az9...@att.com]
Sent: Saturday, March 31, 2018 11:34 PM
To: Kanagaraj Manickam
Cc: onap-sec...@lists.onap.org; onap-tsc
Subject: [onap-tsc] Known vulnerability analysis of CLI

Hi Kanagaraj,
I was reviewing the CLI known vulnerability analysis – thank-you for providing 
that 
(https://wiki.onap.org/pages/viewpage.action?pageId=28377287)

1.   You stated that the use of the commons-codec library in commons-codec 
is a False Positive because it is not a direct dependency and is caused via 3rd 
party library dependency.

• How did you test this in CLI?

[Kanagaraj M]  This library is used by http-client, which is used at the 
back-end of cli project. As part of the build, this is being iterated when 
cli-vlidation project validates all Beijing clis.

• What package is using commons-codec?

[Kanagaraj M] dependency libaray: httpclient 4.3.5

Used by: cli-validation artifact



• Is there a version of this package that uses the most recent version 
of commons-codec (1.11 released in 2017)? Version 1.6 of commons-codec was 
released in 2011.

[Kanagaraj M] Yes, but CLI does not directly use this library.



2.   The CVE for jline 1.8 indicates that the vulnerability is in hawtjni.

• How did you test that 
hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java  is 
not used in jline?

[Kanagaraj M] Jline is 3rd party library used in CLI at the console access 
level where no programming level access is possible. And For attacker, they 
need access /tmp for this vulnerability. In ONAP, we provide the console level 
access over the browser, where there is no possibility for accessing the file 
system .
.
Thanks so much,
Amy

​Amy Zwarico, LMTS
Chief Security Office / Enterprise Security Support / Cloud Security Services
AT&T Services
(205) 403-2241

"This e-mail and any files transmitted with it are the property of AT&T,  and 
are intended solely for the use of the individual or entity to whom this e-mail 
is addressed. If you are not one of the named recipient(s) or otherwise have 
reason to believe that you have received this message in error, please notify 
the sender and delete 

Re: [onap-tsc] TSC Composition Proposal

[GILBERT, MAZIN E (MAZIN E)]

Chris, Steve,

Thanks for drafting a proposal together. Let me share some thoughts following 
the board meeting last week.

1. A number of board members (vendors, suppliers and operators) are concerned 
that we are changing the TSC too soon at this early stage of ONAP.
Although not everyone voted for the June decision, we should proceed with the 
change over, but do it well and smoothly to ensure successful outcome.
I would suggest changing the TSC and Chair for June. All other leadership roles 
should change after Casablanca. Some projects and PTLs already
started Casablanca work and we should avoid disruptions.

2. I am supportive of simplicity and self-nomination. With exceptions.
a. 50% of the TSC must come from operators. Operators must sign and commit.
b. We have over 60 members in ONAP already. We can afford to have 1 member per 
company to ensure diversity.
c. Who qualifies to vote is complex. Just include all active members on the 
technical email list. LF can remove inactive ones.

It is fine bringing this subject up at the TSC meeting tomorrow, but the deeper 
discussion should happen in calls that Phil has been holding before
bringing the proposal to finalize and approve to the TSC.

Mazin






On Apr 4, 2018, at 4:58 PM, Christopher Donley (Chris) 
mailto:christopher.don...@huawei.com>> wrote:

Dear TSC,

Steve Terrill and I have put together a proposal to transition the TSC to its 
“steady state” by June 30, as required in the ONAP Technical Charter.  We have 
tried to incorporate feedback from previous TSC discussions on this topic, and 
are proposing a structure that encourages diversity of companies and roles, 
while recognizing contributions in the community and interested operators who 
may have joined later, but who want to take an active role in ONAP.  See 
attached.

Under our proposal, the TSC will be composed of 15 elected representatives, 
with a cap of no more than two people per company.  Anyone who is interested 
may run for a seat on the TSC.  Voters in the election will consist of people 
who have been active in the community over the previous six month period, as 
demonstrated by one or more of {code contributions, code reviews, lira ticket 
submissions, readthedocs, wiki (pages or file uploads), or subcommittee 
leadership}.

We are interested in feedback on our proposal (including community feedback), 
and would like to discuss this on tomorrow’s TSC call.

Thanks,
Chris & Steve


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=axGeWi3euUr4yk1LBh9N_ZBJjJ98efJ7xfk4c3pl8L0&s=qklC5R9PpmwnqtFhR1ZC8W3cEnvFpCeIkI4Xi1GP-2s&e=

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Composition Proposal

[Jason Hunt]

Thanks, Chris & Steve for the proposal.  A couple quick 
comments/clarifications:

- Should Eligible Voter Criteria also be Eligible TSC Candidate Criteria? 
The previous slide just says candidates have to come from the ONAP 
Community, but not clear what that definition is.

- How often will TSC elections be held?  I ask because the Eligible Voter 
Criteria is limited to previous 6 months of activity.

- Do you think that wiki/file contribution will capture all the active 
subcommittee members?

- It might be good to outline how the 2 members/company will be enforced. 
I assume it would be the top 2 Condorcet vote recipients from each 
company?

Thanks again.

Regards,
Jason Hunt 
Executive Software Architect, IBM 

Phone: 314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt
 



From:   "Haiby, Ranny (Nokia - US/San Jose)" 
To: "Christopher Donley (Chris)" , 
"onap-tsc@lists.onap.org" 
Date:   04/04/2018 04:47 PM
Subject:Re: [onap-tsc] TSC Composition Proposal
Sent by:onap-tsc-boun...@lists.onap.org



Chris and Steve,
 
Thanks for the time and effort put into this proposal.
 
One thing I do not see in the proposal is explanation of the “Support 
operators with high interest in ONAP (regardless of development resources 
involved) to be active in the TSC” item from the first slide. Reading the 
next slides it seems that only active contributors will be able to vote, 
so there is no guarantee operators who did not contribute yet will get a 
seat at the TSC. Would you care to elaborate on this please?
 
Thanks,
 
Ranny.
 
 
From: onap-tsc-boun...@lists.onap.org  On 
Behalf Of Christopher Donley (Chris)
Sent: Wednesday, April 4, 2018 1:58 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] TSC Composition Proposal
 
Dear TSC,
 
Steve Terrill and I have put together a proposal to transition the TSC to 
its “steady state” by June 30, as required in the ONAP Technical Charter. 
We have tried to incorporate feedback from previous TSC discussions on 
this topic, and are proposing a structure that encourages diversity of 
companies and roles, while recognizing contributions in the community and 
interested operators who may have joined later, but who want to take an 
active role in ONAP.  See attached.
 
Under our proposal, the TSC will be composed of 15 elected 
representatives, with a cap of no more than two people per company. Anyone 
who is interested may run for a seat on the TSC.  Voters in the election 
will consist of people who have been active in the community over the 
previous six month period, as demonstrated by one or more of {code 
contributions, code reviews, lira ticket submissions, readthedocs, wiki 
(pages or file uploads), or subcommittee leadership}.
 
We are interested in feedback on our proposal (including community 
feedback), and would like to discuss this on tomorrow’s TSC call.
 
Thanks,
Chris & Steve
 
 ___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=oMOO2HmZ8JJWvUc1M7SklmdX3xn2mSb9tP9VrdTjcqg&m=ImgDY7IpkfCme0DgSOggR5cKrCJbgfdXBRcKpytqQhY&s=-hsupv7_zmNWoVHmKyrWff8tsuDacsO-0vlKeUBWL54&e=





___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-discuss] Action Plan towards Casablanca => ONAP introduction course

[Dhananjay Pavgi]

Thanks, Eric. Yes, this is foundational course from Linux Foundation. In 
addition, we have devised advanced ONAP training courses.

Other than this formative educational thread; we discussed about webinars to 
broad base ONAP knowledge. Have also written to ONAP-TSC email alias. Seek help 
and ideas.

PS. - Plan to announce first webinar of the series on Wednesday, 18th April. 
Please send your list of topic/s, speakers and proposed date. Suggest, we run 
these webinars on Wednesday. Basis # of topics; we can decide frequency.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of eric.deb...@orange.com
Sent: Wednesday, April 4, 2018 5:49 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] [onap-discuss] Action Plan towards Casablanca => ONAP 
introduction course

Hello
A very good EdX course on ONAP introduction "Introduction to ONAP: Complete 
Network Automation" 
https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS163x+1T2018/course/
After reminding some basic NFV concepts, the course explains ONAP, the 
architecture, the main components and the use-case overview.
A very good introduction for beginners with a large number of cool quizzes.


A first answer for the topic "3. Broader learning and education of ONAP."

Best Regards

Eric


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.


Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html 
 externally 
http://tim.techmahindra.com/tim/disclaimer.html 
 internally within 
TechMahindra.


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] [onap-discuss] Action Plan towards Casablanca => ONAP introduction course

[eric.debeau]

Hello
A very good EdX course on ONAP introduction "Introduction to ONAP: Complete 
Network Automation" 
https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS163x+1T2018/course/
After reminding some basic NFV concepts, the course explains ONAP, the 
architecture, the main components and the use-case overview.
A very good introduction for beginners with a large number of cool quizzes.


A first answer for the topic "3. Broader learning and education of ONAP."

Best Regards

Eric


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Composition Proposal

[Haiby, Ranny (Nokia - US/San Jose)]

Chris and Steve,

Thanks for the time and effort put into this proposal.

One thing I do not see in the proposal is explanation of the “Support operators 
with high interest in ONAP (regardless of development resources involved) to be 
active in the TSC” item from the first slide. Reading the next slides it seems 
that only active contributors will be able to vote, so there is no guarantee 
operators who did not contribute yet will get a seat at the TSC. Would you care 
to elaborate on this please?

Thanks,

Ranny.


From: onap-tsc-boun...@lists.onap.org  On 
Behalf Of Christopher Donley (Chris)
Sent: Wednesday, April 4, 2018 1:58 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] TSC Composition Proposal

Dear TSC,

Steve Terrill and I have put together a proposal to transition the TSC to its 
“steady state” by June 30, as required in the ONAP Technical Charter.  We have 
tried to incorporate feedback from previous TSC discussions on this topic, and 
are proposing a structure that encourages diversity of companies and roles, 
while recognizing contributions in the community and interested operators who 
may have joined later, but who want to take an active role in ONAP.  See 
attached.

Under our proposal, the TSC will be composed of 15 elected representatives, 
with a cap of no more than two people per company.  Anyone who is interested 
may run for a seat on the TSC.  Voters in the election will consist of people 
who have been active in the community over the previous six month period, as 
demonstrated by one or more of {code contributions, code reviews, lira ticket 
submissions, readthedocs, wiki (pages or file uploads), or subcommittee 
leadership}.

We are interested in feedback on our proposal (including community feedback), 
and would like to discuss this on tomorrow’s TSC call.

Thanks,
Chris & Steve


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Known vulnerability analysis of Portal

[Stephen Terrill]

Thank-you Manoop.  Could you please update the template accordingly.  Best 
Regards,  Steve.

From: TALASILA, MANOOP (MANOOP) [mailto:talas...@research.att.com]
Sent: Wednesday, April 04, 2018 9:20 PM
To: Stephen Terrill 
Cc: onap-sec...@lists.onap.org; onap-tsc ; 
TATTAVARADA, SUNDER (SUNDER) ; MIR, FARHAN N (FARHAN) 
; FAZAL, ABBAS M (ABBAS) 
Subject: Re: Known vulnerability analysis of Portal

Hi Steve,

Please find the responses in-line for Portal. I also updated the wiki page with 
the below details. Thanks.

Manoop

From: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>
Date: Friday, March 30, 2018 at 4:01 PM
To: "TALASILA, MANOOP (MANOOP)" 
mailto:talas...@research.att.com>>
Cc: "onap-sec...@lists.onap.org" 
mailto:onap-sec...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: Known vulnerability analysis of Portal

Hi Manoop,

I was reviewing the portal known vulnerability analysis – thank-you for 
providing that 
(https://wiki.onap.org/pages/viewpage.action?pageId=27689089
).  It is indicated that there are some changes that cannot be done due to the 
impact (change of all screens).  This lead to a few questions:

  *   Did you analyse the impact of the vulnerability if it was exploted? Is 
there a work-around in our code to avoid the use of it?
Analysis: Yes we did analyze the vulnerability, from our analysis the 
vulnerability cannot be exploited because the portal application follows the 
below design recommendations provided by nexus-iq report.
Recommendation by nexus-iq for this vulnerability (SONATYPE-2016-0064):
It's best to design your application in such a way that users cannot change 
client-side templates.
· Do not mix client and server templates
· Do not use user input to generate templates dynamically
· Do not run user input through $scope.$eval (or any of the other 
expression parsing functions listed above)
· Consider using {@link ng.directive:ngCsp CSP} (but don't rely only on 
CSP)
Action: In following releases, we are planning to upgrade to the latest angular 
versions to address this vulnerability.

  *   Regarding Jackson mapper, are you using it in such a way it in such a way 
that it exposes the vulnerabilities (see: 
https://wiki.onap.org/pages/viewpage.action?pageId=25439016).
Analysis: This vulnerability is not exposed from the portal’s code, because

  1.  The portal does not pass any untrusted data for deserialization, as there 
is XSS/XSRF validation enabled in the portal’s backend code.
  2.  and the default typing (ObjectMapper.setDefaultTyping()) is not called as 
we use concrete java types.
  3.  and we use Spring Security 4.2.3 as recommended in the nexus-iq report.



BR,

Steve.

[mage removed by sender. 
Ericsson]

STEPHEN TERRILL
Technology Specialist
POA Architecture and Solutions
Business Unit Digital Services

Ericsson
Ericsson R&D Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[mage removed by sender. 
http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

_

Re: [onap-tsc] Known vulnerability analysis of Portal

[TALASILA, MANOOP (MANOOP)]

Hi Steve,

Please find the responses in-line for Portal. I also updated the wiki page with 
the below details. Thanks.

Manoop

From: Stephen Terrill 
Date: Friday, March 30, 2018 at 4:01 PM
To: "TALASILA, MANOOP (MANOOP)" 
Cc: "onap-sec...@lists.onap.org" , onap-tsc 

Subject: Known vulnerability analysis of Portal

Hi Manoop,

I was reviewing the portal known vulnerability analysis – thank-you for 
providing that 
(https://wiki.onap.org/pages/viewpage.action?pageId=27689089
).  It is indicated that there are some changes that cannot be done due to the 
impact (change of all screens).  This lead to a few questions:
-  Did you analyse the impact of the vulnerability if it was exploted? 
Is there a work-around in our code to avoid the use of it?
Analysis: Yes we did analyze the vulnerability, from our analysis the 
vulnerability cannot be exploited because the portal application follows the 
below design recommendations provided by nexus-iq report.
Recommendation by nexus-iq for this vulnerability (SONATYPE-2016-0064):
It's best to design your application in such a way that users cannot change 
client-side templates.
· Do not mix client and server templates
· Do not use user input to generate templates dynamically
· Do not run user input through $scope.$eval (or any of the other 
expression parsing functions listed above)
· Consider using {@link ng.directive:ngCsp CSP} (but don't rely only on 
CSP)
Action: In following releases, we are planning to upgrade to the latest angular 
versions to address this vulnerability.
-  Regarding Jackson mapper, are you using it in such a way it in such 
a way that it exposes the vulnerabilities (see: 
https://wiki.onap.org/pages/viewpage.action?pageId=25439016).
Analysis: This vulnerability is not exposed from the portal’s code, because

1.   The portal does not pass any untrusted data for deserialization, as 
there is XSS/XSRF validation enabled in the portal’s backend code.

2.   and the default typing (ObjectMapper.setDefaultTyping()) is not called 
as we use concrete java types.

3.   and we use Spring Security 4.2.3 as recommended in the nexus-iq report.



BR,

Steve.

[mage removed by sender. 
Ericsson]


STEPHEN TERRILL
Technology Specialist
POA Architecture and Solutions
Business Unit Digital Services

Ericsson
Ericsson R&D Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[mage removed by sender. 
http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] ONAP Vulnerability Report - VF-C

[ZWARICO, AMY]

Thank you for the information. Please update the vulnerability analysis in the 
wiki (https://wiki.onap.org/pages/viewpage.action?pageId=25437810) with this 
information.
Thank you, Amy

From: Yan Yang [mailto:yangya...@chinamobile.com]
Sent: Tuesday, April 03, 2018 3:05 AM
To: ZWARICO, AMY 
Cc: 'onap-tsc' ; onap-sec...@lists.onap.org
Subject: 答复: ONAP Vulnerability Report - VF-C

Hi Amy,

Please see my response to your question below

Best Regards,
Yan
发件人: ZWARICO, AMY [mailto:az9...@att.com]
发送时间: 2018年4月1日 3:28
收件人: yangya...@chinamobile.com
抄送: onap-tsc; onap-sec...@lists.onap.org
主题: ONAP Vulnerability Report - VF-C

Hi Yan,
I was reviewing the Usecase-UI known vulnerability analysis – thank-you for 
providing that 
(https://wiki.onap.org/pages/viewpage.action?pageId=25437810)

1.   Is VF-C using the vulnerable component(s) in commons-httpclient?

[Yan]VF-C code don’t use the readRawLine() method in commons-httpclient 
directly. We plan to replace this jar with Apache HttpComponents, but need some 
time to update the code and test.

2.   Is VF-C using the vulnerable component(s) in jackson-mapper-asl?

   [Yan] We don’t use Jackson directly and don’t use 
createBeanDeserializer() function which has the vulnerability. We were unable 
to find any reference to this Vulnerability

3.   Is VF-C using the vulnerable component(s) in xercesImpl?

   [Yan]  About the xercesImpl security issue, we have replaced it 
with new version and this issue have been solved.

Thanks so much,
Amy

​Amy Zwarico, LMTS
Chief Security Office / Enterprise Security Support / Cloud Security Services
AT&T Services
(205) 403-2241

"This e-mail and any files transmitted with it are the property of AT&T,  and 
are intended solely for the use of the individual or entity to whom this e-mail 
is addressed. If you are not one of the named recipient(s) or otherwise have 
reason to believe that you have received this message in error, please notify 
the sender and delete this message immediately from your electronic device. Any 
other use, retention, dissemination, forwarding, printing, or copying of this 
e-mail is strictly prohibited."




___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Known vulnerability analysis of CLI

[ZWARICO, AMY]

Thank you for the update. Please update the vulnerability analysis for CLI at 
(https://wiki.onap.org/pages/viewpage.action?pageId=28377287)
 with this information.

From: Kanagaraj Manickam [mailto:kanagaraj.manic...@huawei.com]
Sent: Monday, April 02, 2018 2:07 AM
To: ZWARICO, AMY 
Cc: onap-sec...@lists.onap.org; onap-tsc 
Subject: RE: [onap-tsc] Known vulnerability analysis of CLI

Hi Amy,

Pls find my answers inline and let me know if additional details required. 
Thanks


Regards
Kanagaraj M
-
Be transparent! Win together !!

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!

From: ZWARICO, AMY [mailto:az9...@att.com]
Sent: Saturday, March 31, 2018 11:34 PM
To: Kanagaraj Manickam
Cc: onap-sec...@lists.onap.org; onap-tsc
Subject: [onap-tsc] Known vulnerability analysis of CLI

Hi Kanagaraj,
I was reviewing the CLI known vulnerability analysis – thank-you for providing 
that 
(https://wiki.onap.org/pages/viewpage.action?pageId=28377287)

1.   You stated that the use of the commons-codec library in commons-codec 
is a False Positive because it is not a direct dependency and is caused via 3rd 
party library dependency.

• How did you test this in CLI?

[Kanagaraj M]  This library is used by http-client, which is used at the 
back-end of cli project. As part of the build, this is being iterated when 
cli-vlidation project validates all Beijing clis.

• What package is using commons-codec?

[Kanagaraj M] dependency libaray: httpclient 4.3.5

Used by: cli-validation artifact



• Is there a version of this package that uses the most recent version 
of commons-codec (1.11 released in 2017)? Version 1.6 of commons-codec was 
released in 2011.

[Kanagaraj M] Yes, but CLI does not directly use this library.



2.   The CVE for jline 1.8 indicates that the vulnerability is in hawtjni.

• How did you test that 
hawtjni-runtime/src/main/java/org/fusesource/hawtjni/runtime/Library.java  is 
not used in jline?

[Kanagaraj M] Jline is 3rd party library used in CLI at the console access 
level where no programming level access is possible. And For attacker, they 
need access /tmp for this vulnerability. In ONAP, we provide the console level 
access over the browser, where there is no possibility for accessing the file 
system .
.
Thanks so much,
Amy

​Amy Zwarico, LMTS
Chief Security Office / Enterprise Security Support / Cloud Security Services
AT&T Services
(205) 403-2241

"This e-mail and any files transmitted with it are the property of AT&T,  and 
are intended solely for the use of the individual or entity to whom this e-mail 
is addressed. If you are not one of the named recipient(s) or otherwise have 
reason to believe that you have received this message in error, please notify 
the sender and delete this message immediately from your electronic device. Any 
other use, retention, dissemination, forwarding, printing, or copying of this 
e-mail is strictly prohibited."


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Known vulnerability analysis of AAF

[Gildas Lanilis]

Hi Jonathan, All Milestones dates for Beijing are available here 
https://wiki.onap.org/display/DW/Release+Planning

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GATHMAN, JONATHAN C
Sent: Tuesday, April 03, 2018 7:33 AM
To: Stephen Terrill 
Cc: onap-sec...@lists.onap.org; GANDHAM, SAI ; KOYA, RAMPRASAD 
; onap-tsc 
Subject: Re: [onap-tsc] Known vulnerability analysis of AAF

Hey Steve,
  When are the dates for RC0,RC1 (If you have a calendar link, I don’t have 
that)?

  My current efforts are
1)  Sonar to report AAF accurately (what is left is getting “Coverage” 
numbers… we had some improvement just this morning… nice to have headway)
2)  Getting the AAF Beijing release working in Winriver VMs.
3)  Getting the best Cassandra,J2EE and Mailer versions that 
eliminate/limit Security issues from dependent libraries.

  When those are working, I’ll be able to swing around and see what we can do 
on those other elements.

  Do you happen to know if anybody else uses Bouncey Castle, and if there are 
better versions out there without the security issues?  That might be a good 
approach.

  In terms of Vulnerability, Bouncey Castle is used exclusively to help 
facilitate Certificate Creation. (AAF Certman).  It is not in any of the 
Service, GUI, Locate, etc components.


--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management

AT&T Services, Inc.
2349 Oaker, Arnold, MO 63010
m  314-550-3312  |  
jonathan.gath...@us.att.com

From: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>
Date: Tuesday, April 3, 2018 at 9:26 AM
To: "GATHMAN, JONATHAN C" mailto:jg1...@att.com>>
Cc: "onap-sec...@lists.onap.org" 
mailto:onap-sec...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>, RAMPRASAD KOYA 
mailto:rk5...@att.com>>, "GANDHAM, SAI" 
mailto:sg4...@att.com>>, "ZWARICO, AMY" 
mailto:az9...@att.com>>
Subject: RE: Known vulnerability analysis of AAF

Hi Jonathan,

Thanks for the reply.  It would be good to know:
-  Do you think that this will be done by RC0, RC1….?
-  If it turns out you can’t replace the version, it would be good to 
what exposure ONAP has to the vulnerability.  Sometimes it turns out ONAP is 
not exposed due to the way that ONAP uses the components.

BR,

Steve

From: GATHMAN, JONATHAN C [mailto:jg1...@att.com]
Sent: Tuesday, April 03, 2018 2:53 AM
To: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>
Cc: onap-sec...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>; KOYA, RAMPRASAD 
mailto:rk5...@att.com>>; GANDHAM, SAI 
mailto:sg4...@att.com>>; ZWARICO, AMY 
mailto:az9...@att.com>>
Subject: Re: Known vulnerability analysis of AAF

Hi Steve,
  We are using “BounceyCastle” for part of the CA work.  I will have to look 
into whether I can remove easily.

  Io.netty and org.apache.httpcomponents are derived dependencies from 
Cassandra.  I’m making inquiries as to what Cassandra Versions we can use to 
get free of License issues as well as whatever flaws you have noted.

--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management

AT&T Services, Inc.
2349 Oaker, Arnold, MO 63010
m  314-550-3312  |  
jonathan.gath...@us.att.com

From: RAMPRASAD KOYA mailto:rk5...@att.com>>
Date: Monday, April 2, 2018 at 5:39 PM
To: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>, "GATHMAN, 
JONATHAN C" mailto:jg1...@att.com>>, "GANDHAM, SAI" 
mailto:sg4...@att.com>>
Cc: "onap-sec...@lists.onap.org" 
mailto:onap-sec...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: RE: Known vulnerability analysis of AAF

Sai, Jonathan – Any thoughts on this?

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Monday, April 02, 2018 2:59 AM
To: KOYA, RAMPRASAD mailto:rk5...@att.com>>
Cc: onap-sec...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: Known vulnerability analysis of AAF

Hi Ram,

Thanks for the review of the known vulnerabilities for AAF: 
https://wiki.onap.org/pages/viewpage.action?pageId=28380057

I note that the actions are still work in progress – do you have an estimated 
time for the analysis.  In the analysis, it would be great if you consider 
whether the way that AAF uses the imported artefacts to be clear on whether AAF 
is exposed to the vulnerability.

Best Regards,

Steve

[Image removed by sender. 
Ericsson]

Re: [onap-tsc] Known vulnerability analysis of AAF

[GATHMAN, JONATHAN C]

Hey Steve,
  When are the dates for RC0,RC1 (If you have a calendar link, I don’t have 
that)?

  My current efforts are

  1.  Sonar to report AAF accurately (what is left is getting “Coverage” 
numbers… we had some improvement just this morning… nice to have headway)
  2.  Getting the AAF Beijing release working in Winriver VMs.
  3.  Getting the best Cassandra,J2EE and Mailer versions that eliminate/limit 
Security issues from dependent libraries.

  When those are working, I’ll be able to swing around and see what we can do 
on those other elements.

  Do you happen to know if anybody else uses Bouncey Castle, and if there are 
better versions out there without the security issues?  That might be a good 
approach.

  In terms of Vulnerability, Bouncey Castle is used exclusively to help 
facilitate Certificate Creation. (AAF Certman).  It is not in any of the 
Service, GUI, Locate, etc components.


--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management

AT&T Services, Inc.
2349 Oaker, Arnold, MO 63010
m  314-550-3312  |  
jonathan.gath...@us.att.com

From: Stephen Terrill 
Date: Tuesday, April 3, 2018 at 9:26 AM
To: "GATHMAN, JONATHAN C" 
Cc: "onap-sec...@lists.onap.org" , onap-tsc 
, RAMPRASAD KOYA , "GANDHAM, SAI" 
, "ZWARICO, AMY" 
Subject: RE: Known vulnerability analysis of AAF

Hi Jonathan,

Thanks for the reply.  It would be good to know:

  *   Do you think that this will be done by RC0, RC1….?
  *   If it turns out you can’t replace the version, it would be good to what 
exposure ONAP has to the vulnerability.  Sometimes it turns out ONAP is not 
exposed due to the way that ONAP uses the components.

BR,

Steve

From: GATHMAN, JONATHAN C [mailto:jg1...@att.com]
Sent: Tuesday, April 03, 2018 2:53 AM
To: Stephen Terrill 
Cc: onap-sec...@lists.onap.org; onap-tsc ; KOYA, 
RAMPRASAD ; GANDHAM, SAI ; ZWARICO, AMY 

Subject: Re: Known vulnerability analysis of AAF

Hi Steve,
  We are using “BounceyCastle” for part of the CA work.  I will have to look 
into whether I can remove easily.

  Io.netty and org.apache.httpcomponents are derived dependencies from 
Cassandra.  I’m making inquiries as to what Cassandra Versions we can use to 
get free of License issues as well as whatever flaws you have noted.

--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management

AT&T Services, Inc.
2349 Oaker, Arnold, MO 63010
m  314-550-3312  |  
jonathan.gath...@us.att.com

From: RAMPRASAD KOYA mailto:rk5...@att.com>>
Date: Monday, April 2, 2018 at 5:39 PM
To: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>, "GATHMAN, 
JONATHAN C" mailto:jg1...@att.com>>, "GANDHAM, SAI" 
mailto:sg4...@att.com>>
Cc: "onap-sec...@lists.onap.org" 
mailto:onap-sec...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: RE: Known vulnerability analysis of AAF

Sai, Jonathan – Any thoughts on this?

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Monday, April 02, 2018 2:59 AM
To: KOYA, RAMPRASAD mailto:rk5...@att.com>>
Cc: onap-sec...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: Known vulnerability analysis of AAF

Hi Ram,

Thanks for the review of the known vulnerabilities for AAF: 
https://wiki.onap.org/pages/viewpage.action?pageId=28380057

I note that the actions are still work in progress – do you have an estimated 
time for the analysis.  In the analysis, it would be great if you consider 
whether the way that AAF uses the imported artefacts to be clear on whether AAF 
is exposed to the vulnerability.

Best Regards,

Steve

[Image removed by sender. 
Ericsson]
STEPHEN TERRILL
Technology Specialist
POA Architecture and Solutions
Business Unit Digital Services

Ericsson
Ericsson R&D Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[Image removed by sender. 
http://www.ericsson.com/current_campaign]

Re: [onap-tsc] Known vulnerability analysis of AAF

[GATHMAN, JONATHAN C]

Hi Steve,
  We are using “BounceyCastle” for part of the CA work.  I will have to look 
into whether I can remove easily.

  Io.netty and org.apache.httpcomponents are derived dependencies from 
Cassandra.  I’m making inquiries as to what Cassandra Versions we can use to 
get free of License issues as well as whatever flaws you have noted.

--
Jonathan Gathman
Principled-System Architect
ATO Tech Dev/SEAT/Platform Architecture and Technology Management

AT&T Services, Inc.
2349 Oaker, Arnold, MO 63010
m  314-550-3312  |  
jonathan.gath...@us.att.com

From: RAMPRASAD KOYA 
Date: Monday, April 2, 2018 at 5:39 PM
To: Stephen Terrill , "GATHMAN, JONATHAN C" 
, "GANDHAM, SAI" 
Cc: "onap-sec...@lists.onap.org" , onap-tsc 

Subject: RE: Known vulnerability analysis of AAF

Sai, Jonathan – Any thoughts on this?

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Monday, April 02, 2018 2:59 AM
To: KOYA, RAMPRASAD 
Cc: onap-sec...@lists.onap.org; onap-tsc 
Subject: Known vulnerability analysis of AAF

Hi Ram,

Thanks for the review of the known vulnerabilities for AAF: 
https://wiki.onap.org/pages/viewpage.action?pageId=28380057

I note that the actions are still work in progress – do you have an estimated 
time for the analysis.  In the analysis, it would be great if you consider 
whether the way that AAF uses the imported artefacts to be clear on whether AAF 
is exposed to the vulnerability.

Best Regards,

Steve

[Image removed by sender. 
Ericsson]
STEPHEN TERRILL
Technology Specialist
POA Architecture and Solutions
Business Unit Digital Services

Ericsson
Ericsson R&D Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[Image removed by sender. 
http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Review of SDC known vulnerability Analysis

[Stephen Terrill]

Hi Dan,

Thank-you for the clarification.  When going over the status of my review with 
the security sub-committee I received a question that made me realize that I 
couldn’t quite answer, so I have a follow-up question.

The sdnc-oam is in gerrit so it is downloadable, however from the description 
below it is not included in SDNC when it is instantiated with OOM – is that 
correct?

Could any of the vulnerabilities allow malicious code to be created as an 
output of the dgbuilder and find their way into SDNC as part of a DG?  The 
vulnerabilities that subject dgbuilder to DDoS wouldn’t but potential malicious 
code insertion could ….

BR,

Steve



From: TIMONEY, DAN [mailto:dt5...@att.com]
Sent: Monday, April 02, 2018 7:13 PM
To: Stephen Terrill 
Cc: onap-sec...@lists.onap.org; onap-tsc 
Subject: Re: Review of SDC known vulnerability Analysis

Steve,

The dgbuilder is a design time tool.  We use it to create and update the 
directed graphs, which then get stored in Gerrit and managed from there as 
source code.

Eventually we’d like to support using the dgbuilder as an editor integrated 
with SDC at run time to update and deploy new versions of directed graphs – 
especially to allow rapid deployment of patches.  However, in its current form, 
dgbuilder is really only appropriate as a design time tool.

Dan

--
Dan Timoney
SDN-CP / OpenECOMP SDN-C SSO

Please go to  D2 ECOMP Release Planning 
Wiki for 
D2 ECOMP Project In-take, 2016 Release Planning, Change Management, and find 
key Release Planning Contact Information.

From: Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>
Date: Monday, April 2, 2018 at 3:45 AM
To: "TIMONEY, DAN" mailto:dt5...@att.com>>
Cc: "onap-sec...@lists.onap.org" 
mailto:onap-sec...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: Review of SDC known vulnerability Analysis

Hi Dan,

Thank-you for the report on the SDC known vulernabilities - 
https://wiki.onap.org/pages/viewpage.action?pageId=28379582
 .

For most of the impacts it states that low risk – only occurs in design tool 
(dgbuilder).  How is this tool used by SDNC?  Is it used in the runtime 
environment, or can it be called in the run-time environment?

Best Regards,

Steve


[Ericsson]

STEPHEN TERRILL
Technology Specialist
POA Architecture and Solutions
Business Unit Digital Services

Ericsson
Ericsson R&D Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc