rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/20/90)
There is a security problem with certain X clients running under SunOS 4.1. The problem only affects setuid programs that have been linked with relative -L shared library paths. xterm and xload are possible candidates, from the core MIT X distribution. IF you are using shared X libraries, AND you have installed xterm and/or xload as setuid programs, then please do one of the following: Option 1. Relink the program statically (using -Bstatic). For example, in the R4 xterm Imakefile, change the line NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB)) to NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),-Bstatic XawClientLibs -Bdynamic,$(TERMCAPLIB) $(PTYLIB)) and in the R4 xload Imakefile, change the line LOCAL_LIBRARIES = XawClientLibs to LOCAL_LIBRARIES = -Bstatic XawClientLibs -Bdynamic Option 2. Make the program non-setuid. You should consult your system administrator concerning protection of resources (e.g. ptys and /dev/kmem) used by these programs, to make sure that you do not create additional security problems at your site. There is a third option, which is to link the programs only with absolute library paths. This only works if reasonable versions of the libraries are already installed at the time that you link the program. Since this option introduces possibilities of link errors (depending on your environment), and it is poor build practice to forcibly install libraries except during an install phase, I am not providing Imakefiles details for this option, but you may want to consider this option (given that Option 1 has a performance penalty) if you do not feel comfortable with the consequences of Option 2. If you have questions about how to correct this problem at your site, please feel free to send me mail about it, and I will try to answer as best I can. We will try to correct this problem in the R5 build procedures (although personally, I think Sun made a big mistake in creating this hole, and the correct fix is to patch SunOS 4.1). Bob Scheifler Director, MIT X Consortium rws@expo.lcs.mit.edu
stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (12/21/90)
In article <9012201420.AA14517@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: |> There is a security problem with certain X clients running under SunOS 4.1. |> The problem only affects setuid programs that have been linked with relative -L |> shared library paths. xterm and xload are possible candidates, from the core |> MIT X distribution. IF you are using shared X libraries, AND you have installed |> xterm and/or xload as setuid programs, then please do one of the following: [...] |> There is a third option, which is to link the programs only with absolute |> library paths. This only works if reasonable versions of the libraries are |> already installed at the time that you link the program. Since this option |> introduces possibilities of link errors (depending on your environment), and |> it is poor build practice to forcibly install libraries except during an |> install phase, I am not providing Imakefiles details for this option, but |> you may want to consider this option (given that Option 1 has a performance |> penalty) if you do not feel comfortable with the consequences of Option 2. IMHO, the drawbacks of options 1 and 2 are indeed well worth the trouble of pursueing option3. If my understanding of Sun's shared libs and the X build process is correct, option 3 should be trivial to implement: just type xmkmf in the xterm and xload directories and recompile. If imake config files are set up correctly this should cause libraries to be searched for in the trusted places only or in some directory specified by absolute path (e.g., LoaderLibPrefix is -L/usr/local/X11R4/lib in our environment). What's the big deal? Please correct me if I'm wrong. -- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/21/90)
If my understanding of Sun's shared libs and the X
build process is correct, option 3 should be trivial to implement:
just type xmkmf in the xterm and xload directories and recompile.
This should work if your libraries are already installed (but the
next time you rebuild Makefiles in your tree the information will
be lost, and you might forget there's a problem).casper@fwi.uva.nl (Casper H.S. Dik) (12/21/90)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > If my understanding of Sun's shared libs and the X > build process is correct, option 3 should be trivial to implement: > just type xmkmf in the xterm and xload directories and recompile. >This should work if your libraries are already installed (but the >next time you rebuild Makefiles in your tree the information will >be lost, and you might forget there's a problem). First a warning: if you run SunOS 4.1, but had your xterm built with SunOS 4.0.x, you're at risk too. Now my solution: You can change the Imake.rules file to generate a non-relative path: (TOP=$PWD, rather than .) Instead of linking with -L../../lib/X -lX11, the linking will be done with -L/usr/local/src/X11R4/lib/X -lX11 (on my system). This is not a very good solution, because it hardwires TOP in the toplevel Makefile. This will make it difficult to move the X source tree around. (You must edit $(TOP)/Makefile, after moving) *** mit/config/Imake.rules.org Sat Mar 31 01:58:27 1990 --- mit/config/Imake.rules Tue Nov 20 12:09:35 1990 *************** *** 606,612 **** echo " $(RM) Makefile.bak; $(MV) Makefile Makefile.bak"; \ @@\ $(RM) Makefile.bak; $(MV) Makefile Makefile.bak; \ @@\ else exit 0; fi @@\ ! $(IMAKE_CMD) -DTOPDIR=$(TOP) -DCURDIR=$(CURRENT_DIR) imakeflags #endif /* BuildMakefileTarget */ --- 606,612 ---- echo " $(RM) Makefile.bak; $(MV) Makefile Makefile.bak"; \ @@\ $(RM) Makefile.bak; $(MV) Makefile Makefile.bak; \ @@\ else exit 0; fi @@\ ! $(IMAKE_CMD) -DTOPDIR=`cd $(TOP); pwd` -DCURDIR=$(CURRENT_DIR) imakeflags #endif /* BuildMakefileTarget */ -- NOTE: Some machine instructions | Casper H.S. Dik must be executed on the CPU. | casper@fwi.uva.nl (a manual page on the Gould PowerNode) | NIC: !cd151