From: Sun Security Coordination Team To: "I)ruid" Cc: security curmudgeon , security-alert[at]sun.com Date: Mon, 7 Apr 2008 11:08:27 -0700 Subject: Re: [Full-disclosure] CAU-EX-2008-0001: Solaris ypupdated Command Execution On Sat, Apr 05, 2008 at 03:04:47PM -0500, I)ruid wrote: > On Sat, 2008-04-05 at 06:32 +0000, security curmudgeon wrote: Hello I)ruid and security curmudgeon, > > : Release Date: 2008.04.04 > > : Title: ypupdated_exec.rb > > : Description: Solaris ypupdated Command Execution > > : Tested: Solaris x86/sparc 10, sparc 9, 8, 2.7 > > : > > : Josh D. from Avalon Security Research is > > : credited with originally discovering this vulnerability. > > : > > : This Metasploit exploit module was modeled after kcope's exploit > > : released to Milw0rm on 2008.03.20. > > : > > : http://osvdb.org/displayvuln.php?osvdb_id=11517 > > : http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0209 --^ This should be an 8, as in 1999-0208. > > : http://www.securityfocus.com/bid/1749/info > > : http://www.milw0rm.com/exploits/5282 > > > > This was originally reported in Solaris 4.1.x (Dec 19, 1994). Is this > > really the same vulnerability from '94, or was it patched and then found > > vulnerable again (regression, new vulnerable code, etc)? This is related to the original vulnerability - it is not the same vulnerability but the original fix was incomplete. > Honestly, I was going off of SecurityFocus's assessment. The guys over > there seem to think it is because they added the exploit code that my > msf module is based on (milw0rm 5282) to the BID exploits page for that > vuln. The description sounds like exactly what is happening via this > exploit (shell meta-characters cause command execution during map > update's use of the shell). Their list of vulnerable platforms also > includes Solaris up through 10. I personally did my exploit testing > against x86 Solaris 10, and I have a friend over at McAfee who tested > against their Solaris farm and found sparc Solaris 2.6, 7, 8, and 9 also > vulnerable. The recently discovered vulnerability states the following: +-- | Vulnerable systems include Solaris 2.7, 8, 9, and 10, when | ypupdated is started with the '-i' command-line option. +-- Note that the ypupdated(1M) man page documents the '-i' option as: -i Accept RPC calls with the insecure AUTH_UNIX creden- tials. This allows programmatic updating of the NIS maps in all networks. So if sites are running ypupdated with the -i option then they are already giving away access to their NIS maps. > > When the milw0rm post was made, many VDBs including OSVDB created new > > tracking numbers for it. If this is truly the same vulnerability that has > > gone unpatched in Solaris all this time, OSVDB would continue to use > > 11517. But if this is a new vulnerability in the same service, we'd use > > 43433. > > > > Any clarification would be greatly appreciated. We did address the original vulnerability in Solaris 2.6 when ypupdated was bundled with Solaris. For Solaris versions 1.1 through 2.5.1 when the NIS server capability was not bundled with the OS but available as a separate unbundled package called NSKit the fix was to bump the revision of NSKit to 1.2 and remove ypupdated from NSKit. Note that the issue was addressed before Solaris 2.6 was released so no patches were required to address the original vulnerability. The fix applied at the time however was incomplete in that it didn't handle some payloads when the -i option is in use as mentioned above. > The CERT advisory that that Sun bug references[2] sounds like the same > vulnerability as the one the exploits target. Under the entry for Sun > in the CERT advisory, it also seems to indicate that the bug was not > going to be fixed. The wording in CERT Advisory CA-1995-17 for Sun: +-- | BUG 1230027/1232146 fixed in 4.1.3, will not fix 2.4 +-- is confusing to us as well since the issue wasn't technically fixed in 4.1.3 (Solaris 1.1) but rather the ypupdated daemon was removed from NSKit which also applied to Solaris 2.4. The rest of the vendor statement is easier to understand: +-- | The ypupdated program is no longer shipped with NS-KIT. If we do decide | in the future to support it again, we will fix the bug. +-- Sun did in fact fix the bug via 1232146 a few months after the CERT Advisory came out during Solaris 2.6 development. We'll contact CERT to have our vendor statement in CERT Advisory CA-1995-17 updated to closer reflect reality. > The CVE entry at the National Vuln Database[3] for the BID points to an > X-Force advisory[4] as likely the original advisory. It also sounds > like the same vuln. > > So after all that I just read, I'm still inclined to think it's the same > vuln which was never fixed as the Sun people that handled it at the time > may have thought rpc.ypupdated was being phased out. If it's NOT the > same bug, it's damn similar (: Yes, the root cause is essentially the same however now its only the '-i' code path which is affected. The new bugID for this latest ypupdated vulnerability is 6679204. We'll be publishing a Sun Alert for this bugID shortly. We hope that helps clarify things. Let us know if there are any other questions or anything we can help out with. > [1] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4286300 > [2] http://www.cert.org/advisories/CA-1995-17.html > [3] http://nvd.nist.gov/nvd.cfm?cvename=CVE-1999-0208 > [4] http://xforce.iss.net/xforce/xfdb/110 > > -- > I)ruid, C˛ISSP > druid[at]caughq.org > http://druid.caughq.org Best regards, Sun Security Coordination Team security-alert[at]sun.com | http://blogs.sun.com/security