We just released Hibernate ORM version
5.6.2.Final we had to make a few changes to some SPIs to ease native compilation, but unfortunately we forgot to make sure these were backwards compatible.
With this bug fix release we introduced default methods in the SPIs
Exporter to retain the backwards compatibility with
Hibernate ORM includes a default implementation of its
JndiService, which is used internally to lookup
Datasource and references to the platform’s
TransactionManager. This service is also used to register its own components to allow them being looked up by other frameworks.
Datasource and/or a
TransactionManager to JNDI is a common practice in the industry on many runtimes and application servers running Hibernate ORM; this functionality is required by the JPA specification and we believe is a reasonable use case of JNDI. A conversation with the security team came to the same conclusion, after we scrutinized our code.
Previously, when performing a
Datasource lookup, any valid JNDI lookup URLs were accepted by the code, including schemas which might not be local. Initially this looked a little alarming, but considering this URL can only be provided by the Hibernate configuration it’s not considered a security vulneratbility; as a hardening improvement though - and an excess of caution - this release now improves the code to reject any URL which isn’t using the
We don’t think this is really necessary nor urgent, but it should make any other (possibly future?) vulnerability related to JNDI much harder to exploit.
As usual, please let us know if it breaks your application; we don’t expect anyone to actually have made use of exotic patterns to bind their datasources or transaction managers, so we don’t expect this to actually matter to anyone - but it’s good to be cautious when JNDI is involved.