dhm@sei.cmu.edu (Daniel Miller) (04/30/88)
In the April 29 1988 issue of "Government Computer News" front page article titled "European Raids 30 Sensitive Systems", there is a paragraph which reads (quoted without permission): Once they saw his input, they determined he was using a bug in the GNU EMACS text editor to establish himself as a system manager by placing his own programs in the systems area. Not a technical explanation for sure... does anyone have any background on this "bug"??? ... Daniel "Dan" H. Miller Above opinions are my own Software Engineering Inst.; Carnegie-Mellon U.; Pittsburgh PA 15213; _USA_ dhm@sei.cmu.edu + 1 412 268-7728
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (04/30/88)
In article <5290@aw.sei.cmu.edu> dhm@sei.cmu.edu (Daniel Miller) writes: >In the April 29 1988 issue of "Government Computer News" front page >article titled "European Raids 30 Sensitive Systems", > Once they saw his input, they determined he was using a bug in the > GNU EMACS text editor to establish himself as a system manager by > placing his own programs in the systems area. Well, if you are so foolish to install GnuEmacs with permissions of 777 then there is a *very* large security hole. Just hack up your own GnuEmacs with something like the following trojan code included and cat it into the executable file. The next time root or someone su-ed to root edits something <blam> instant trojan shell. (and (zerop (user-uid)) (call-process "you know what goes here ... ;-)")) Moral: NEVER NEVER make executables world writable. (And READ those install scripts before using them!!!!) --- Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) 326 Commonwealth Ave. UUCP: mit-eddie!mgm.mit.edu!wolfgang Boston, Ma. 02115 TEL: (617) 267-4365
mike@ists (Mike Clarkson) (05/01/88)
Nothing in gnu Emacs is suid root (or anything else), nor is anything default world writable. Gnu should be no more "dangerous" than any other program. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
michael@pbinfo.UUCP (Michael Schmidt) (05/02/88)
Neulich schrieb dhm@sei.cmu.edu (Daniel Miller):
Once they saw his input, they determined he was using a bug in the
GNU EMACS text editor to establish himself as a system manager by
placing his own programs in the systems area.
One has to be very carefull in installing GNUEmacs. (Well, you
have always to be very carefull.) You can install Emacs with
#undef'ined HIGHPRIORITY, then forget that and set the suid bit
on Emacs on the owner to root. This will cause at least, that
your files owned by root. I didn't try processes, but ...
Michael Schmidt
--
Michael Schmidt, Universitaet-GH Paderborn, FB 17, Warburger Str.100,
D-4790 Paderborn, West Germany
Mail: michael@pbinfo.UUCP or michael%pbinfo@uunet.uu.netevan@csli.STANFORD.EDU (Evan Kirshenbaum) (05/03/88)
In article <220@corona.pb> michael@pbinfo.UUCP (Michael Schmidt) writes: >Neulich schrieb dhm@sei.cmu.edu (Daniel Miller): > Once they saw his input, they determined he was using a bug in the > GNU EMACS text editor to establish himself as a system manager by > placing his own programs in the systems area. > gnuemacs (like TECO emacs before it) has at least one interesting security hole. I doubt if it's considered proper to post it to the net, but you might consider the differences between find-file and insert-file and why you should probably only use the latter if you're suid root. (Also if you are writing applications which read files and which are likely to be run by root.) It's interesting that this hole is easy to spot if any editor OTHER than gnuemacs is used (even cat). As such, it's probably too risky to break into a system this way. I've heard that the old ITS emacs/mailer was susceptible to this, and you could send "letter bombs" to people who used it. --- Evan Kirshenbaum Stanford University evan@csli.Stanford.EDU ...!ucbvax!csli.stanford.edu!evan If you think my opinions represent this university, you haven't been on campus recently!
michael@pbinfo.UUCP (Michael Schmidt) (05/04/88)
Neulich schrieb mike@ists (Mike Clarkson):
Nothing in gnu Emacs is suid root (or anything else), ...
If you want to have Emacs run with a reniced priority, it can do
it for you and set its own priority to whatsoever you told the
config.h. BUT, it can do it only, if it is running suid root (of
course). Normally, if you have defined HIGHPRI in your config.h,
Emacs does an
#ifdef HIGHPRI
setpriority (PRIO_PROCESS, getpid (), HIGHPRI);
setuid (getuid ());
#endif HIGHPRI
in emacs.c. Then, if you forget, that you decided NOT to define
HIGHPRI and install it with suid root, you will have trouble.
So, as I mentioned earlier, you have to be carefull (as allways).
Michael Schmidt
--
Michael Schmidt, Universitaet-GH Paderborn, FB 17, Warburger Str.100,
D-4790 Paderborn, West Germany
Mail: michael@pbinfo.UUCP or michael%pbinfo@uunet.uu.netjfjr@MITRE-BEDFORD.ARPA (05/04/88)
I installed emacs on three different Suns. I am NOT a unix,
emacs,sun or security weenie. I just followed directions (well
with a little help from my friends ;}) It worked, I worked,
they worked, no problems. There is no mention of security
problems in the instructions ...Could it be that I am facing
the prospect of three Suns with gaping security holes that
I have no hope of understanding let alone fixing??
Jerry Freedman, Jr
jfjr@mitre-bedford.arparbj@ICST-CMR.ARPA (Root Boy Jim) (05/11/88)
Nothing in gnu Emacs is suid root (or anything else), nor is anything default world writable. Gnu should be no more "dangerous" than any other program. It doesn't have to be. Hint: what editor do you use as root? I distribute emacs around here, and there are a few machines I wouldn't mind having root access to. Do you think people are going to look thru all the lisp files to find my trojan horse? It could be anywhere, from startup.el to dired.el to rmail.el. Or it could be in a compiled .elc with the original source, virtually undetectable. Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611 (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Hello... IRON CURTAIN? Send over a SAUSAGE PIZZA! World War III? No thanks!
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (05/11/88)
In article <193@ists> mike@ists (Mike Clarkson) writes: >Nothing in gnu Emacs is suid root (or anything else), nor is anything >default world writable. Gnu should be no more "dangerous" than any >other program. >-- >Mike Clarkson mike@ists.UUCP >Institute for Space and Terrestrial Science mike@ists.yorku.ca >York University, North York, Ontario, >CANADA M3J 1P3 (416) 736-5611 Sorry mike. You are wrong. $ grep -n chmod gnuemacs-18.51/build-install gnuemacs-18.51/build-install:29:chmod 777 $BIN/{ctags,etags,emacs} PS. For those that haven't caught on yet, change the 777 to 755 --- Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) 326 Commonwealth Ave. UUCP: mit-eddie!mgm.mit.edu!wolfgang Boston, Ma. 02115 TEL: (617) 267-4365
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (05/12/88)
In article <220@corona.pb> michael@pbinfo.UUCP (Michael Schmidt) writes: >Neulich schrieb dhm@sei.cmu.edu (Daniel Miller): > Once they saw his input, they determined he was using a bug in the > GNU EMACS text editor to establish himself as a system manager by > placing his own programs in the systems area. I would strongly suggest that GNUemacs users who want security 1. Don't put (nil) in their load path 2. (setq inhibit-local-variables t) This eliminates some 'trojan horses'. 'Nuff said. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
les@chinet.UUCP (Leslie Mikesell) (05/13/88)
In article <7013@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: >>$ grep -n chmod gnuemacs-18.51/build-install >>gnuemacs-18.51/build-install:29:chmod 777 $BIN/{ctags,etags,emacs} >>PS. For those that haven't caught on yet, change the 777 to 755 >Has everyone forgot that a non-superuser writing to a s{ug}id file >CLEARS the s{ugid} bit(s)? [at least in every version of Unix I've >seen or heard of] S{ug}id is not the point here. Anyone can compile up a new version, put it in place and wait for root to execute it. A few added lines of code could easily make it create a copy of another program (like /bin/sh) in some hidden place and make it suid root. Les Mikesell
mike@turing.UNM.EDU (Michael I. Bushnell) (05/13/88)
The latest issue of CACM clears this whole thing up. The problem was in
movemail. From page 489:
As distributed, the program uses the UNIX Set-User-ID-to_root
feature; that is, a section of the program runs with system-manager
privileges. This movemail facility allows the user to change file
ownership and move files into another's directory. Unfortunately, the
program did not prevent someone from moving a file into the systems
area. Aware of this hole, the intruder created a shell script that, when
executed at root level, would grant him system privileges. He used the
movemail facility to rename his script to masquerade as a utility
periodically run by the system. When the script was executed by the system,
he gained system-manager privileges.
I hope this clears some of the confusion up. From the comment in
movemail.c, movemail can use POP to get the mail, and, to do so,
it must be setuid root. It is possible that this little used feature
was not extensively debugged, and that on the system in question, the
POP code was comipiled in and movemail made setuid root.
--
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
14308 Skyline Rd NE Computer Science Dept.
Albuquerque, NM 87123 OR Farris Engineering Ctr.
OR University of New Mexico
mike@turing.unm.edu Albuquerque, NM 87131
{ucbvax,gatech}!unmvax!turing.unm.edu!mikedaveb@llama.rtech.UUCP (It takes a clear mind to make it) (05/14/88)
Someone wrote: > Nothing in gnu Emacs is suid root (or anything else), nor is anything > default world writable. Gnu should be no more "dangerous" than any > other program. I've just gotten my May CACM, and I'm passing this on for those who haven't gotten it. There is a real problem, fix enclosed below. The seed of this discussion was the attribution that the West German cracker got root privs on an LBL machine from Gnu Emacs. The beginning of the article say "We captured all his keystrokes on a printer and saw how he used a subtle bug in the Gnu-Emacs text editor to obtain system-manager privileges." Leaks of this assertion prompted statements like the above "there is nothing setuid", and discussions about chmoding the executables to be non-writable (good advice, by the way.) the truth points at a real bug, caused by incorrect installation. Later the article says "typical of the security holes he exploited was a bug in the Gnu-Emacs program. This popular, versatile text editor includes its own mail system, allowing a user to forward a file to another user. As distributed, the program uses the UNIX Set-User-ID-to_root feature; that is, a section of the program runs with system-manager priveleges. This movemail facility allows the user to change file ownership and move files into another's directory. Unfortunately, the program did not prevent someone from moving a file into the systems area. Aware of this hole, the intruder created a shell script that, when executed at the root level, would grant him system priveleges. He used the movemail facility to rename his script as a utility periodically run by the system. When the script was executed by the system, he gained system-manager priveleges." No, movemail doesn't NEED to run as root, but often does. From INSTALL: * rmail gets error getting new mail rmail gets new mail from /usr/spool/mail/$USER using a program called movemail. This program interlocks with /bin/mail using the protocol defined by /bin/mail, which involves creating a lock file. It must be able to write in /usr/spool/mail in order to do this. my mail directory is: drwxrwxr-x 2 root wheel 2048 May 13 21:53 /usr/spool/mail/ so you could be setgid wheel instead of setuid root. However, the installation instructions don't say what to do, and it appears that some people (like me) take the easy way out... -rwsr-xr-x 1 root 18432 Aug 13 1986 etc/movemail* My 17.49 movemail.c has some stuff from Barry at BU to address the problem. I seem to recall he posted it, and it unfortunaely seems to have missed the official distribution: /* BZS 7/28/86 - to run suid we need to check permissions on files */ if(!insecure(inname) || !outsecure(outname)) fatal("Permission Denied"); /**/ and insecure(sp) char *sp; { struct stat st; if(stat(sp,&st) < 0) return(0); return(st.st_uid == getuid()); } outsecure(sp) char *sp; { char *cp; struct stat st; char buf[1024]; char *rindex(); strcpy(buf,sp); sp = buf; if((cp = rindex(sp,'/')) != 0) *cp = '\0'; else strcpy(sp,"."); if(stat(sp,&st) < 0) return(0); if((st.st_mode & S_IFDIR) == 0) return(0); return(!access(sp,W_OK)); } In contrast, the 18.51 code suggests it could be suid root, works around one of the downstream problems, but ignores the fundamental insecurity. #if defined(BSD) || defined(XENIX) /* In case movemail is setuid to root, make sure the user can read the output file. */ /* This is desirable for all systems but I don't want to assume all have the umask system call */ umask (umask (0) & 0333); #endif /* BSD or Xenix */ Barry's code should be put into your release if you have CACM readers at your site, and should be added to the regular distribution. The INSTALL and PROBLEMS files should say specifically how to install movemail, using setgid instead of suid. -dB {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.uucp
chris@mimsy.UUCP (Chris Torek) (05/15/88)
[discussion of holes in movemail] Note that if you are running 4.3BSD, you should define MAIL_USE_FLOCK and that the resulting program should not be setuid. The MAIL_USE_FLOCK code was done here (by Don Hopkins, prodded by me; we were running 4.2BSD here then, but we had already modified mail to use flock().) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mouse@mcgill-vision.UUCP (der Mouse) (05/16/88)
In article <227@corona.pb>, michael@pbinfo.UUCP (Michael Schmidt) writes: > #ifdef HIGHPRI > setpriority (PRIO_PROCESS, getpid (), HIGHPRI); > setuid (getuid ()); > #endif HIGHPRI > Then, if you forget, that you decided NOT to define HIGHPRI and > install it with suid root, you will have trouble. This is silly, particularly when interchanging the last two lines of code in the quoted section (the setuid() and the #endif) totally cures the problem. Why wasn't it written that way to begin with? The cost of two more (trivial) syscalls per run is low enough to be ignorable, especially when it insulates against this sort of hazard. Note, though, that if you don't define HIGHPRI and then install it setuid root, all files it creates will be root-owned, which will make the problem immediately visible. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
mike@ists (Mike Clarkson) (05/16/88)
In article <5263@bloom-beacon.MIT.EDU>, wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: > In article <193@ists> mike@ists (Mike Clarkson) writes: > >Nothing in gnu Emacs is suid root (or anything else), nor is anything > >default world writable. Gnu should be no more "dangerous" than any > >other program. > Sorry mike. You are wrong. > > $ grep -n chmod gnuemacs-18.51/build-install > gnuemacs-18.51/build-install:29:chmod 777 $BIN/{ctags,etags,emacs} I stand corrected: emacs is world writable. (I assume this has something to do with RMS's philosophy - if you can give it away, you should be able to delete it ?:-) Personally I think this is wrong. But it is not suid root. As for trojan horses I consider them to be unlikely, though I suppose it would be wise only to use vi while su'ed to root. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
michael@pbinfo.UUCP (Michael Schmidt) (05/17/88)
Neulich schrieb chris@mimsy.UUCP (Chris Torek):
Note that if you are running 4.3BSD, you should define MAIL_USE_FLOCK
and that the resulting program should not be setuid.
And using s-bsd4-3.h at least doesn't hurt under SunOS 3.4. So
you can use 'flock' and there is no need for movemail to be
setuid.
Michael Schmidt
--
Michael Schmidt, Universitaet-GH Paderborn, FB 17, Warburger Str.100,
D-4790 Paderborn, West Germany
Mail: michael@pbinfo.UUCP or michael%pbinfo@uunet.uu.netmike@ists (Mike Clarkson) (05/18/88)
In article <2086@rtech.UUCP>, daveb@llama.rtech.UUCP (It takes a clear mind to make it) writes: > Someone wrote: > > Nothing in gnu Emacs is suid root (or anything else), nor is anything > > default world writable. Gnu should be no more "dangerous" than any > > other program. > > I've just gotten my May CACM, and I'm passing this on for those who > haven't gotten it. There is a real problem, fix enclosed below. Thank-you for the excellent posting: I was the "Someone" and I'm much relieved to know that the problem has been clearly identified. We don't run movemail suid here because we are using Suns with the flock system call to lock the file. It's always amazing to see how fast a little suid program can cause havoc. Are there many sites who's mailers write temp files in /usr/spool/mail to lock the files? Or do most people have flock or its equivalent? While we are on the subject, perhaps we should also replace flock with lockf for sites that have it. Then people can remote mount /usr/spool/mail from clients on a network and still have locking across nfs. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
rbj@ICST-CMR.ARPA (Root Boy Jim) (05/26/88)
> $ grep -n chmod gnuemacs-18.51/build-install > gnuemacs-18.51/build-install:29:chmod 777 $BIN/{ctags,etags,emacs} You mean you still use build-install when there's a Makefile available? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
mike@ists (Mike Clarkson) (05/28/88)
In article <238@corona.pb>, michael@pbinfo.UUCP (Michael Schmidt) writes: > Neulich schrieb chris@mimsy.UUCP (Chris Torek): > Note that if you are running 4.3BSD, you should define MAIL_USE_FLOCK > and that the resulting program should not be setuid. > > And using s-bsd4-3.h at least doesn't hurt under SunOS 3.4. So > you can use 'flock' and there is no need for movemail to be > setuid. > > Michael Schmidt Can somebody set me straight on this? Just because the system has flock doesn't mean that the /bin/mail on the system uses it. On a Sun, /bin/mail uses lock files (/usr/spool/mail/fredboobar.lock). See the man page for /bin/mail. If your code uses flock, /bin/mail won't neccessarily honour it. Note that the default for GNU on a Sun does *not* use FLOCK. Add to this two further complications: on a Sun, whether you use /bin/mail or /usr/ucb/mail depends on your path. Does /usr/ucb/mail use FLOCK or spool lock files? And if you are running on a Sun, there's probably another Sun or two on your network. If you run movemail on a client, you can run into real problems if you are sharing /usr/spool/mail over NFS. If you are running movemail on the client with FLOCK defined, and the server is trying to write to your mail file, the server can do what it likes. You'd have to have everyone using lockf to stop this. (See the man pages on flock for this.) This is an important issue, because not only can your mailbox get trashed, but other people are starting to use the movemail code for other mailers as well. Elm just had patches posted to use the movemail code for that mailer. On Suns (sun 3.5), we run movemail sgid daemon, and /usr/spool/mail 775, with no FLOCK defined. We share our mailhost's /usr/spool/mail with the clients over NFS. Does anyone have sources handy to see how /bin/mail and /usr/ucb/mail do file locking on a Sun? -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611