From owner-freebsd-security Mon Jul 28 22:35:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA11035 for security-outgoing; Mon, 28 Jul 1997 22:35:06 -0700 (PDT) Received: from milehigh.denver.net (milehigh.denver.net [204.144.180.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA11029 for ; Mon, 28 Jul 1997 22:35:04 -0700 (PDT) Received: from localhost (jdc@localhost) by milehigh.denver.net (8.8.5/8.8.5) with SMTP id XAA28459 for ; Mon, 28 Jul 1997 23:38:25 -0600 (MDT) Date: Mon, 28 Jul 1997 23:38:24 -0600 (MDT) From: John-David Childs cc: security@FreeBSD.ORG Subject: Re: security hole in FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Vincent Poy wrote: > On Mon, 28 Jul 1997, Jonathan A. Zdziarski wrote: > > =)Hrm if you always use kill -9 try the reverse, just a kill or a kill -15 > > I did that too. even kill -HUP only kills the master process. I > had to kill the child process manually. That's what the killall script is for :-) Since I've finally plowed through the dozens (hundreds? ;-) of messages on the subject... None of my FreeBSD systems have ever installed a /root/.rhosts file to my knowledge, unless it's been a zero length file. I'd have to grok the scripts, but I know for a fact that a FreeBSD install wouldn't know to create a /root/.rhosts that had the name of your other machine in it. Some one of your admins did that luser trick (e.g. to enable rsh/rcp). Second, my interpretation of the init man page suggests that securelevel 1 would PREVENT me from writing to mounted disks at the time the securelevel 1 is "invoked". So, for instance, if I used sysctl to change kern.securelevel from 0 to 1 *right now*, my server processes (httpd, sendmail, etc.) would suddenly blow up because they couldn't write to the disks. Thus, the only time one would want to invoke securelevel 1 would be from /etc/rc before the disks are mounted. Correct??? (The rest is dribble mostly directed to Vince, but possibly useful to others). Third, Vince stated something to the effect that Jordan Hubbard couldn't hold a candle to this hacker ("wasn't in the same league") and then posted IRC dribble. I'd bet this hacker couldn't hold a candle to Jordan and probably is just an luser with a copy of rootkit. (Just had to get that one off my mind ;) Fourth, you might as well take that machine off the net (turn it off) if you can't get physical access to it for 2-4 months. It's gone gone gone! If you've been telnetting to it forever with no encryption, tcpwrappers, or router filters, your hacker could have been on your system for weeks or months before acting up and you wouldn't have a clue.. A few years ago when I was a weenie (ok, I still am compared to Jordan and Nate and... ;-) I challenged (deliberately) some of my more clueful customers to hack me...one of them was root on my system for almost a month before I noticed suspicious activity. Your descriptions of comparing files between machines (e.g. comparing byte sizes/dates of telnetd) suggest that you never ran anything like tripwire/cops to compute checksums of the files. Thus, you'd have NO clue which files really might have been changed. And if you DID run Tripwire before the hacker, and ran it again after the hacker, but didn't compare the result to a known clean OFFLINE copy of the tripwire database (e.g. a paper/floppy copy)...forget it! :) -- John-David Childs (JC612) @denver.net/Internet-Coach/@ronan.net System Administrator Enterprise Internet Solutions & Network Engineer 901 E 17th Ave, Denver 80218 All programmers are playwrights and all computers are lousy actors.