Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The LDAP implementation in HiveServer2 in Apache Hive before 1.0.1 and 1.1.x before 1.1.1, as used in IBM InfoSphere BigInsights 3.0, 3.0.0.1, and 3.0.0.2 and other products, mishandles simple unauthenticated and anonymous bind configurations, which allows remote attackers to bypass authentication via a crafted LDAP request.
Recommended action: Upgrade to 1.1.1 or 1.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Hive (JDBC + HiveServer2) implements SSL for plain TCP and HTTP connections (it supports both transport modes). While validating the server's certificate during the connection setup, the client in Apache Hive before 1.2.2 and 2.0.x before 2.0.1 doesn't seem to be verifying the common name attribute of the certificate. In this way, if a JDBC client sends an SSL request to server abc.com, and the server responds with a valid certificate (certified by CA) but issued to xyz.com, the client will accept that as a valid certificate and the SSL handshake will go through.
Recommended action: Upgrade to 2.0.1 or 1.2.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Hive 2.1.x before 2.1.2, 2.2.x before 2.2.1, and 2.3.x before 2.3.1 expose an interface through which masking policies can be defined on tables or views, e.g., using Apache Ranger. When a view is created over a given table, the policy enforcement does not happen correctly on the table for masked columns.
Recommended action: Upgrade to 2.3.1, 2.2.1 or 2.1.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Hive 0.6.0 to 2.3.2, malicious user might use any xpath UDFs (xpath/xpathstring/xpathboolean/xpathnumber/xpathdouble/xpathfloat/xpathlong/xpathint/xpathshort) to expose the content of a file on the machine running HiveServer2 owned by HiveServer2 user (usually hive) if hive.server2.enable.doAs=false.
Recommended action: Upgrade to 2.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Hive 2.1.0 to 2.3.2, when 'COPY FROM FTP' statement is run using HPL/SQL extension to Hive, a compromised/malicious FTP server can cause the file to be written to an arbitrary location on the cluster where the command is run from. This is because FTP client code in HPL/SQL does not verify the destination location of the downloaded file. This does not affect hive cli user and hiveserver2 user as hplsql is a separate command line script and needs to be invoked differently.
Recommended action: Upgrade to 2.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authorization framework in Apache Hive 1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0 and 1.2.1, on clusters protected by Ranger and SqlStdHiveAuthorization, allows attackers to bypass intended parent table access restrictions via unspecified partition-level operations.
Recommended action: Upgrade to 1.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Hive before 0.13.1, when in SQL standards based authorization mode, does not properly check the file permissions for (1) import and (2) export statements, which allows remote authenticated users to obtain sensitive information via a crafted URI.
Recommended action: Upgrade to 0.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.