Great Circle Associates Firewalls
(September 1995)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Firewall on Solaris 2.4, truss, CERN httpd mods.
From: Chiaki Ishikawa <ishikawa @ personal-media . co . jp>
Date: Fri, 29 Sep 1995 07:49:57 +0900
To: firewalls @ GreatCircle . Com
Reply-to: ishikawa @ personal-media . co . jp

PMC e-mail id: 4030 

Thank you to many readers of firewall mailing list for pointing out to
me that truss on Solaris takes -f flag to trace all the forked
children.

This made it possible to trace processes on my firewall hosts when I
could insert the call to truss in the calling/called process chain.
(Also, someone's method of using a simple program to pause() for
interrupt and then exec the program given as argument seems to be very
effective.)

Now I have used the truss this way to trace CERN httpd and ftpd and
come up with the attached modification of CERN httpd.  

[Well, not exactly, I have decided not to post the change after I
write this memo. It is a little lengthy. If there is a request, I may
post it (107 lines), and plan to make it available via ftp very soon.]

This memo itself is a little lengthy, but someone using Solaris
for firewall may find this useful.

A few little things that may be of interest to firewall host
maintainer especially concerning ftpd and httpd:

1. As someone mentioned Sun's ldd can't print ALL the shared libraries
which are called at run time.  ldd httpd shows the following output.

$ ldd /usr/local/etc/httpd
	libresolv.so.1 =>	 /usr/lib/libresolv.so.1
	libnsl.so.1 =>	 /usr/lib/libnsl.so.1
	libsocket.so.1 =>	 /usr/lib/libsocket.so.1
	libdl.so.1 =>	 /usr/lib/libdl.so.1
	libc.so.1 =>	 /usr/lib/libc.so.1
	libintl.so.1 =>	 /usr/lib/libintl.so.1
	libw.so.1 =>	 /usr/lib/libw.so.1

But depending on the contents of the nsswitch.conf in the chroot
environment, other shared library files are required.  In my case,
using the trace in the above manner, I found that on top of the above
shared library files,

	/usr/lib/nss_dns.so*
	/usr/lib/nss_files.so*

were accessed by the chrooted CERN httpd. So I added them to chroot
environment.  (However, httpd seemed to work anyway without the
additions. It probably didn't resolve guest host names very well,
though.)

2. Timezone info (Solaris 2.x)

Using truss also revealed that both ftpd and CERN httpd accessed the
following timezone information file.

	/usr/share/lib/zoneinfo/Japan

So I had to copy it to the chroot environment.	This was never
mentioned in the Sun's relatively well written ftpd man page.

Before I had wondered why the log message from ftpd used GMT instead
the local time.	 Since I copied the above file, the reported time in
the log file has now now become the one based on local time.

