The other day I noticed a strange response I hadn't seen before when running a VERSION command against an 188.8.131.52 Listener:
It seemed as though the Listener was leaking memory.
I was able to reproduce this issue across other nodes in the RACs I had access to. Instead of the standard 348 byte TNS VERSION response
I was getting a 2011 byte TNS response:
I was also able to reproduce the result by running the VERSION command locally using the lsnrctl utility.
With a bit of digging it seems as though 184.108.40.206 Listeners with CPU April 2012 (patchset 13621679) are vulnerable to a memory leak issue. Most likely due to a buffer not being terminated/copied correctly.
This flaw could potentially come in handy during a pentest when trying to enumerate SIDs/Service names:
I was unable to reproduce this flaw on Listeners patched with CPU July 2012 (patchset 13923474) -- meaning Oracle are most likely wise to the issue...
Note: I was able to notice this issue as I was using Metasploit's tnscmd module. Unlike the tnsversion module, tnscmd outputs the full TNS conversation and not just the 348 bytes of the version string.