ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #8 1990-12-21 (1 file, 5010 bytes)
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
Date: Fri Dec 21 15:34:42 PST 1990 Subject: Core Security Digest V1 #8 Core Security Digest Volume 1 Issue 8 subject(s): HP-UX binmail problem Sharied library paths under SunOS 4.1 X security (fwd) Re: Suns 4.1 problems with X (fwd) The unix core security mailing list is by invitation only and contains sensitive material which SHOULD NOT BE REVEALED to non-members. DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS. If you must keep copies on-line, please encrypt them at the very least. PLEASE POST TO: [email protected] PLEASE SEND EMERGENCY ALERTS TO: [email protected] PLEASE SEND REQUESTS TO: [email protected] ------------------------------------------------------------------------ Date: Tue, 18 Dec 90 22:23:39 MET From: Edwin Kremer <[email protected]> Subject: HP-UX binmail problem We're experiencing a security problem with "/bin/mail" on the HP9000 series 300 systems running HP-UX 7.0. I won't call it a security hole in a sense that we all have to get paranoid right now, but at least it's a nasty privacy hole (that might become a security hole, depending on how sensitive the stuff is that you're mailing). After some thoughts I thought this should appear on Neil's inner security list for new, unfixed holes. Maybe you consider this an overkill, in that case: sorry. Please correct me if I'm wrong. To start with the background information you need, this is what "/bin/mail" looks like: -r-xr-sr-x 2 bin mail 106496 Oct 12 1989 /bin/mail The mail spool directory "/usr/mail" is of course: drwxrwxr-x 2 bin mail 13312 Dec 18 21:11 /usr/mail Any mailbox in "/usr/mail" looks like: -rw-rw---- 1 root mail 1444 Dec 18 17:43 /usr/mail/root Ok, the scheme for local mail delivery is easy: some mail user agent (mailx, Elm, GNU Emacs's RMAIL, ...) calls "/usr/lib/sendmail" which in turn calls "/bin/mail" (from now on referred to as "binmail") for local mail delivery. Binmail appends to the mailbox in "/usr/mail" if it exists. No problem. If the mailbox DOESN'T EXISTS, binmail creates it. Looks good, but... Imagine the following scenario: user "badguy" sends a message to another user "victim". User "victim" doesn't seem to have a mailbox in "/usr/mail". "badguy" uses mailx (any other MUA will do [calling binmail directly also does the trick]) to compose his message; mailx calls sendmail, which in turn calls binmail. As soon as binmail runs, it runs with euid=badguy, egid=mail. Binmail creates "/usr/mail/victim": this file is now owned by "badguy". Now binmail does a 'chown("/usr/mail/victim", victim, mail)'. However, in the meantime (the small amount of time that he owned the mailbox) "badguy" could have done anything he wanted with it. Various options surely spring to mind... Experiments showed that in appr. 80% of all cases you're quick enough to do something nasty with the mailbox. Running binmail "nicely" increases this percentage of course. Note that this problem _only_ occurs if the mailbox doesn't exist. Well, why doesn't it exist then?? Because some MUA's can be configured to unlink the mailbox if it is empty (GNU's RMAIL does, mailx might, Elm might). I got around this problem temporarily by doing the following: 1) trying hard to configure all MUA's __not to__ remove the mailbox if it is empty. That is really hard, because users can easily change that back in there own init files (~/.elm/elmrc, ~/.mailrc) but in that case they just have to blame themselves. 2) making the creation of an empty mailbox with the right permission part of my "installing a new user" script. Unfortunately, I don't have the HP-UX source code, so I can't dig any further trying to get around this problem. I hope you can help, if there's anything I can do, feel free to ask... ------------------------------------------------------------------------ Date: Wed, 19 Dec 90 04:48:12 -0800 From: [email protected] Subject: Sharied library paths under SunOS 4.1 There is a problem with the way sharied libraries are handled in SunOS 4.1 and the config files for x11r4 and mh-6.7. One of the changes between 4.0 and 4.1 is in the way the sharied libraries paths are handled. This difference unfortuately presents itself as a security problem. NOTE: this is not a bug or a hole in SunOS!!! >From the SunOS 4.1 manual page for ld(1): -Ldir Add dir to the list of directories in which to search for libraries. [...] When building a program in which one or more objects are loaded when -Bdynamic is in effect, those directories specified by -L options will be "remembered" for use at execution time. [...] Note that such directories are retained in exactly the form specified in the option, which means that relative directory specifications (i.e., not beginning with "/") will be evaluated relative to the current directory when the program is run, not just during the operation of ld. Unfortunately there are many program that use relative paths in there library path specifications. This normally would not present a problem except in the case of programs that are setuid to root (or any other userid). This if a program was compiled with the line: cc prog.c -o prog -L../lib The program will search the directory ../lib before searching the directories /lib /usr/lib or /usr/local/lib. This situation presents itself as a serious security problem since any user can create a file "../lib/libname.so.1.2" (where "libname" is a name of a library that prog loads at runtime) thus permitting the user defined code to be loaded in the executable and run. Two software packages that fall into thus situation are the X11 windowing system (release 4) and the rand mail handler (version 6.7). The best way to detect this is to trace the programs and watch for the accessing relative directory paths. for example: % mkdir lib test % ln -s /lib/libc.so.0.14 lib % cd test % trace prog open ("/usr/lib/ld.so", 0, 021044) = 3 [... deleted text ...] open ("../lib", 0, 01567340000) = 3 fstat (3, 0xdfff7b8) = 0 mmap (0xde02000, 8192, 0x3, 0x80000012, 4, 0) = 0xde02000 getdents (3, 0xde00100, 8192) = 60 getdents (3, 0xde00100, 8192) = 0 close (3) = 0 open ("../lib/libc.so.0.14", 0, 01567347240) = 3 read (3, "".., 32) = 32 mmap (0, 409600, 0x5, 0x80000002, 3, 0) = 0xdd76000 mmap (0xddd6000, 16384, 0x7, 0x80000012, 3, 385024) = 0xddd6000 [... deleted text ...] exit (0) = ? The X11 Windowing system has several setuid root programs (xterm and sometimes the X server). The best way to remedy this is to either install the X libraries first then recompile with the -L option deleted from the Makefile (as opposed to compiling the binaries staticly as suggested in other postings). Another system that has this problem is the Rand Mail Handler version 6.7. When compiled for the Pop mail system option inc, msgchk, popwrd, and pops are installed setuid to root. The reason inc(1) msgchk(1) are setuid to root is so that it can use a privileged port for the RPOP protocol. Thus it is safe to remove the setuid bit from the mh binaries if you are not running pop mail system. Or, of course, you can recompile without POP defined in the config file (unfortunatly POP is defined in the default config file). This problem will be fixed in the next release. If you have to run with POP I suggest or fix uip/Makefile yourself. If anyone else knows of any software packages that have this problem I will be interested in hearing about it. It is my recomindation to Sun that the "-Lload_path" be discontinued as a compiled in sharied library load path and that they add an new option for explicately defining a compiled in sharied library load path. ------------------------------------------------------------------------ Date: Fri, 21 Dec 90 13:00:41 CDT From: [email protected] (Bryan Koch) Subject: X security (fwd) I received the following message today from the person responsible for installing X-windows software in our field organization. - - - - - - - - - - - - - - - - MIT has finally publically acknowledged that dynamically linked setuid root programs, like xterm, have a potential security hole that will allow a user to gain superuser access. Basically, a user can impose their own X library in front of the default distributed lib via an environment variable. By trapping any well-known library call in their own, they can theoretically run as root. Our xterm is vulnerable. You may wish to remove setuid from xterm. Also vulnerable are xload and xcpustate. These programs require access to /dev/kmem; they should be altered to be setgid, owned by group kmem. There may still be risk in these programs. ------------------------------------------------------------------------ Date: Fri, 21 Dec 90 15:28:04 PST From: neil (Neil Gorsuch) Subject: Re: Suns 4.1 problems with X (fwd) [ This was posted in comp.windows.x and re-posted in alt.security - neil ] 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 [email protected] ------------------------------------------------------------------------ End of Core Security Digest Volume 1 Issue 8 **********************
END OF DOCUMENT
|ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved.|