I think CERN httpd also needs this file so that the time reported in its
own log can be set to local time setting. (Since my default setting of
HTTPD log was GMT, I didn't realize the problem in the case of httpd.)

If you use Solaris 2.x and are puzzled about the GMT appearing in
your log file, this may be the cause.

Change of CERN httpd: (I think this is not specific to Solaris.)

The following patch of CERN httpd makes the standalone httpd (that is,
configuration without inetd) to have non-root effect u/gid when it
waits for network connection. It used to wait as root process
and made me a little nervous.

Once an initial change was made in HTUserInit.c, httpd generated the
extra message in http.error.MMddYY file of the form

>[28/Sep/1995:20:20:53 +0000] [OK] [host: gate] Failed to init groups for user www
>[28/Sep/1995:20:20:53 +0000] [OK] [host: gate] Failed to set group id to 60001
>[28/Sep/1995:20:20:53 +0000] [OK] [host: gate] Failed to set user id to 29002
>[28/Sep/1995:20:21:06 +0000] [OK] [host: gate referer: http://www:80/] Failed to init groups for user www
>[28/Sep/1995:20:21:06 +0000] [OK] [host: gate referer: http://www:80/] Failed to set group id to 60001
>[28/Sep/1995:20:21:06 +0000] [OK] [host: gate referer: http://www:80/] Failed to set user id to 29002

As a matter of fact, I think similar messages are generated if httpd
is invoked from non-root user as well. (Although, the message is [OK]
one and probably can be ignored peacefully, sysadmin people tend to
dislike to see log files named as *.error.* growing up.)  So I
suppressed such message in HTDaemon.c.

I run the modified httpd as in the following script.

The first line is the truss for debugging purposes. (Notice -f?)
The second line changes the root of file system BEFORE httpd runs.
The chrootuid program is a chroot/change uid program freely available
on the net. Since I now invoke httpd from root, simple chroot command
will do here. I used to change userid to www before running httpd.

Because I change the root file system external to httpd, I didn't
incorporate the chroot function within my modification as suggested by
David Miller on this mailing list.

(part of) Invoking script:
	...
echo
echo "Invoke as root and open port 80"
echo
	/usr/bin/truss -o /tmp/h.out -f \
	/usr/local/bin/chrootuid /pub_area/www root	\
	/bin/httpd    -p 80 \
	-r /usr/local/etc/httpd_conf.chroot

Caveat: 


[We assume that the accessed files are readable to the UserId
and GroupId of the httpd. This I think is valid more or less.]

The solution is here is not 100% bullet proof since if someone finds a
way to force httpd to execute arbitrary machine instructions, then it
is conceivable that the attacker can make the httpd to regain root
status since the saved id is still root.  This was pointed out to the
{effective,real,save} user/group id in the case of ftpd earlier in
this mailing list by Mark Riggins of AT&T.

I suppose possible such attack can be made using, say, the recently
reported syslog-related library functions overflow and such.

I GIVE UP: In order to remove such possibility, we need to make httpd
and ftpd run without saved id being root id.  I think that both in the
case of ftpd and httpd, we can add additional layer of fork(s) with
proper changing of saved g/uid and remove the this possibility of
success of such attack.  But I have run out of steam now and have not
had the time to look into such modification. Any taker ?

I can certainly say that the modification here will make the httpd run
as secure as famed wu-ftpd in terms of the effective u/gid when it
waits for the connection from outside. At least this makes it a little
more comfortable to run httpd from root.  (By the way, I invoke both
httpd and ftpd AFTER chroot is done externally and there is no mknod,
sh and other dangerous programs in the chroot environment.)

Finally, here is the output of showid.
---
# ps -aef | grep httpd
    root  2103	2100  4 07:00:17 pts/2	  0:00 grep httpd
    root  2073	   1  4 06:59:14 ?	  0:00 /bin/httpd -p 80 -r /usr/local/etc/httpd_conf.chroot
# /usr/local/etc/showid 2073
Process: 2073
effective  : (uid, gid) = (29002, 60001) (www, nobody)   <=== HERE!
real	   : (uid, gid) = (0, 1) (root, other)
saved	   : (uid, gid) = (0, 1) (root, other)           <=== Hmm...
 # of supplementary groups: 11
# ps -aef | grep ftpd
    root  2106	2100  4 07:00:27 pts/2	  0:00 grep ftpd
    root  2053	2052 56 06:56:13 ?	  0:01 /usr/local/etc/ftpd -a -d -l
# /usr/local/etc/showid 2053
Process: 2053
effective  : (uid, gid) = (29001, 60001) (ftp, nobody)   <=== HERE!
real	   : (uid, gid) = (0, 1) (root, other)
saved	   : (uid, gid) = (0, 1) (root, other)           <=== Hmm...
 # of supplementary groups: 1
----

You might want to check the effective uid/gid of httpd watiting for
the external connection on your gateway machine. It probably is root.

BTW, as far as one trusts the code of ftpd and httpd, simple chroot
externally before invoking them would have been sufficient. Or is it?

Any comments welcome.

-- 
     Chiaki Ishikawa         	ishikawa @
 personal-media .
 co .
 jp             
    Personal Media Corp.                  
  Shinagawa, Tokyo, Japan 141




Indexed By Date Previous: Re: Dual-DNS: Traffic from Internal DNS to Real World
From: Chris Tyler <chris @ dejong . com>
Next: [no subject]
From: Baey Chin Cheng <dbsbanke @ technet . sg>
Indexed By Thread Previous: Strange Questions
From: <CPL=SEAN=M=HOWARD%DATACOMM%1ST=SRIG @ mqg-smtp3 . usmc . mil> (CPL HOWARD, ACID DA9C36)
Next: [no subject]
From: Baey Chin Cheng <dbsbanke @ technet . sg>

Google
 
Search Internet Search www.greatcircle.com