The 'Security Digest' Archives (TM)

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

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #13 1991-03-05 (1 file, 1822 bytes)
SOURCE: http://securitydigest.org/exec/display?f=core/archive/113.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Tue Mar 5 11:34:43 PST 1991
Subject: Core Security Digest V1 #13

Core Security Digest Volume 1 Issue 13

subject(s):

            Recent CERT advisory about SunOS /bin/mail security hole
            more on core list change

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:                              core@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   core-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             core-request@uninet.cpd.com


------------------------------------------------------------------------

Date: Fri, 1 Mar 91 17:50:31 -0500
From: steve@umiacs.UMD.EDU (Steve D. Miller)
Subject: Recent CERT advisory about SunOS /bin/mail security hole

I guess this keeps me on the list for the next year. (-:  I don't remember
seeing this discussed; my apologies if this is old news to everyone.

   For those who don't know, it appears that the /bin/mail security hole
recently discussed by CERT applies to the Unix products offered by many
vendors.  I have managed to disassemble the relevant portions of the fixed
SunOS binary, and have verified that the same stack-clobbering problem
exists in all of the following:

	- SunOS, as described in the CERT advisory (obviously); curiously
		enough, I don't think this applies to SunOS 3.2 (!)
	- Ultrix 3.1
	- Ultrix 4.0
	- Encore UMAX 4.3
	- Versions of 4.XBSD that provide /bin/mail (BSDs before Reno) or
		/usr/libexec/delivermail (I think the latter was on the
		Reno tape, but I'm not 100% sure of that).  If you're
		running Reno, and can get a copy of /usr/libexec/mail.local,
		you're probably better off.

   The particular gotcha fixed by the SunOS patch (or so I am led to
believe, by my lame-ass attempt at disassembly) is at the beginning of the
sendrmt() routine, where everything up to the first !  in the name argument
is copied into the rsys array, regardless of whether or not one runs off the
end of the array.  Sun also apparently changed some code early on in main();
the code used to assume that it should go into mail-printing mode if the
second character of the second-to-last argument was an `f', regardless of
whether or not the first character was a `-'.  I don't think that has any
security implications, but hey, maybe I'm wrong.

   I have (or will have by early next week) fixes for all of these systems.
I have many of these changes completed already, but I put in a lot of other
/bin/mail fixes (to cure a variety of *other* stack-clobbering problems,
both potential and -- no doubt -- imaginary; see in particular the handling
of -r and truename in bulkmail(), which I think might be a real problem) and
I want to inflict this on the local user community for a little bit first.

   I presume that CERT knows about all this, but I've dropped them a note
Just In Case.

------------------------------------------------------------------------

Date: Tue, 5 Mar 91 11:33:07 PST
From: neil (Neil Gorsuch)
Subject: more on core list change

[ The "reports" that are now required at least once a year for most members
to remain on this list may consist of any of the following:

1. An explanation of a new security hole, with COOKBOOK DIRECTIONS on how
   to exploit it if it's not obvious.
2. A clarification of an announced, but not explained, security hole.

In the words of someone else, "meat, we need meat".

Neil ]

------------------------------------------------------------------------

        End of Core Security Digest Volume 1 Issue 13
        **********************

END OF DOCUMENT