Last updated at Wed, 26 Jul 2017 14:44:13 GMT
As we all know, the past couple of months have been busy times for our industry. As lead exploit developer, it is my duty to stay on top of all of the vulnerabilities being published. When working through the plethora of issues published in October's patch-extravaganza, there was one particular vulnerability that I felt compelled to investigate.
That issue was CVE-2010-3509. After all, I've had a soft spot in my heart for the Common Desktop Environment (CDE) since back the late 90's.
Oracle's CPU release included this issue as a 10.0 CVSS affecting rpc.cmsd on Solaris 8, 9, and 10. As is customary of Oracle's CPU document, there were no additional details presented. At this point the issue went on the back burner.
Later that day, Digital Defense (DDI) released their advisory about this issue. Even though there was nothing substantial in the DDI advisory, it did mention "Buffer Overflow", "Denial of Service" and "integer overflow". In the "Solution Description" section, they even supplied the Sun bug ID of 6214701. This gave me hope.
Unfortunately, the Sun bug ID only stated "6214701 rpc.cmsd core dump". Wow, that was very anti-climactic.
As the days continued, multiple unpatched vulnerabilities were discovered being exploited in the wild. These issues take priority over patched issues, and so it wasn't until after they had been investigated that I could come back to the rpc.cmsd bug.
Back on this bug, I moved to the next step, patch diffing.
It had been quite a while since I had done any patch diffing against Solaris patches. I didn't know that after acquiring Sun, Oracle decided to require a valid support contract to access patches. Furthermore, for Solaris 8, you need an additional level of "legacy" support. I am generally annoyed and deterred by this kind of road block. I assume certain other researchers agree.
That said, where there is a will, there is a way. An anonymous contributor offered to provide the desired patches. Finally, on to the fun part. Armed with the usual IDA Pro and BinDiff, I set to it. I investigated Solaris 9 on SPARC first, since I had immediate access to a SPARC in the vulnerable configuration. After a dozen or so clicks of the mouse, I was finally looking at what I wanted to see. There was only one changed function, the "_DtCm_rtable_create_4_svc" function, as seen below.
After further analysis, I became quite confused. What I saw in the code differences, as you can see below, was not an "integer overflow". Nor was it a "Buffer Overflow"...
Those fluent in SPARC assembly can see, the added basic blocks are due to checks for a NULL return from the "DmCmGetPrefix" function. This function is nearly identical to the "strchr" function. Here, it is being used to search for an '@' character. Later, the returned values are passed to "strcmp" function. BUT, if you pass NULL to "strcmp", it will attempt to blindly de-reference it and cause a crash.
Then, I thought to myself, "Maybe there are other changes in one of the other patches." After all, DDI's advisory did specifically say Solaris 10. I set off to check the rest of the patches.
Turns out, all of them are the same. I checked Solaris 9 and 10, on both x86 and SPARC. In all cases, the only change was the additional of a null pointer check. Either a null pointer de-reference got a 10.0 CVSS, or Oracle didn't properly fix the vulnerability that DDI described.
Is this the kind of analysis we should expect from Oracle? I hope everyone enjoyed the time they spent downloading, applying, writing vulnerability checks, reports, and so on, for this bug! Personally, I feel a little like a child at Christmas that asked for a new game system and got a hula-hoop.
To conclude, I concede that I may have made some mistake. After all, I am human. If you have further information, please do not hesitate to contact me! I will do my best to make sure this post is factually correct.
Until next time, beware of the FUD!
