Re: [EXTERNAL] Re: Vulnerabilities in Transitive dependencies

2023-05-02 Thread Robert Bradshaw via user
Generally these types of vulnerabilities are only exploitable when
processing untrusted data and/or exposing a public service to the
internet. This is not the typical use of Beam (especially the latter),
but that's not to say Beam can't be used in this way. That being said,
it's preferable to simply update libraries rather than have to do this
kind of analysis. On that note, +1 to the removal of Avro from core as
a mitigation for this vulnerability, though that's sometimes easier
said than done.

On Tue, May 2, 2023 at 7:35 AM Brule, Joshua L. (Josh), CISSP via user
 wrote:
>
> The SnakeYAML analysis is exactly what I was looking for. The library of 
> concern is org.codehaus.jackson jackson-mapper-asl 1.9.13.

Are you looking at
https://security.snyk.io/package/maven/org.codehaus.jackson:jackson-mapper-asl/1.9.13
?

I see NOTE: "This vulnerability is only exploitable when the
non-default UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled" which a
quick grep through our codebase indicates we do not use.

> Our scanner is reporting ~20 CVEs with a CVSS of >= 7 and ~60 CVEs total.
>
>
>
> Thank you,
>
> Josh
>
>
>
> From: Bruno Volpato 
> Date: Monday, May 1, 2023 at 9:04 PM
> To: user@beam.apache.org , Brule, Joshua (Josh) L., 
> CISSP 
> Subject: [EXTERNAL] Re: Vulnerabilities in Transitive dependencies
>
> Hi Joshua,
>
>
>
> It may take a lot of effort and knowledge to review whether CVEs are 
> exploitable or not.
>
> I have seen this kind of analysis done in a few cases, such as SnakeYAML 
> recently: https://s.apache.org/beam-and-cve-2022-1471 
> (https://github.com/apache/beam/issues/25449)
>
>
>
> If there is a patch available, I believe we should err on the side of caution 
> and update them (if possible).
>
>
>
> For the example that you mentioned, there is some work started by Alexey 
> Romanenko to remove/decouple Avro from Beam core, so we can upgrade to newer 
> versions: https://github.com/apache/beam/issues/25252.
>
> Another recent progress is Beam releasing a new version of its vendored gRPC 
> to move past some CVEs originated from protobuf-java: 
> https://github.com/apache/beam/issues/25746
>
>
>
>
>
> Is there any other particular dependency that you are concerned about?
>
> Please consider filing an issue at https://github.com/apache/beam/issues so 
> we can start tracking it.
>
>
>
>
>
> Best,
>
> Bruno
>
>
>
>
>
>
>
> On Mon, May 1, 2023 at 5:28 PM Brule, Joshua L. (Josh), CISSP via user 
>  wrote:
>
> Hello,
>
>
>
> I am hoping you could help me with our vulnerability remediation process. We 
> have several development teams using Apache Beam in their projects. When 
> performing our Software Composition Analysis (Third-Party Software) scan, 
> projects utilizing Apache Beam have an incredible number of CVEs, Jackson 
> Data Mapper being an extreme outlier.
>
>
>
> I Jackson Data Mapper is a transitive dependency via Avro but I am wondering. 
> Has the Apache Beam team reviewed these CVEs and found them NOT EXPLOITABLE 
> as implemented. Or if exploitable implemented mitigations pre/post usage of 
> the library?
>
>
>
> Thank you for your time,
>
> Josh
>
>
>
> Joshua Brule | Sr Information Security Engineer


Re: [EXTERNAL] Re: Vulnerabilities in Transitive dependencies

2023-05-02 Thread Brule, Joshua L. (Josh), CISSP via user
The SnakeYAML analysis is exactly what I was looking for. The library of 
concern is org.codehaus.jackson jackson-mapper-asl 1.9.13. Our scanner is 
reporting ~20 CVEs with a CVSS of >= 7 and ~60 CVEs total.

Thank you,
Josh

From: Bruno Volpato 
Date: Monday, May 1, 2023 at 9:04 PM
To: user@beam.apache.org , Brule, Joshua (Josh) L., CISSP 

Subject: [EXTERNAL] Re: Vulnerabilities in Transitive dependencies
Hi Joshua,

It may take a lot of effort and knowledge to review whether CVEs are 
exploitable or not.
I have seen this kind of analysis done in a few cases, such as SnakeYAML 
recently: https://s.apache.org/beam-and-cve-2022-1471 
(https://github.com/apache/beam/issues/25449)

If there is a patch available, I believe we should err on the side of caution 
and update them (if possible).

For the example that you mentioned, there is some work started by Alexey 
Romanenko to remove/decouple Avro from Beam core, so we can upgrade to newer 
versions: https://github.com/apache/beam/issues/25252.
Another recent progress is Beam releasing a new version of its vendored gRPC to 
move past some CVEs originated from protobuf-java: 
https://github.com/apache/beam/issues/25746


Is there any other particular dependency that you are concerned about?
Please consider filing an issue at https://github.com/apache/beam/issues so we 
can start tracking it.


Best,
Bruno



On Mon, May 1, 2023 at 5:28 PM Brule, Joshua L. (Josh), CISSP via user 
mailto:user@beam.apache.org>> wrote:
Hello,

I am hoping you could help me with our vulnerability remediation process. We 
have several development teams using Apache Beam in their projects. When 
performing our Software Composition Analysis (Third-Party Software) scan, 
projects utilizing Apache Beam have an incredible number of CVEs, Jackson Data 
Mapper being an extreme outlier.

I Jackson Data Mapper is a transitive dependency via Avro but I am wondering. 
Has the Apache Beam team reviewed these CVEs and found them NOT EXPLOITABLE as 
implemented. Or if exploitable implemented mitigations pre/post usage of the 
library?

Thank you for your time,
Josh

Joshua Brule | Sr Information Security Engineer