Ultrix x.x /etc/rc.local security holes via /tmp/t1

[Ian! D. Allen [CGL]]

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 at watcgl.uwaterloo.ca idallen at watcgl.waterloo.edu
 [129.97.128.64]  Computer Graphics Lab/University of Waterloo/Ontario/Canada