The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #38 not known (1 file, 9158 bytes)
NOTICE: recognises the rights of all third-party works.


Subject: #38 - Unix Security Mailing List


	Admin and new members
	Re: revised tftpd writeup
	Re:  revised tftpd writeup
	Tech report on the Worm
	Re: revised tftpd writeup
	Re: revised tftpd writeup 
	Mailbridges - Bumf from DDN
	DDN MGT Bulletin #46
	Re:  revised tftpd writeup
	Another Sendmail Nasty.
	Re: FYI-- another sendmail nasty
	rumos + CERT
	Re: ~uucp
	Security Mailing Lists
	Re: Unix security list - status & more


Editors Corner.

Not much to say right now beyond Happy Holidays.

Newcomers to the list since last issue:
	Neil Webber (rutgers!harvard!cfisun!palladium!nw)
	Sam A. McCall III (lll-winken!!mccall)

Date: Fri, 25 Nov 88 11:50:12 est
From: John Robert LoVerso <loverso@xenna>
Subject: Re: revised tftpd writeup

> 		"A fourth alternative is to hack tftp to do a chroot call, and
> 		 put the (limited) set of files you allow to be copied in the
> 		 restricted directory.  This is similar to the technique used
> 		 with ftp.  It too requires source code.

Its not necessary to hack tftpd at all.  Just write a small setuid root
program called "chroot".  It chdir()s and chroot()s to its first argument,
setuid()s to the invoker's real uid, and then exec()s the program given by
the remaining arguments.

With that, copy /etc/tftpd to ~ftp/bin (make it mode 111) and change your
inetd.conf to read:

# a more "secure" tftp using the anonymous ftp area
tftp	dgram	udp	nowait	nobody	/usr/local/bin/chroot	chroot /usr/spool/ftp /bin/tftpd

John R LoVerso, Encore Computer Corp

Date: Sun, 27 Nov 88 22:21:58 EST
From: David Herron E-Mail Hack <>
Subject: Re:  revised tftpd writeup

Ok, using programs we have on our system here's what *I* would do,
and *do* do in certain circumstances

	tftp tcp/?? ... root ... <path>/chroot /u/tftp <path>/setuid tftp ...

That is, the tftp service starts up as root, so that it can run
chroot and chroot over to the safe area.  Then we have this program
called "setuid" which setuid()'s over to the first argument and 
runs the command on the rest of the command line.  We have a matching
program called setgid which has it's uses as well.

None of those programs are installed with setuid, because it's an
obvious security hole.
Subject: Tech report on the Worm
Date: Mon, 28 Nov 88 19:53:07 EST
From: Gene Spafford <>

My tech report on the Internet Worm is finally finished!  You can get a
compressed PostScript version of the formatted report via FTP as

1) ftp to  (
2) login for anonymous ftp
3) set binary mode on
4) cd pub/reports
5) get TR823.PS.Z
6) quit

Then uncompress the file and print it.  

If you have already orderd a paper copy of the report and you can FTP a copy
to print it yourself, please send me mail and cancel your request for a paper

If you cannot FTP a copy and you have already ordered a paper copy, have
patience.  As soon as they get printed they will be mailed -- before the
end of this week, I am told.

If you cannot FTP a copy and would like to order a paper copy, send me your
surface mail address and I will add your name to the list.


Date: 25 Nov 88 10:28:33 PST (Friday)
Subject: Re: revised tftpd writeup
From: "Lennart_Lovstrand.EuroPARC"

> Its not necessary to hack tftpd at all.  Just write a small setuid root
> program called "chroot".  It chdir()s and chroot()s to its first
> setuid()s to the invoker's real uid, and then exec()s the program given
> the remaining arguments.

Please either don't make that program setuid root or hardwire the directory
you are chrooting to!

If you leave it as is, any user on your system can make themselves a setuid
root shell by creating a mock root file system as in the following example:

