The 'Security Digest' Archives (TM)

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

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #23 not known (1 file, 4732 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/123.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Security Digest Volume 1 Issue 23

subject(s):

            Cuserid() is a security hole
            Need list of names
            sounds like GAtech has discovered that Gene is no longer there ...
            security-emergency usage
            Re:  news hosing
            my apology
            setuid scripts
            client-address-restrictor for daemons

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

Date: Tue, 30 May 89 17:52:30 CST
From: David Newall  <uunet!munnari!PISA.sait.oz.au!david>
Subject: Cuserid() is a security hole

[ There is an on-going debate in comp.unix.wizards about this - neil ]

According to the manual, cuserid(3) is supposed to "return the character
login name of the user".  I interpret this as meaning it will return the
login name of the invoker.  This is _not_ what cuserid() does.

In fact, cuserid() returns the login name of the person who is logged in
on the terminal pointed to by stdin, stdout or stderr.  So if one were to
close stdin (or point it at a text file), close stderr, and point stdout
at someone else's terminal, cuserid() would return that person's login
name, and not yours.  A great pity if the program you're running relies
on cuserid() to identify the caller.

Oh, and the same applies for getlogin().

So people, do not, absolutely do not, rely on these functions to identify
the user.  Use getuid() or geteuid() instead.

I personally think this is an important security hole.  Consider, for
example, set gid mail programs...

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

Date: Tue, 30 May 89 22:46:29 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: Need list of names

For purposes of checking for weak passwords, I'de like to obtain a
list of common names (Al, Fred, George... Alice, Kathy, Susan...)
Does anybody have such a list online they'd be willing to share with
me?

Please e-mail -- don't post.

Thanks in advance!

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

Date: Thu, 1 Jun 1989 2:46:12 CDT
From: Werner Uhrig <uunet!rascal.ics.UTEXAS.EDU!werner>
Subject: sounds like GAtech has discovered that Gene is no longer there ...

[ This kind of posting mght be more appropriate in misc.security - neil ]

 From: daves@pravda.gatech.edu (Dave Smith)
 Newsgroups: rec.humor.funny
 Subject: intelligence at GA Tech
 Keywords: true, funny
 Message-ID: <3384@looking.UUCP>
 Date: 28 May 89 23:30:03 GMT

This is a bit old, but i'v just finally got around to mailing it.

Dr. Richard LeBlanc, associate professor of ICS, was quoted in "The Technique,"
Georgia Tech's newspaper, last November (after the computer worm hit the net):

"It turned out that the worm exploited three or four different holes in the
system. From this, and the fact that we were able to capture and examine some
of the source code, we realized that we were dealing with someone very sharp,
probably not someone here on campus."

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

Date: Thu, 8 Jun 89 02:09:00 PDT
From: neil (Neil Gorsuch)
Subject: security-emergency usage

A security list posting was recently sent out via the "security-emergency"
posting address that should have been sent via the regular "security" posting
address.  I implemented the security-emergency avenue for things like this:

INTERNET VIRUS XXVII IS LOOSE, DISCONNECT SUN MODEL 973/60's!
FILE /tmp/stop_it_pretty_please_we_surrender STOPS THE UUCP SENDMAIL VIRUS!

Hopefully, security-emergency won't be needed very often, if at all 8<).

[ The next two messages are about the erroneous posting. - neil ]

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

Date: Tue, 6 Jun 89 10:44:24 MDT
From: uunet!cadnetix.COM!rusty (Rusty)
Subject: Re:  news hosing

In 'security-alert' mailing list I (stupidly, I might add) said somthing like:

        ...delete 190 good newsgroups and to add 10 bogus groups....
        .... contact me.... blah blah

