Red Hat filed CVE-2024-3094 late last week on 2024-03-29. This implicates recent releases of the native liblzma library as a vector for malicious code.
This is not the pure Java version that we depend upon for HBase's support for the LZMA algorithm ( https://github.com/apache/hbase/tree/master/hbase-compression/hbase-compression-xz). We depend on version 1.9 of xz-java, which was published in 2021, well before maintenance changes in the project and the involvement of a person who is now believed to be a malicious actor. Projects like HBase that depend on xz-java have no reason to be concerned about the issues affecting the native xz library. How the backdoor was introduced calls into question the trustworthiness and viability of the XZ project. GitHub has disabled all repositories related to XZ and liblzma, even xz-java. The webpage for XZ and xz-java is down. The open source software community is responding vigorously. CVE-2024-3094 has a CVSS score 10, the highest possible score. Your security team may become interested in HBase because of hbase-compression-xz's dependency on xz-java. It is likely any discovered dependency on any LZMA implementation will at least raise questions. For now xz-java remains available in Maven central. (See https://central.sonatype.com/artifact/org.tukaani/xz/versions) We may have no choice but to immediately remove hbase-compression-xz if Maven blocks or drops xz-java too, because that will break our builds. There is no immediate cause for concern. Still, we believe XZ compression provides little to no value over more modern alternatives, like ZStandard, that can also achieve similar compression ratios. XZ, and alternatives like ZStandard with the compression level set to a high value, are also suitable only for archival use cases and unsuitable for compression of flush files or for use in minor compactions. Given how niche any use of XZ compression could be, we are wondering if there are actually any users of it. If we have no users of hbase-compression-xz, then it provides little to no value and continued maintenance of hbase-compression-xz given the issues with its dependency does not make sense. Do you use XZ compression, or are you planning to? If we deprecate XZ compression immediately and then remove it in 2.6, would this present a problem? In a private discussion we reached consensus on this approach, but, of course, that is not yet a plan, and something that could easily change based on feedback. >From https://nvd.nist.gov/vuln/detail/CVE-2024-3094: "Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library." -- Best regards, Andrew