|  % pwd
|  /home/lovstrand/foo
|  % ls -R
|  bin	chroot	etc
|  bin:
|  chmod	chown	sh	su
|  etc:
|  passwd
|  % cat etc/passwd
|  root::0:0:
|  % ls -l bin/sh
|  -rwxr-xr-x  1 lovstran    57344 Nov 25 17:59 bin/sh
|  % chroot . bin/su
|  # chown root bin/sh
|  # chmod u+s root bin/sh
|  # ^D
|  % ls -l bin/sh
|  -rwsr-xr-x  1 root        57344 Nov 25 17:59 bin/sh

--Lennart <Lovstrand.EuroPARC@Xerox.COM>
Rank Xerox EuroPARC, 61 Regent Street, Cambridge CB2 1AB, England
From: "Matt Crawford" <>
Subject: Re: revised tftpd writeup 
Date: Fri, 25 Nov 88 11:37:11 CST

>> Its not necessary to hack tftpd at all.  Just write a small setuid root
>> program called "chroot".  It chdir()s and chroot()s to its first argument,
>> setuid()s to the invoker's real uid, and then exec()s the program given by
>> the remaining arguments.

Don't make such a chroot program publicly executable, or it can
*still* be used to break in.  Remember, there's a reason that the
chroot() syscall is restricted to the superuser.


Date: Thu, 1 Dec 88 23:53:59 PST
From: (Brian Kantor)
Subject: Mailbridges - Bumf from DDN

As I received it:

Date: Thu, 1 Dec 88 13:03:30 PST
From: DDN Reference <NIC@SRI-NIC.ARPA>
Subject: DDN MGT Bulletin #46

DDN MGT Bulletin 46              DCA DDN Defense Communications System   
1 Dec 88                         Published by: DDN Network Info Center
                                    (NIC@SRI-NIC.ARPA)  (800) 235-3155

                        DEFENSE  DATA  NETWORK

                         MANAGEMENT  BULLETIN

The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities.  Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [ or] using login="anonymous" and password="guest".  The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).


Vulnerabilities exist for sites using Berkeley UNIX software or
software derived from Berkeley UNIX.  If you don't know if your
system uses Berkeley derived UNIX, contact your vendor.
The following direction has been prepared with assistance from
Berkeley and the Computer Emergency Reaction Team (CERT).  The
fix was independently validated.  If you are running FTP service
(with ftpd) then you will need to take the following steps:
Steps (1), (2), and (3) below should be taken NOW.  Follow up
shortly afterward with the remaining steps.
(1) Become root.
(2) Remove the FTP server program (ftpd).  One of the following
will work.  It is OK to do all four.
    rm /etc/ftpd
    rm /usr/etc/ftpd
    rm /etc/in.ftpd
    rm /usr/etc/in.ftpd
(3) EITHER reboot your system OR kill the running ftpd process.
(4) You are safe at this point, but your system is no longer
providing an FTP server.  (You have removed the FTP server
program from your disk.)  NOTE: You will still be able to use
FTP to obtain the fix from the Network Information Center (NIC),
but you will not be able to accept externally initiated file
(5) Obtain the ftpd fix from the NIC, from Berkeley, from the
CERT, or from your vendor.  Install according to the instructions.
NOTE: A version of the patch was disseminated about a month ago
from Berkeley, and many sites will already have installed the
fix.  The fix that is now being released is a slight improvement
to this earlier fix, and we suggest making this additional
The fix is available from the NIC through anonymous FTP.  To get
a copy:
    Open an FTP connection to SRI-NIC.ARPA
    Retrieve the contents of NETINFO:UNIX-FTPD.SHAR

(NOTE! If you obtained a copy of the fix prior to receiving this
 bulletin you will need to retrieve a fresh copy of the fix.)

