From owner-freebsd-security@FreeBSD.ORG Sun May 2 10:29:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C780816A4CE for ; Sun, 2 May 2004 10:29:17 -0700 (PDT) Received: from avgw.bjut.edu.cn (avgw.bjut.edu.cn [202.112.78.85]) by mx1.FreeBSD.org (Postfix) with SMTP id C483F43D41 for ; Sun, 2 May 2004 10:29:16 -0700 (PDT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net ([218.107.145.7]) by avgw.bjut.edu.cn (SAVSMTP 3.1.5.43) with SMTP id M2004050301291202603 for ; Mon, 03 May 2004 01:29:12 +0800 Received: from localhost (localhost [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 0A5341175D for ; Mon, 3 May 2004 01:29:12 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00383-06 for ; Mon, 3 May 2004 01:29:11 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id DBE9711706; Mon, 3 May 2004 01:29:10 +0800 (CST) Date: Mon, 3 May 2004 01:29:10 +0800 From: Xin LI To: freebsd-security@FreeBSD.org Message-ID: <20040502172910.GA775@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.2-CURRENT FreeBSD 5.2-CURRENT #33: Mon Apr 26 15:10:21 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Subject: What's our current policy on ports FORBIDDEN knob? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2004 17:29:17 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, I'm a little curious about the way FORBIDDEN knob is used in ports system. Traditionally, we use it to mark a port which have known security issue, with the new vuxml mechanism, are we still doing the same thing when necessary? Or, only the "critical" ones, for example, remote exploitable buffer overruns, etc? If the second assumption (only critical ones are marked FORBIDDEN) is true, then what's our criteria of what should be marked FORBIDDEN or not? Say, how serious a bug should be before a port is marked FORBIDDEN? Someone who knows about these things please clarify this. Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAlS/mOfuToMruuMARAgvbAJ9JBZ4CNDaAmp8B/0Q5PJy4k9YsqwCfVRtJ YGZ6AVtdjrXyJet5kIvCXik= =g7ca -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-security@FreeBSD.ORG Sun May 2 12:36:09 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D00E16A4CF for ; Sun, 2 May 2004 12:36:09 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id B47BE43D49 for ; Sun, 2 May 2004 12:36:08 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 3701C54840; Sun, 2 May 2004 14:36:08 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id CEF816FB63; Sun, 2 May 2004 14:36:07 -0500 (CDT) Date: Sun, 2 May 2004 14:36:07 -0500 From: "Jacques A. Vidrine" To: Xin LI Message-ID: <20040502193607.GB33431@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Xin LI , freebsd-security@FreeBSD.org References: <20040502172910.GA775@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040502172910.GA775@frontfree.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@FreeBSD.org Subject: Re: What's our current policy on ports FORBIDDEN knob? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2004 19:36:09 -0000 On Mon, May 03, 2004 at 01:29:10AM +0800, Xin LI wrote: > Greetings, > > I'm a little curious about the way FORBIDDEN knob is used in ports system. > Traditionally, we use it to mark a port which have known security issue, > with the new vuxml mechanism, are we still doing the same thing when > necessary? Or, only the "critical" ones, for example, remote exploitable > buffer overruns, etc? > > If the second assumption (only critical ones are marked FORBIDDEN) > is true, then what's our criteria of what should be marked FORBIDDEN > or not? Say, how serious a bug should be before a port is marked > FORBIDDEN? > > Someone who knows about these things please clarify this. Thanks in advance! The VuXML document is used to record practically all security issues, large or small. FORBIDDEN is more subjective. Personally, I mark a port FORBIDDEN if I believe it presents immediate danger to users. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon May 3 07:12:44 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 064D016A4CE for ; Mon, 3 May 2004 07:12:44 -0700 (PDT) Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F5043D54 for ; Mon, 3 May 2004 07:12:41 -0700 (PDT) (envelope-from artur@pydo.org) Received: from bastion.pydo.net (bastion.pydo.net [62.212.97.116]) by kraid.nerim.net (Postfix) with ESMTP id 5711C41A66 for ; Mon, 3 May 2004 16:12:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bastion.pydo.net (Postfix) with ESMTP id B89864C259; Mon, 3 May 2004 15:55:38 +0200 (CEST) Received: from bastion.pydo.net ([127.0.0.1]) by localhost (fw.pydo.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73408-03-6; Mon, 3 May 2004 15:55:31 +0200 (CEST) Received: from pydo.org (univers.ipv6.pydo.org [IPv6:2001:618:472:0:250:8dff:fea5:1452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bastion.pydo.net (Postfix) with ESMTP id 748B14C258; Mon, 3 May 2004 15:55:31 +0200 (CEST) Message-ID: <40964F53.60408@pydo.org> Date: Mon, 03 May 2004 15:55:31 +0200 From: Artur Pydo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: andy@lewman.com References: <20040501125409.GA65876@phobos.osem.com> In-Reply-To: <20040501125409.GA65876@phobos.osem.com> X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pydo.net cc: freebsd-security@freebsd.org Subject: Re: chkrootkit and 4.10-prerelease issues? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 14:12:44 -0000 Hello, andy@lewman.com wrote: > Has anyone else seen chkrootkit (version 0.43) on 4.10-prerelease or > later report chfn, chsh, and date as infected? This is a reported bug of freebsd version detection in the shell script. It should be corrected in the next release of chkrootkit. -- Best regards, Artur Pydo. From owner-freebsd-security@FreeBSD.ORG Mon May 3 07:19:52 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68CA916A4CE for ; Mon, 3 May 2004 07:19:52 -0700 (PDT) Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CD843D46 for ; Mon, 3 May 2004 07:19:52 -0700 (PDT) (envelope-from artur@pydo.org) Received: from bastion.pydo.net (bastion.pydo.net [62.212.97.116]) by kraid.nerim.net (Postfix) with ESMTP id 06609418FC for ; Mon, 3 May 2004 16:19:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bastion.pydo.net (Postfix) with ESMTP id 63E0C4C2E3 for ; Mon, 3 May 2004 16:19:47 +0200 (CEST) Received: from bastion.pydo.net ([127.0.0.1]) by localhost (fw.pydo.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 93552-04 for ; Mon, 3 May 2004 16:19:44 +0200 (CEST) Received: from pydo.org (univers.ipv6.pydo.org [IPv6:2001:618:472:0:250:8dff:fea5:1452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bastion.pydo.net (Postfix) with ESMTP id DD8AF4C2E2 for ; Mon, 3 May 2004 16:19:44 +0200 (CEST) Message-ID: <40965500.4040205@pydo.org> Date: Mon, 03 May 2004 16:19:44 +0200 From: Artur Pydo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: freebsd-security@freebsd.org X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pydo.net Subject: Bad VuXML check on PNG port ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 14:19:52 -0000 Hello, The current png-1.2.5_4 port has no more vulnerability. It has been corrected by ache@FreeBSD.org yesterday. But when i try to install the updated port to remplace the vulnerable one this is what i am told : # make install ===> png-1.2.5_4 has known vulnerabilities: >> libpng denial-of-service. Reference: >> Please update your ports tree and try again. *** Error code 1 The 4-STABLE ports tree is up-to-date. Isn't it a problem to be unable to update a vulnerable port ? -- Best regards, Artur Pydo. From owner-freebsd-security@FreeBSD.ORG Mon May 3 07:43:36 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9366C16A4CE for ; Mon, 3 May 2004 07:43:36 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D7D43D2D for ; Mon, 3 May 2004 07:43:36 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id A868B5482B; Mon, 3 May 2004 09:43:35 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 4C1646FF34; Mon, 3 May 2004 09:43:35 -0500 (CDT) Date: Mon, 3 May 2004 09:43:35 -0500 From: "Jacques A. Vidrine" To: Artur Pydo Message-ID: <20040503144335.GA15293@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Artur Pydo , freebsd-security@freebsd.org References: <40965500.4040205@pydo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40965500.4040205@pydo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: Bad VuXML check on PNG port ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 14:43:36 -0000 On Mon, May 03, 2004 at 04:19:44PM +0200, Artur Pydo wrote: > Hello, > > The current png-1.2.5_4 port has no more vulnerability. > It has been corrected by ache@FreeBSD.org yesterday. > But when i try to install the updated port to remplace > the vulnerable one this is what i am told : > > # make install > ===> png-1.2.5_4 has known vulnerabilities: > >> libpng denial-of-service. > Reference: > > >> Please update your ports tree and try again. > *** Error code 1 > > The 4-STABLE ports tree is up-to-date. > > Isn't it a problem to be unable to update a vulnerable port ? The VuXML document needed to be updated after ache@ made the fix. I've done so now. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon May 3 10:59:38 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0F0D16A4D5; Mon, 3 May 2004 10:59:38 -0700 (PDT) Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B87C43D54; Mon, 3 May 2004 10:59:36 -0700 (PDT) (envelope-from artur@pydo.org) Received: from bastion.pydo.net (bastion.pydo.net [62.212.97.116]) by kraid.nerim.net (Postfix) with ESMTP id 0A472412B0; Mon, 3 May 2004 19:59:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bastion.pydo.net (Postfix) with ESMTP id A8A284C2E2; Mon, 3 May 2004 19:59:34 +0200 (CEST) Received: from bastion.pydo.net ([127.0.0.1]) by localhost (fw.pydo.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15471-01-5; Mon, 3 May 2004 19:59:31 +0200 (CEST) Received: from pydo.org (univers.ipv6.pydo.org [IPv6:2001:618:472:0:250:8dff:fea5:1452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bastion.pydo.net (Postfix) with ESMTP id 5811D4C2EA; Mon, 3 May 2004 19:59:31 +0200 (CEST) Message-ID: <40968883.3070103@pydo.org> Date: Mon, 03 May 2004 19:59:31 +0200 From: Artur Pydo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <40965500.4040205@pydo.org> <20040503144335.GA15293@madman.celabo.org> In-Reply-To: <20040503144335.GA15293@madman.celabo.org> X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pydo.net cc: freebsd-security@freebsd.org Subject: Re: Bad VuXML check on PNG port ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 17:59:38 -0000 Hello, Jacques A. Vidrine wrote: > The VuXML document needed to be updated after ache@ made the fix. > I've done so now. Yes but the file located at : ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/eik/auditfile.tbz has not been updated and it works as the reference database for portaudit and, i suppose, for the pkg_install-base-devel ports. Nothing has changed for me even after updating the ports tree and the portaudit reference file. I know that there is a workaround modifying 'auditfile' by hand as it is a ascii file. I suggest that in future one avoid setting vulnerable versions as > 0 because the update fails as long as the reference file has not been updated with the correct vulnerable port later. In this case it would be much more efficient to set 'png<1.2.5_3' from the beginning. Thanks for your help. -- Best regards, Artur Pydo. From owner-freebsd-security@FreeBSD.ORG Mon May 3 11:06:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5FA916A4CE for ; Mon, 3 May 2004 11:06:23 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F8743D49 for ; Mon, 3 May 2004 11:06:23 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 4C74754840; Mon, 3 May 2004 13:06:22 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id E2E786FF34; Mon, 3 May 2004 13:06:21 -0500 (CDT) Date: Mon, 3 May 2004 13:06:21 -0500 From: "Jacques A. Vidrine" To: Artur Pydo Message-ID: <20040503180621.GA16203@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Artur Pydo , freebsd-security@freebsd.org References: <40965500.4040205@pydo.org> <20040503144335.GA15293@madman.celabo.org> <40968883.3070103@pydo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40968883.3070103@pydo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: Bad VuXML check on PNG port ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:06:24 -0000 On Mon, May 03, 2004 at 07:59:31PM +0200, Artur Pydo wrote: > Hello, > > Jacques A. Vidrine wrote: > > >The VuXML document needed to be updated after ache@ made the fix. > >I've done so now. > > Yes but the file located at : > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/eik/auditfile.tbz > > has not been updated and it works as the reference database for > portaudit and, i suppose, for the pkg_install-base-devel ports. > > Nothing has changed for me even after updating the ports tree > and the portaudit reference file. I know that there is a workaround > modifying 'auditfile' by hand as it is a ascii file. What you are describing is a problem with portaudit. You might want to contact eik@ to determine why the lag time. > I suggest that in future one avoid setting vulnerable versions as > 0 > because the update fails as long as the reference file has not been > updated with the correct vulnerable port later. > > In this case it would be much more efficient to set 'png<1.2.5_3' > from the beginning. I guess you mean `png <= 1.2.5_3'. That approach has its own problems, but I do use it sometimes if I am quite certain of which later port version will be fixed. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Mon May 3 11:28:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C191716A4CE; Mon, 3 May 2004 11:28:45 -0700 (PDT) Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F1AE43D4C; Mon, 3 May 2004 11:28:45 -0700 (PDT) (envelope-from artur@pydo.org) Received: from bastion.pydo.net (bastion.pydo.net [62.212.97.116]) by mallaury.noc.nerim.net (Postfix) with ESMTP id D5F8C62D65; Mon, 3 May 2004 20:28:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bastion.pydo.net (Postfix) with ESMTP id 9F9D84C259; Mon, 3 May 2004 20:28:36 +0200 (CEST) Received: from bastion.pydo.net ([127.0.0.1]) by localhost (fw.pydo.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23379-04-5; Mon, 3 May 2004 20:28:34 +0200 (CEST) Received: from pydo.org (univers.ipv6.pydo.org [IPv6:2001:618:472:0:250:8dff:fea5:1452]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bastion.pydo.net (Postfix) with ESMTP id 436394C256; Mon, 3 May 2004 20:28:34 +0200 (CEST) Message-ID: <40968F52.1070405@pydo.org> Date: Mon, 03 May 2004 20:28:34 +0200 From: Artur Pydo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-fr, fr, en-us, en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <40965500.4040205@pydo.org> <20040503144335.GA15293@madman.celabo.org> <40968883.3070103@pydo.org> <20040503180621.GA16203@madman.celabo.org> In-Reply-To: <20040503180621.GA16203@madman.celabo.org> X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at pydo.net cc: freebsd-security@freebsd.org Subject: Re: Bad VuXML check on PNG port ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:28:45 -0000 Hi, Jacques A. Vidrine wrote: > What you are describing is a problem with portaudit. You might want > to contact eik@ to determine why the lag time. OK. >>In this case it would be much more efficient to set 'png<1.2.5_3' >>from the beginning. > > I guess you mean `png <= 1.2.5_3'. You're right. :) -- Best regards, Artur Pydo. From owner-freebsd-security@FreeBSD.ORG Mon May 3 11:47:31 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C05E016A4CE for ; Mon, 3 May 2004 11:47:31 -0700 (PDT) Received: from mail.xensia.net (colo1.xensia.net [217.158.173.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB9543D54 for ; Mon, 3 May 2004 11:47:31 -0700 (PDT) (envelope-from listsucker@ipv5.net) Received: from 81-174-2-199.f5.ngi.it ([81.174.2.199] helo=godzilla) by mail.xensia.net with asmtp (TLSv1:DES-CBC3-SHA:168) id 1BKiTR-000LWK-00; Mon, 03 May 2004 19:47:30 +0100 Date: Mon, 3 May 2004 20:47:13 +0200 From: Frankye - ML To: freebsd-security@freebsd.org Message-Id: <20040503204713.3abb28e0@godzilla> In-Reply-To: <40968883.3070103@pydo.org> References: <40965500.4040205@pydo.org> <20040503144335.GA15293@madman.celabo.org> <40968883.3070103@pydo.org> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.10) X-Face: =3I@Jvohf91[b8M]~KUNFaCt}pnTO2K^E#_P4`uCU]D"pHw List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:47:31 -0000 On Mon, 03 May 2004 19:59:31 +0200 Artur Pydo wrote: [cut] | I know that there is a workaround | modifying 'auditfile' by hand as it is a ascii file. | | I suggest that in future one avoid setting vulnerable versions as > 0 | because the update fails as long as the reference file has not been | updated with the correct vulnerable port later. | | In this case it would be much more efficient to set 'png<1.2.5_3' | from the beginning. imvho the drawbacks of this solution outweight its usefulness. If a commit does not solve the problem but makes the port to look not vulnerable, and I'm a very sloppy or very overworked sysadmin, I might not notice. Would you prefer me sweating around the upgrade of something I know is patched, but portaudit prevents me from portupgrading, or my cracked zombie machine pounding at your network while I'm slacking off? :) Just my 2 cents Frankye From owner-freebsd-security@FreeBSD.ORG Mon May 3 22:50:02 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0DB116A4CE for ; Mon, 3 May 2004 22:50:02 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.45.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2ED443D41 for ; Mon, 3 May 2004 22:49:59 -0700 (PDT) (envelope-from bogorodskiy@inbox.ru) Received: from [194.186.150.78] (port=49309 helo=localhost) by mx1.mail.ru with esmtp id 1BKso9-0007mN-00 for freebsd-security@freebsd.org; Tue, 04 May 2004 09:49:34 +0400 Date: Tue, 4 May 2004 09:49:09 +0400 From: Roman Bogorodskiy To: freebsd-security@freebsd.org Message-ID: <20040504054909.GA3119@lame.novel.ru> Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline "From: Roman Bogordskiy " User-Agent: Mutt/1.5.6i X-Spam: Not detected Subject: ctags(1) command execution vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 05:50:03 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, ctags(1) uses external application sort(1) for sorting the tags file. It calls it via system(3) function.=20 Look at the /usr/src/usr.bin/ctags/ctags.c file, there are such lines here:=20 if (uflag) { (void)asprintf(&cmd, "sort -o %s %s", outfile, outfile); if (cmd =3D=3D NULL) err(1, "out of space"); system(cmd); free(cmd); cmd =3D NULL; } This code will be executed when "-u" arg was given. So, if we'll execute=20 ctags in a such way: ctags -u -f ';echo hi' *.c we get the following: Syntax error: ";" unexpected sort: option requires an argument -- o Try `sort --help' for more information. hi hi We can put any command instead of 'echo hi' and it would be executed (for two times).=20 I understand that ctags(1) is not a suid application and this vulnerability probably could not be exploited. Never the less, this is a bad behavior for any kind of program.=20 Solution: --- usr.bin/ctags/ctags.c.orig Tue May 4 09:23:30 2004 +++ usr.bin/ctags/ctags.c Tue May 4 09:25:48 2004 @@ -166,7 +166,7 @@ if (uflag) { for (step =3D 0; step < argc; step++) { (void)asprintf(&cmd, - "mv %s OTAGS; fgrep -v '\t%s\t' OTAGS >%s; rm OTAGS", + "mv '%s' OTAGS; fgrep -v '\t%s\t' OTAGS >'%s'; rm OTAGS", outfile, argv[step], outfile); if (cmd =3D=3D NULL) err(1, "out of space"); @@ -181,7 +181,7 @@ put_entries(head); (void)fclose(outf); if (uflag) { - (void)asprintf(&cmd, "sort -o %s %s", + (void)asprintf(&cmd, "sort -o '%s' '%s'", outfile, outfile); if (cmd =3D=3D NULL) err(1, "out of space"); -Roman Bogorodskiy --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iQEVAwUBQJcu1SpMDQ8aPhy0AQLZ0Af+J2ZWvcdtSRdbG207Q9P+aDcARfwwDgXJ 0aXXVx9t1h+KY7/elitlgXzQzvuqVdeFDt52+wCvFNNjb6d2QeqNBCYb7rdcxT8y q00G8N/uYcTDM635C6nmetr0Q+Aio1tIGiMyp8P4goT6n45MpoA5i/oLKhGsFp8c FpiOkaqKB6WIqe9d1hrxXgrBDe4LFHjK1eH6JlBGS6M5xWpk1pu4XByY/3t2fLGE Pd5oJL5WBUT6p9dRAnNeEC7qOKVqhBAQ8WMlSf7/SaQPQJK8eaVRy9FEpgbmayA4 pe+jU+PnurB0y5grpntnznWbCTnzwluDPfwROpnEMxhp7KvPgC1Law== =Hf2c -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-security@FreeBSD.ORG Mon May 3 23:33:22 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECD1916A4CE for ; Mon, 3 May 2004 23:33:21 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id F3F2D43D1D for ; Mon, 3 May 2004 23:33:19 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 31945 invoked from network); 4 May 2004 06:25:55 -0000 Received: from office.sbnd.net (HELO straylight.m.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 4 May 2004 06:25:54 -0000 Received: (qmail 71235 invoked by uid 1000); 4 May 2004 06:33:16 -0000 Date: Tue, 4 May 2004 09:33:16 +0300 From: Peter Pentchev To: freebsd-security@freebsd.org Message-ID: <20040504063316.GM971@straylight.m.ringlet.net> Mail-Followup-To: freebsd-security@freebsd.org References: <20040504054909.GA3119@lame.novel.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3607uds81ZQvwCD0" Content-Disposition: inline In-Reply-To: <20040504054909.GA3119@lame.novel.ru> User-Agent: Mutt/1.5.6i Subject: Re: ctags(1) command execution vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 06:33:22 -0000 --3607uds81ZQvwCD0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 04, 2004 at 09:49:09AM +0400, Roman Bogorodskiy wrote: > Hello, >=20 > ctags(1) uses external application sort(1) for sorting the tags file. > It calls it via system(3) function.=20 [snip] > This code will be executed when "-u" arg was given. So, if we'll execute= =20 > ctags in a such way: >=20 > ctags -u -f ';echo hi' *.c [snip] > - "mv %s OTAGS; fgrep -v '\t%s\t' OTAGS >%s; rm OTAGS", > + "mv '%s' OTAGS; fgrep -v '\t%s\t' OTAGS >'%s'; rm OTAGS", [snip] > - (void)asprintf(&cmd, "sort -o %s %s", > + (void)asprintf(&cmd, "sort -o '%s' '%s'", Unfortunately, this is still not a complete solution; the following still works, at least for me: ctags -u -f "'; echo hi; '" *.c Filtering the filename characters would be a better idea; possibly something like the attached patch. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn'= t! Index: src/usr.bin/ctags/ctags.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/ctags/ctags.c,v retrieving revision 1.18 diff -u -r1.18 ctags.c --- src/usr.bin/ctags/ctags.c 28 Jul 2002 15:50:38 -0000 1.18 +++ src/usr.bin/ctags/ctags.c 4 May 2004 06:27:23 -0000 @@ -46,6 +46,7 @@ #include __FBSDID("$FreeBSD: src/usr.bin/ctags/ctags.c,v 1.18 2002/07/28 15:50:38 d= wmalone Exp $"); =20 +#include #include #include #include @@ -84,6 +85,7 @@ void init(void); void find_entries(char *); static void usage(void); +static char *validatename(const char *); =20 int main(int argc, char **argv) @@ -118,7 +120,7 @@ dflag++; break; case 'f': - outfile =3D optarg; + outfile =3D validatename(optarg); break; case 't': tflag =3D YES; @@ -201,6 +203,25 @@ exit(1); } =20 +static char * +validatename(const char *fname) +{ + char *n, *q; + const char *p, *end; + size_t len; + + len =3D strlen(fname); + n =3D malloc(len + 1); + if (n =3D=3D NULL) + errx(1, "out of memory"); + end =3D n + len; + for (p =3D fname, q =3D n; *p !=3D '\0' && q !=3D end; p++) + if (isalnum(*p) || strchr("-_./", *p) !=3D NULL) + *q++ =3D *p; + *q =3D '\0'; + return (n); +} + /* * init -- * this routine sets up the boolean pseudo-functions which work by --3607uds81ZQvwCD0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAlzks7Ri2jRYZRVMRAgQ4AJ9LEE0VNee8HhLbHAsbYYhr7+potgCfU48a U3Zm3CwU67Chz1MsWVZMglM= =RRar -----END PGP SIGNATURE----- --3607uds81ZQvwCD0-- From owner-freebsd-security@FreeBSD.ORG Mon May 3 23:44:10 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B99916A4CE for ; Mon, 3 May 2004 23:44:10 -0700 (PDT) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB3A143D62 for ; Mon, 3 May 2004 23:44:09 -0700 (PDT) (envelope-from hamburg@fas.harvard.edu) Received: from [140.247.133.37] (roam133-37.student.harvard.edu [140.247.133.37])i446i9i22446 for ; Tue, 4 May 2004 02:44:09 -0400 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <20040504054909.GA3119@lame.novel.ru> References: <20040504054909.GA3119@lame.novel.ru> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6FDDCA56-9D96-11D8-A696-0003939A19AA@fas.harvard.edu> Content-Transfer-Encoding: 7bit From: Michael Hamburg Date: Tue, 4 May 2004 02:44:05 -0400 To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: ctags(1) command execution vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 06:44:10 -0000 While I don't think that's much of a vulnerability (you can only really attack your own account), your patch doesn't fix it. You can still executed code with: ctags -u -f "'; echo hi '" *.c To remove this "vulnerability," you'd have to either escape the string, then quote it, or even better, do the system call with a vector. It probably isn't worth the bother, but if you want to patch it, patch it right... Mike Hamburg On May 4, 2004, at 1:49 AM, Roman Bogorodskiy wrote: > Hello, > > ctags(1) uses external application sort(1) for sorting the tags file. > It calls it via system(3) function. > > Look at the /usr/src/usr.bin/ctags/ctags.c file, there are such lines > here: > > if (uflag) { > (void)asprintf(&cmd, "sort -o %s %s", > outfile, outfile); > if (cmd == NULL) > err(1, "out of space"); > system(cmd); > free(cmd); > cmd = NULL; > } > > This code will be executed when "-u" arg was given. So, if we'll > execute > ctags in a such way: > > ctags -u -f ';echo hi' *.c > > we get the following: > > Syntax error: ";" unexpected > sort: option requires an argument -- o > Try `sort --help' for more information. > hi > hi > > We can put any command instead of 'echo hi' and it would be executed > (for two times). > > I understand that ctags(1) is not a suid application and this > vulnerability probably could not be exploited. Never the less, this is > a > bad behavior for any kind of program. > > Solution: > > --- usr.bin/ctags/ctags.c.orig Tue May 4 09:23:30 2004 > +++ usr.bin/ctags/ctags.c Tue May 4 09:25:48 2004 > @@ -166,7 +166,7 @@ > if (uflag) { > for (step = 0; step < argc; step++) { > (void)asprintf(&cmd, > - "mv %s OTAGS; fgrep -v '\t%s\t' OTAGS >%s; rm OTAGS", > + "mv '%s' OTAGS; fgrep -v '\t%s\t' OTAGS >'%s'; rm OTAGS", > outfile, argv[step], outfile); > if (cmd == NULL) > err(1, "out of space"); > @@ -181,7 +181,7 @@ > put_entries(head); > (void)fclose(outf); > if (uflag) { > - (void)asprintf(&cmd, "sort -o %s %s", > + (void)asprintf(&cmd, "sort -o '%s' '%s'", > outfile, outfile); > if (cmd == NULL) > err(1, "out of space"); > > > -Roman Bogorodskiy > From owner-freebsd-security@FreeBSD.ORG Thu Apr 29 11:57:43 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A8DE16A4CE for ; Thu, 29 Apr 2004 11:57:43 -0700 (PDT) Received: from idos.mave.ru (eustrop.pikenet.ru [194.135.35.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38D9F43D45 for ; Thu, 29 Apr 2004 11:57:41 -0700 (PDT) (envelope-from eustrop@net.mave.ru) Received: from azest.net.mave.ru (azest.net.mave.ru [10.0.0.10]) by idos.mave.ru (8.12.9p2/8.12.9) with ESMTP id i3TIvcui022097; Thu, 29 Apr 2004 22:57:38 +0400 (MSD) (envelope-from eustrop@net.mave.ru) Received: from azest.net.mave.ru (localhost.mave.ru [127.0.0.1]) by azest.net.mave.ru (8.12.9p2/8.12.9) with ESMTP id i3TIvbMq004217; Thu, 29 Apr 2004 22:57:37 +0400 (MSD) (envelope-from eustrop@azest.net.mave.ru) Received: (from eustrop@localhost) by azest.net.mave.ru (8.12.9p2/8.12.9/Submit) id i3TIvaap004216; Thu, 29 Apr 2004 22:57:36 +0400 (MSD) (envelope-from eustrop) From: Alex V Eustrop Message-Id: <200404291857.i3TIvaap004216@azest.net.mave.ru> In-Reply-To: <20040429160357.GA6623@gremlin.timing.com> To: Nick Golder Date: Thu, 29 Apr 2004 22:57:36 +0400 (MSD) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version devel-20040427, clamav-milter version 0.70s X-Virus-Scanned: clamd / ClamAV version devel-20040427, clamav-milter version 0.70s X-Virus-Status: Clean X-Virus-Status: Clean X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on azest.net.mave.ru X-Mailman-Approved-At: Tue, 04 May 2004 03:26:44 -0700 cc: freebsd-security@freebsd.org Subject: Re: Sendmail issues; possible exploit? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2004 18:57:43 -0000 > On a 4.8-RELEASE-p17 machine running Sendmail 8.12.8p2 we are seeing the > following errors in /var/log/{messages,maillog}: > sm-mta[50018]: i3TDTBcR050018: SYSERR(root): out of memory: Cannot > allocate memory Are you using clamav-milter? There are was such trouble with clamav-milter from clamav-devel before Apr 2004 on FreeBSD 4.9 (sendmail 8.12.9p2) I had that problem with 1.5 minutes or more while transferring single message to sendmail with clamav-milter. Sendmail has no trouble without clamav-milter or with other one (For example - spamass-milter-0.2.0_1 port) Clamav was fixed for that bug, but real problem could be (on not to be) inside sendmail. P.S. I am not sure that my message will be posted to freebsd-security@, but you can forward it to upcoming discussion if it's interesting. -- Regards Eustrop From owner-freebsd-security@FreeBSD.ORG Tue May 4 17:39:11 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2828816A4CF for ; Tue, 4 May 2004 17:39:11 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 622AB43D5C for ; Tue, 4 May 2004 17:39:10 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (sccrmhc11) with ESMTP id <2004050500390901100d30r3e>; Wed, 5 May 2004 00:39:09 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i450d88B081667 for ; Tue, 4 May 2004 17:39:08 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i450d7v3081666 for freebsd-security@freebsd.org; Tue, 4 May 2004 17:39:07 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 4 May 2004 17:39:07 -0700 From: "Crist J. Clark" To: freebsd-security@freebsd.org Message-ID: <20040505003907.GA80906@blossom.cjclark.org> References: <20040504054909.GA3119@lame.novel.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040504054909.GA3119@lame.novel.ru> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: ctags(1) command execution vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 00:39:11 -0000 On Tue, May 04, 2004 at 09:49:09AM +0400, Roman Bogorodskiy wrote: > Hello, > > ctags(1) uses external application sort(1) for sorting the tags file. > It calls it via system(3) function. > > Look at the /usr/src/usr.bin/ctags/ctags.c file, there are such lines > here: > > if (uflag) { > (void)asprintf(&cmd, "sort -o %s %s", > outfile, outfile); > if (cmd == NULL) > err(1, "out of space"); > system(cmd); > free(cmd); > cmd = NULL; > } Ick. There's another system(3) call above this one too, for (step = 0; step < argc; step++) { (void)asprintf(&cmd, "mv %s OTAGS; fgrep -v '\t%s\t' OTAGS >%s; rm OTAGS", outfile, argv[step], outfile); if (cmd == NULL) err(1, "out of space"); system(cmd); free(cmd); cmd = NULL; } Also bad. > This code will be executed when "-u" arg was given. So, if we'll execute > ctags in a such way: > > ctags -u -f ';echo hi' *.c > > we get the following: > > Syntax error: ";" unexpected > sort: option requires an argument -- o > Try `sort --help' for more information. > hi > hi The two 'hi's are from each system(3) call. > Solution: As has been pointed out, the problem here is user supplied data to a system(3) call that we really cannot sanitize without filtering a lot of valid file names. The Right Thing is to get rid of system(3). This seems to work. Fixing the sort is trivial. Adding the regex checks to the program adds a little complexity, but not a lot. Anyone who actually uses ctags(1) want to try them out some more to see if they hold up? Index: ctags.c =================================================================== RCS file: /export/freebsd/ncvs/src/usr.bin/ctags/ctags.c,v retrieving revision 1.18 diff -u -r1.18 ctags.c --- ctags.c 28 Jul 2002 15:50:38 -0000 1.18 +++ ctags.c 5 May 2004 00:27:09 -0000 @@ -44,11 +44,13 @@ #endif #include +#include __FBSDID("$FreeBSD: src/usr.bin/ctags/ctags.c,v 1.18 2002/07/28 15:50:38 dwmalone Exp $"); #include #include #include +#include #include #include #include @@ -164,16 +166,37 @@ put_entries(head); else { if (uflag) { + FILE *oldf; + regex_t *regx; + + if ((oldf = fopen(outfile, "r")) == NULL) + err(1, "opening %s", outfile); + if (unlink(outfile)) + err(1, "unlinking %s", outfile); + if ((outf = fopen(outfile, "w")) == NULL) + err(1, "recreating %s", outfile); + if ((regx = calloc(argc, sizeof(regex_t))) == NULL) + err(1, "RE alloc"); for (step = 0; step < argc; step++) { - (void)asprintf(&cmd, - "mv %s OTAGS; fgrep -v '\t%s\t' OTAGS >%s; rm OTAGS", - outfile, argv[step], outfile); - if (cmd == NULL) - err(1, "out of space"); - system(cmd); - free(cmd); - cmd = NULL; + (void)strcpy(lbuf, "\t"); + (void)strlcat(lbuf, argv[step], LINE_MAX); + (void)strlcat(lbuf, "\t", LINE_MAX); + if (regcomp(regx + step, lbuf, + REG_NOSPEC)) + warn("RE compilation failed"); + } +nextline: + while (fgets(lbuf, LINE_MAX, oldf)) { + for (step = 0; step < argc; step++) + if (regexec(regx + step, + lbuf, 0, NULL, 0) == 0) + goto nextline; + fputs(lbuf, outf); } + for (step = 0; step < argc; step++) + regfree(regx + step); + fclose(oldf); + fclose(outf); ++aflag; } if (!(outf = fopen(outfile, aflag ? "a" : "w"))) @@ -181,13 +204,15 @@ put_entries(head); (void)fclose(outf); if (uflag) { - (void)asprintf(&cmd, "sort -o %s %s", - outfile, outfile); - if (cmd == NULL) - err(1, "out of space"); - system(cmd); - free(cmd); - cmd = NULL; + pid_t pid; + if ((pid = fork()) == -1) + err(1, "fork failed"); + else if (pid == 0) { + execlp("sort", "sort", "-o", outfile, + outfile, NULL); + /* NOT REACHED */ + err(1, "exec of sort failed"); + } } } } -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed May 5 05:01:24 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29FB416A4CE for ; Wed, 5 May 2004 05:01:24 -0700 (PDT) Received: from ux1.ibb.net (ux1.ibb.net [64.215.98.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CBC43D1F for ; Wed, 5 May 2004 05:01:23 -0700 (PDT) (envelope-from mipam@ibb.net) Received: from localhost (mipam@localhost) by ux1.ibb.net (8.9.3/8.9.3/UX1TT) with ESMTP id MAA18567 for ; Wed, 5 May 2004 12:50:09 +0200 X-Authentication-Warning: ux1.ibb.net: mipam owned process doing -bs Date: Wed, 5 May 2004 12:50:09 +0200 (MET DST) From: Mipam To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: worms and fw sending rst's instead of drop X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 12:01:24 -0000 Hi, I was wondering upon how some of you think upon some issues upon block policies in firewalls. Basically you can choose a firewall to send resets back as answer upon probes etc to not allowed ports, or you can choose a firewall to drop the packets. In general i think just dropping is the better one. Consider the lastest worms like blaster and sasser. How many hits would some firewalls encounter on blocked ports from such worms on bussy networks? If a firewall has to send resets upon each hit, the firewall is very bussy sending out resets. On very bussy firewalls it may even lead to a serious degree of resource starvation? Simply dropping these probes wouldnt cause these problems because no answer is generated. Of course, another possibility is to limit the amount of resets you're sending back. Like: if i have to send more then n resets back i wont, meaning not on all packets resets are send back. But i dont think firewalls support such a feature yet? Moreover worms like blaster and sasser spread way to fast for manual intervention. An IDS would have to intervene i guess. How difficult would it be for an IDS to notice that in such a short notice so much traffic from and to certain ports (eg 445) is being generated and block the stuff because such an amount has to be an anomaly? I guess it's the only way to remedy such problems. Of course traffic shaping helps as well. Bye, Mipam. From owner-freebsd-security@FreeBSD.ORG Wed May 5 09:56:40 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4770B16A4CE for ; Wed, 5 May 2004 09:56:40 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AB5443D73 for ; Wed, 5 May 2004 09:56:36 -0700 (PDT) (envelope-from nectar@celabo.org) Received: by gw.celabo.org (Postfix, from userid 1001) id 080515486E; Wed, 5 May 2004 11:56:36 -0500 (CDT) Date: Wed, 5 May 2004 11:56:36 -0500 From: "Jacques A. Vidrine" To: freebsd-security@FreeBSD.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Message-ID: <20040505165636.GB40758@hellblazer.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-security@FreeBSD.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i Subject: Fwd: [Re: cvs commit: src/sys/vm vm_map.c] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 16:56:40 -0000 Hello, FYI: A FreeBSD user suggested that this issue requires a security advisory. The issue has been public for some time, but currently, FreeBSD does not issue advisories for local denial-of-service issues. It is expected that this bug will soon be fixed in FreeBSD 4.x (it is already fixed in FreeBSD 5.x, as you can see below). Cheers, -- Jacques Vidrine ----- Forwarded message from Tim Robbins ----- Date: Tue, 23 Mar 2004 21:53:10 +1100 From: Tim Robbins To: Pawel Jakub Dawidek cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c Message-ID: <20040323105310.GA14855@cat.robbins.dropbear.id.au> On Tue, Mar 23, 2004 at 11:33:00AM +0100, Pawel Jakub Dawidek wrote: > On Tue, Mar 23, 2004 at 12:37:35AM -0800, Tim J. Robbins wrote: > +> tjr 2004/03/23 00:37:34 PST > +> > +> FreeBSD src repository > +> > +> Modified files: > +> sys/vm vm_map.c > +> Log: > +> Do not copy vm_exitingcnt to the new vmspace in vmspace_exec(). Copying > +> it led to impossibly high values in the new vmspace, causing it to never > +> drop to 0 and be freed. > > How serious it is? Do you planning to MFC it to RELENG_4 with peter@'s > patch of course? A user can cause the kernel to allocate an unbounded amount of wired memory, causing the machine to panic or stop responding. It's been observed to happen under real workloads; that is, the circumstances are not so contrived that the bug could only be caused by a malicious user. I don't have any immediate plans to MFC it (I don't have any 4.x systems right now), but peter@ or ps@ may want to after letting it settle for a while in -current. Tim ----- End forwarded message ----- From owner-freebsd-security@FreeBSD.ORG Wed May 5 14:26:56 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A9416A4CE; Wed, 5 May 2004 14:26:56 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A984C43D53; Wed, 5 May 2004 14:26:52 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (nectar@localhost [127.0.0.1]) i45LQqWf002527; Wed, 5 May 2004 14:26:52 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Received: (from nectar@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i45LQqJ2002525; Wed, 5 May 2004 14:26:52 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Date: Wed, 5 May 2004 14:26:52 -0700 (PDT) Message-Id: <200405052126.i45LQqJ2002525@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: nectar set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-04:08.heimdal X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 21:26:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:08.heimdal Security Advisory The FreeBSD Project Topic: heimdal cross-realm trust vulnerability Category: core Module: crypto_heimdal Announced: 2004-05-05 Credits: Heimdal project Affects: FreeBSD 4 with Kerberos 5 installed, and FreeBSD 5 Corrected: 2004-05-05 19:49:41 UTC (RELENG_4, 4.10-PRERELEASE) 2004-05-05 19:55:46 UTC (RELENG_5_2, 5.2.1-RELEASE-p6) 2004-05-05 20:48:19 UTC (RELENG_4_10, 4.10-RELEASE-RC) 2004-05-05 20:01:06 UTC (RELENG_4_9, 4.9-RELEASE-p6) 2004-05-05 20:06:30 UTC (RELENG_4_8, 4.8-RELEASE-p19) CVE Name: CAN-2004-0371 FreeBSD only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Heimdal implements the Kerberos 5 network authentication protocols. Principals (i.e. users and services) represented in Kerberos are grouped into separate, autonomous realms. Unidirectional or bidirectional trust relationships may be established between realms to allow the principals in one realm to recognize the authenticity of principals in another. These trust relationships may be transitive. An authentication path is the ordered list of realms (and therefore KDCs) that were involved in the authentication process. The authentication path is recorded in Kerberos tickets as the `transited' field. It is possible for the Key Distribution Center (KDC) of a realm to forge part or all of the `transited' field. KDCs should validate this field before accepting authentication results, checking that each realm in the authentication path is trusted and that the path conforms to local policy. Applications are required to perform this type of checking if the KDC has not already done so. Prior to FreeBSD 5.1, Kerberos 5 was an optional component of FreeBSD, and was not installed by default. II. Problem Description Some versions of Heimdal do not perform appropriate checking of the `transited' field. III. Impact For sites that have established trust relationships with other realms, it is possible for the administrator(s) of those other realms to impersonate any Kerberos principal in any other realm. IV. Workaround Disable all inter-realm trust relationships. The Heimdal advisory listed in the References section below provides details for checking for trust relationships and disabling them. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_2, RELENG_4_9, or RELENG_4_8 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.8, 4.9, 5.1, and 5.2 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 4.8, 4.9, 5.1 with Heimdal 0.5.1] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:08/heimdal51.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:08/heimdal51.patch.asc [FreeBSD 5.2 with Heimdal 0.6] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:08/heimdal6.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:08/heimdal6.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/secure/lib/libcrypto # make obj && make depend && make # cd /usr/src/kerberos5 # make obj && make depend && make && make install Be sure to restart any running services that use Kerberos, such as kdc(8) or sshd(8). Perhaps the simplest way to ensure all such applications are restarted is to reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/crypto/heimdal/kdc/config.c 1.1.1.2.2.4 src/crypto/heimdal/kdc/kdc.8 1.1.1.2.2.5 src/crypto/heimdal/kdc/kdc_locl.h 1.1.1.2.2.4 src/crypto/heimdal/kdc/kerberos5.c 1.1.1.2.2.5 src/crypto/heimdal/lib/krb5/krb5-protos.h 1.1.1.3.2.5 src/crypto/heimdal/lib/krb5/rd_req.c 1.1.1.3.2.3 src/crypto/heimdal/lib/krb5/transited.c 1.1.1.3.2.3 RELENG_5_2 src/UPDATING 1.282.2.14 src/crypto/heimdal/kdc/config.c 1.1.1.7.2.1 src/crypto/heimdal/kdc/kdc.8 1.1.1.7.2.1 src/crypto/heimdal/kdc/kdc_locl.h 1.1.1.6.2.1 src/crypto/heimdal/kdc/kerberos5.c 1.1.1.8.2.1 src/crypto/heimdal/lib/krb5/krb5-protos.h 1.1.1.9.2.1 src/crypto/heimdal/lib/krb5/rd_req.c 1.1.1.6.6.1 src/crypto/heimdal/lib/krb5/transited.c 1.1.1.6.2.1 src/sys/conf/newvers.sh 1.56.2.13 RELENG_4_10 src/crypto/heimdal/kdc/config.c 1.1.1.2.2.3.8.1 src/crypto/heimdal/kdc/kdc.8 1.1.1.2.2.4.8.1 src/crypto/heimdal/kdc/kdc_locl.h 1.1.1.2.2.3.8.1 src/crypto/heimdal/kdc/kerberos5.c 1.1.1.2.2.4.8.1 src/crypto/heimdal/lib/krb5/krb5-protos.h 1.1.1.3.2.4.8.1 src/crypto/heimdal/lib/krb5/rd_req.c 1.1.1.3.2.2.10.1 src/crypto/heimdal/lib/krb5/transited.c 1.1.1.3.2.2.8.1 RELENG_4_9 src/UPDATING 1.73.2.89.2.7 src/crypto/heimdal/kdc/config.c 1.1.1.2.2.3.6.1 src/crypto/heimdal/kdc/kdc.8 1.1.1.2.2.4.6.1 src/crypto/heimdal/kdc/kdc_locl.h 1.1.1.2.2.3.6.1 src/crypto/heimdal/kdc/kerberos5.c 1.1.1.2.2.4.6.1 src/crypto/heimdal/lib/krb5/krb5-protos.h 1.1.1.3.2.4.6.1 src/crypto/heimdal/lib/krb5/rd_req.c 1.1.1.3.2.2.8.1 src/crypto/heimdal/lib/krb5/transited.c 1.1.1.3.2.2.6.1 src/sys/conf/newvers.sh 1.44.2.32.2.7 RELENG_4_8 src/UPDATING 1.73.2.80.2.22 src/crypto/heimdal/kdc/config.c 1.1.1.2.2.3.4.1 src/crypto/heimdal/kdc/kdc.8 1.1.1.2.2.4.4.1 src/crypto/heimdal/kdc/kdc_locl.h 1.1.1.2.2.3.4.1 src/crypto/heimdal/kdc/kerberos5.c 1.1.1.2.2.4.4.1 src/crypto/heimdal/lib/krb5/krb5-protos.h 1.1.1.3.2.4.4.1 src/crypto/heimdal/lib/krb5/rd_req.c 1.1.1.3.2.2.6.1 src/crypto/heimdal/lib/krb5/transited.c 1.1.1.3.2.2.4.1 src/sys/conf/newvers.sh 1.44.2.29.2.20 - ------------------------------------------------------------------------- VII. References -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAmVTvFdaIBMps37IRAkhZAKCQZmbxNkicz82VEcPeDO/840uNxwCfQ/0U NYT36OgpzsBI9Jc0cpDXTA4= =i17O -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed May 5 14:27:00 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F0B516A4CE; Wed, 5 May 2004 14:27:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B5443D5A; Wed, 5 May 2004 14:26:57 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (nectar@localhost [127.0.0.1]) i45LQvrV002569; Wed, 5 May 2004 14:26:57 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Received: (from nectar@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i45LQv5w002567; Wed, 5 May 2004 14:26:57 -0700 (PDT) (envelope-from security-advisories@freebsd.org) Date: Wed, 5 May 2004 14:26:57 -0700 (PDT) Message-Id: <200405052126.i45LQv5w002567@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: nectar set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-04:09.kadmind X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 21:27:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:09.kadmind Security Advisory The FreeBSD Project Topic: heimdal kadmind remote heap buffer overflow Category: contrib Module: crypto_heimdal Announced: 2004-05-05 Credits: Evgeny Demidov, VulnDisco, Love Hornquist-Astrand Affects: FreeBSD 4 systems built with both Kerberos 4 and Kerberos 5. FreeBSD 5 systems prior to 5.1 built with both Kerberos 4 and Kerberos 5. Corrected: 2004-05-05 20:19:48 UTC (RELENG_4, 4.10-PRERELEASE) 2004-05-05 20:48:57 UTC (RELENG_4_10, 4.10-RELEASE-RC) 2004-05-05 20:15:56 UTC (RELENG_4_9, 4.9-RELEASE-p7) 2004-05-05 20:17:51 UTC (RELENG_4_8, 4.8-RELEASE-p20) CVE Name: CAN-2004-0434 FreeBSD only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Heimdal implements the Kerberos 5 network authentication protocols. The k5admind(8) daemon provides the administrative interface to the Kerberos Key Distribution Center (KDC). In some configurations, k5admind also includes Kerberos 4 compatibility. NOTE: FreeBSD versions prior to 5.1-RELEASE contain optional Kerberos 4 support. FreeBSD versions 5.1-RELEASE and later do not include Kerberos 4 support of any kind. II. Problem Description An input validation error was discovered in the k5admind code that handles the framing of Kerberos 4 compatibility administration requests. The code assumed that the length given in the framing was always two or more bytes. Smaller lengths will cause k5admind to read an arbitrary amount of data into a minimally-sized buffer on the heap. Note that this code is not present unless k5admind has been compiled with Kerberos 4 support. This will occur if a FreeBSD system is compiled with both of the WITH_KERBEROS4 and WITH_KERBEROS5 build flags. These flags are never simultaneously set during the FreeBSD binary release process; consequently, binary installs of FreeBSD (even with Kerberos support installed) are not affected. III. Impact A remote attacker may send a specially formatted message to k5admind, causing it to crash or possibly resulting in arbitrary code execution. IV. Workaround Disable the Kerberos 4 support in k5admind by running it with the `--no-kerberos4' option. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_4_9 or RELENG_4_8 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.8 and 4.9. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:09/kadmind.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:09/kadmind.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/kerberos5/tools # make obj && make depend && make # cd /usr/src/kerberos5/lib # make obj && make depend && make # cd /usr/src/kerberos5/libexec/k5admind # make obj && make depend && make all install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/crypto/heimdal/kadmin/version4.c 1.1.1.1.2.6 RELENG_4_10 src/crypto/heimdal/kadmin/version4.c 1.1.1.1.2.5.6.1 RELENG_4_9 src/UPDATING 1.73.2.89.2.8 src/crypto/heimdal/kadmin/version4.c 1.1.1.1.2.5.4.1 src/sys/conf/newvers.sh 1.44.2.32.2.8 RELENG_4_8 src/UPDATING 1.73.2.80.2.23 src/crypto/heimdal/kadmin/version4.c 1.1.1.1.2.5.2.1 src/sys/conf/newvers.sh 1.44.2.29.2.21 - ------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAmVp/FdaIBMps37IRArWAAJ9wsAaSmpmkdisZ7dKCdUqtjzi5/ACfQx91 Rl2JAQ/JrZyoOlwYRea1SLc= =gQfq -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu May 6 17:39:47 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 968E016A4CE for ; Thu, 6 May 2004 17:39:47 -0700 (PDT) Received: from joint.crazylogic.net (joint.crazylogic.net [66.207.217.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7374743D2D for ; Thu, 6 May 2004 17:39:45 -0700 (PDT) (envelope-from matt@crazylogic.net) Received: from haklot ([66.207.217.141]) by joint.crazylogic.net (8.12.9/8.12.9) with ESMTP id i440XLNN021506 for ; Mon, 3 May 2004 20:33:21 -0400 (EDT) (envelope-from matt@crazylogic.net) From: "Matt Gostick" To: Date: Mon, 3 May 2004 20:33:22 -0400 Message-ID: <001001c4316f$6ab193d0$cb01a8c0@haklot> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: scheduled pings X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:39:47 -0000 Hello, I have just setup some ipfw rules to checkout some traffic to one of my boxes. I have three servers, only one of which has weird traffic. It is getting ping'd on a five minute interval from approx 3 to 8 different ip addresses within the same second. For example: May 3 20:20:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 202.160.241.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:20:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 202.160.241.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 64.35.7.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 212.162.1.194 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 216.74.133.194 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 63.218.7.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:03 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 166.90.213.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:04 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 205.158.108.194 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 64.35.7.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 212.162.1.194 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 216.74.133.194 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 63.218.7.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:13 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 166.90.213.130 xxx.xxx.xxx.xxx in via dc0 May 3 20:25:14 gaspra kernel: ipfw: 65002 Deny ICMP:8.0 205.158.108.194 xxx.xxx.xxx.xxx in via dc0 I've just started denying pings to the box... What is this? Matt Gostick From owner-freebsd-security@FreeBSD.ORG Fri May 7 07:19:13 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D34A16A4E3; Fri, 7 May 2004 07:19:13 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 137F343D46; Fri, 7 May 2004 07:19:13 -0700 (PDT) (envelope-from bogorodskiy@inbox.ru) Received: from [194.186.150.154] (port=49786 helo=localhost) by mx2.mail.ru with esmtp id 1BM698-000NmS-00; Fri, 07 May 2004 18:16:15 +0400 Date: Fri, 7 May 2004 18:18:22 +0400 From: Roman Bogorodskiy To: "Crist J. Clark" Message-ID: <20040507141821.GA777@lame.novel.ru> Mail-Followup-To: "Crist J. Clark" , freebsd-security@freebsd.org References: <20040504054909.GA3119@lame.novel.ru> <20040505003907.GA80906@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20040505003907.GA80906@blossom.cjclark.org> "From: Roman Bogordskiy " User-Agent: Mutt/1.5.6i X-Spam: Not detected cc: freebsd-security@freebsd.org Subject: Re: ctags(1) command execution vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 14:19:13 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Crist wrote: > As has been pointed out, the problem here is user supplied data to a syst= em(3) > call that we really cannot sanitize without filtering a lot of valid file= names. > The Right Thing is to get rid of system(3). >=20 > This seems to work. Fixing the sort is trivial. Adding the regex checks t= o the > program adds a little complexity, but not a lot. Anyone who actually uses= =20 > ctags(1) want to try them out some more to see if they hold up? Using fork() + execlp() instead of system() is a good idea. Your solution works for me.=20 Will this fix be commited?=20 -Roman Bogorodskiy --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iQEVAwUBQJuarSpMDQ8aPhy0AQIExAf/ZERpW7JIgpim7codjVeO14eVfqbD2zvW B79SL13M4F+zixK9Ber++XdMZJu7Tdr3sjziy3TqbQ1ipnzII+G0vzOcaivvdlfR l/27GVl3g+n99o8dT4IRueeWO0ekclOUVy0Wxe+US+8+NCqzPNpJYZH8faC1Me5C H34ghHDx2HMgbrbnWRUgmsDocc/FK7sxCytLKxXgCLVLHawk3sF6Dd485/t/DCfK k+DENYHOdQjMDzNF5NarRvOT9rblfdRlVsy8kqIC0NL61ZXvMPegoFxpM9JF5rj7 bkrZeEu1weTGQVuEReigrfrvu2qxUbUc8R4bbn/ZXS/tWh3fcx6QgQ== =a5R7 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-security@FreeBSD.ORG Fri May 7 09:09:31 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8127316A4CE for ; Fri, 7 May 2004 09:09:31 -0700 (PDT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 557FC43D60 for ; Fri, 7 May 2004 09:09:30 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.161.84.3]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040507160929.QKEN29216.out009.verizon.net@mac.com>; Fri, 7 May 2004 11:09:29 -0500 Message-ID: <409BB4B0.5000904@mac.com> Date: Fri, 07 May 2004 12:09:20 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Gostick References: <001001c4316f$6ab193d0$cb01a8c0@haklot> In-Reply-To: <001001c4316f$6ab193d0$cb01a8c0@haklot> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.161.84.3] at Fri, 7 May 2004 11:09:29 -0500 cc: freebsd-security@freebsd.org Subject: Re: scheduled pings X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 16:09:31 -0000 Matt Gostick wrote: > I have just setup some ipfw rules to checkout some traffic to one of my > boxes. I have three servers, only one of which has weird traffic. It > is getting ping'd on a five minute interval from approx 3 to 8 different > ip addresses within the same second. For example: [ ... ] > I've just started denying pings to the box... There are a bunch of network monitoring tools which will do something like this, normally used by ISPs and the like to verify that a server is up; you should contact whoever owns the source IPs and ask them what they're doing. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Fri May 7 11:28:00 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EEF016A4CE for ; Fri, 7 May 2004 11:28:00 -0700 (PDT) Received: from www3.your-server.de (www3.your-server.de [213.133.104.3]) by mx1.FreeBSD.org (Postfix) with SMTP id B623343D49 for ; Fri, 7 May 2004 11:27:59 -0700 (PDT) (envelope-from nectar@FreeBSD.org) Received: (qmail 25007 invoked by uid 505); 7 May 2004 18:27:59 -0000 Received: from nectar@FreeBSD.org by www3.your-server.de by uid 502 with qmail-scanner-1.15 (vexira: 6.25.0.3/6.25.0.53. Clear:. Processed in 1.785454 secs); 07 May 2004 18:27:59 -0000 X-Qmail-Scanner-Mail-From: nectar@FreeBSD.org via www3.your-server.de X-Qmail-Scanner: 1.15 (Clear:. Processed in 1.785454 secs) Received: from pd9e8e6e3.dip.t-dialin.net (HELO europa.DSHSTATISTIK.DE) (217.232.230.227) by www3.your-server.de with SMTP; 7 May 2004 18:27:57 -0000 Received: from europa.DSHSTATISTIK.DE ([192.168.0.30]) by europa.DSHSTATISTIK.DE with Microsoft SMTPSVC(5.0.2195.5329); Fri, 7 May 2004 20:30:16 +0200 Received: by europa.DSHSTATISTIK.DE (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG05072004-203011-124.MMD@DSHSTATISTIK.DE; Fri, 7 May 2004 20:30:11 +0200 Delivered-To: dshstat-webmaster@dsh-statistik.de Received: (qmail 18366 invoked by uid 910); 7 May 2004 18:12:49 -0000 Delivered-To: dshstat-johannes.klein@dsh-statistik.de Received: (qmail 18361 invoked by uid 505); 7 May 2004 18:12:49 -0000 Received: from bugtraq-return-14264-johannes.klein=dsh-statistik.de@securityfocus.com by www3.your-server.de by uid 502 with qmail-scanner-1.15 (vexira: 6.25.0.3/6.25.0.53. Clear:. Processed in 1.198223 secs); 07 May 2004 18:12:49 -0000 X-Qmail-Scanner-Mail-From: bugtraq-return-14264-johannes.klein=dsh-statistik.de@securityfocus.com via www3.your-server.de X-Qmail-Scanner: 1.15 (Clear:. Processed in 1.198223 secs) Received: from outgoing3.securityfocus.com (HELO outgoing.securityfocus.com) (205.206.231.27) by www3.your-server.de with SMTP; 7 May 2004 18:12:47 -0000 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing.securityfocus.com (Postfix) with QMQP id 4A31D236F89; Fri, 7 May 2004 20:01:47 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm Precedence: bulk Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 14028 invoked from network); 5 May 2004 10:44:12 -0000 Date: Wed, 5 May 2004 11:56:36 -0500 From: "Jacques A. Vidrine" To: freebsd-security@FreeBSD.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Message-ID: <20040505165636.GB40758@hellblazer.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-security@FreeBSD.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i X-OriginalArrivalTime: 07 May 2004 18:30:16.0125 (UTC) FILETIME=[57B63ED0:01C43461] Subject: Fwd: [Re: cvs commit: src/sys/vm vm_map.c] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 18:28:00 -0000 Hello, FYI: A FreeBSD user suggested that this issue requires a security advisory. The issue has been public for some time, but currently, FreeBSD does not issue advisories for local denial-of-service issues. It is expected that this bug will soon be fixed in FreeBSD 4.x (it is already fixed in FreeBSD 5.x, as you can see below). Cheers, -- Jacques Vidrine ----- Forwarded message from Tim Robbins ----- Date: Tue, 23 Mar 2004 21:53:10 +1100 From: Tim Robbins To: Pawel Jakub Dawidek cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c Message-ID: <20040323105310.GA14855@cat.robbins.dropbear.id.au> On Tue, Mar 23, 2004 at 11:33:00AM +0100, Pawel Jakub Dawidek wrote: > On Tue, Mar 23, 2004 at 12:37:35AM -0800, Tim J. Robbins wrote: > +> tjr 2004/03/23 00:37:34 PST > +> > +> FreeBSD src repository > +> > +> Modified files: > +> sys/vm vm_map.c > +> Log: > +> Do not copy vm_exitingcnt to the new vmspace in vmspace_exec(). Copying > +> it led to impossibly high values in the new vmspace, causing it to never > +> drop to 0 and be freed. > > How serious it is? Do you planning to MFC it to RELENG_4 with peter@'s > patch of course? A user can cause the kernel to allocate an unbounded amount of wired memory, causing the machine to panic or stop responding. It's been observed to happen under real workloads; that is, the circumstances are not so contrived that the bug could only be caused by a malicious user. I don't have any immediate plans to MFC it (I don't have any 4.x systems right now), but peter@ or ps@ may want to after letting it settle for a while in -current. Tim ----- End forwarded message -----