Thanks for the thoughtful responses, Laszlo and Okumin! I understand the concern about backward compatibility if we continue to deprecate these classes. Strengthening the safeguard so that creating a temporary UDF with a blacklisted class *fails* would certainly close this loophole.
Although I worry that even if Hive blocks temp UDF creation, the classes remain available in the JVM. If someone mistakenly removes them from the blacklist, they instantly become a major security hole. I’d like to hear if others also see value in moving toward deprecating and eventually deleting these classes with a public announcement. Thanks, Riju On Mon, Aug 18, 2025 at 12:23 AM Shohei Okumiya <[email protected]> wrote: > Hi, > > In my opinion, we should not have had those methods by default, and > then we can deprecate them with a public announcement. They have > unusual semantics on access control. Blacklisting them is also an > option if we choose not to. > > Regards, > Okumin > > On Fri, Aug 15, 2025 at 1:47 PM László Bodor <[email protected]> > wrote: > > > > 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 > >> > >> >