For further information about the retrieval of the patch, call
the NIC at (800) 235-3155.
The fix is also available from the CERT; send computer mail to:
CERT [at] SEI.CMU.EDU to get the fix via computer mail.
(6) Once the fix is installed, you can resume providing an FTP
server.  For further information about the patch itself call
the Computer Emergency Response Team Coordination Center at
(412) 268-7090, Keith Bostic (Berkeley) at (415) 642-8524, or
Phil Lapsley or Peter Yee (Berkeley) at (415) 642-7447.
(7) Be sure you have installed the SENDMAIL and FINGERD fixes
that were previously provided (see DDN Management Bulletin #43).
It is important that these fixes be installed.  The FINGERD hole
is sufficiently dangerous that you should remove fingerd pending
installation of the fix.  Follow steps (1), (2), and (3) above
substituting "fingerd" for "ftpd".  The fixes for these problems
are also available from the NIC.
(8) If you are running an (obsolete) BSD 4.2 derived system, then
it is strongly advised that you obtain an upgrade to 4.3 (or its

Date: Fri, 25 Nov 88 11:10:19 PST
From: (Gary Winiger)
Subject: Re:  revised tftpd writeup

>	On some BSD systems, the "tftpd" daemon is an old security hole that is
>	nonetheless sometimes overlooked.  Exact details of *why* this daemon
>	is a risk to system security are beyond the scope of this mailing list.
>	However, the means to minimize "tftpd" risks are not.
[text deleted]
>	    people who have sources:
[text deleted]
>		"A fourth alternative is to hack tftp to do a chroot call, and
>		 put the (limited) set of files you allow to be copied in the
>		 restricted directory.  This is similar to the technique used
>		 with ftp.  It too requires source code.
>								Tony Nardo

	On SunOS 4.0 the tftpd daemon has a ``-s'' option which will take the
next parameter as a root directory for a chroot(2) call.  The daemon also is
coded to set the uid and gid to -2 (nobody).  Unfortunately the programmer
didn't check the return code from the set{uid,gid} system calls.  The sets
are failing due to missing casts on the -2 parameters.  The system calls
check to make sure that the parameter recieved has a value in the unsigned
short range (-1 is special cased).

	SunOS MLS (a B1 complient version of SunOS) has this bug fixed and
further requires that all access to tftp be done at ``system_low'' (the lowest
possible label of the system).  ``System_low'' is the label associated with 
public information, and by definition (even in the RFC), since there is no
possible authentication, tftp is restricted to public information.

P.S.  A bug report has been filed to fix the coding error in a future SunOS

Date: Fri, 2 Dec 88 11:27:37 PST
From: Russell Brand <wuthel!>
Subject: CERT

Arpa is in the progress of extrablishing a computer emergency reponse
team.  It's tweny-four number is 412 268 7090 and net address is

In theory they will become "the people to call" when "bad things

Currently they are creating a database of people and doing all the
things the one needs to do to start up such a center.  Seems like a
phone number that we should distribute out to people that will
hopefully never need it.

Subject: Another Sendmail Nasty.
Date: Sun, 04 Dec 88 13:14:17 PST
From: the terminal of Geoff Goodfellow <>

   220 xxxx Sendmail 5.xx/xx ready at Sun, 4 Dec 88 09:27:55 PST
   mail from:<geoff>
   250 <geoff>... Sender ok
   rcpt to:</tmp/foo>
   554 </tmp/foo>... Cannot mail directly to files
   rcpt to:</tmp/foo>
   250 </tmp/foo>... Recipient ok
   354 Enter mail, end with "." on a line by itself
   hi there.
   250 Ok
   221 xxxx closing connection
% ls -l /tmp/foo
-rw-rw-rw-  1 geoff         526 Dec  4 09:28 /tmp/foo
% cat /tmp/foo
>From geoff  Sun Dec  4 09:28:15 1988
Received: by xxxx (5.xx/xx)
        id AA20484; Sun, 4 Dec 88 09:28:15 PST
Date: Sun, 4 Dec 88 09:28:15 PST
From: geoff (Geoff Goodfellow)
Message-Id: <8812041728.AA20484@xxxx>
Apparently-To: </tmp/foo>

hi there.

Subject: Re: FYI-- another sendmail nasty
Date: Sun, 04 Dec 88 21:08:52 -0500
From: Steve Dyer <>

On XENIX 386 running sendmail 5.54, I get the behavior you describe.

On the RT running 4.3 and the "latest" sendmail (5.59), I get
RCPT TO: </tmp/foo>
554 </tmp/foo>... Cannot mail directly to files
RCPT TO: </tmp/foo>
550 </tmp/foo>... Addressee unknown
Subsequent attempts during this connection continue to return
"addressee unknown" each time the same file is given.
This pattern is repeated for each new file attempted to mail to.

Inspecting the code, 5.59 sets QDONTSEND|QBADADDR in its address
lists, which explains the particular error message we get in 5.59,
whereas 5.54 only sets QDONTSEND.  (Apparently, QDONTSEND don't
mean "don't send"!  I haven't explore why.)


Date: Sun, 4 Dec 88 20:41:53 PST
From: Russell Brand <wuthel!>
Subject: rumos + CERT

The people who get CERT mail are:

Patrick Barron
Richard Pethia
Robert Kirkpatrick
Larry Druffel
Edward DeHart


From: zardoz!ccicpg!uunet!attcan!utzoo!henry
Date: Sun, 27 Nov 88 00:20:52 EST
Subject: Re: ~uucp

> The ~uucp=/usr/spool/uucppublic notion goes back to V7.

We need to distinguish two issues here:  the location of uucp's home
directory, and the syntax used by a remote user to specify uucppublic.
(I speculate that Mark is a C shell user and hence is taking "~uucp"
to mean "uucp's home directory" rather than "the uucppublic syntax",
which is what I meant.)

Uucp's home directory was indeed uucppublic in V7.  However...

> Referring to ~uucp
> from another system via a uucp command is kind of pointless, since you can
> say ~ and get the same effect with less effort...

Not in V7 you couldn't; the V7 uucp did not understand "~/...".  I know,
I had to hack it in myself when the Software Toolchest insisted on using it.
(One caution:  the tape you got if you ordered V7 just before distribution
ended was not the same as the one we got at the beginning of distribution.
It is known that late V7s were slightly later software than early ones.
And 32V, on which 4BSD was based, wasn't quite exactly a V7 either.)

The custom of using "~uucp" to refer to uucppublic was widespread in the
early days of Usenet.  It appears that it either originated at Duke U.
(which was the original hub of Usenet) or was picked up by them from some
group within Bell.  It definitely appears in Duke's old "Setting up the Net"
document, and definitely does not appear in the V7 uucp documentation.
I had occasion to check on this, because the question "is this a documented
feature, which should be preserved for backward compatibility?" came up.
(And I just re-checked it -- I still have that stuff on line).

                                     Henry Spencer at U of Toronto Zoology

Date: Wed, 23 Nov 88 02:38:37 EST
From: (Mel Pleasant)
Subject: Security Mailing Lists

Guys, I've done a lot of thinking about everything that you've all had to
say.  I see no real problems with the existence of Neil and Andrew's lists.
I'm not sure I like the idea of the less restricted list's contents being
distributed in the more restricted list but that's a topic for another day.
I see no real differnce between Andrew's list and except
that Andrew has publicly declared himself to be alittle bit more careful
about who can get on the list.  Having yet another list of `fixers' as Mark
suggests I don't believe will work.  Remember, Gene's list started out as a
list of names appearing in headers when the problem first started.  The
people in those initial headers were considered "safe".  Essentially, the
recipients were vouched for by the sender.  The list grew and Gene merely
turned it into a mailing address when the names in the headers became so
unwieldy.  I believe that Andrew has simply formalized the process.

I'm beginning to think that the only problem is site validation.  Andrew
attempted to answer this concern in his first posting but I still don't feel
good about the answer.  For instance, he says that a "largish" site has to
be involved in the vouching process.  I've got a good idea who the largish
sites are.  I bet all of you do too.  I bet my list doesn't stack up the
same as any of yours though.  Maybe, besides the chosen references by the
applying site, some known set of "largish" sites must be involved as well.
One of them must back the application even if they are not given as a
referenece by the applying site.  This, I believe, will tend to tie the
community alittle closer together.  All members will be somehow related to
and around the core largish sites.  Without something like this, I fear a
tree with many long/extended branches where the folks vouching for others
aren't as interested or don't see the need for security concerns.  What do
you all think?

-- Mel
Date: Sat, 26 Nov 88 06:47:15 CST
From: John G Dobnick <>
Subject: Re: Unix security list - status & more

aburt@isis.UUCP (Andrew Burt):
> An ideal situation would be this: List member finds hole, submits to list,
> list members fix, tell vendors, (now the tricky part) vendors send out
> fixes to sites (particularly to those without source).
> I'm not against fixing problems, I'm against widely publicizing what those
> problems are.  There are always people who will abuse such information that
> comes their way.  I maintain that stopping N lazy hackers does much more
> good than informing N (busy) sysadmins what could happen.  Inform the N
> sysadmins how to FIX the problem, sure.  But don't give away any more
> information than is stricly needed to accomplish this.

I must (at least partially) disagree with you on this.  My experience with
(an admittedly small spectrum of vendors) is that (a) they send out patches
or replacement modules for the system to fix security holes, but *don't*
tell the customer *what* the security problems are [IBM and DEC some to 
mind here] and (b) there is NO guarantee that these patches won't make things
*worse*!  [and with Object Code Only releases, there is no way to tell!

My experience with Univac/Sperry/Unisys -- who supply source code for the
OS -- is that mistakes DO happen.  Emergency fixes ARE examined (by me!)
for "reasonableness".   I *have* been supplied fixes that (c) do not, and
NEVER COULD, work, (d) make things considerably worse, or (e) have absolutely
no relation to the problem at hand.  (They also mostly supply fixes that DO
work, but that's not the issue here.)

I am sure this happens with other vendors too, but with Object Code Only
systems, how do you know?  And if the vendor doesn't even tell you what
the changes are *supposed* to do...

It is for these reasons that I believe in the wide dissemination of security
hole (and other bug) information.  The more sources of information I
have, the better I am able to support my system.   I am extremely un-
comfortable depending ONLY on the vendor, who has his own reasons for NOT
telling me things I need to know.  Perhaps needless to say, I believe in 
the (generally) open discussion of security issues, on the theory that
the "bad guys" already know this, and that an open discussion will alert
the "good guys" to the problem, so that they can take action.

[BTW: I am on our *local* redistribution list for your security list,
and have been for quite some time -- like since it was last active.
I have yet to see a real message, other than the one you sent out
to the "old" list describing the new signup procedures, and which did
NOT (obviously) state that old members must "re-up" to stay on the list. 
Has anything new been sent out since then?  And is there an "archive" of
old issues, for those of us who have missed something?]

I thank you for your time in reading there random ramblings.  I hope I
have been able to affect your position, preferably in a direction closer
to mine.
John G Dobnick
Date: Sun, 27 Nov 88 16:23:30 PST
From: Steve Schoch <>
Subject: tftpd

> 		"A fourth alternative is to hack tftp to do a chroot call, and
> 		 put the (limited) set of files you allow to be copied in the
> 		 restricted directory.  This is similar to the technique used
> 		 with ftp.  It too requires source code.

If you run tftp from /etc/inetd.conf and don't want it to run as root,
you can simply refuse any requests with a '/' in the path name.  If you
can think of a way around that, let me know about it (and send me the
password file from this machine).

We have just these files in /tftpboot:

80668053, boot.hex, mon.exe



                        The UNIX Security Mailing List

                  Ignore the headers on this list and mail to:
                  ...!ncar!isis!security (mail for the list).
                  ...!ncar!isis!sec-request (administrativia).