Directory traversal attacks on the Sun Solaris SMC Web Server under releases 8 and 9 allow a remote attacker to determine whether or not a file exists on the underlying filesystem due to differences in error messages.
afadcf605c1e2463d9dc1006e2bcbc5d78588c56164f93b99e0edf5afbb88bee
From warchild@spoofed.org Mon Sep 22 01:14:38 2003
Date: Mon, 22 Sep 2003 01:14:38 -0400
From: Jon Hart <warchild@spoofed.org>
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<br>" + 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