Hi Riju! Good catch!
I’m afraid we can’t remove classes from the hive-exec JAR as long as users are expected to adjust the blacklist configuration and rely on those options. So the only viable approach is an alternative safeguard. Given the registry here: https://github.com/apache/hive/blob/78db8e93e7e713e0ba7d5dcb9fc7792d12cae38c/ql/src/java/org/apache/hadoop/hive/ql/exec/FunctionRegistry.java#L583 The behavior should be: if “reflect” is blacklisted, then creating a UDF with a class (e.g., GenericUDFReflect) that falls under a blacklisted UDF should fail with a clear, user-friendly exception. Regards, Laszlo Bodor On Fri, 15 Aug 2025 at 02:54, Riju Trivedi <[email protected]> wrote: > Hello Team, > > We have identified a potential security gap in Hive’s handling of > blacklisted UDFs. While reflect, reflect2, java_method, and in_file are > blacklisted via the hive.server2.builtin.udf.blacklist property to > prevent direct invocation, their corresponding classes (e.g., > org.apache.hadoop.hive.ql.udf.generic.GenericUDFReflect) are still > shipped in hive-exec.jar. > > This allows a user with the privilege to create temporary UDFs to register > these classes and execute arbitrary Java code as the Hive service user, > bypassing the blacklist. > > For example, > > CREATE TEMPORARY FUNCTION my_tempudf AS > 'org.apache.hadoop.hive.ql.udf.generic.GenericUDFReflect'; > > SELECT my_tempudf("java.lang.Runtime", "exec", "...") > > could grant access to Kerberos tickets or sensitive HDFS data. > > Would like to know your thoughts on whether we should consider removing > these classes from hive-exec.jar Or implementing an alternative safeguard > to fully block their use? > > Thanks, > > Riju > > >
