From warchild@spoofed.org Mon Sep 22 01:14:38 2003 Date: Mon, 22 Sep 2003 01:14:38 -0400 From: Jon Hart To: security-alert@sun.com Subject: Information disclosure with SMC webserver on Solaris 9 Message-ID: <20030922051438.GB15803@spoofed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Status: RO Content-Length: 2816 Lines: 71 Hi, I was playing around with the Sun Management Console (SMC) webserver that runs on port 898 on Solaris 9, and noticed an interesting but disturbing fact with its 404 error messages. The quick summary is that it returns different 404 errors depending on where in the code the webserver decides to call sendError(). If the file requested by the user does not exist, then the following is called: httpservletresponse.sendError(404, "File Not Found
" + file); which results in an error page similar to: Error: 404 File Not Found /stuff/blah If the file requested by the user does exist, but cannot be accessed for a particular reason (i.e., file.getAbsolutePath() and file.getCanonicalPath() don't match), then the following is called: httpservletresponse.sendError(404); which results in an error page similar to: Error: 404 No detailed message Unfortunately, no checks are done to see that the requested URL doesn't traverse out of the web root (typically /usr/sadm/lib/smc/htdocs) prior to calls to serveDir() or serveFile(), so these two functions happily access any path specified with root privileges. Although it doesn't look to be possible to access files outside the web root, the differing error messages can tell remote users if a file or directory anywhere on the target system exists, which is a good bit of information disclosure especially since this service runs as root. As an example of interesting things to request, try the following: http://yourhost:898/../../../../../tmp/.X11-unix http://yourhost:898/../../../../../.rhosts http://yourhost:898/../../../../../.ssh http://yourhost:898/../../../../../var/yp which will answer interesting questions like "does my target run X-windows?", "do the administrators of this machine use r-services to administer the machine?", "do the administrators of this machine login as root using ssh?" and "does my target use NIS/yp?" The possibilities of this attack are only limited by an attacker's imagination. There are quite a few problems with this code, but a fix is relatively easy. First, ensure that directory traversal never happens in the first place, which will aleviate future problems with SMC serving up /etc/shadow and the like. Next, don't lie and return 404 messages willy nilly simply because a check fails. The file does exist, but internal "sanity checks" failed and java threw and exception, so do the right thing and return 500. With that, requests will be restrained within the webroot and http return codes will be correct and vital bits of information about your box won't be divulged. Or, if none of that works or isn't possible, don't run SMC by default, and if you do need to run it, run it as an unprivileged user like 'nobody' or 'www'. Thanks for your prompt attention to this matter, -jon