I'm having a bit of trouble creating actionable issues. Some of the CVEs are low impact and/or found in largely unused transitive dependencies. Actually getting rid of the CVEs may not be worth the effort since the CVEs are not applicable, or some mitigating measures are already in place. We could add the issues anyway, so searching though Jira will give users/developers the context they need to determine if the CVE is acceptable.
Regards, Wes On Wed, Apr 19, 2023 at 4:14 PM Wes Schuitema <[email protected]> wrote: > Thanks, my pleasure. I'll translate our findings to some actionable Jira > issues later this week. > > Regards, > > Wes > > > > On Mon, Apr 17, 2023 at 1:06 PM Nick Dimiduk <[email protected]> wrote: > >> Hi Wes, >> >> Thanks a lot for doing this work. Let's start burning down your list! >> >> On Tue, Apr 11, 2023 at 11:37 AM Wes Schuitema <[email protected]> wrote: >> >> > We've scanned the HBase repositories (both hbase and hbase-thirdparty) >> for >> > CVEs using a Maven dependency-check plugin ( >> > https://jeremylong.github.io/DependencyCheck/dependency-check-maven/). >> >> >> There's also hbase-connectors, which will need to be monitored. Can we >> install this plugin into our builds? Raise a JIRA? >> >> The scan was done on the master branch (3.0.0-alpha-4) >> >> >> Master branch is a great place to start. We seem to maintain two active >> minor release lines, so we'll eventually want to also monitor those as >> well. >> >> The results of the check are included in the results section, >> > summarizing: >> > - We did not find any critical issues relevant to HBase >> > - Most of the CVEs can be safely suppressed so they will not show up >> again >> > in future scans >> > - Some CVEs can be easily fixed by updating a few minor dependencies >> > - Newer Hadoop versions also contain a lot of updates that remove CVEs >> > >> >> Fantastic! >> >> Steps we can take from here: >> > - Fix some minor issues on the master branch (update javax.el-3.0.1-b08 >> and >> > woodstox-core-5.3.0) >> > - Add dependency check to Maven configuration and suppress remaining >> CVEs >> > in a restrictive manner (e.g., scoped on CPE, with time limit, adding >> > helpful notes) >> > - Include CVE checking in the build process >> > >> >> This plan sounds good to me. >> >> Results >> > >> >> For each of these, you can start by filing a ticket with a subject like >> "Mitigate CVE-ABC", and set the "affectsVersions" field to the current >> release from each branch. For the description, put exactly what you have >> here, including your suggested resolution. Then the community can easily >> start implementing your suggestions. >> >> --- >> > Dependency: guava-31.1-jre.jar (from hbase-thirdparty) >> > CVEs: CVE-2020-8908 >> > Description: Deprecated method to create temporary files can makes those >> > files world readable, never used in the code base. >> > Action: Could suppress this CVE in combination with a checkstyle rule to >> > prevent usage of method >> > >> > Dependency: commons-beanutils-1.9.2.jar >> > CVEs: CVE-2014-0114, CVE-2019-10086 >> > Description: Brought in through commons-validator. CVEs can lead to >> remote >> > code in specific situations. This was never relevant in the HBase code >> base >> > since the code from the dependency is never used directly or indirectly. >> > The only code that is used from commons-validator is to validate ipv6 >> > addresses. >> > Action: Since the dependency was easy to update, we've done just that on >> > the master branch >> > >> > Dependency: commons-net-3.6.jar >> > CVEs: CVE-2021-37533 >> > Description: Brought in by hadoop-common. Library contains an FTP client >> > with a vulnerability. This client is never used in the HBase code base. >> The >> > latest Hadoop version (3.3.4) uses a version of this library without the >> > CVE. >> > Action: An update would remove this CVE, alternatively, we could prevent >> > usage of the FTPClient using checkstyle or something similar. >> > >> > Dependency: guava-27.0-jre.jar >> > CVEs: CVE-2020-8908 >> > Description: Deprecated method to create temporary files can makes those >> > files world readable, never used in the code base. >> > Action: Importing any Guava code unless from the hbase-thirdparty is >> > already banned. This CVE could be supressed. >> > >> > Dependency: hadoop-hdfs-3.2.4-tests.jar >> > CVEs: CVE-2020-11022, CVE-2020-11023, CVE-2015-6584, CVE-2022-24785, >> > CVE-2022-31129 >> > Description: CVEs are found in Javascript libraries present in this JAR >> > (jquery-3.4.1.min.js, jquery.dataTables.min.js, moment.min.js). Assuming >> > this code is only used in test situation this should not be an issue. >> We've >> > checked how HBase loads its own static resources and have concluded that >> > these libraries can never be accidentally served up by HBase. >> > Action: We can suppress these CVEs specifically for this dependency so >> it >> > will show up when the JavaScript libraries are introduced through some >> > other means. >> > >> > Dependency: hadoop-yarn-common-3.2.4.jar >> > CVEs: CVE-2019-11358, CVE-2020-11022, CVE-2020-11023, CVE-2022-31160 >> > Description: CVEs are found in JavaScript libraries present in this JAR >> > (jquery-3.3.1.min.js, jquery-ui-1.13.1.custom.min.js) We've checked how >> > HBase loads its own static resources and have concluded that these >> > libraries can never be accidentally served up by HBase. >> > Action: We can suppress these CVEs specifically for this dependency so >> it >> > will show up when the JavaScript libraries are introduced through some >> > other means. >> > >> > Dependency: htrace-core4-4.1.0-incubating.jar >> > CVEs: CVE-2018-1000873, CVE-2018-7489, CVE-2017-7525, CVE-2020-10650, >> > CVE-2020-35490, CVE-2020-35491, CVE-2020-36518, CVE-2022-42003, >> > CVE-2022-42004 >> > Description: All CVEs are from the jackson dependency that's shaded into >> > htrace. There are no usages of this shaded dependency and there is even >> a >> > build time check that prevents this. >> > Action: Moving to a newer version of Hadoop (>= 3.3.2) will also solve >> it >> > by removing the htrace dependency. These CVEs can be suppressed when >> coming >> > in from htrace. >> > >> > Dependency: javax.el-3.0.1-b08.jar >> > CVEs: CVE-2021-28170 >> > Description: This dependency is brought in through javax.servlet.jsp in >> > hbase-server and is a direct dependency in hbase-thrift and hbase-rest. >> > There is a bug in the Java Expression Language parser that enabled >> > attackers to bypass input sanitization when using the >> ELParserTokenManager. >> > We found it difficult to determine how much of an issue this is for >> HBase. >> > Action: The artifact has been moved to jakarta.el, moving to this >> library >> > would remove the CVE (the latest version javax.el still has this >> > vulnerability) >> > >> > Dependencies: jetty-io-9.4.43.v20210629.jar, >> > jetty-server-9.4.43.v20210629.jar >> > CVEs: CVE-2022-2048, CVE-2022-2047 >> > Description: This old Jetty version is brought in by hadoop-common. >> There >> > are no usages of this version of Jetty and any usage is banned using >> > maven-enforcer >> > Action: These CVEs can be suppressed since there is already a mechanism >> in >> > place preventing usage >> > >> > Dependencies: jruby-complete-9.3.9.0.jar >> > CVEs: CVE-2022-1471 >> > Description: Parsing a specially crafted YML file using this version of >> > snakeyaml can cause a denial-of-service due to infinite recursion when >> > parsing the file. This version of snakeyaml is shaded into >> jruby-complete, >> > which is used exclusively for the HBase shell. In the context of the >> HBase >> > shell this CVE is not applicable. >> > Action: This CVE can be suppressed when occurring in combination with >> > jruby-complete because it's a false positive >> > >> > Dependencies: kerb-server-1.0.1.jar, kerby-xdr-1.0.1.jar >> > CVEs: CVE-2023-25613 >> > Description: These dependencies are brought in by hadoop-common. The CVE >> > only comes into play when using an LdapIdentityBackend. There is some >> test >> > code that makes use of kerby, but the problematic backend is never used. >> > Action: This CVE can be suppressed, code is only used in tests, and the >> > part that has the vulnerability is never used nor present as a >> dependency >> > >> > Dependency: netty-3.10.6.Final.jar >> > CVEs: CVE-2019-20444, CVE-2019-20445, CVE-2019-16869, CVE-2020-11612, >> > CVE-2021-37136, CVE-2021-37137, CVE-2022-41881, CVE-2021-43797, >> > CVE-2021-21295, CVE-2021-21409, CVE-2021-21290, CVE-2022-24823 >> > Description: This dependency is brough in by hadoop-common. A shaded >> > version of netty is used in HBase, and there is also a maven-enforcer >> rule >> > preventing usage of non-shaded versions >> > Action: These CVEs can be suppressed in the context of this dependency >> > because it will never be used >> > >> > Dependency: netty-all-4.1.68.Final.jar >> > CVEs: CVE-2022-41881, CVE-2021-43797, CVE-2022-24823 >> > Description: This dependency is brough in by hadoop-common. A shaded >> > version of netty is used in HBase, and there is also a maven-enforcer >> rule >> > preventing usage of non-shaded versions >> > Action: These CVEs can be suppressed in the context of this dependency >> > because it will never be used >> > >> > Dependencies: netty-codec-4.1.45.Final.jar, >> > netty-transport-4.1.45.Final.jar >> > CVEs: CVE-2020-11612, CVE-2021-37136, CVE-2021-37137, CVE-2022-41881, >> > CVE-2021-43797, CVE-2021-21295, CVE-2021-21409, CVE-2021-21290, >> > CVE-2022-24823 >> > Description: This netty version is brough in by zookeeper. A shaded >> version >> > of netty is used in HBase, and there is also a maven-enforcer rule >> > preventing usage of non-shaded versions >> > Action: These CVEs can be suppressed in the context of this dependency >> > because it will never be used >> > >> > Dependency: nimbus-jose-jwt-9.8.1.jar >> > CVEs: CVE-2021-31684 >> > Description: This dependency is brought in through hadoop-auth but is >> not >> > used in the HBase code base. >> > Action: This one can be suppressed because it's not relevant >> > >> > Dependency: okhttp-2.7.5.jar >> > CVEs: CVE-2021-0341 >> > Description: This dependency is brought in through hadoop-hdfs-client. >> The >> > CVE is not applicable with normal. Library is never directly in HBase >> code >> > base, and a quick look in the Hadoop code shows that the problematic >> class >> > is not used there either. >> > Action: Can be suppressed, not relevant for HBase >> > >> > Dependency: hbase-shaded-client-byo-hadoop >> > CVEs: CVE-2021-37404, CVE-2022-25168, CVE-2022-26612, CVE-2018-8009, >> > CVE-2020-9492, CVE-2021-25642 >> > Description: This is a false positive. The last part of the name >> (hadoop) >> > in combination with the current HBase version number (3.0.0) causes >> these >> > Hadoop 3.0.0 CVEs to be listed. >> > Action: This one can be suppressed >> > >> > Dependency: protobuf-java version 2.5.0 >> > CVEs: CVE-2015-5237, CVE-2021-22569, CVE-2021-22570, CVE-2022-3171 >> > Description: Required on 2.x for backwards compatibility. This >> dependency >> > could be removed in version 3 >> > Action: We could suppress this CVE with a time limit, revisit it if it's >> > still present after that time limit >> > >> > Dependency: token-provider-1.0.1.jar >> > CVEs: CVE-2023-25613 >> > Description: This dependency is brought in by kerb-client. The CVE is >> only >> > relevant for a specific authentication back-end, something only relevant >> > server side. The CVE is not applicable for clients. >> > Action: This one can be suppressed >> > >> > Dependency: woodstox-core-5.3.0.jar >> > CVEs: CVE-2022-40152 >> > Description: This dependency is brough in through hadoop-common. It's >> used >> > exclusively in the Configuration class. The Configuration class is also >> > used for HBase configuration. The problem applies to DTD processing, >> which >> > can be disabled. DTD processing is disabled in the single case of XML >> > stream processing found in the HBase code base. The DTD processing is >> not >> > always disabled in the Configuration class though. New versions of >> Hadoop >> > have updated the dependency to 5.4 which prevents the problem by >> > configuring a maximum depth when processing DTDs. >> > Action: We should be able to update the dependency either by moving to a >> > newer Hadoop version or adding the new version to dependency management >> > >> > Regards, >> > >> > Wes >> > >> > -- >> > >> > - Winner of Dutch Innovation award within Law Enforcement >> > - Active in 26 countries >> > >> > Wes Schuitema >> > Software Engineer >> > >> > phone: >> > skype: >> > site: >> > pgp: +31 (0)50 21 11 622 >> > [email protected] >> > web-iq.com >> > 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA >> > The content of this email is confidential and intended for the recipient >> > specified in message only. It is strictly forbidden to share any part of >> > this message with any third party, without a written consent of the >> sender. >> > If you received this message by mistake, please reply to this message >> and >> > follow with its deletion, so that we can ensure such a mistake does not >> > occur in the future. >> > >> > > > -- > > - Winner of Dutch Innovation award within Law Enforcement > - Active in 26 countries > > Wes Schuitema > Software Engineer > > phone: > skype: > site: > pgp: +31 (0)50 21 11 622 > [email protected] > web-iq.com > 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA > The content of this email is confidential and intended for the recipient > specified in message only. It is strictly forbidden to share any part of > this message with any third party, without a written consent of the sender. > If you received this message by mistake, please reply to this message and > follow with its deletion, so that we can ensure such a mistake does not > occur in the future. > -- - Winner of Dutch Innovation award within Law Enforcement - Active in 26 countries Wes Schuitema Software Engineer phone: skype: site: pgp: +31 (0)50 21 11 622 [email protected] web-iq.com 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
