From owner-freebsd-security Sun Nov 26 05:31:44 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA06928 for security-outgoing; Sun, 26 Nov 1995 05:31:44 -0800 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA06923 for ; Sun, 26 Nov 1995 05:31:36 -0800 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id VAA03492 for freebsd-security@freebsd.org; Sun, 26 Nov 1995 21:31:17 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-security@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-security@freebsd.org Date: 26 Nov 1995 21:31:13 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <499q71$3d0$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199511250241.CAA02783@genesis.atrad.adelaide.edu.au>, <199511250818.AAA28898@precipice.shockwave.com> Subject: Re: I wonder how much trouble something like this would be to do? :) Sender: owner-security@freebsd.org Precedence: bulk pst@shockwave.com (Paul Traina) writes: > It uses the tun device, and raw IP sockets for its transport. (What's > the point of wrapping IP in TCP? IP is unreliable anyway 8)) >There are advantages if you're running a stream cypher protocol like RC4. I've got a working prototype using "any backend transport you care to implement" - I've been testing it with ssh, although I plan to use either udp or raw IP as well for beating international packet losses.. :-) It only took an hour or so to implement, and even then I wasn't working at it exclusively... Cheers, -Peter From owner-freebsd-security Tue Nov 28 07:38:57 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA12615 for security-outgoing; Tue, 28 Nov 1995 07:38:57 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA12599 for ; Tue, 28 Nov 1995 07:38:30 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA03560; Tue, 28 Nov 1995 10:38:08 -0500 Date: Tue, 28 Nov 1995 10:38:08 -0500 From: "Garrett A. Wollman" Message-Id: <9511281538.AA03560@halloran-eldar.lcs.mit.edu> To: Michael Smith Cc: security@freebsd.org Subject: Re: I wonder how much trouble something like this would be to do? :) In-Reply-To: <199511250241.CAA02783@genesis.atrad.adelaide.edu.au> References: <199511241604.SAA13149@office.elvisti.kiev.ua> <199511250241.CAA02783@genesis.atrad.adelaide.edu.au> Sender: owner-security@freebsd.org Precedence: bulk < said: > It uses the tun device, and raw IP sockets for its transport. (What's > the point of wrapping IP in TCP? IP is unreliable anyway 8)) It would be better to copy the style of the `eon' network interface, and use IPsec and IP-in-IP encapsulation. I built something similar (without security) about three years ago in an ill-fated attempt to completely redesign the IP multicast support. (Hint: IP multicast includes support for tunneling already.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-security Tue Nov 28 20:05:54 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA06567 for security-outgoing; Tue, 28 Nov 1995 20:05:54 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA06557 for ; Tue, 28 Nov 1995 20:05:44 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id UAA03705 for ; Tue, 28 Nov 1995 20:03:40 -0800 Prev-Resent: Tue, 28 Nov 1995 20:03:39 -0800 Prev-Resent: "security@freebsd.org " Received: from freefall.freebsd.org (freefall.cdrom.com [192.216.222.4]) by time.cdrom.com (8.6.12/8.6.9) with ESMTP id UAA03687 for ; Tue, 28 Nov 1995 20:01:29 -0800 Received: from violet.berkeley.edu (violet.Berkeley.EDU [128.32.155.22]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA06408 for ; Tue, 28 Nov 1995 20:03:25 -0800 Received: from diva.EECS.Berkeley.EDU by violet.berkeley.edu (8.7.1/1.33r) id UAA29817; Tue, 28 Nov 1995 20:03:22 -0800 Received: from euler.Berkeley.EDU (euler.Berkeley.EDU [128.32.142.1]) by diva.EECS.Berkeley.EDU (8.6.10/8.6.4) with ESMTP id UAA18866 for ; Tue, 28 Nov 1995 20:01:13 -0800 Received: from usblues.twilight.com by euler.Berkeley.EDU (8.6.10/1.28) id UAA05122; Tue, 28 Nov 1995 20:01:11 -0800 Received: (from tom@localhost) by usblues.twilight.com id UAA13167 for hackers_guild@euler.Berkeley.EDU; Tue, 28 Nov 1995 20:01:08 -0800 From: Tom Markson Message-Id: <199511290401.UAA13167@usblues.twilight.com> Subject: SKIP Source is released To: hackers_guild@euler.Berkeley.EDU Date: Tue, 28 Nov 1995 20:01:06 -0800 (PST) X-Mailer: ELM [version 2.4 PL24 PGP5] Content-Type: text Resent-To: security@freebsd.org Resent-Date: Tue, 28 Nov 1995 20:03:39 -0800 Resent-Message-ID: <3703.817617819@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk Hi, I thought the people on this list would find this interesting... ------------------------------------------ Sun Microsystems is pleased to announce the publicly available source code for SKIP (Simple Key Management for Internet Protocols). Here are some extracts from the README to explain what it can do. Check out http://skip.incog.com for more information. --Snip-- ALPHA 1 Release of SKIP Reference Source for SunOS 4.1.3 -------------------------------------------------------- SKIP is a Key-management protocol for IP based protocols. It is an acronym for Simple Key-management for Internet Protocols. SKIP is documented in the SKIP IETF IPSEC draft included in this directory as draft-ietf-ipsec-skip-05.txt. The most recent SKIP draft is always available at http://skip.incog.com and the Internet-Drafts directories. >From this public source release, you can build a fully functional IP-layer encryption package which supports DES and Triple-DES for SunOS 4.1.3. This means that every IP networked application can have it's network traffic encrypted. Unlike application level encryption packages, this package encrypts IP packets. Thus, applications do not need to be recompiled or modified to take advantage of encryption. The SKIP source is possible through the efforts of engineers in Sun Microsystems Internet Commerce Group. The developers and designers are Ashar Aziz, Tom Markson, Martin Patterson, Hemma Prafullchandra and Joseph Reveane. Linda Cavanaugh worked on the documentation. The package compiles under both the SunPro compiler and GCC. We expect that this release should port without too much pain to any operating system which uses BSD style networking (mbufs). A legal warning: Because this package contains strong encryption, the Software must not be transferred to persons who are not US citizens or permanent residents of the US, or exported outside the US (except Canada) in any form (including by electronic transmission) without prior written approval from the US Government. Non-compliance with these restrictions constitutes a violation of the U.S. Export Control Laws. This source release may be used for both commercial and noncommercial purposes, subject to the restrictions described in the software and patent license statements. Furthermore, Sun Microsystems has licensed the Stanford public key patents from Cylink Corp. which are available to users of this package on a royalty free basis. The patent statement is in README.PATENT. Be sure to read this, as it contains some restrictions and other important information. Also included in this release is a high speed Big Number package written by Colin Plumb. bnlib/legal.c contains Colin's software license statement. Features -------- 1. SKIP V2 compliant implementation using ESP encapsulation. 2. Support for DES/3DES for traffic and key encryption. 3. Diffie-Hellman Public Key Agreement based system. 4. Full Support for manual establishment of master keys. 5. Support for multiple NSIDs and multiple local certificates. 6. GUI tool for user friendly manipulation of access control lists and key statistics. 7. Command line tools for manipulating access control lists, etc. 8. Implementation of the Certificate Discovery protocol fully integrated into SKIP. 9 Implementation of X.509 public key certificates. 10. Implementation of DSA signature algorithm for certificate signatures. 11. Implementation for MD2, MD5 and SHA message digest algorithms. 12. Implementation of ASN.1 DER encoding/decoding. 13. SunScreen(tm) SKIP compatibility mode. 14. Implementation of hashed public keys as defined in the SKIP draft. Implementation of programs to generate hashed public keys. 15. Certificate utilities to convert X.509 Certificates to hashed keys and print both X.509 and Hashed certificates. 16. High performance Big Number library for Diffie-Hellman calculations. 17. Implementation is effectively "public domain" and may be used both commercially and non-commercially. 18. Patent Agreement with Cylink allows roylaty-free use of the Diffie-Hellman and other Stanford patents with this package for commercial and non-commercial use. Read README.PATENT for some restrictions. 19. Inclusion of prime generation program used to generate the primes in SKIP draft. From owner-freebsd-security Wed Nov 29 03:19:38 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA02855 for security-outgoing; Wed, 29 Nov 1995 03:19:38 -0800 Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA02760 for ; Wed, 29 Nov 1995 03:18:34 -0800 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id NAA02155 for security@freebsd.org; Wed, 29 Nov 1995 13:15:24 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id MAA28875 for ; Wed, 29 Nov 1995 12:01:33 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id MAA15889 for security@freebsd.org; Wed, 29 Nov 1995 12:01:31 +0200 From: "Andrew V. Stesin" Message-Id: <199511291001.MAA15889@office.elvisti.kiev.ua> Subject: Re: chroot/setuid vs type enforcement (fwd) To: security@freebsd.org Date: Wed, 29 Nov 1995 12:01:31 +0200 (EET) X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 5204 Sender: owner-security@freebsd.org Precedence: bulk Here are interesting thoughts about hardening security of chrooted environment... Forwarded message: # From: "Marcus J. Ranum" # Message-Id: <199511290431.XAA20148@switchblade.iwi.com> # Subject: Re: chroot/setuid vs type enforcement # To: jeromie@garrison.com # Date: Tue, 28 Nov 1995 23:31:00 -0500 (EST) # Cc: firewalls@GreatCircle.COM, mjr@iwi.com # Organization: Information Warehouse! Inc, Baltimore, MD # Phone: 410-889-8569 # Coredump: Infocalypse Now!!! # # jeromie@garrison.com writes: # > As far as being able to remove system calls from accessibility, I would # >like to hear about if any firewalls have done this. Removing the system calls # >from accessibility would limit potential vulerabilities. # # It's not hard to do; you simply comment them out of the kernel # or appropriately modify the kernel. I staunchly refuse to accept that # these things are rocket science, or even very difficult; the kernel # is just a program and if you are smart enough to use a system you can # get source for then it's easy to fix. # # Let's examine one possiblity. Suppose I am using chroot() to # protect my firewall. And the argument I want to make is that I want # to be sure, for sure, that nobody can tweak a buffer overrun and # call a socket from inside the chrooted area. # # [This is all from BSDI/NetBSD.] # uipc_syscalls.c, at around line 79, has the source code # for the socket() system call. vfs_syscalls.c, at around line 613 # has the source code for the chroot() system call. # # You'll notice, in chroot() that the proc struct (the process # table slot) for each process has the vnode of the process' root # file system in it. That's hung off the p->p_fd, which is the # process' file descriptor table - which in turn stores the # root vnode as p->p_fd->fd_rdir. With me so far? :) # # Now, there's a vnode that's stashed away (see vfs_lookup # and the system init code in init_main.c) and it's called "rootvnode." # Given it's name, you won't be shocked to discover that it's the # root filesystem's "top" vnode. # # So - we can assume that if a process' root vnode is not # the same as the system's root vnode, then it's been chrooted. TA-DA! # It actually may be simpler than that, since line 127 of vfs_lookup.c # implies that processes which have NOT been chrooted have a root # vnode of NULL: # # if ((ndp->ni_rootdir = fdp->fd_rdir) == NULL) # ndp->ni_rootdir = rootvnode; # # Let's assume that's correct. Now we "harden" our kernel # by altering the socket() system call thusly: # # uipc_syscalls.c line 78: # # if(p->fdp->fr_rdir != NULL) # return(EPERM); # # WHOAH! It took me 24 lines to explain it, and 2 to code it! # What this means is that a chrooted process that does a socket() will # get a permission denied. Maybe that's a bit too brute force. We # might want to put the code into connect() instead and only let the # process connect to localhost - or whatever. You get the idea. This # is trivial code that takes minutes to implement. # # The *TRICK* is implementing the RIGHT code in the RIGHT # place. For this example, if I put it in socket() - what about other # forms of IPC? See - I'd need to be darn careful to cover all the # angles. That's nothing to do with the formal properties of my # protection model; that's a simple matter of Getting The Code Right # and Damn The Formal Handwaving. # # >In summary, the strongest feature touted by sctc is that chroot() is vulerable # >to buffer overflows. In my eyes, this means that if a proxy were to get # >subverted, it would not take much to subvert the chroot() setuid() calls and # >gain full access over the firewall. I would like to hear if anyone has # >comments on this issue..?? # # Chroot() is not "vulnerable to buffer overflows" -- processes # that have chrooted are potentially vulnerable to buffer overflows. # # Subverting a chroot() that has been correctly combined with # a setuid() is *HARD* - if the chroot() area is set up correctly and # the kernel is implemented correctly, and your system doesn't # automatically trust connections from itself, then you are not going # to be able to do a lot of damage. But, as I've shown above, there # are lots of ways to address that kind of thing. You can make it # impossible to break out of a chroot simply by setuid()ing to a non # root user - then you are no longer permitted to chroot again. If # there's no way in the chroot area to get privs, then there's no # way out other than via a socket - and you can nail that dead with # 2 lines of code. # # The easiest way, however, is to be REAL careful about not # having buffer overruns in your code. :) # # This whole game is about being REAL careful about your code. # Whether it's code in the kernel or code in user space, it's just # code. Because someone's waved the orange-book over the hacks they # made to the kernel doesn't make them any fancier than the kind of # hackery I described above (but for sure they're better documented!) # # mjr. # -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-security Wed Nov 29 07:27:56 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA22701 for security-outgoing; Wed, 29 Nov 1995 07:27:56 -0800 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA22696 for ; Wed, 29 Nov 1995 07:27:50 -0800 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tKoN4-0003wGC; Wed, 29 Nov 95 07:24 PST Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id QAA00425; Wed, 29 Nov 1995 16:24:27 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: "Andrew V. Stesin" cc: security@FreeBSD.ORG Subject: Re: chroot/setuid vs type enforcement (fwd) In-reply-to: Your message of "Wed, 29 Nov 1995 12:01:31 +0200." <199511291001.MAA15889@office.elvisti.kiev.ua> Date: Wed, 29 Nov 1995 16:24:27 +0100 Message-ID: <423.817658667@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@FreeBSD.ORG Precedence: bulk > Here are interesting thoughts about hardening security of chrooted > environment... > > # Let's examine one possiblity. Suppose I am using chroot() to > # protect my firewall. And the argument I want to make is that I want > # to be sure, for sure, that nobody can tweak a buffer overrun and > # call a socket from inside the chrooted area. Amongst other things in this context you need to spoof/handle: the actual pid of "PID==1", since you don't want them to send weird signals to init. /dev you probably don't even want them to be able to do a mknod... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Wed Nov 29 23:50:38 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04784 for security-outgoing; Wed, 29 Nov 1995 23:50:38 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04779 for ; Wed, 29 Nov 1995 23:50:35 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA07924 for ; Wed, 29 Nov 1995 23:48:11 -0800 To: security@freebsd.org Subject: Robert Du Gaue: ****HELP***** Date: Wed, 29 Nov 1995 23:48:11 -0800 Message-ID: <7921.817717691@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk Argh. Anyone here care to do a little sleuthing for this FreeBSD-using service provider? Jordan ------- Forwarded Message Return-Path: rdugaue@web3.calweb.com Received: from calweb.calweb.com (calweb.calweb.com [165.90.138.3]) by time.cdrom.com (8.6.12/8.6.9) with ESMTP id VAA05579 for ; Wed, 29 Nov 1995 21:18:24 -0800 Received: from web3.calweb.com by calweb.calweb.com via ESMTP (8.6.12/940406.SGI.AUTO) for id FAA20984; Thu, 30 Nov 1995 05:21:28 GMT Received: (from rdugaue@localhost) by web3.calweb.com (8.7/8.6.9) id VAA07285; Wed, 29 Nov 1995 21:21:29 -0800 (PST) Date: Wed, 29 Nov 1995 21:21:28 -0800 (PST) From: Robert Du Gaue To: "Jordan K. Hubbard" Subject: ****HELP***** Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, we've got a major problem I'm hoping you can solve. Yesterday a user (know pirate) pissed off another hacker and somehow he got into the system and deleted the users directory, took our pw file (cated out in an IRC channel with the encrypted pws). We immediately check our systems, found sendmail to be 8.9, upgraded all these sendmails to 8.7, blocked 2 class addresses that he may have came from, removed root from ftp on one of the machines, and deleted all the lp stuff (since we have no printers). Checked for suid programs. Well, we restored the directory, and it got deleted again tonight. We have no idea how he is doing this. He's changed a the /etc/raddb/users file (removed the user from the file) also. In a word, I'm stuck, we're unsure of how he's doing it and I'm very scared right now that he'll do something major to the system. ------- End of Forwarded Message From owner-freebsd-security Thu Nov 30 00:03:33 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05610 for security-outgoing; Thu, 30 Nov 1995 00:03:33 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05605 for ; Thu, 30 Nov 1995 00:03:29 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA08121; Thu, 30 Nov 1995 00:00:50 -0800 To: Robert Du Gaue Cc: security@freebsd.org Subject: Re: ****HELP***** In-reply-to: Your message of "Wed, 29 Nov 1995 21:21:28 PST." Date: Thu, 30 Nov 1995 00:00:50 -0800 Message-ID: <8119.817718450@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk Hmmmmmm. A couple of things that confuse me here.. You say you "upgraded" sendmail 8.9 to 8.7? :) I can ask around, but I wasn't aware of anything too pathologically wrong with either version. Second, I assume you've deleted the account of the person being attacked? I'm curious how he got ahold of the real password file - are you sure it wasn't just the shadow passwords? If you can give us more clues, we can both give you avenues to follow in securing your system and track down the method(s) the perp is using. Also, please don't be afraid to employ legal means. What this hacker has done is a felony and and should be made an example of to the fullest extent provided by the law. Most data crime units in the various PDs are fairly eager, actually - it's budget time! :-) Also, the security@freebsd.org list is available for discussing security issues with other admins throughout the world, many of whom are pretty good. I'm sure at least one or two people here will have some first tips for you to try (security isn't really my bag, to be honest!). Anyway, I'd be happy to help you out, but we obviously need more information about what this guy is actually up to.. Any log info or anything else you think may be relevant? Thanks. Jordan > Well, we've got a major problem I'm hoping you can solve. Yesterday a > user (know pirate) pissed off another hacker and somehow he got into the > system and deleted the users directory, took our pw file (cated out in an > IRC channel with the encrypted pws). We immediately check our systems, > found sendmail to be 8.9, upgraded all these sendmails to 8.7, blocked 2 > class addresses that he may have came from, removed root from ftp on one > of the machines, and deleted all the lp stuff (since we have no printers). > > Checked for suid programs. Well, we restored the directory, and it got > deleted again tonight. We have no idea how he is doing this. He's changed > a the /etc/raddb/users file (removed the user from the file) also. In a > word, I'm stuck, we're unsure of how he's doing it and I'm very scared > right now that he'll do something major to the system. From owner-freebsd-security Thu Nov 30 00:54:36 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08864 for security-outgoing; Thu, 30 Nov 1995 00:54:36 -0800 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA08859 for ; Thu, 30 Nov 1995 00:54:28 -0800 Received: (from rdugaue@localhost) by web1.calweb.com (8.7/8.6.9) id AAA17336; Thu, 30 Nov 1995 00:55:11 -0800 (PST) Date: Thu, 30 Nov 1995 00:55:10 -0800 (PST) From: Robert Du Gaue To: "Jordan K. Hubbard" cc: security@freebsd.org Subject: Re: ****HELP***** In-Reply-To: <8119.817718450@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk > Hmmmmmm. A couple of things that confuse me here.. You say you > "upgraded" sendmail 8.9 to 8.7? :) I can ask around, but I wasn't This was sendmail 8.6.9, I thought we were runing 8.6.12 on all the machines, but weren't. They are now running 8.7. I'm told 8.6.9 had a serious security flaw in it, at least that's what the history docs say in 8.7.2 also. > Second, I assume you've deleted the account of the person being attacked? Well it's a regular user. Is this the normal method? Reassign him a new login id? One thing is though is that he's a dedicated fix-ip account too with a registered domain so I'm hesitate to disable his system because of something someone is doing to him. I can remove his locally account, but the hacker has also gone into the radius /etc/raddb/users file and removed his fixed IP login also. > I'm curious how he got ahold of the real password file - are you sure > it wasn't just the shadow passwords? When we speficially asked the user if there was an '*' in the second field he said 'no, a bunch of garbage characters'. > If you can give us more clues, we can both give you avenues to follow > in securing your system and track down the method(s) the perp is using. One thing very strange was my user said this guy appeared to be controling him in IRC. He (the perp) was moving the user around from room to room (joining him into gay channels and stuff) and then typing in lines for him also. All with the user watching without able to control what he was doing to him. > Also, please don't be afraid to employ legal means. What this hacker > has done is a felony and and should be made an example of to the > fullest extent provided by the law. Most data crime units in the > various PDs are fairly eager, actually - it's budget time! :-) Really???? Has Law Enforcement finally figured out this is serious shit? I was under the impression that most agenices have no clue on what to do and how to do anything about it. > > Also, the security@freebsd.org list is available for discussing > security issues with other admins throughout the world, many of whom > are pretty good. I'm sure at least one or two people here will have > some first tips for you to try (security isn't really my bag, to be > honest!). Ok, thanks! I'll subscribe to this one. > > Anyway, I'd be happy to help you out, but we obviously need more > information about what this guy is actually up to.. Any log info or > anything else you think may be relevant? Thanks. So far we've started blocking these services at our router: tftpd nfs portmapper bootp (client and server) finger (IE,67 68 69 79 2049) nntp outside our domain any IP requests coming into our router that is not in our domain. All machines are running 8.7 with the exception of the SGI which is running 8.6.12. I've installed tcp_wrappers on all the FreeBSD systems and will be configuring that in tommorrow morning. From owner-freebsd-security Thu Nov 30 07:40:33 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA21123 for security-outgoing; Thu, 30 Nov 1995 07:40:33 -0800 Received: from wiley.muc.ditec.de (wiley.muc.ditec.de [194.120.126.9]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA20853 for ; Thu, 30 Nov 1995 07:39:59 -0800 Received: from vector.eikon.e-technik.tu-muenchen.de (ns059.munich.netsurf.de [194.64.166.59]) by wiley.muc.ditec.de (8.6.12/8.6.9) with ESMTP id QAA08322; Thu, 30 Nov 1995 16:33:06 +0100 Received: from localhost (localhost [127.0.0.1]) by vector.eikon.e-technik.tu-muenchen.de (8.6.12/8.6.9) with SMTP id QAA02524; Thu, 30 Nov 1995 16:25:18 +0100 Message-Id: <199511301525.QAA02524@vector.eikon.e-technik.tu-muenchen.de> X-Authentication-Warning: vector.eikon.e-technik.tu-muenchen.de: Host localhost didn't use HELO protocol To: Robert Du Gaue cc: security@FreeBSD.ORG, tb@emi.net Subject: Re: ****HELP***** Reply-To: "Julian H. Stacey" X-mailer: EXMH version 1.6.4 10/10/95 In-reply-to: Your message of "Thu, 30 Nov 1995 00:00:50 PST." <8119.817718450@time.cdrom.com> Date: Thu, 30 Nov 1995 16:25:16 +0100 From: "Julian H. Stacey" Sender: owner-security@FreeBSD.ORG Precedence: bulk Hi, Responding to: > From: Robert Du Gaue > Cc: security@FreeBSD.ORG > To: "Jordan K. Hubbard" > Subject: Re: ****HELP***** > Cc: security@FreeBSD.ORG With reference to the > One thing very strange was my user said this guy appeared to be > controling him in IRC. He (the perp) was moving the user around from room > to room (joining him into gay channels and stuff) and then typing in > lines for him also. All with the user watching without able to control > what he was doing to him.> Ref. the IRC bit ... Sounds like one of the attack methods may be getting hold of your X Display too ? A friend Tom Bagley did a demo for me years ago, to show me my X session was unsafe (innocent demo I might add, nothing nasty). Anyway, ask Tom how to sew that particular hole up (I can't remember) that'll still leave all the other holes of to block of course. I'm no security wizz unfortunately, But for background reading, you might want to check out URLs on my http://www.freebsd.org/~jhs/computing.html (Security section) In particular perhaps this might help ? Security Alert Report Authorities CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-security Thu Nov 30 07:48:56 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA22781 for security-outgoing; Thu, 30 Nov 1995 07:48:56 -0800 Received: from passer.osg.gov.bc.ca (root@passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA22762 for ; Thu, 30 Nov 1995 07:48:53 -0800 Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.2/8.6.10) with SMTP id HAA08436; Thu, 30 Nov 1995 07:48:42 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199511301548.HAA08436@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: "Jordan K. Hubbard" , Robert Du Gaue cc: security@FreeBSD.org, cy@passer.osg.gov.bc.ca Subject: Re: ****HELP***** In-reply-to: Your message of "Wed, 29 Nov 95 23:48:11 PST." <7921.817717691@time.cdrom.com> Date: Thu, 30 Nov 95 07:48:42 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.org Precedence: bulk [header information deleted] > > Well, we've got a major problem I'm hoping you can solve. Yesterday a > user (know pirate) pissed off another hacker and somehow he got into the > system and deleted the users directory, took our pw file (cated out in an > IRC channel with the encrypted pws). We immediately check our systems, > found sendmail to be 8.9, upgraded all these sendmails to 8.7, blocked 2 > class addresses that he may have came from, removed root from ftp on one > of the machines, and deleted all the lp stuff (since we have no printers). Sendmail 8.7.2 is the latest version. 8.7 does have a hole where it may be exploited using the syslog() bug. If you don't receive mail on all of your systems, don't run sendmail on the systems that don't need it. If you do run it out of inetd with the "-bs" option, then add a line to crontab with the "-q" option. > > Checked for suid programs. Well, we restored the directory, and it got > deleted again tonight. We have no idea how he is doing this. He's changed > a the /etc/raddb/users file (removed the user from the file) also. In a > word, I'm stuck, we're unsure of how he's doing it and I'm very scared > right now that he'll do something major to the system. Hackers love to leave backdoors. Check the size and checksum (MD5) of your login program with that of a system you know has not been compromised. Since you have more than one machine, don't trust your other machines. They may have been attacked too. Look in the /dev directory for files that should not be there, e.g. plaintext files or programs. Make sure that all of the users in your password file are legitimate. Verify that your ps and netstat programs are intact. There may be a daemon running on your system that could allow the hacker to login as root. Make sure your rc.local file has not been altered nor any bogus entries in your root crontab created. Are you running NIS? If so, block those ports to outside access. Also block ports 512 and 520, exec and route. If you don't provide telnet service to your customers, wrap it. Disallow all "r" commands (you may allow them between your hosts, however that guarentees that if one system is compromised all of them are). Considering the fact that the hacker has removed the user from your radius users file, the hacker knows something about radius. Block your radius port. Only allow your portmaster to talk to that port. (My first impression of the freely available Radius source code was very poor). Of course, block finger, nfs, portmap (or install portmap3 with TCP/Wrapper extensions), and tftp, just to name a few. These are just a few ideas that come to mind. There are many more. Check the latest CERT advisory. They discuss the recent flurry of hacker activity in it. I hope this helps. Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Fri Dec 1 21:36:30 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA22131 for security-outgoing; Fri, 1 Dec 1995 21:36:30 -0800 Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA22105 for ; Fri, 1 Dec 1995 21:35:19 -0800 Received: (mconst@localhost) by soda.CSUA.Berkeley.EDU (8.6.11/PHILMAIL-1.11) id VAA04777; Fri, 1 Dec 1995 21:33:35 -0800 Date: Fri, 1 Dec 1995 21:33:35 -0800 From: Michael Constant Message-Id: <199512020533.VAA04777@soda.CSUA.Berkeley.EDU> To: jkh@time.cdrom.com, rdugaue@calweb.com Subject: Re: ****HELP***** Cc: security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk > One thing very strange was my user said this guy appeared to be > controling him in IRC. He (the perp) was moving the user around from room > to room (joining him into gay channels and stuff) and then typing in > lines for him also. All with the user watching without able to control > what he was doing to him. This is a very standard "hacker" thing to do. All you have to do is convince the victim to type something stupid, like "/on ^msg * $1-" and then you have control over their entire irc session, and since you can force them to use the "/exec" command against their will, you also have control over their entire account. Also, instead of asking the victim to execute a stupid command, you can give them a security- compromising script and ask them to load it. Some IRC scripts have very subtle security holes; I personally refuse to use any IRC script I didn't write myself. Check your system for vulnerability from the inside. What can your users do? The hacker has complete control over the victim's account, and can thus do anything that your ordinary users can do. - Michael Constant From owner-freebsd-security Fri Dec 1 23:36:03 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA00603 for security-outgoing; Fri, 1 Dec 1995 23:36:03 -0800 Received: from maui.com (langfod@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA00590 for ; Fri, 1 Dec 1995 23:35:54 -0800 Received: (from langfod@localhost) by maui.com (8.6.10/8.6.6) id VAA17697 for security@freebsd.org; Fri, 1 Dec 1995 21:40:11 -1000 From: David Langford Message-Id: <199512020740.VAA17697@ maui.com> Subject: BoS: SKIP Source Release is out! (fwd) To: security@freebsd.org Date: Fri, 1 Dec 1995 21:40:11 -1000 (HST) X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5041 Sender: owner-security@freebsd.org Precedence: bulk There was some mention about secure transports and FreeBSD a bit ago. I thought someone might be interested in this bit of news. >From owner-best-of-security@suburbia.net Wed Nov 29 00:31:57 1995 >Date: Tue, 28 Nov 1995 17:22:29 -0800 >From: markson@osmosys.incog.com (Tom Markson) >To: cypherpunks@toad.com >Subject: BoS: SKIP Source Release is out! >Precedence: bulk >Sender: owner-best-of-security@suburbia.net > >Hi, > >Check out http://skip.incog.com. We've released the source to the SKIP >key management and IP layer encryption package for SunOs 4.x. > >Here's a piece of the README file: > > > ALPHA 1 Release of SKIP Reference Source for SunOS 4.1.3 > -------------------------------------------------------- > >SKIP is a Key-management protocol for IP based protocols. It is an >acronym for Simple Key-management for Internet Protocols. SKIP is >documented in the SKIP IETF IPSEC draft included in this directory >as draft-ietf-ipsec-skip-05.txt. The most recent SKIP draft is >always available at http://skip.incog.com and the Internet-Drafts >directories. > >>From this public domain source release, you can build a fully >functional IP-layer encryption package which supports DES and >Triple-DES for SunOS 4.1.3. This means that every IP networked >application can have it's network traffic encrypted. Unlike >application level encryption packages, this package encrypts >IP packets. Thus, applications do not need to be recompiled or >modified to take advantage of encryption. > >The SKIP source is possible through the efforts of engineers in Sun >Microsystems Internet Commerce Group. The developers and designers >are Ashar Aziz, Tom Markson, Martin Patterson, Hemma Prafullchandra and >Joseph Reveane. Linda Cavanaugh worked on the documentation. > >The package compiles under both the SunPro compiler and GCC. We expect >that this release should port without too much pain to any operating >system which uses BSD style networking (mbufs). > >A legal warning: Because this package contains strong encryption, the >Software must not be transferred to persons who are not US citizens or >permanent residents of the US, or exported outside the US (except >Canada) in any form (including by electronic transmission) without >prior written approval from the US Government. Non-compliance with >these restrictions constitutes a violation of the U.S. Export Control >Laws. > >This source release may be used for both commercial and noncommercial >purposes, subject to the restrictions described in the software and >patent license statements. > >Furthermore, Sun Microsystems has licensed the Stanford public key patents >from Cylink Corp. which are available to users of this package on a royalty >free basis. The patent statement is in README.PATENT. Be sure to read this, >as it contains some restrictions and other important information. > >Also included in this release is a high speed Big Number package written >by Colin Plumb. bnlib/legal.c contains Colin's software license statement. > >Features >-------- > 1. SKIP V2 compliant implementation using ESP encapsulation. > 2. Support for DES/3DES for traffic and key encryption. > 3. Diffie-Hellman Public Key Agreement based system. > 4. Full Support for manual establishment of master keys. > 5. Support for multiple NSIDs and multiple local certificates. > 6. GUI tool for user friendly manipulation of access control lists > and key statistics. > 7. Command line tools for manipulating access control lists, etc. > 8. Implementation of the Certificate Discovery protocol fully > integrated into SKIP. > 9 Implementation of X.509 public key certificates. > 10. Implementation of DSA signature algorithm for certificate > signatures. > 11. Implementation for MD2, MD5 and SHA message digest algorithms. > 12. Implementation of ASN.1 DER encoding/decoding. > 13. SunScreen(tm) SKIP compatibility mode. > 14. Implementation of hashed public keys as defined in the SKIP > draft. Implementation of programs to generate hashed public > keys. > 15. Certificate utilities to convert X.509 Certificates to hashed > keys and print both X.509 and Hashed certificates. > 16. High performance Big Number library for Diffie-Hellman > calculations. > 17. Implementation is effectively "public domain" and may be used both > commercially and non-commercially. > 18. Patent Agreement with Cylink allows roylaty-free use of the > Diffie-Hellman and other Stanford patents with this package for > commercial and non-commercial use. Read README.PATENT for > some restrictions. > 19. Inclusion of prime generation program used to generate the > primes in SKIP draft. > > > -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | Maui Research and Technology Center -- Network Administrator | \--------------------------------------------------------------------/ From owner-freebsd-security Sat Dec 2 00:38:04 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA05554 for security-outgoing; Sat, 2 Dec 1995 00:38:04 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA05535 for ; Sat, 2 Dec 1995 00:37:51 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA21321; Sat, 2 Dec 1995 19:09:40 GMT From: Michael Smith Message-Id: <199512021909.TAA21321@genesis.atrad.adelaide.edu.au> Subject: Re: ****HELP***** To: rdugaue@calweb.com (Robert Du Gaue) Date: Sat, 2 Dec 1995 19:09:40 +0000 () Cc: jkh@time.cdrom.com, security@FreeBSD.ORG In-Reply-To: from "Robert Du Gaue" at Nov 30, 95 00:55:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1953 Sender: owner-security@FreeBSD.ORG Precedence: bulk Robert Du Gaue stands accused of saying: > Well it's a regular user. Is this the normal method? Reassign him a new > login id? One thing is though is that he's a dedicated fix-ip account too > with a registered domain so I'm hesitate to disable his system because of > something someone is doing to him. I can remove his locally account, but > the hacker has also gone into the radius /etc/raddb/users file and > removed his fixed IP login also. Just on the networking side, check that you _don't_ have the bpf code (options bpfilter n) in the FreeBSD kernel. Do a virgin install to another machine and check the permissions on everything in /dev, and sizes, dates and _md5_checksums_ of all of your system binaries. Jordan; how hard would it be to generate a file with the md5's of a stock release system's "standard binaries" for this sort of thing? > > I'm curious how he got ahold of the real password file - are you sure > > it wasn't just the shadow passwords? > > When we speficially asked the user if there was an '*' in the second > field he said 'no, a bunch of garbage characters'. I would presume you've checked the permissions on /etc/master.passwd, /etc/pwd.db and /etc/spwd.db? Change the admin passwords on the portmaster too (if it has that sort of thing). Change your root password too. (obviously 8) > Really???? Has Law Enforcement finally figured out this is serious shit? > I was under the impression that most agenices have no clue on what to do > and how to do anything about it. Hell yes. There's money in the industry now 8) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Sat Dec 2 01:52:29 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA09832 for security-outgoing; Sat, 2 Dec 1995 01:52:29 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA09822 for ; Sat, 2 Dec 1995 01:52:19 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id BAA00324; Sat, 2 Dec 1995 01:52:03 -0800 To: Michael Smith cc: rdugaue@calweb.com (Robert Du Gaue), security@FreeBSD.ORG Subject: Re: ****HELP***** In-reply-to: Your message of "Sat, 02 Dec 1995 19:09:40 GMT." <199512021909.TAA21321@genesis.atrad.adelaide.edu.au> Date: Sat, 02 Dec 1995 01:52:02 -0800 Message-ID: <322.817897922@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG Precedence: bulk > Jordan; how hard would it be to generate a file with the md5's of a stock > release system's "standard binaries" for this sort of thing? Probably not too hard. Let me think about it. You'd want a file for each distrib, probably. Jordan From owner-freebsd-security Sat Dec 2 02:06:36 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA13496 for security-outgoing; Sat, 2 Dec 1995 02:06:36 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA13415 for ; Sat, 2 Dec 1995 02:06:14 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id UAA21630; Sat, 2 Dec 1995 20:37:50 GMT From: Michael Smith Message-Id: <199512022037.UAA21630@genesis.atrad.adelaide.edu.au> Subject: Re: ****HELP***** To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 2 Dec 1995 20:37:49 +0000 () Cc: msmith@atrad.adelaide.edu.au, rdugaue@calweb.com, security@FreeBSD.ORG In-Reply-To: <322.817897922@time.cdrom.com> from "Jordan K. Hubbard" at Dec 2, 95 01:52:02 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 990 Sender: owner-security@FreeBSD.ORG Precedence: bulk Jordan K. Hubbard stands accused of saying: > > > Jordan; how hard would it be to generate a file with the md5's of a stock > > release system's "standard binaries" for this sort of thing? > > Probably not too hard. Let me think about it. You'd want a file > for each distrib, probably. And a script somewhere for checking it? Should we perhaps start looking at a SCO-like "perms" setup? Is this something that the security and ISP people would smile happily upon? (ie. a distribution-wide listing of md5's, permissions and ownerships, burnt onto the release CD for security's sake 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[ From owner-freebsd-security Sat Dec 2 04:41:06 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA11708 for security-outgoing; Sat, 2 Dec 1995 04:41:06 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA11680 for ; Sat, 2 Dec 1995 04:40:40 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id XAA09388; Sat, 2 Dec 1995 23:33:07 +1100 Date: Sat, 2 Dec 1995 23:33:07 +1100 From: Bruce Evans Message-Id: <199512021233.XAA09388@godzilla.zeta.org.au> To: jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au Subject: Re: ****HELP***** Cc: rdugaue@calweb.com, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk >> > Jordan; how hard would it be to generate a file with the md5's of a stock >> > release system's "standard binaries" for this sort of thing? >> >> Probably not too hard. Let me think about it. You'd want a file >> for each distrib, probably. mtree -c -k md5digest -p / >/safe/all.md5 Bug: when run by non-root, this exits when it hits the unreadable file sper4.036. It's as bad as wc :-(. Worse bug: when run by root, this exits when it hits an unreadable file in /proc. Some regular files aren't. >And a script somewhere for checking it? Should we perhaps start looking at >a SCO-like "perms" setup? Is this something that the security and ISP >people would smile happily upon? mtree -p / (ie. a distribution-wide listing of md5's, permissions and ownerships, >burnt onto the release CD for security's sake 8) mtree -c -k md5digest,mode,uid,gid -p / >/safe/all.md5 Bruce From owner-freebsd-security Sat Dec 2 07:22:23 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01302 for security-outgoing; Sat, 2 Dec 1995 07:22:23 -0800 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA01287 for ; Sat, 2 Dec 1995 07:22:17 -0800 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id QAA27671 ; Sat, 2 Dec 1995 16:22:03 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id QAA25586 ; Sat, 2 Dec 1995 16:22:02 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.1/keltia-uucp-2.6) id MAA02291; Sat, 2 Dec 1995 12:32:24 +0100 (MET) From: Ollivier Robert Message-Id: <199512021132.MAA02291@keltia.freenix.fr> Subject: Re: ****HELP***** To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 2 Dec 1995 12:32:24 +0100 (MET) Cc: rdugaue@calweb.com, jkh@time.cdrom.com, security@FreeBSD.org In-Reply-To: <199512021909.TAA21321@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Dec 2, 95 07:09:40 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1393 X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org Precedence: bulk It seems that Michael Smith said: > Jordan; how hard would it be to generate a file with the md5's of a stock > release system's "standard binaries" for this sort of thing? Tripwire has been made for that purpose... You can generate a database with all the signatures very easily. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #7: Mon Nov 6 21:08:06 MET 1995 From owner-freebsd-security Sat Dec 2 10:15:05 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA20825 for security-outgoing; Sat, 2 Dec 1995 10:15:05 -0800 Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.95.74]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20805 for ; Sat, 2 Dec 1995 10:14:59 -0800 Received: (from robert@localhost) by fledge.watson.org (8.6.12/8.6.10) id NAA17943; Sat, 2 Dec 1995 13:14:43 -0500 Date: Sat, 2 Dec 1995 13:14:42 -0500 (EST) From: Robert Watson To: "Jordan K. Hubbard" cc: Michael Smith , Robert Du Gaue , security@FreeBSD.ORG Subject: Re: ****HELP***** In-Reply-To: <322.817897922@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk Actually, what might be nice is to include the MD5's with the system, and have a script in daily.local that verifies that the key system binaries are correct. Obviously then the md5 file would be at risk, but.. This would also be nice, unrelated to the daily part, after an upgrade to check if there are any old binaries lying around. Actually, one thing I was going to ask about was -- is there a difference between the 2.1.0 binaries for standard executables (eg., pine) and the 2.0.5 ones? Is there anyway I can use strings (or something) to get a list of all the old binaries on my system and upgrade them if needed? On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > Jordan; how hard would it be to generate a file with the md5's of a stock > > release system's "standard binaries" for this sort of thing? > > Probably not too hard. Let me think about it. You'd want a file > for each distrib, probably. > > Jordan From owner-freebsd-security Sat Dec 2 10:30:07 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA23475 for security-outgoing; Sat, 2 Dec 1995 10:30:07 -0800 Received: from uucp1.calweb.com (root@uucp1.calweb.com [165.90.138.20]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA23406 for ; Sat, 2 Dec 1995 10:29:59 -0800 Received: (from rdugaue@localhost) by uucp1.calweb.com (8.7.2/8.7.2) id KAA01601; Sat, 2 Dec 1995 10:30:32 GMT Date: Sat, 2 Dec 1995 10:30:32 +0000 () From: Robert Du Gaue To: Robert Watson cc: "Jordan K. Hubbard" , Michael Smith , security@FreeBSD.ORG Subject: Re: ****HELP***** In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk I plan on rebuilding a new system from scratch, then I'll wipe all the bin directories clena on the compromised systems and use the rebuilt system to update all the bins. Which should I do? /bin /sbin /usr/sbin /usr/bin Where else? I know there are alot I'm missing... On Sat, 2 Dec 1995, Robert Watson wrote: > Date: Sat, 2 Dec 1995 13:14:42 -0500 (EST) > From: Robert Watson > To: "Jordan K. Hubbard" > Cc: Michael Smith , > Robert Du Gaue , security@FreeBSD.ORG > Subject: Re: ****HELP***** > > > Actually, what might be nice is to include the MD5's with the system, and > have a script in daily.local that verifies that the key system binaries > are correct. Obviously then the md5 file would be at risk, but.. This > would also be nice, unrelated to the daily part, after an upgrade to > check if there are any old binaries lying around. > > Actually, one thing I was going to ask about was -- is there a difference > between the 2.1.0 binaries for standard executables (eg., pine) and the > 2.0.5 ones? Is there anyway I can use strings (or something) to get a > list of all the old binaries on my system and upgrade them if needed? > > On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > > > Jordan; how hard would it be to generate a file with the md5's of a stock > > > release system's "standard binaries" for this sort of thing? > > > > Probably not too hard. Let me think about it. You'd want a file > > for each distrib, probably. > > > > Jordan > From owner-freebsd-security Sat Dec 2 12:57:23 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19389 for security-outgoing; Sat, 2 Dec 1995 12:57:23 -0800 Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.95.74]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19335 for ; Sat, 2 Dec 1995 12:57:16 -0800 Received: (from robert@localhost) by fledge.watson.org (8.6.12/8.6.10) id PAA18431; Sat, 2 Dec 1995 15:57:01 -0500 Date: Sat, 2 Dec 1995 15:57:01 -0500 (EST) From: Robert Watson To: Robert Du Gaue cc: "Jordan K. Hubbard" , Michael Smith , security@FreeBSD.ORG Subject: Re: ****HELP***** In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG Precedence: bulk /usr/local/bin, some systems have /usr/contrib/bin, /usr/libexec, /usr/local/libexec, /usr/local/sbin, also do your libs -- /usr/lib, /usr/local/lib, if you haev X, /usr/X11R6/bin, /usr/X11R6/lib, /stand if you use it.. and /lkm. In fact, it occurs to me that if you're really concerned, maybe it would be best just to reinstall FreeBSD on that system? Or use the upgrade package in 2.1.0 to overwrite the distribution itself (backing up heavily first, though.) That way you know that things are configured/installed without backdoors (assuming you trust Jordan, and I think most of us do :). Kind of a pain for a often-used system with a lot of personal configuration details, but.. Anyhow, that's what I'd do. Also, if you haven't yet, file a report with CERT and scan their archives for stuff that might be relevant. Also, you might check to see if the most recent ftp related CERT advisory effects you -- I think there's probably a group of people who read the advisories, and test their ISP at once :). Unless you've changed your ftp config under FreeBSD to enable it, it shouldn't work, though. On Sat, 2 Dec 1995, Robert Du Gaue wrote: > I plan on rebuilding a new system from scratch, then I'll wipe all the > bin directories clena on the compromised systems and use the rebuilt > system to update all the bins. Which should I do? > > /bin /sbin /usr/sbin /usr/bin Where else? I know there are alot I'm > missing... > > > On Sat, 2 Dec 1995, Robert Watson wrote: > > > Date: Sat, 2 Dec 1995 13:14:42 -0500 (EST) > > From: Robert Watson > > To: "Jordan K. Hubbard" > > Cc: Michael Smith , > > Robert Du Gaue , security@FreeBSD.ORG > > Subject: Re: ****HELP***** > > > > > > Actually, what might be nice is to include the MD5's with the system, and > > have a script in daily.local that verifies that the key system binaries > > are correct. Obviously then the md5 file would be at risk, but.. This > > would also be nice, unrelated to the daily part, after an upgrade to > > check if there are any old binaries lying around. > > > > Actually, one thing I was going to ask about was -- is there a difference > > between the 2.1.0 binaries for standard executables (eg., pine) and the > > 2.0.5 ones? Is there anyway I can use strings (or something) to get a > > list of all the old binaries on my system and upgrade them if needed? > > > > On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > > > > > Jordan; how hard would it be to generate a file with the md5's of a stock > > > > release system's "standard binaries" for this sort of thing? > > > > > > Probably not too hard. Let me think about it. You'd want a file > > > for each distrib, probably. > > > > > > Jordan > > > From owner-freebsd-security Sat Dec 2 14:00:51 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28979 for security-outgoing; Sat, 2 Dec 1995 14:00:51 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28949 for ; Sat, 2 Dec 1995 14:00:44 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id OAA04273; Sat, 2 Dec 1995 14:00:03 -0800 To: Robert Du Gaue cc: Robert Watson , Michael Smith , security@FreeBSD.ORG Subject: Re: ****HELP***** In-reply-to: Your message of "Sat, 02 Dec 1995 10:30:32 GMT." Date: Sat, 02 Dec 1995 14:00:03 -0800 Message-ID: <4271.817941603@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG Precedence: bulk > I plan on rebuilding a new system from scratch, then I'll wipe all the > bin directories clena on the compromised systems and use the rebuilt > system to update all the bins. Which should I do? > Erm. In this instance, you might be better off simply backing up the files you want to *keep* and then reinstalling the entire system from the 2.1 distribution. 2.1's installer isn't bad, and it's possible to get back a lot of the configuration data just through answering questions in the novice install. Jordan > /bin /sbin /usr/sbin /usr/bin Where else? I know there are alot I'm > missing... > > > On Sat, 2 Dec 1995, Robert Watson wrote: > > > Date: Sat, 2 Dec 1995 13:14:42 -0500 (EST) > > From: Robert Watson > > To: "Jordan K. Hubbard" > > Cc: Michael Smith , > > Robert Du Gaue , security@FreeBSD.ORG > > Subject: Re: ****HELP***** > > > > > > Actually, what might be nice is to include the MD5's with the system, and > > have a script in daily.local that verifies that the key system binaries > > are correct. Obviously then the md5 file would be at risk, but.. This > > would also be nice, unrelated to the daily part, after an upgrade to > > check if there are any old binaries lying around. > > > > Actually, one thing I was going to ask about was -- is there a difference > > between the 2.1.0 binaries for standard executables (eg., pine) and the > > 2.0.5 ones? Is there anyway I can use strings (or something) to get a > > list of all the old binaries on my system and upgrade them if needed? > > > > On Sat, 2 Dec 1995, Jordan K. Hubbard wrote: > > > > > > Jordan; how hard would it be to generate a file with the md5's of a sto ck > > > > release system's "standard binaries" for this sort of thing? > > > > > > Probably not too hard. Let me think about it. You'd want a file > > > for each distrib, probably. > > > > > > Jordan > >