Oracle databases vulnerable to injected listeners
During its latest patch day, Oracle said that a critical hole in the Oracle database had been fixed. The discoverer of the hole, responding to this, went ahead and published the vulnerability details. Although the vulnerability affects almost all Oracle installations in production use, however, there isn't actually a patch for these versions. Oracle database administrators themselves should therefore take immediate action to protect their systems.
Oracle credited Joxean Koret at the bottom of its Critical Patch Updates for April (CPU) documentation. When the security expert asked the company why he had been credited, Oracle replied that it was in acknowledgement of his report of a critical security hole in 2008, and that the hole had now been fixed. Koret therefore proceeded to publish details about the vulnerability, explained how it can be exploited and recommended that users install the latest CPU patches to protect their systems. However, it then turned out that there aren't actually any patches for any of the currently available Oracle database versions. The security fixes that were described by Oracle refer to the "main code line" only, which is the as yet unreleased Oracle 12. However, as virtually all installations in production use are affected, the vast majority of Oracle administrators have been left out in the cold and must take immediate action themselves.
The Oracle database server has a separate network connection process that usually operates on TCP port 1521. The database registers as a listener with this process and the process forwards the client requests on to the actual database system that handles the requested database instance. Since version 8i, these network connection processes can register additional listeners. Such a listener can even be registered for an existing database instance. The active listener interprets this as a new Oracle Real Application Clusters (RAC) node and uses the new listener to implement load balancing. In other words: every second database connection will be routed via the new listener.
Alexander Kornbrust, an expert on Oracle security at Red Database Security, thinks that this security hole is particularly serious "because it allows remote and unauthenticated attackers to redirect the database's network traffic on the database server to an arbitrary server and then intercept it. All they need to know is the Oracle SID or Oracle service name." And yet there is little point in hoping that Oracle will soon release a patch. Kornbrust anticipates that this will take even longer than the 3 months that will pass before the next CPU release. Oracle's patch policy stipulates that the patch sets for the yet to be released version 18.104.22.168 will be issued before any security patches are released. "For this reason, it often takes between one and two years", complained the Oracle specialist.
Oracle administrators should therefore take immediate action to protect their installations. For those who don't use clustering, this will be a relatively easy matter. They can use the
dynamic_registration = off
instruction in the
listener.ora configuration file to disable the unnecessary feature. Things become more difficult in cluster environments. One option is to restrict access to the listener in such a way that the listener is unreachable from the internet and the local office network. In some configurations, the
TCP.VALIDNODE_CHECKING option can also be used to limit the systems that can talk to the listener to those that are included on the
TCP.INVITED_NODE list. While long, random SIDs and service names make attacks more difficult, they usually can't prevent them. Protection can be achieved most effectively by making sure that communications are encrypted via SSL/TLS. However, for most admins this may not be an option because Oracle charges a hefty extra fee for this functionality. Further vulnerability information can be found in Joxean Koret's posting entitled "The history of a -probably- 13 years old Oracle bug: TNS Poison."