Newsgroups: comp.unix.ultrix Path: utzoo!utgpu!watserv1!watcgl!idallen From: "Ian! D. Allen [CGL]" Subject: Ultrix x.x /etc/rc.local security holes via /tmp/t1 Message-ID: <1991Feb28.083356.6769@watcgl.waterloo.edu> Sender: idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada Date: Thu, 28 Feb 1991 08:33:56 GMT Lines: 32 You'll like this one; it's so simple. On Ultrix (any version), if you happen to have directories named /tmp/t1 or /tmp/t2, all kinds of nasty things will happen to your /etc/motd and /etc/gettytab because /etc/rc.local assumes it can write to these tmp names as files, and it edits the contents into your /etc/motd and /etc/gettytab. Nobody checks the error returns on any of these commands, so if the names are directories, well, you get a mess. The problem is even neater than this, since rc.local doesn't remove /tmp/t1 before writing into it, and the writing is done *before* clearing /tmp. So J.Q. Twit on your machine just makes this symlink: % ln -s /vmunix /tmp/t1 and the next time your machine reboots, your rc.local wipes out your vmunix. Actually, to be most destructive, link /tmp/t2 to /vmunix and /tmp/t1 to, say, /etc/passwd or something. Then rc.local will clobber both of them. Standard rules of (shell) programming: - pick unique names for your temp files - remove your temp files before you write into them - check all your error returns and don't barge ahead with bad data This problem with /tmp/t1 has been in every version of Ultrix since I started counting somewhere back around Ultrix 2.0-1. If DEC had an electronic SPR clearing house, you probably wouldn't be reading this now. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada