From owner-freebsd-security Mon Mar 19 16:56:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id 50A1D37B735 for ; Mon, 19 Mar 2001 16:56:39 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id RAA16800 for ; Mon, 19 Mar 2001 17:55:12 -0700 (MST) Message-Id: <4.3.2.7.2.20010319172800.00cf9c60@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Mar 2001 17:54:51 -0700 To: security@freebsd.org From: Brett Glass Subject: Odd event -- possible security hole or DoS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A fellow I know just stopped me as I walked past his office to say that his FreeBSD system was acting strangely. I stopped in to take a look for him. It's running FreeBSD 2.8 with security patches -- a WAY old release. (I got him to agree to let me upgrade it to 4.3-RELEASE for him if it's a good release.) In any event, I ran netstat on his machine and discovered that there was a huge backlog of open TCP connections, some of them stuck in states such as CLOSING, FIN_WAIT_1 and FIN_WAIT_2. Also, POP clients couldn't get through; it looked as if sockets were being opened but the daemons weren't being spawned. I was just about to reboot the server when it occured to me that this might erase any evidence of what was going wrong. So, I considered for a bit and realized that the behavior I was seeing just might happen if inetd somehow messed up. I decided to try sending a HUP to inetd, just to see what would happen. Immediately, the system sprang back to life and cleared the old connections. And the following appeared in the log: Mar 19 17:27:12 victim fingerd[16439]: query from 208.59.253.87: `root ' Mar 19 17:27:12 victim fingerd[16437]: query from 208.59.253.87: ` ' Interesting. Someone with a cable modem playing games. Probably should identify the culprit, but I'm more interested in knowing how he managed to cause the system to malfunction. In case it helps, here's a bit more about the system configuration. The finger daemon had been set, via the -p option, to return a message saying that finger requests were being denied. The line in inetd.conf looked like this: finger stream tcp nowait nobody /usr/libexec/fingerd fingerd -s -l -p /usr/local/bin/nonetfinger "nonetfinger" is a program that my friend grabbed from my BSDCon paper and compiled. It simply outputs a message to standard output. It doesn't even look at its arguments. Hmmm. So, what's going on here? Was someone trying to execute a DoS or remote root exploit here, perhaps by trying to feed something quoted to fingerd and/or the program it invoked? Why did it hang things up so badly? Does this hint at a security flaw in inetd or fingerd that needs attention (or has gotten some since that old version of FreeBSD)? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message