Information disclosure with SMC webserver on Solaris 9

Greetings,

I sent this email to Sun a month ago tomorrow, and to date the only
response I've received has been this:

	From [email protected]  Mon Sep 22 03:09:48 2003
	Date: Mon, 22 Sep 2003 12:39:56 +0530
	From: Sun Security Coordination Team <[email protected]>
	Subject: Re: Information disclosure with SMC webserver on Solaris 9
	To: Jon Hart <[email protected]>
	X-Mailer: Ximian Evolution 1.4.0

	Thanks for bringing this to our notice.
	We acknowledge that your findings are true, and we will
	address them appropriately.

Attempts to contact Sun regarding this matter have been unsuccessful --
nobody seems to be awake at [email protected].  I also tried using
Sun's security forums, but I have not received any responses their
either:

	http://supportforum.sun.com/salerts/index.php?t=msg&th=139&start=0&rid=0

So, I'm forwarding my initial email (below) to this list in the hopes
that _someone_ from Sun is on this list and can get the ball rolling on
getting this fixed.  But, to be completely honest, I'm not gonna hold my
breath. 

Thanks in advance,

-jon

----- Forwarded message from Jon Hart <[email protected]> -----

Date: Mon, 22 Sep 2003 01:14:38 -0400
From: Jon Hart <[email protected]>
To: [email protected]
Subject: Information disclosure with SMC webserver on Solaris 9
Message-ID: <[email protected]>
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
	



----- End forwarded message -----