Well, I apologize for panicing (panicking?) when 190 good (and moderately
important) newsgroups went <flush> yesterday.  When I realized that it was
not such an emergency I wished for a way to un-mail my letter, but it was
too late by then (hours had passed).  We recently lost our experienced
news and system administrator here at Cadnetix, and so our inexperienced
replacement obeyed what he thought was a valid command.  I did not stop
long enough to realize that these sort of 'commands' are probably very common.
So, I jumped to the conclusion that someone had managed to fool uunet into
posting a rmgroup (or whatever it was) message.  Thus, I thought it was
a violation of security.  And, since misc.security had been one of the groups
deleted, I could not go in and ask there.  (And, with misc.security deleted,
my 'security sensor' overrode my common sense.  Since I had seen nothing
about this on any of the security groups I had left to me, I assumed the
worst.

Again, I apologize for the panic, I apologize for the '(ab)use' of the security
emergency alert mailing list.  Please, everyone, turn your flamethrowers off now,
I'm more than burnt to a crisp.  But, in the future, it might do to remember that
sometimes people get put in situations where they are in over their heads (due
to knowing more than the average joe, but not quite enough for the task at hand)
and where they take the available information and jump to (wrong) conclusions.

Oh, well.  Its nice to know that, had it been a real emergency, people are there...

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

Date: Tue, 6 Jun 89 10:46:26 MDT
From: elroy!ames!ncar.UCAR.EDU!boulder!cadnetix.COM!rusty (Rusty)
Subject: my apology

Oh, one other thing - thanks to all who took the time to respond.

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

Date: Tue, 13 Jun 89 12:12:22 CDT
From: Tom Christiansen <uunet!uxc.cso.uiuc.edu!convex!tchrist>
Subject: setuid scripts

i know this has all been hashed over before, but i can't seem
to find a good write-up on the precise nature of the kernel
bug involving resolution of symlinks and when you look at which
inode.  could someone elucidate a bit on this?

[ I am almost done setting up zardoz as an archive server.  There will be
a seperate server entry point for the security archives that will be netlib
based, but will only mail archived security digests to mailing addresses
on the security list.  More details when it's done. - neil ]

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

Date: Tue, 13 Jun 89 09:52:24 PDT
From: uunet!zapi!gpz (G. Paul Ziemba)
Subject: client-address-restrictor for daemons

[ This is the last message in this digest - neil ]

Hi folks,

We (3com) recently connected one of our vaxes to the Internet,
and in the process of making everything secure I wrote
this code to restrict access from the outside. It's
a quick hack, and there are improvements that could be made
I'm sure, but it does an adequate job.

FUNCTIONALITY:
--------------

This routine, when called from unix server code (e.g., rlogind)
immediately after the getpeername call, checks the internet
address given against a list of address matching patterns in the
file /etc/secure-addrs. Address matching patterns are similar to
filename matching patterns in the c-shell, with the following
expansion characters supported: *,?,[,],{,}.

The unix _exit() function can be called if the return value
of this function is false (zero), thus restricting server use
to the specific addresses or ranges of addresses in the file.

Attempts from unlisted addresses can be logged, as shown in the
sample server code below.

REDISTRIBUTION, COPYRIGHTS, ETC.
--------------------------------

The routine secure_addr.c, written by me (G. Paul Ziemba), is hereby
released into the public domain provided that proper attribution
is left in the source code (i.e., header comments). Feel free
to use it, modify it, etc.

TYPICAL SERVER MODIFICATION:
----------------------------

I just compiled the routine with cc -c to produce a .o file, then
modified the servers to call secure_addr. Recompiling the servers
against the .o file (and with the appropriate compiler flag)
completed the process.

Here is a sample from our rlogind.c:

Additions are bracketed by #ifdef INET_SECUREs.
Note that <arpa/inet.h> had to be included in order to make inet_ntoa()
work. syslog logs the offending source address in human-readable form.

------------------------------------------------------------------------
#ifdef INET_SECURE
#include <arpa/inet.h>
#endif /* INET_SECURE */

[...some other #defines...]

extern  int errno;
int     reapchild();
struct  passwd *getpwnam();
char    *malloc();

/*ARGSUSED*/
main(argc, argv)
        int argc;
        char **argv;
{
        int on = 1, fromlen;
        struct sockaddr_in from;

        openlog("rlogind", LOG_PID | LOG_AUTH, LOG_AUTH);
        fromlen = sizeof (from);
        if (getpeername(0, &from, &fromlen) < 0) {
                fprintf(stderr, "%s: ", argv[0]);
                perror("getpeername");
                _exit(1);
        }
#ifdef INET_SECURE
        if (!secure_addr(&from)) {
                syslog(LOG_WARNING, "rlogind: Permission denied (%s)",
                        inet_ntoa(from.sin_addr));
                _exit(1);
        }
#endif /* INET_SECURE */
        .
        .
        .
        .
        .
-------------------------------------------------------------------------



The code itself:

---cut here---
/*
 *
 *      secure_addr.c   05/23/89 gpz "G. Paul Ziemba"
 *                      (gpz@3com.com or zapi!gpz)
 *
 *              (I'd be happy to hear from anyone making
 *              improvements to this code, so I can incorporate
 *              them here, too)
 *
 *              This function takes a struct sockaddr_in pointer
 *              and tries to match the internet address part
 *              against tokens in the file
 *              /etc/secure-addrs. Tokens in this file are
 *              strings of the form d.d.d.d where d is a
 *              decimal number between 0 and 255 inclusive.
 *              The token may also contain the magic characters
 *              *,?,[,],{, and }, which are interpreted in the
 *              same way that the c-shell expands file names.
 *
 *              One token is allowed per line. Comments start
 *              with '#' and end with a newline.
 *
 *              EXAMPLES (Note periods before wildcards!!)
 *
 *              129.213.0.15
 *              129.213.*
 *              129.21[23].*
 *              129.213.{120,10}.*
 *
 *              Thanks to koblas@yoyodyne.mips.com, who (I think)
 *              wrote the glob() function.
 */


#include <ctype.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

END OF DOCUMENT