The other day I noticed a strange response I hadn't seen before when running a VERSION command against an 220.127.116.11 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 18.104.22.168 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.