From owner-freebsd-security Sun May 13 20:43:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id 0A50A37B42C for ; Sun, 13 May 2001 20:43:28 -0700 (PDT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id KAA12716 for ; Mon, 14 May 2001 10:40:51 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id KAA11476; Mon, 14 May 2001 10:43:27 +0700 (ICT) Date: Mon, 14 May 2001 10:43:27 +0700 (ICT) Message-Id: <200105140343.KAA11476@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn References: <200105022120.f42LK1386574@freefall.freebsd.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was in the process of applying patch SA-01:39 to some machines here, I tried to download the patches from Japanese servers (ftp.jp.frebsd.org) and noticed that none of them had the patch (last available was SA-01:33). SA-01:39 had been released 2 weeks ago, it sound a good enough delay to update ftp server? Beside, I am very much in favor of the RELENG new branch for security. Best regards, Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun May 13 21:22:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 26CC637B42C for ; Sun, 13 May 2001 21:22:29 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id VAA78441; Sun, 13 May 2001 21:22:04 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3AFF5D6B.20DA92A@DougBarton.net> Date: Sun, 13 May 2001 21:22:03 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Olivier Nicole Cc: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn References: <200105022120.f42LK1386574@freefall.freebsd.org> <200105140343.KAA11476@banyan.cs.ait.ac.th> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Olivier Nicole wrote: > SA-01:39 had been released 2 weeks ago, it sound a good enough delay > to update ftp server? The problems with our ftp servers have been well publicized. While we regret the inconvenience, comments of this nature don't do anything to ingratiate you to an all-volunteer group. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun May 13 21:25:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from e450.mnsi.net (e450.mnsi.net [206.48.122.98]) by hub.freebsd.org (Postfix) with ESMTP id 9EA9937B423 for ; Sun, 13 May 2001 21:25:46 -0700 (PDT) (envelope-from mail@max-info.net) Received: from lan4 (dyn216-8-128-183.ADSL.mnsi.net [216.8.128.183]) by e450.mnsi.net (8.11.2/8.11.2/check_local 4.2) with SMTP id f4E4PiT08814 for ; Mon, 14 May 2001 00:25:45 -0400 (EDT) Message-ID: <003601c0dc2d$d15dd340$fd00a8c0@Home> From: "Ryan Masse" To: Subject: patches Date: Mon, 14 May 2001 00:24:49 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org how are the patches installed? simply chmod +x patch then ./patch? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun May 13 21:31:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id AC20837B424 for ; Sun, 13 May 2001 21:31:43 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CDC32678BA; Sun, 13 May 2001 21:31:42 -0700 (PDT) Date: Sun, 13 May 2001 21:31:42 -0700 From: Kris Kennaway To: Ryan Masse Cc: freebsd-security@FreeBSD.ORG Subject: Re: patches Message-ID: <20010513213142.A98203@xor.obsecurity.org> References: <003601c0dc2d$d15dd340$fd00a8c0@Home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003601c0dc2d$d15dd340$fd00a8c0@Home>; from mail@max-info.net on Mon, May 14, 2001 at 12:24:49AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 14, 2001 at 12:24:49AM -0400, Ryan Masse wrote: > how are the patches installed? >=20 > simply chmod +x patch then ./patch? Follow the directions in the advisory. Kris --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6/1+jWry0BWjoQKURAgS7AKCFoyZCOAhdt11fOjJqyjiF+ZG21ACguZkI sg5M0hHmxZChZB9Eht+v0CE= =64bZ -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun May 13 21:32:18 2001 Delivered-To: freebsd-security@freebsd.org Received: from yang.earlham.edu (yang.earlham.edu [159.28.1.1]) by hub.freebsd.org (Postfix) with ESMTP id B62EA37B42C for ; Sun, 13 May 2001 21:32:16 -0700 (PDT) (envelope-from marouni@earlham.edu) Received: from earlham.edu (IDENT:nobody@localhost.localdomain [127.0.0.1]) by yang.earlham.edu (8.9.3/8.9.3) with SMTP id XAA17446 for freebsd-security@FreeBSD.ORG; Sun, 13 May 2001 23:32:16 -0500 Message-Id: <200105140432.XAA17446@yang.earlham.edu> Date: Mon, 14 May 2001 04:32:16 -0000 To: freebsd-security@FreeBSD.ORG Subject: From: Nicholas Marouf X-Mailer: TWIG 2.3.2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth f5f72479 unsubscribe freebsd-security marouni@earlham.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 3: 7:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B65E337B422; Mon, 14 May 2001 03:07:31 -0700 (PDT) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id MAA34147; Mon, 14 May 2001 12:07:29 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Coleman Kane Cc: Retal , freebsd-security@FreeBSD.ORG Subject: Re: Some Kernel options, sc is broken References: <002601ba1df7$4da07940$b88f39d5@a> <20010513012229.A561@cokane.yi.org> From: Dag-Erling Smorgrav Date: 14 May 2001 12:07:29 +0200 In-Reply-To: <20010513012229.A561@cokane.yi.org> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Coleman Kane writes: > Well, their is brokeness here. The sc driver no longer reads the flags > from the hints correctly. You probably forgot hint.sc.0.at="isa" The rest of the sc hints will be ignored if that one isn't found. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 5:30:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from garuda.barc.ernet.in (garuda.barc.ernet.in [202.41.86.4]) by hub.freebsd.org (Postfix) with ESMTP id B4CD237B423 for ; Mon, 14 May 2001 05:30:13 -0700 (PDT) (envelope-from root@apsara.barc.ernet.in) Received: from apsara.barc.ernet.in (apsara.barc.ernet.in [192.168.1.21]) by garuda.barc.ernet.in (8.9.3/8.9.3) with ESMTP id RAA02652 for ; Mon, 14 May 2001 17:56:56 +0530 (IST) (envelope-from root@apsara.barc.ernet.in) Received: from localhost (root@localhost) by apsara.barc.ernet.in (8.9.3/8.9.3) with ESMTP id SAA18837 for ; Mon, 14 May 2001 18:07:02 +0530 Date: Mon, 14 May 2001 18:07:02 +0530 (IST) From: root To: Subject: ipfw rules and securelevel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear friends, Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I as root can change the variable "net.inet.ip.fw.enable" using sysctl. When I run a command sysctl -w net.inet.ip.fw.enable=0 It disables the ipfw rules. Is it a feature or hole in freebsd. please help RS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 6:26:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 7459D37B43C for ; Mon, 14 May 2001 06:26:34 -0700 (PDT) (envelope-from poige@morning.ru) Received: from NIC1 ([195.161.98.236]) by ns.morning.ru (8.9.3/8.9.3) with ESMTP id VAA13174; Mon, 14 May 2001 21:26:12 +0800 (KRAST) (envelope-from poige@morning.ru) Date: Mon, 14 May 2001 21:28:56 +0700 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <10320318256.20010514212856@morning.ru> To: root Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw rules and securelevel In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Dear friends, > Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > I run a command > sysctl -w net.inet.ip.fw.enable=0 > It disables the ipfw rules. > Is it a feature or hole in freebsd. doesn't matter how it is called, only matters how it hurts... (it does) > please help -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 7: 3:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id F0C2437B422 for ; Mon, 14 May 2001 07:03:27 -0700 (PDT) (envelope-from poige@morning.ru) Received: from NIC1 ([195.161.98.236]) by ns.morning.ru (8.9.3/8.9.3) with ESMTP id WAA14049 for ; Mon, 14 May 2001 22:03:26 +0800 (KRAST) (envelope-from poige@morning.ru) Date: Mon, 14 May 2001 22:06:10 +0700 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 2 (High) Message-ID: <19322552168.20010514220610@morning.ru> To: freebsd-security@FreeBSD.ORG Subject: Re[2]: ipfw rules and securelevel In-Reply-To: <10320318256.20010514212856@morning.ru> References: <10320318256.20010514212856@morning.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Dear friends, >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When >> I run a command >> sysctl -w net.inet.ip.fw.enable=0 >> It disables the ipfw rules. >> Is it a feature or hole in freebsd. > doesn't matter how it is called, only matters how it hurts... (it does) >> please help the "patch" (hard to call it a patch, but nevertheless) is adding CTLFLAG_SECURE to the relevant definition of the node: this diff out is for 3.5 stable: 92c92 < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, --- > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 7:10:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 6D89537B43E for ; Mon, 14 May 2001 07:10:08 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 1375 invoked by uid 1000); 14 May 2001 14:09:28 -0000 Date: Mon, 14 May 2001 17:09:28 +0300 From: Peter Pentchev To: Igor Podlesny Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw rules and securelevel Message-ID: <20010514170927.A849@ringworld.oblivion.bg> Mail-Followup-To: Igor Podlesny , freebsd-security@FreeBSD.ORG References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <19322552168.20010514220610@morning.ru>; from poige@morning.ru on Mon, May 14, 2001 at 10:06:10PM +0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: > > >> Dear friends, > >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > >> I run a command > > >> sysctl -w net.inet.ip.fw.enable=0 > > >> It disables the ipfw rules. > > >> Is it a feature or hole in freebsd. > > > doesn't matter how it is called, only matters how it hurts... (it does) > > >> please help > > the "patch" (hard to call it a patch, but nevertheless) is adding > CTLFLAG_SECURE to the relevant definition of the node: > > this diff out is for 3.5 stable: > > 92c92 > < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > --- > > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, Patches/diffs are usually much easier to review and apply if they are in context or unified diff format - this helps when the patch is made against a possibly changed file :) And.. well.. it might be obvious to you (in this case it's pretty obvious to figure out ;), but still it helps a lot to mention which file(s) the patch is against :) G'luck, Peter -- I am the meaning of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 7:13: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from relay3.inwind.it (relay3.inwind.it [212.141.53.74]) by hub.freebsd.org (Postfix) with ESMTP id F262D37B422 for ; Mon, 14 May 2001 07:13:06 -0700 (PDT) (envelope-from fathom@comune.arzignano.vi.it) Received: from comune.arzignano.vi.it (62.98.92.194) by relay3.inwind.it (5.5.029) id 3AE401CE004D2820 for freebsd-security@FreeBSD.org; Mon, 14 May 2001 16:13:05 +0200 Message-ID: <3AFFE661.5D6015EA@comune.arzignano.vi.it> Date: Mon, 14 May 2001 16:06:25 +0200 From: Francesco Toscan X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.org Subject: Warnings while compiling Samba Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, last night i decided to turn that old 486 into a Samba server for my internal network. I cvsupped to 4.3-STABLE, synched my source and ports tree and then compiled samba-devel from ports. make goes fine and servers work well as expected, but during compilation i noticed several warnings like this: lib/util.o: In function `smbd_mktemp': lib/util.o(.text+0x28d8): warning: mktemp() possibly used unsafely; consider using mkstemp() Now, servers work, but should i be concerned about any security issues derivating from these warnings? TIA, F. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 7:18:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 5709F37B43F for ; Mon, 14 May 2001 07:18:39 -0700 (PDT) (envelope-from poige@morning.ru) Received: from NIC1 ([195.161.98.236]) by ns.morning.ru (8.9.3/8.9.3) with ESMTP id WAA14549; Mon, 14 May 2001 22:18:34 +0800 (KRAST) (envelope-from poige@morning.ru) Date: Mon, 14 May 2001 22:21:18 +0700 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <5523460344.20010514222118@morning.ru> To: Peter Pentchev Cc: freebsd-security@FreeBSD.ORG Subject: Re[2]: ipfw rules and securelevel In-Reply-To: <20010514170927.A849@ringworld.oblivion.bg> References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: >> >> >> Dear friends, >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When >> >> I run a command >> >> >> sysctl -w net.inet.ip.fw.enable=0 >> >> >> It disables the ipfw rules. >> >> >> Is it a feature or hole in freebsd. >> >> > doesn't matter how it is called, only matters how it hurts... (it does) >> >> >> please help >> >> the "patch" (hard to call it a patch, but nevertheless) is adding >> CTLFLAG_SECURE to the relevant definition of the node: >> >> this diff out is for 3.5 stable: >> >> 92c92 >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, >> --- >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > Patches/diffs are usually much easier to review and apply if they are > in context or unified diff format - this helps when the patch is made > against a possibly changed file :) And.. well.. it might be obvious > to you (in this case it's pretty obvious to figure out ;), but still > it helps a lot to mention which file(s) the patch is against :) oh, you're right :) it was /usr/src/sys/netinet/ip_fw.c unified diff: --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 @@ -89,7 +89,7 @@ #ifdef SYSCTL_NODE SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, &fw_enable, 0, "Enable ipfw"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, &fw_one_pass, 0, > G'luck, > Peter -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 7:26:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 19C5D37B422 for ; Mon, 14 May 2001 07:26:09 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id QAA29949; Mon, 14 May 2001 16:26:07 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14zJIT-0000Qx-00 for ; Mon, 14 May 2001 16:26:05 +0200 Date: Mon, 14 May 2001 16:26:05 +0200 From: Szilveszter Adam To: freebsd-security@FreeBSD.org Subject: Re: Warnings while compiling Samba Message-ID: <20010514162605.C3213@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , freebsd-security@FreeBSD.org References: <3AFFE661.5D6015EA@comune.arzignano.vi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AFFE661.5D6015EA@comune.arzignano.vi.it>; from fathom@comune.arzignano.vi.it on Mon, May 14, 2001 at 04:06:25PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 04:06:25PM +0200, Francesco Toscan wrote: > Hi, > > last night i decided to turn that old 486 into a Samba server for my > internal network. > I cvsupped to 4.3-STABLE, synched my source and ports tree and then > compiled samba-devel from ports. > make goes fine and servers work well as expected, but during compilation > i noticed several warnings like this: > > lib/util.o: In function `smbd_mktemp': > lib/util.o(.text+0x28d8): warning: mktemp() possibly used unsafely; > consider using mkstemp() > > Now, servers work, but should i be concerned about any security issues > derivating from these warnings? Hello, This warning is always triggered if the linker encounters this function name since often it is used unsafely and since FreeBSD provides a better alternative. But this is for the programmer/porter who might consider if he better swap mktemp() to mkstemp() or not. Unfortunately, it is not as easy as switching the two words... so I do not think you should be very concerned about this. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 8: 2:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 9A9F737B423 for ; Mon, 14 May 2001 08:02:40 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 565 invoked by uid 1000); 14 May 2001 15:02:02 -0000 Date: Mon, 14 May 2001 18:02:02 +0300 From: Peter Pentchev To: Igor Podlesny Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw rules and securelevel Message-ID: <20010514180201.C453@ringworld.oblivion.bg> Mail-Followup-To: Igor Podlesny , freebsd-security@FreeBSD.ORG References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5523460344.20010514222118@morning.ru>; from poige@morning.ru on Mon, May 14, 2001 at 10:21:18PM +0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote: > > > > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: > >> > >> >> Dear friends, > >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > >> >> I run a command > >> > >> >> sysctl -w net.inet.ip.fw.enable=0 > >> > >> >> It disables the ipfw rules. > >> > >> >> Is it a feature or hole in freebsd. > >> > >> > doesn't matter how it is called, only matters how it hurts... (it does) > >> > >> >> please help > >> > >> the "patch" (hard to call it a patch, but nevertheless) is adding > >> CTLFLAG_SECURE to the relevant definition of the node: > >> > >> this diff out is for 3.5 stable: > >> > >> 92c92 > >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > >> --- > >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > Patches/diffs are usually much easier to review and apply if they are > > in context or unified diff format - this helps when the patch is made > > against a possibly changed file :) And.. well.. it might be obvious > > to you (in this case it's pretty obvious to figure out ;), but still > > it helps a lot to mention which file(s) the patch is against :) > > oh, you're right :) > > it was > /usr/src/sys/netinet/ip_fw.c > > unified diff: > > --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 > +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 > @@ -89,7 +89,7 @@ > > #ifdef SYSCTL_NODE > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > &fw_enable, 0, "Enable ipfw"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > &fw_one_pass, 0, Yup, this patch is much clearer, and I see no real reason against committing it. Actually, I think that even more of those sysctl's should be flagged as 'secure' - e.g. the ones related to logging. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 8:10:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 750BC37B42C for ; Mon, 14 May 2001 08:10:06 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4EF9SS53087; Mon, 14 May 2001 18:09:28 +0300 (EEST) (envelope-from ru) Date: Mon, 14 May 2001 18:09:28 +0300 From: Ruslan Ermilov To: Peter Pentchev Cc: Igor Podlesny , freebsd-security@FreeBSD.ORG Subject: Re: ipfw rules and securelevel Message-ID: <20010514180928.A52742@sunbay.com> Mail-Followup-To: Peter Pentchev , Igor Podlesny , freebsd-security@FreeBSD.ORG References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514180201.C453@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, May 14, 2001 at 06:02:02PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 06:02:02PM +0300, Peter Pentchev wrote: > On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote: > > > > > > > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: > > >> > > >> >> Dear friends, > > >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > > >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > > >> >> I run a command > > >> > > >> >> sysctl -w net.inet.ip.fw.enable=0 > > >> > > >> >> It disables the ipfw rules. > > >> > > >> >> Is it a feature or hole in freebsd. > > >> > > >> > doesn't matter how it is called, only matters how it hurts... (it does) > > >> > > >> >> please help > > >> > > >> the "patch" (hard to call it a patch, but nevertheless) is adding > > >> CTLFLAG_SECURE to the relevant definition of the node: > > >> > > >> this diff out is for 3.5 stable: > > >> > > >> 92c92 > > >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > >> --- > > >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > > > Patches/diffs are usually much easier to review and apply if they are > > > in context or unified diff format - this helps when the patch is made > > > against a possibly changed file :) And.. well.. it might be obvious > > > to you (in this case it's pretty obvious to figure out ;), but still > > > it helps a lot to mention which file(s) the patch is against :) > > > > oh, you're right :) > > > > it was > > /usr/src/sys/netinet/ip_fw.c > > > > unified diff: > > > > --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 > > +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 > > @@ -89,7 +89,7 @@ > > > > #ifdef SYSCTL_NODE > > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > &fw_enable, 0, "Enable ipfw"); > > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > > &fw_one_pass, 0, > > Yup, this patch is much clearer, and I see no real reason against > committing it. Actually, I think that even more of those sysctl's > should be flagged as 'secure' - e.g. the ones related to logging. > Hmm, but I think that for (securelevel < 3) the transition should still be allowed. The correct fix then would be: Index: ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.164 diff -u -p -r1.164 ip_fw.c --- ip_fw.c 2001/04/06 06:52:25 1.164 +++ ip_fw.c 2001/05/14 15:04:12 @@ -96,9 +96,19 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); #ifdef SYSCTL_NODE + +static int +sysctl_fw_enable(SYSCTL_HANDLER_ARGS) +{ + + if (req->newptr && securelevel >= 3) + return (EPERM); + return sysctl_handle_int(oidp, arg1, arg2, req); +} + SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, - &fw_enable, 0, "Enable ipfw"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW, + &fw_enable, 0, sysctl_fw_enable, "I", "Enable ipfw"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, &fw_one_pass, 0, "Only do a single pass through ipfw when using dummynet(4)"); -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 8:39:24 2001 Delivered-To: freebsd-security@freebsd.org Received: from ajax1.sovam.com (ajax1.sovam.com [194.67.1.172]) by hub.freebsd.org (Postfix) with ESMTP id 6A46E37B42C; Mon, 14 May 2001 08:39:17 -0700 (PDT) (envelope-from avn@any.ru) Received: from ts9-a275.dial.sovam.com ([195.239.71.19]:1126 "EHLO srv2.any" ident: "root" whoson: "-unregistered-" smtp-auth: TLS-CIPHER: "EDH-RSA-DES-CBC3-SHA keybits 192/192 version TLSv1/SSLv3" TLS-PEER: ) by ajax1.sovam.com with ESMTP id ; Mon, 14 May 2001 19:39:03 +0400 Received: from localhost (avn@localhost) by srv2.any (8.11.3/8.11.3) with ESMTP id f4EFZD612601; Mon, 14 May 2001 19:35:13 +0400 (MSD) (envelope-from avn@any.ru) X-Authentication-Warning: srv2.any: avn owned process doing -bs Date: Mon, 14 May 2001 19:35:13 +0400 (MSD) From: "Alexey V. Neyman" X-X-Sender: To: Ruslan Ermilov Cc: Subject: Re: ipfw rules and securelevel In-Reply-To: <20010514180928.A52742@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello there! On Mon, 14 May 2001, Ruslan Ermilov wrote: >+ if (req->newptr && securelevel >= 3) >+ return (EPERM); Then, maybe it's worth introducing a sysctl tuneable, which, once set, will prohibit all userland sysctl writing and providing interface for it in /etc/rc.conf, setting it in boot time. This will separate such functionality from kern.securelevel (I may prefer running at securelevel lower than 3, still having sysctls protected). As an improvement of said before, it can be good to be able to lock separate branches of sysctl tree - i.e., setting net.sysctl_readonly to 1 protects the entire net.* branch from writing. # Alexey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 10:17:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id D9AF937B422 for ; Mon, 14 May 2001 10:17:17 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id JAA14432 for ; Mon, 14 May 2001 09:13:38 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma014425; Mon, 14 May 01 09:13:15 -0500 Message-ID: <3AFFD9F1.EFB2B30E@centtech.com> Date: Mon, 14 May 2001 08:13:21 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: nfs mounts / su / yp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm running FreeBSD client machines and mixed NFS servers. My clients nfs mount (or automount) the shares from the servers, and all are using NIS for login/password authentication. Home areas are NFS mounted also. My question is, if a user has (or gets) root on their desktop machine (FreeBSD 4.x), it allows them to su to any NIS user, and have access to anything as them, etc.. We often have users log in to other users machines, and change desks, etc. So I can't only allow one or two users to log in to a particular box (this would be a nightmare, as I have hundreds of machines to work with). It's more like an su restriction set that needs to be created. Like, only certain users can su to root.. and root can only su to the user that it originally su'd from, if any. I'm just curious what anyone else might be doign to solve this problem, since it allows users to do dangerous things as other users.. Thanks.. Eric -- ------------------------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 10:29:23 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id 93E4E37B422 for ; Mon, 14 May 2001 10:29:19 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id MAA19301; Mon, 14 May 2001 12:29:19 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma019297; Mon, 14 May 01 12:29:09 -0500 Message-ID: <3B0015E5.2E1AED1B@centtech.com> Date: Mon, 14 May 2001 12:29:09 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Oulman, Jamie" Cc: "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp References: <3BF50BC1C2B5D411A06700508BD94D61016197AB@exchange2.iphrase.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If a user reboots their machine, goes into single user mode, and changes the local root password (and adds their username into the wheel group of course), then boots into multiuser mode, they can su to root, then su to any NIS user they desire, and do malicious things as that user. su'ing from root to any other user never asks for a password, so login.conf isn't used (right?).. Eric "Oulman, Jamie" wrote: > > I dont know about su -> nis user restriction. But the only users in the > wheel group should be able to su root. Also. Login.conf may be of some help. > > Cheers. > > -jamie > > -----Original Message----- > From: Eric Anderson [mailto:anderson@centtech.com] > Sent: Monday, May 14, 2001 9:13 AM > To: freebsd-security@FreeBSD.ORG > Subject: nfs mounts / su / yp > > I'm running FreeBSD client machines and mixed NFS servers. My clients > nfs mount (or automount) the shares from the servers, and all are using > NIS for login/password authentication. Home areas are NFS mounted > also. My question is, if a user has (or gets) root on their desktop > machine (FreeBSD 4.x), it allows them to su to any NIS user, and have > access to anything as them, etc.. We often have users log in to other > users machines, and change desks, etc. So I can't only allow one or two > users to log in to a particular box (this would be a nightmare, as I > have hundreds of machines to work with). It's more like an su > restriction set that needs to be created. Like, only certain users can > su to root.. and root can only su to the user that it originally su'd > from, if any. I'm just curious what anyone else might be doign to solve > this problem, since it allows users to do dangerous things as other > users.. > > Thanks.. > Eric > > -- > ---------------------------------------------------------------------------- > --- > Eric Anderson anderson@centtech.com Centaur Technology (512) > 418-5792 > The idea is to die young as late as possible. > ---------------------------------------------------------------------------- > --- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- ------------------------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11: 2:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id 08D3D37B42C for ; Mon, 14 May 2001 11:02:43 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f4EI2Ii52070; Mon, 14 May 2001 14:02:18 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Mon, 14 May 2001 14:02:15 -0400 (EDT) From: Rob Simmons To: Eric Anderson Cc: "Oulman, Jamie" , freebsd-security@freebsd.org Subject: Re: nfs mounts / su / yp In-Reply-To: <3B0015E5.2E1AED1B@centtech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 You could set the console to insecure in /etc/ttys. That way single user mode will ask for the root password. You still can't prevent someone from booting with their own floppy disk and making changes that way. I think the only way to prevent that is to use an encrypted filesystem of some sort. Robert Simmons Systems Administrator http://www.wlcg.com/ On Mon, 14 May 2001, Eric Anderson wrote: > If a user reboots their machine, goes into single user mode, and changes > the local root password (and adds their username into the wheel group of > course), then boots into multiuser mode, they can su to root, then su to > any NIS user they desire, and do malicious things as that user. su'ing > from root to any other user never asks for a password, so login.conf > isn't used (right?).. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AB2qv8Bofna59hYRA0ebAKCQ9R1wLoemlWAuEdplqcSMcY12IQCfVH0B 8SkJHNs8J3aEYZ8dk27La2k= =Qb9E -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11: 9:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 41F9E37B423 for ; Mon, 14 May 2001 11:09:18 -0700 (PDT) (envelope-from meshko@daedalus.cs.brandeis.edu) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id OAA30982; Mon, 14 May 2001 14:09:02 -0400 Date: Mon, 14 May 2001 14:09:02 -0400 (EDT) From: Mikhail Kruk To: Rob Simmons Cc: Eric Anderson , "Oulman, Jamie" , Subject: Re: nfs mounts / su / yp In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, you can disable booting from floppy, setup BIOS password and physically lock the case. We have a bunch of Linux boxes running NIS in our lab with this kind of setup and I believe there was no problems. It's rather hard to break in the locked computer case without people noticing it. On Mon, 14 May 2001, Rob Simmons wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > You could set the console to insecure in /etc/ttys. That way single user > mode will ask for the root password. You still can't prevent someone from > booting with their own floppy disk and making changes that way. I think > the only way to prevent that is to use an encrypted filesystem of some > sort. > > Robert Simmons > Systems Administrator > http://www.wlcg.com/ > > On Mon, 14 May 2001, Eric Anderson wrote: > > > If a user reboots their machine, goes into single user mode, and changes > > the local root password (and adds their username into the wheel group of > > course), then boots into multiuser mode, they can su to root, then su to > > any NIS user they desire, and do malicious things as that user. su'ing > > from root to any other user never asks for a password, so login.conf > > isn't used (right?).. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.5 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE7AB2qv8Bofna59hYRA0ebAKCQ9R1wLoemlWAuEdplqcSMcY12IQCfVH0B > 8SkJHNs8J3aEYZ8dk27La2k= > =Qb9E > -----END PGP SIGNATURE----- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11: 9:40 2001 Delivered-To: freebsd-security@freebsd.org Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by hub.freebsd.org (Postfix) with ESMTP id 72CAD37B423 for ; Mon, 14 May 2001 11:09:33 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by maila.telia.com (8.11.2/8.11.0) with ESMTP id f4EI9WZ14730 for ; Mon, 14 May 2001 20:09:32 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id UAA09696 for ; Mon, 14 May 2001 20:09:29 +0200 (CEST) Received: (qmail 32719 invoked by uid 1001); 14 May 2001 18:09:28 -0000 Date: Mon, 14 May 2001 20:09:28 +0200 From: Erik Trulsson To: Eric Anderson Cc: "Oulman, Jamie" , "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp Message-ID: <20010514200927.A32697@student.uu.se> Mail-Followup-To: Eric Anderson , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" References: <3BF50BC1C2B5D411A06700508BD94D61016197AB@exchange2.iphrase.com> <3B0015E5.2E1AED1B@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B0015E5.2E1AED1B@centtech.com>; from anderson@centtech.com on Mon, May 14, 2001 at 12:29:09PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 12:29:09PM -0500, Eric Anderson wrote: > If a user reboots their machine, goes into single user mode, and changes > the local root password (and adds their username into the wheel group of > course), then boots into multiuser mode, they can su to root, then su to > any NIS user they desire, and do malicious things as that user. su'ing > from root to any other user never asks for a password, so login.conf > isn't used (right?).. > > Eric If a user can login as root or su to root then they can (almost by definition) do whatever they want. The solution is therefore to prevent users getting root access in the first place since once they get it it is too late to do anything about it. First of, all make sure that only people you trust are in the wheel group and know the root password. This will prevent other people from doing an su to root. If you edit /etc/ttys and mark the console as 'insecure' then the root password should be needed when going singleuser. This should stop people rebboting into singleuser mode. Just make sure that you don't forget the root password. To be totally secure you must also make sure that users cannot boot from any removable media. (floppys, CDROM, etc.) This will probably involve changing the BIOS settings to boot from HD before checking other devices. You also need to password protect the BIOS so that other people can't change the settings back again. If you are really paranoid you should also lock the computer cases so that nobody can change the HD or something similar. > > > "Oulman, Jamie" wrote: > > > > I dont know about su -> nis user restriction. But the only users in the > > wheel group should be able to su root. Also. Login.conf may be of some help. > > > > Cheers. > > > > -jamie > > > > -----Original Message----- > > From: Eric Anderson [mailto:anderson@centtech.com] > > Sent: Monday, May 14, 2001 9:13 AM > > To: freebsd-security@FreeBSD.ORG > > Subject: nfs mounts / su / yp > > > > I'm running FreeBSD client machines and mixed NFS servers. My clients > > nfs mount (or automount) the shares from the servers, and all are using > > NIS for login/password authentication. Home areas are NFS mounted > > also. My question is, if a user has (or gets) root on their desktop > > machine (FreeBSD 4.x), it allows them to su to any NIS user, and have > > access to anything as them, etc.. We often have users log in to other > > users machines, and change desks, etc. So I can't only allow one or two > > users to log in to a particular box (this would be a nightmare, as I > > have hundreds of machines to work with). It's more like an su > > restriction set that needs to be created. Like, only certain users can > > su to root.. and root can only su to the user that it originally su'd > > from, if any. I'm just curious what anyone else might be doign to solve > > this problem, since it allows users to do dangerous things as other > > users.. > > > > Thanks.. > > Eric > > -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:14:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from allmaui.com (server25.aitcom.net [208.234.0.10]) by hub.freebsd.org (Postfix) with ESMTP id 7FDF137B423 for ; Mon, 14 May 2001 11:14:06 -0700 (PDT) (envelope-from craig@allmaui.com) Received: from allmaui.com (pwnat-2-o.placeware.com [209.1.15.34]) by allmaui.com (8.8.8/8.8.5) with ESMTP id OAA05591; Mon, 14 May 2001 14:13:49 -0400 Message-ID: <3B00216B.6D83C12D@allmaui.com> Date: Mon, 14 May 2001 11:18:19 -0700 From: Craig Cowen X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Simmons Cc: Eric Anderson , "Oulman, Jamie" , freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org how about using a bios passwd and removing the floppy from bios? Rob Simmons wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > You could set the console to insecure in /etc/ttys. That way single user > mode will ask for the root password. You still can't prevent someone from > booting with their own floppy disk and making changes that way. I think > the only way to prevent that is to use an encrypted filesystem of some > sort. > > Robert Simmons > Systems Administrator > http://www.wlcg.com/ > > On Mon, 14 May 2001, Eric Anderson wrote: > > > If a user reboots their machine, goes into single user mode, and changes > > the local root password (and adds their username into the wheel group of > > course), then boots into multiuser mode, they can su to root, then su to > > any NIS user they desire, and do malicious things as that user. su'ing > > from root to any other user never asks for a password, so login.conf > > isn't used (right?).. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.5 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE7AB2qv8Bofna59hYRA0ebAKCQ9R1wLoemlWAuEdplqcSMcY12IQCfVH0B > 8SkJHNs8J3aEYZ8dk27La2k= > =Qb9E > -----END PGP SIGNATURE----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:18:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 338B037B422 for ; Mon, 14 May 2001 11:18:43 -0700 (PDT) (envelope-from fhouston@east.isi.edu) Received: from rosencrantz.east.isi.edu (rosencrantz.east.isi.edu [38.245.76.213]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA09155; Mon, 14 May 2001 14:18:19 -0400 (EDT) Date: Mon, 14 May 2001 14:18:16 -0400 (Eastern Daylight Time) From: Forrest Houston To: Erik Trulsson Cc: Eric Anderson , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp In-Reply-To: <20010514200927.A32697@student.uu.se> Message-ID: X-X-Sender: fhouston@ale.east.isi.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The problem is further complicated though when you want the user to have root access. We have some people around here who need/want total access to their machine. However there is still the concern of the NFS mounts. What do you do in these circumstances? Thanks Forrest On Mon, 14 May 2001, Erik Trulsson wrote: > > If a user can login as root or su to root then they can (almost by > definition) do whatever they want. The solution is therefore to prevent > users getting root access in the first place since once they get it it is > too late to do anything about it. > First of, all make sure that only people you trust are in the wheel group and > know the root password. This will prevent other people from doing an su to root. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:30:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id 233A837B423 for ; Mon, 14 May 2001 11:30:21 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f4EITTq53367; Mon, 14 May 2001 14:29:29 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Mon, 14 May 2001 14:29:25 -0400 (EDT) From: Rob Simmons To: Craig Cowen Cc: Eric Anderson , "Oulman, Jamie" , freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp In-Reply-To: <3B00216B.6D83C12D@allmaui.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 If you use an encrypted filesystem, that is not needed. If you are taking care of a large number of various boxen, you will want to use a solution that is software based. You don't want to rely on BIOS passwords and stuff like that. You can cut open a locked case, you can set the jumper to reset the BIOS, but you will get nowhere booting from floppy if the filesystem is encrypted. Robert Simmons Systems Administrator http://www.wlcg.com/ On Mon, 14 May 2001, Craig Cowen wrote: > how about using a bios passwd and removing the floppy from bios? > > Rob Simmons wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > You could set the console to insecure in /etc/ttys. That way single user > > mode will ask for the root password. You still can't prevent someone from > > booting with their own floppy disk and making changes that way. I think > > the only way to prevent that is to use an encrypted filesystem of some > > sort. > > > > Robert Simmons > > Systems Administrator > > http://www.wlcg.com/ > > > > On Mon, 14 May 2001, Eric Anderson wrote: > > > > > If a user reboots their machine, goes into single user mode, and changes > > > the local root password (and adds their username into the wheel group of > > > course), then boots into multiuser mode, they can su to root, then su to > > > any NIS user they desire, and do malicious things as that user. su'ing > > > from root to any other user never asks for a password, so login.conf > > > isn't used (right?).. > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.5 (FreeBSD) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE7AB2qv8Bofna59hYRA0ebAKCQ9R1wLoemlWAuEdplqcSMcY12IQCfVH0B > > 8SkJHNs8J3aEYZ8dk27La2k= > > =Qb9E > > -----END PGP SIGNATURE----- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7ACQJv8Bofna59hYRA64hAJ9lX9fPXaYKX2Eo+ocK6s3SHHKmKQCfUfq2 hhrN8URrhnM0gwFz3u9TIyk= =wPUA -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:43:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by hub.freebsd.org (Postfix) with ESMTP id CF67A37B423 for ; Mon, 14 May 2001 11:43:04 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailf.telia.com (8.11.2/8.11.0) with ESMTP id f4EIh3C04639 for ; Mon, 14 May 2001 20:43:03 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id UAA14641 for ; Mon, 14 May 2001 20:43:01 +0200 (CEST) Received: (qmail 33470 invoked by uid 1001); 14 May 2001 18:42:59 -0000 Date: Mon, 14 May 2001 20:42:59 +0200 From: Erik Trulsson To: Forrest Houston Cc: Eric Anderson , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp Message-ID: <20010514204259.A33451@student.uu.se> Mail-Followup-To: Forrest Houston , Eric Anderson , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" References: <20010514200927.A32697@student.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fhouston@east.isi.edu on Mon, May 14, 2001 at 02:18:16PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 02:18:16PM -0400, Forrest Houston wrote: > The problem is further complicated though when you want the user to have > root access. We have some people around here who need/want total access > to their machine. However there is still the concern of the NFS > mounts. What do you do in these circumstances? > If those people have their own, personal, machines then you solve it by not letting any other machines trust the 'compromised' machines. Only export that persons homedirectory via NFS to that machine. Do not allow any other directories to be mounted. Be careful with accepting logins/connections from it. Basically treat it as if it was some unknown machine out on the Big Bad Internet. And make sure that the root password for those machines is different from that on other machines. It is usually a bad idea to give users root access if you don't trust them. If you still have to give them root access then isolate their machines so that they cannot access other machines. > Thanks > Forrest > > On Mon, 14 May 2001, Erik Trulsson wrote: > > > > > If a user can login as root or su to root then they can (almost by > > definition) do whatever they want. The solution is therefore to prevent > > users getting root access in the first place since once they get it it is > > too late to do anything about it. > > First of, all make sure that only people you trust are in the wheel group and > > know the root password. This will prevent other people from doing an su to root. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:52:28 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id 313E237B43C for ; Mon, 14 May 2001 11:52:24 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id NAA21330; Mon, 14 May 2001 13:52:23 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma021327; Mon, 14 May 01 13:52:13 -0500 Message-ID: <3B00295D.24643CD7@centtech.com> Date: Mon, 14 May 2001 13:52:13 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Erik Trulsson Cc: Forrest Houston , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I think the problem is that a local root should mean only local root access, and su should not allow you to su to non-local users (ie, NIS users). Forrest, you have it close to what I am troubling with. I have users that WILL get root on their desktop machines, one way or the other. These users log into others machines (which is needed, and acceptable).. The problem is simply how do you stop root from su'ing to another user? (and deleting the binary is not an answer, since downloading and/or compiling your own is simple enough).. Eric Erik Trulsson wrote: > > On Mon, May 14, 2001 at 02:18:16PM -0400, Forrest Houston wrote: > > The problem is further complicated though when you want the user to have > > root access. We have some people around here who need/want total access > > to their machine. However there is still the concern of the NFS > > mounts. What do you do in these circumstances? > > > > If those people have their own, personal, machines then you solve it by not > letting any other machines trust the 'compromised' machines. > Only export that persons homedirectory via NFS to that machine. Do not allow > any other directories to be mounted. Be careful with accepting > logins/connections from it. Basically treat it as if it was some unknown > machine out on the Big Bad Internet. > > And make sure that the root password for those machines is different from > that on other machines. > > It is usually a bad idea to give users root access if you don't trust them. > If you still have to give them root access then isolate their machines so > that they cannot access other machines. > > > Thanks > > Forrest > > > > On Mon, 14 May 2001, Erik Trulsson wrote: > > > > > > > > If a user can login as root or su to root then they can (almost by > > > definition) do whatever they want. The solution is therefore to prevent > > > users getting root access in the first place since once they get it it is > > > too late to do anything about it. > > > First of, all make sure that only people you trust are in the wheel group and > > > know the root password. This will prevent other people from doing an su to root. > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > > Erik Trulsson > ertr1013@student.uu.se -- ------------------------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 11:58:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by hub.freebsd.org (Postfix) with ESMTP id E3FC437B424 for ; Mon, 14 May 2001 11:58:33 -0700 (PDT) (envelope-from fhouston@east.isi.edu) Received: from rosencrantz.east.isi.edu (rosencrantz.east.isi.edu [38.245.76.213]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id OAA09580; Mon, 14 May 2001 14:58:11 -0400 (EDT) Date: Mon, 14 May 2001 14:58:08 -0400 (Eastern Daylight Time) From: Forrest Houston To: Eric Anderson Cc: Erik Trulsson , "Oulman, Jamie" , "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp In-Reply-To: <3B00295D.24643CD7@centtech.com> Message-ID: X-X-Sender: fhouston@ale.east.isi.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I agree w/ Erik (w/ the k) in that some sort of automounting of the user's individual home directory is needed. However since we have a variety of machines (pretty much all flavors of Unix except HP) here we need something that can be used pretty much across all platforms and is of course easy to support... So far I haven't found anything yet, but it's become a back burner issue so I haven't looked for anything in years either :( Always looking for hints, clues, suggestions though ;) Forrest On Mon, 14 May 2001, Eric Anderson wrote: > Well, I think the problem is that a local root should mean only local > root access, and su should not allow you to su to non-local users (ie, > NIS users). Forrest, you have it close to what I am troubling with. I > have users that WILL get root on their desktop machines, one way or the > other. These users log into others machines (which is needed, and > acceptable).. The problem is simply how do you stop root from su'ing to > another user? (and deleting the binary is not an answer, since > downloading and/or compiling your own is simple enough).. > > Eric > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:20:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by hub.freebsd.org (Postfix) with ESMTP id 6E4B437B42C for ; Mon, 14 May 2001 12:20:37 -0700 (PDT) (envelope-from Antoine.Beaupre@ericsson.ca) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4EJKa807350 for ; Mon, 14 May 2001 14:20:36 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4EJD2w02258 for ; Mon, 14 May 2001 14:13:02 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id f4EJD1G25133 for ; Mon, 14 May 2001 15:13:01 -0400 (EDT) Received: by lmc35.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 15:13:00 -0400 Received: from lmc.ericsson.se (lmcpc100455.pc.lmc.ericsson.se [142.133.23.150]) by LMC37.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQDZQA1X; Mon, 14 May 2001 15:12:46 -0400 From: "Antoine Beaupre (LMC)" Reply-To: "'freebsd-security@freebsd.org'" To: freebsd-security@FreeBSD.ORG Message-ID: <3B002E2B.1337F4C9@lmc.ericsson.se> Date: Mon, 14 May 2001 15:12:43 -0400 Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,fr-CA,fr MIME-Version: 1.0 Subject: Re: nfs mounts / su / yp References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [cc's trimmed] Eric Anderson wrote: > > Well, I think the problem is that a local root should mean only local > root access, and su should not allow you to su to non-local users (ie, > NIS users). That policy (local-only su) if implemented on a machine, can be circumvented when the user gets root access. Heck, the user can even install another system that *doesn't have* that policy. > The problem is simply how do you stop root from su'ing to > another user? You can't. Once the user has root, he can reinstall a complete system, bypassing any *local* policy you might have. You can't keep root from doing *anything* by definition. I think there has been a few threads regarding this on this list. This might be seen as a UNIX design flaw but I certainly disagree. Anyways, that is not the issue here. I thing the problem is more: "How do you stop a workstation user from reading other users home directories, even as root?" First, if the home directories are physically stored on the workstation, the local user can hack root (or break into the box/hard drive itself) and read these. End of story. Second, if the home directories are stored on a NFS server, you'll soon realize that your all-powerful local workstation user can easily masquerade as any user id, as soon as he has control over his own box. This is not a design problem in FreeBSD, but in NFS. I think the only solution has already been mentionned, but I'll include it here for completeness. Third: you store each user's home directory on his own workstation, without sharing it through the network. This is the only solution if you cannot restrict root access to these workstations. NFS/YP design is not really "absolutely" secure, nor has it ever been this way. It relies on certain predicates, one of these being that the userid info coming from an nfs/yp client is trustable. Which is not the case if you allow root on these clients. Anyways, someone with root access to a box on a network can even sniff the network for these nice little NFS packets (or yp passwords, for that matter) and bypass anything you might have put in their way. Correct me if I'm wrong. A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:26:54 2001 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E4CC537B440 for ; Mon, 14 May 2001 12:26:50 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4EJQo801983 for freebsd-security@FreeBSD.ORG; Mon, 14 May 2001 12:26:50 -0700 (PDT) Date: Mon, 14 May 2001 12:26:50 -0700 From: Alfred Perlstein To: "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp Message-ID: <20010514122650.T18676@fw.wintelcom.net> References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> <3B002E2B.1337F4C9@lmc.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B002E2B.1337F4C9@lmc.ericsson.se>; from Antoine.Beaupre@ericsson.ca on Mon, May 14, 2001 at 03:12:43PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Antoine Beaupre (LMC) [010514 12:20] wrote: > [cc's trimmed] > > Eric Anderson wrote: > > > > Well, I think the problem is that a local root should mean only local > > root access, and su should not allow you to su to non-local users (ie, > > NIS users). > > That policy (local-only su) if implemented on a machine, can be > circumvented when the user gets root access. > > Heck, the user can even install another system that *doesn't have* that > policy. > > > The problem is simply how do you stop root from su'ing to > > another user? > > You can't. Once the user has root, he can reinstall a complete system, > bypassing any *local* policy you might have. You can't keep root from > doing *anything* by definition. I think there has been a few threads > regarding this on this list. This might be seen as a UNIX design flaw > but I certainly disagree. Anyways, that is not the issue here. FreeBSD has securelevels, while not ideal, if implemented properly they can limit what root can do. -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:39: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id 5E44437B423 for ; Mon, 14 May 2001 12:38:59 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f4EJcul09943 for ; Mon, 14 May 2001 21:38:57 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id VAA10857 for ; Mon, 14 May 2001 21:38:55 +0200 (CEST) Received: (qmail 34225 invoked by uid 1001); 14 May 2001 19:38:54 -0000 Date: Mon, 14 May 2001 21:38:54 +0200 From: Erik Trulsson To: "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp Message-ID: <20010514213854.A34209@student.uu.se> Mail-Followup-To: "'freebsd-security@freebsd.org'" References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> <3B002E2B.1337F4C9@lmc.ericsson.se> <20010514122650.T18676@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514122650.T18676@fw.wintelcom.net>; from bright@wintelcom.net on Mon, May 14, 2001 at 12:26:50PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, May 14, 2001 at 12:26:50PM -0700, Alfred Perlstein wrote: > * Antoine Beaupre (LMC) [010514 12:20] wrote: > > [cc's trimmed] > > > > Eric Anderson wrote: > > > > > > Well, I think the problem is that a local root should mean only local > > > root access, and su should not allow you to su to non-local users (ie, > > > NIS users). > > > > That policy (local-only su) if implemented on a machine, can be > > circumvented when the user gets root access. > > > > Heck, the user can even install another system that *doesn't have* that > > policy. > > > > > The problem is simply how do you stop root from su'ing to > > > another user? > > > > You can't. Once the user has root, he can reinstall a complete system, > > bypassing any *local* policy you might have. You can't keep root from > > doing *anything* by definition. I think there has been a few threads > > regarding this on this list. This might be seen as a UNIX design flaw > > but I certainly disagree. Anyways, that is not the issue here. > > FreeBSD has securelevels, while not ideal, if implemented properly > they can limit what root can do. Yes, but if users have physical access to the machine they can always reboot into single user mode. In that case securelevels don't help. It is very difficult to secure a machine completely if users have physical access to it. -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:43:55 2001 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E824337B424 for ; Mon, 14 May 2001 12:43:52 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4EJhRC02201; Mon, 14 May 2001 12:43:27 -0700 (PDT) Date: Mon, 14 May 2001 12:43:27 -0700 From: Alfred Perlstein To: Erik Trulsson Cc: "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp Message-ID: <20010514124326.C2009@fw.wintelcom.net> References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> <3B002E2B.1337F4C9@lmc.ericsson.se> <20010514122650.T18676@fw.wintelcom.net> <20010514213854.A34209@student.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514213854.A34209@student.uu.se>; from ertr1013@student.uu.se on Mon, May 14, 2001 at 09:38:54PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Erik Trulsson [010514 12:39] wrote: > On Mon, May 14, 2001 at 12:26:50PM -0700, Alfred Perlstein wrote: > > > > FreeBSD has securelevels, while not ideal, if implemented properly > > they can limit what root can do. > > Yes, but if users have physical access to the machine they can always reboot > into single user mode. In that case securelevels don't help. > > It is very difficult to secure a machine completely if users have physical > access to it. My apologies, I didn't realize you were talking about physical access. -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:46:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by hub.freebsd.org (Postfix) with ESMTP id C9BBC37B423 for ; Mon, 14 May 2001 12:46:32 -0700 (PDT) (envelope-from Antoine.Beaupre@ericsson.ca) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4EJkW801380 for ; Mon, 14 May 2001 14:46:32 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4EJkVw19332 for ; Mon, 14 May 2001 14:46:32 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id f4EJkVG27463 for ; Mon, 14 May 2001 15:46:31 -0400 (EDT) Received: by lmc35.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 15:46:31 -0400 Received: from lmc.ericsson.se (lmcpc100455.pc.lmc.ericsson.se [142.133.23.150]) by LMC37.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQDZQAZZ; Mon, 14 May 2001 15:46:27 -0400 From: "Antoine Beaupre (LMC)" To: freebsd-security@FreeBSD.ORG Message-ID: <3B003611.E96E8AE1@lmc.ericsson.se> Date: Mon, 14 May 2001 15:46:25 -0400 Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,fr-CA,fr MIME-Version: 1.0 Subject: Re: nfs mounts / su / yp References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> <3B002E2B.1337F4C9@lmc.ericsson.se> <20010514122650.T18676@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Antoine Beaupre (LMC) [010514 12:20] wrote: > > [cc's trimmed] > > > > You can't. Once the user has root, he can reinstall a complete system, > > bypassing any *local* policy you might have. You can't keep root from > > doing *anything* by definition. I think there has been a few threads > > regarding this on this list. This might be seen as a UNIX design flaw > > but I certainly disagree. Anyways, that is not the issue here. > > FreeBSD has securelevels, while not ideal, if implemented properly > they can limit what root can do. Definitly. One might also mention the infmaous Jail. :) But then again, I think our folks here mentionned something like: On Mon, 14 May 2001, Eric Anderson wrote: > I have users that WILL get root on their desktop machines, one way or > the other. At that point, securelevel or not, jail or not, if the user has physical access to the machine, he is the Root God. Make the console insecure, he'll boot with a floppy. Make the floppy unbootable with a BIOS password, he'll jump the board. Remove the floppy and any removable altogether, and he'll slam his own floppy drive in. Put a lock on the case, he'll break it. There's no escape. A client machine is by definition untrustable, if you don't trust the operator. I think a sysadmin giving a workstation, with full access to a "shared" network (ie. with NFS and YP packets flying around), to a user, must trust the user. Or at least restrict access to the network, or change its infrastructure. I know I might get flamed for this, but you guys should take a look at samba. :) The SMB shares are password protected, usually, which means that they do not (necessarly) rely on client-side authentication, and allow password encryption. I might be wrong though. :) A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 12:47:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from cpimssmtpu13.email.msn.com (cpimssmtpu13.email.msn.com [207.46.181.88]) by hub.freebsd.org (Postfix) with ESMTP id B910B37B424 for ; Mon, 14 May 2001 12:47:10 -0700 (PDT) (envelope-from JHowie@msn.com) Received: from x86w2kw1 ([216.103.48.12]) by cpimssmtpu13.email.msn.com with Microsoft SMTPSVC(5.0.2195.3225); Mon, 14 May 2001 12:47:05 -0700 Message-ID: <00f101c0dcaf$5214db60$0101a8c0@development.local> From: "John Howie" To: , "Erik Trulsson" Cc: "Forrest Houston" , "Oulman, Jamie" , References: <20010514200927.A32697@student.uu.se> <20010514204259.A33451@student.uu.se> <3B00295D.24643CD7@centtech.com> Subject: Re: nfs mounts / su / yp Date: Mon, 14 May 2001 12:51:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 14 May 2001 19:47:05.0683 (UTC) FILETIME=[A75F3A30:01C0DCAE] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Original Message ----- From: "Eric Anderson" To: "Erik Trulsson" Cc: "Forrest Houston" ; "Oulman, Jamie" ; Sent: Monday, May 14, 2001 11:52 AM Subject: Re: nfs mounts / su / yp > Well, I think the problem is that a local root should mean only local > root access, and su should not allow you to su to non-local users (ie, > NIS users). Forrest, you have it close to what I am troubling with. I > have users that WILL get root on their desktop machines, one way or the > other. These users log into others machines (which is needed, and > acceptable).. The problem is simply how do you stop root from su'ing to > another user? (and deleting the binary is not an answer, since > downloading and/or compiling your own is simple enough).. > [remainder deleted] Eric, If you are saying that you are going to give/allow users root access then your problems go further than simply denying them the ability to su to another user from root. If you do not intend to allow users to become root, through securing the boot process and disabling bootable removable drives, then removing su is an option, as merely downloading the binary or compiling the source will not work as it needs to be installed with the owner as root and the suid bit set. If your concern is that users might become root by exploiting a vulnerability, then join the club. That is a problem we all have to deal with. You will just have to be proactive in applying patches and monitoring your audit logs for suspicious activity. Feel free to contact me directly, off list, if you want to discuss this further. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 13:19: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from cithaeron.argolis.org (bgm-24-94-35-22.stny.rr.com [24.94.35.22]) by hub.freebsd.org (Postfix) with ESMTP id D94FA37B422 for ; Mon, 14 May 2001 13:18:53 -0700 (PDT) (envelope-from piechota@argolis.org) Received: from localhost (piechota@localhost) by cithaeron.argolis.org (8.11.3/8.11.3) with ESMTP id f4EKFwX68435; Mon, 14 May 2001 16:16:14 -0400 (EDT) (envelope-from piechota@argolis.org) X-Authentication-Warning: cithaeron.argolis.org: piechota owned process doing -bs Date: Mon, 14 May 2001 16:15:50 -0400 (EDT) From: Matt Piechota To: "Antoine Beaupre (LMC)" Cc: Subject: Re: nfs mounts / su / yp In-Reply-To: <3B003611.E96E8AE1@lmc.ericsson.se> Message-ID: <20010514161231.L55013-100000@cithaeron.argolis.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 May 2001, Antoine Beaupre (LMC) wrote: > I know I might get flamed for this, but you guys should take a look at > samba. :) The SMB shares are password protected, usually, which means > that they do not (necessarly) rely on client-side authentication, and > allow password encryption. While the idea isn't bad, SMB has enough flaws that I wouldn't use it. Along the same line though, AFS or Coda might be a good option. I believe someone mentioned that at MIT everyone knows the root password to public workstations, but it doesn't do too much good since they auth to the AFS servers to get at files. What especially nice is AFS is free and open now (although I'm not sure what the status is for FreeBSD). I'm not sure if AFS encrypts the data as it passes over the wire (not that SMB does either). -- Matt Piechota Finger piechota@emailempire.com for PGP key AOL IM: cithaeron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 13:20:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from kawoserv.kawo2.rwth-aachen.de (kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 8C47E37B43E for ; Mon, 14 May 2001 13:20:38 -0700 (PDT) (envelope-from alex@big.endian.de) Received: from zerogravity.kawo2.rwth-aachen.de (zerogravity.kawo2.rwth-aachen.de [134.130.181.28]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.6.9) with ESMTP id WAA10657 for ; Mon, 14 May 2001 22:20:37 +0200 Received: by zerogravity.kawo2.rwth-aachen.de (Postfix, from userid 1001) id 9D65214AF8; Mon, 14 May 2001 22:20:39 +0200 (CEST) Date: Mon, 14 May 2001 22:20:39 +0200 From: Alexander Langer To: freebsd-security@freebsd.org Subject: sh(1) -p flag Message-ID: <20010514222039.A13757@zerogravity.kawo2.rwth-aachen.d> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Please read PR bin/19946 which describes a matter that must be discussed here (don't forget the Audit-Trail!). Thanks Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 13:33:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by hub.freebsd.org (Postfix) with ESMTP id 2997437B423 for ; Mon, 14 May 2001 13:33:20 -0700 (PDT) (envelope-from Antoine.Beaupre@ericsson.ca) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4EKXI824896 for ; Mon, 14 May 2001 15:33:18 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4EKPnO24865 for ; Mon, 14 May 2001 15:25:49 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id f4EKPlG00093 for ; Mon, 14 May 2001 16:25:48 -0400 (EDT) Received: by lmc35.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 16:25:46 -0400 Received: from lmc.ericsson.se (lmcpc100455.pc.lmc.ericsson.se [142.133.23.150]) by LMC37.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQDZQBS4; Mon, 14 May 2001 16:25:33 -0400 From: "Antoine Beaupre (LMC)" Reply-To: freebsd-security@FreeBSD.ORG To: freebsd-security@FreeBSD.ORG Message-ID: <3B003F3B.906F3802@lmc.ericsson.se> Date: Mon, 14 May 2001 16:25:31 -0400 Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,fr-CA,fr MIME-Version: 1.0 Subject: Re: nfs mounts / su / yp References: <20010514161231.L55013-100000@cithaeron.argolis.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt Piechota wrote: > > On Mon, 14 May 2001, Antoine Beaupre (LMC) wrote: > > > I know I might get flamed for this, but you guys should take a look at > > samba. :) The SMB shares are password protected, usually, which means > > that they do not (necessarly) rely on client-side authentication, and > > allow password encryption. > > While the idea isn't bad, SMB has enough flaws that I wouldn't use it. I wasn't aware of that. Flaws in the implementation or in the design? I thought samba was pretty well written, but I guess this is compared to their Windows counterpart. ;) > Along the same line though, AFS or Coda might be a good option. Yes, I considered that too. However, it seems the ports collection only features a AFS client, and no server. Again, correct me if I'm wrong! A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14: 2:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from tethys.valhalla.net (tethys.valhalla.net [195.26.32.112]) by hub.freebsd.org (Postfix) with ESMTP id 4E50937B424 for ; Mon, 14 May 2001 14:02:28 -0700 (PDT) (envelope-from mark@tethys.valhalla.net) Received: by tethys.valhalla.net (Postfix, from userid 500) id 1741033009; Mon, 14 May 2001 22:02:27 +0100 (BST) Date: Mon, 14 May 2001 22:02:27 +0100 From: Mark Drayton To: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp Message-ID: <20010514220227.A1187@tethys.valhalla.net> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <20010514161231.L55013-100000@cithaeron.argolis.org> <3B003F3B.906F3802@lmc.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B003F3B.906F3802@lmc.ericsson.se>; from Antoine.Beaupre@ericsson.ca on Mon, May 14, 2001 at 04:25:31PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Antoine Beaupre (LMC) (Antoine.Beaupre@ericsson.ca) wrote: > Matt Piechota wrote: > > While the idea isn't bad, SMB has enough flaws that I wouldn't use > > it. > > I wasn't aware of that. Flaws in the implementation or in the design? > I thought samba was pretty well written, but I guess this is compared > to their Windows counterpart. ;) SMB != Samba. Samba is just a UNIX implementation of the SMB (session message block) protocol. Samba is very well written (in fact MS use one of the Samba stress testing programs to test their own code) but the actual SMB protocol itself is reputed to be evil. I've never looked at it in any depth so I can't say. Cheers, -- Mark Drayton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14: 7:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 41EE337B42C for ; Mon, 14 May 2001 14:07:54 -0700 (PDT) (envelope-from fhouston@east.isi.edu) Received: from rosencrantz.east.isi.edu (rosencrantz.east.isi.edu [38.245.76.213]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA11574 for ; Mon, 14 May 2001 17:07:36 -0400 (EDT) Date: Mon, 14 May 2001 17:07:32 -0400 (Eastern Daylight Time) From: Forrest Houston To: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp In-Reply-To: <20010514220227.A1187@tethys.valhalla.net> Message-ID: X-X-Sender: fhouston@ale.east.isi.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Maybe it's a misperception on my part, but I thought samba was mainly for *nix to win* file sharing. Can you do *nix to *nix? Looking through the distribution I have I see a smbclient but that says it's more like an ftp program than anything else. Personally I don't really see that as a workable solution if I'm "downloading" files all the time between the server and the local machine. Did I overlook something? Forrest On Mon, 14 May 2001, Mark Drayton wrote: > Antoine Beaupre (LMC) (Antoine.Beaupre@ericsson.ca) wrote: > > Matt Piechota wrote: > > > While the idea isn't bad, SMB has enough flaws that I wouldn't use > > > it. > > > > I wasn't aware of that. Flaws in the implementation or in the design? > > I thought samba was pretty well written, but I guess this is compared > > to their Windows counterpart. ;) > > SMB != Samba. Samba is just a UNIX implementation of the SMB (session > message block) protocol. Samba is very well written (in fact MS use one > of the Samba stress testing programs to test their own code) but the > actual SMB protocol itself is reputed to be evil. I've never looked at > it in any depth so I can't say. > > Cheers, > > -- > > Mark Drayton > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14:14: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3155D37B424 for ; Mon, 14 May 2001 14:14:03 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4ELE1N03319; Mon, 14 May 2001 14:14:01 -0700 (PDT) Date: Mon, 14 May 2001 14:14:01 -0700 From: Alfred Perlstein To: Forrest Houston Cc: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp Message-ID: <20010514141401.H2009@fw.wintelcom.net> References: <20010514220227.A1187@tethys.valhalla.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fhouston@east.isi.edu on Mon, May 14, 2001 at 05:07:32PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Forrest Houston [010514 14:08] wrote: > Maybe it's a misperception on my part, but I thought samba was mainly for > *nix to win* file sharing. Can you do *nix to *nix? Looking through the > distribution I have I see a smbclient but that says it's more like an ftp > program than anything else. Personally I don't really see that as a > workable solution if I'm "downloading" files all the time between the > server and the local machine. > > Did I overlook something? This is sorta getting offtopic, however at least freebsd-current has support for mounting "smb shares", it may be in -stable but i don't know offhand. -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14:14:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from tethys.valhalla.net (tethys.valhalla.net [195.26.32.112]) by hub.freebsd.org (Postfix) with ESMTP id 060BC37B43E for ; Mon, 14 May 2001 14:14:24 -0700 (PDT) (envelope-from mark@tethys.valhalla.net) Received: by tethys.valhalla.net (Postfix, from userid 500) id 32EBD33009; Mon, 14 May 2001 22:14:23 +0100 (BST) Date: Mon, 14 May 2001 22:14:23 +0100 From: Mark Drayton To: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp Message-ID: <20010514221423.B1187@tethys.valhalla.net> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <20010514220227.A1187@tethys.valhalla.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fhouston@east.isi.edu on Mon, May 14, 2001 at 05:07:32PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Forrest Houston (fhouston@east.isi.edu) wrote: > Maybe it's a misperception on my part, but I thought samba was mainly > for *nix to win* file sharing. Can you do *nix to *nix? Looking > through the distribution I have I see a smbclient but that says it's > more like an ftp program than anything else. Personally I don't > really see that as a workable solution if I'm "downloading" files all > the time between the server and the local machine. Samba is intended for windows <-> unix filesharing. However, this isn't to say unix <-> unix wouldn't work; I haven't tried it myself because it's a bit of a nutty idea. Obviously NFS/Coda/something is a better solution for this. smbclient does a lot more than basic ftp-style filesharing (it'll log you into a domain etc) but you're right in saying it is a bad way of doing things on a pure unix platform. Sorry to have gone off on a tangent... Cheers, -- Mark Drayton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14:33:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from cithaeron.argolis.org (bgm-24-94-35-22.stny.rr.com [24.94.35.22]) by hub.freebsd.org (Postfix) with ESMTP id E073E37B423 for ; Mon, 14 May 2001 14:33:53 -0700 (PDT) (envelope-from piechota@argolis.org) Received: from localhost (piechota@localhost) by cithaeron.argolis.org (8.11.3/8.11.3) with ESMTP id f4ELXVd68601 for ; Mon, 14 May 2001 17:33:47 -0400 (EDT) (envelope-from piechota@argolis.org) X-Authentication-Warning: cithaeron.argolis.org: piechota owned process doing -bs Date: Mon, 14 May 2001 17:33:26 -0400 (EDT) From: Matt Piechota To: Subject: Re: nfs mounts / su / yp In-Reply-To: <3B003F3B.906F3802@lmc.ericsson.se> Message-ID: <20010514172900.Q55013-100000@cithaeron.argolis.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 May 2001, Antoine Beaupre (LMC) wrote: > > While the idea isn't bad, SMB has enough flaws that I wouldn't use it. > > I wasn't aware of that. Flaws in the implementation or in the design? I > thought samba was pretty well written, but I guess this is compared to > their Windows counterpart. ;) Well, flaws in the default configuration. The LAN Manager Hash (for compatibility) strikes me first. You can crack a *lot* of LM hashes in a few seconds, with nothing more than a network sniffer and L0phtcrack. > Yes, I considered that too. However, it seems the ports collection only > features a AFS client, and no server. Again, correct me if I'm wrong! I think arla will serve AFS on FreeBSD. Coda will for sure (the Coda server is userspace, requires no kernel support). The client is an option in the 4.x series (at least). One thing: a friend of mine was running Coda on Linux, and claims his cell crashed taking all his data with it. I don't know what he did, but I haven't done it yet. :) -- Matt Piechota Finger piechota@emailempire.com for PGP key AOL IM: cithaeron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14:37:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from cithaeron.argolis.org (bgm-24-94-35-22.stny.rr.com [24.94.35.22]) by hub.freebsd.org (Postfix) with ESMTP id 3CB5C37B422 for ; Mon, 14 May 2001 14:37:27 -0700 (PDT) (envelope-from piechota@argolis.org) Received: from localhost (piechota@localhost) by cithaeron.argolis.org (8.11.3/8.11.3) with ESMTP id f4ELb8w68611; Mon, 14 May 2001 17:37:24 -0400 (EDT) (envelope-from piechota@argolis.org) X-Authentication-Warning: cithaeron.argolis.org: piechota owned process doing -bs Date: Mon, 14 May 2001 17:37:03 -0400 (EDT) From: Matt Piechota To: Forrest Houston Cc: Subject: Re: nfs mounts / su / yp In-Reply-To: Message-ID: <20010514173509.F55013-100000@cithaeron.argolis.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 May 2001, Forrest Houston wrote: > Maybe it's a misperception on my part, but I thought samba was mainly for > *nix to win* file sharing. Can you do *nix to *nix? Looking through the > distribution I have I see a smbclient but that says it's more like an ftp > program than anything else. Personally I don't really see that as a > workable solution if I'm "downloading" files all the time between the > server and the local machine. Linux has an smbmount command, and there's a commercial product called sharity which, AFAIK, is a user daemon that looks like an nfs mount. I know it works (and is free) for Mac OS X, and exists for IRIX (and probably many others). -- Matt Piechota Finger piechota@emailempire.com for PGP key AOL IM: cithaeron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 14:54:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from poontang.schulte.org (poontang.schulte.org [209.134.156.197]) by hub.freebsd.org (Postfix) with ESMTP id 9EA2937B42C for ; Mon, 14 May 2001 14:54:34 -0700 (PDT) (envelope-from christopher@schulte.org) Received: from schulte-laptop.schulte.org (nb40.netbriefings.com [64.183.199.40]) by poontang.schulte.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4ELroWB077396; Mon, 14 May 2001 16:54:13 -0500 (CDT) Message-Id: <5.1.0.14.0.20010514164900.02e4b008@pop.schulte.org> X-Sender: schulte@pop.schulte.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 May 2001 16:52:53 -0500 To: Matt Piechota , Forrest Houston From: Christopher Schulte Subject: Re: nfs mounts / su / yp Cc: In-Reply-To: <20010514173509.F55013-100000@cithaeron.argolis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:37 PM 5/14/2001 -0400, Matt Piechota wrote: >On Mon, 14 May 2001, Forrest Houston wrote: >Linux has an smbmount command, and there's a commercial product called >sharity which, AFAIK, is a user daemon that looks like an nfs mount. I >know it works (and is free) for Mac OS X, and exists for IRIX (and >probably many others). ftp://ftp.butya.kz/pub/smbfs/ This is native SMB/CIFS filesystem (smbfs for short) for FreeBSD. It is a complete, kernel side implementation of SMB requester and filesystem. I've used it on 4.x boxes to 'smbmount' remote smb shares to the fbsd filesystem. Seems to work ok, and there's even been updates since I installed my version. >-- >Matt Piechota >Finger piechota@emailempire.com for PGP key >AOL IM: cithaeron --chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 15:16:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from skink.ru.ac.za (skink.ru.ac.za [146.231.128.4]) by hub.freebsd.org (Postfix) with ESMTP id DB89837B424 for ; Mon, 14 May 2001 15:16:25 -0700 (PDT) (envelope-from dom@dude.dsl.ru.ac.za) Received: from dude.dsl.ru.ac.za ([146.231.113.85]) by skink.ru.ac.za with esmtp (Exim 3.16 #1) id 14zQdZ-000M8T-00 for freebsd-security@freebsd.org; Tue, 15 May 2001 00:16:21 +0200 Received: (from dom@localhost) by dude.dsl.ru.ac.za (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id f4EMLOZ00650 for freebsd-security@freebsd.org; Tue, 15 May 2001 00:21:24 +0200 Date: Tue, 15 May 2001 00:21:24 +0200 From: Dominic Parry To: freebsd-security@freebsd.org Subject: Re: nfs mounts / su / yp Message-ID: <20010515002124.A647@dude.dsl.ru.ac.za> References: <3B0015E5.2E1AED1B@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rsimmons@wlcg.com on Mon, May 14, 2001 at 02:02:15PM -0400 X-added-header: added by skink.ru.ac.za Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a thought, you could in your bios set password and then boot only of the hdd. That way no one could boot of a stiffy etc. On Mon 2001-05-14 (14:02), Rob Simmons wrote: //> -----BEGIN PGP SIGNED MESSAGE----- //> Hash: RIPEMD160 //> //> You could set the console to insecure in /etc/ttys. That way single user //> mode will ask for the root password. You still can't prevent someone from //> booting with their own floppy disk and making changes that way. I think //> the only way to prevent that is to use an encrypted filesystem of some //> sort. //> //> Robert Simmons //> Systems Administrator //> http://www.wlcg.com/ //> //> On Mon, 14 May 2001, Eric Anderson wrote: //> //> > If a user reboots their machine, goes into single user mode, and changes //> > the local root password (and adds their username into the wheel group of //> > course), then boots into multiuser mode, they can su to root, then su to //> > any NIS user they desire, and do malicious things as that user. su'ing //> > from root to any other user never asks for a password, so login.conf //> > isn't used (right?).. //> -----BEGIN PGP SIGNATURE----- //> Version: GnuPG v1.0.5 (FreeBSD) //> Comment: For info see http://www.gnupg.org //> //> iD8DBQE7AB2qv8Bofna59hYRA0ebAKCQ9R1wLoemlWAuEdplqcSMcY12IQCfVH0B //> 8SkJHNs8J3aEYZ8dk27La2k= //> =Qb9E //> -----END PGP SIGNATURE----- //> //> //> //> To Unsubscribe: send mail to majordomo@FreeBSD.org //> with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 15:54:38 2001 Delivered-To: freebsd-security@freebsd.org Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by hub.freebsd.org (Postfix) with ESMTP id 0BE8A37B422 for ; Mon, 14 May 2001 15:54:35 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailc.telia.com (8.11.2/8.11.0) with ESMTP id f4EMsXQ18885 for ; Tue, 15 May 2001 00:54:33 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id AAA21512 for ; Tue, 15 May 2001 00:54:33 +0200 (CEST) Received: (qmail 40415 invoked by uid 1001); 14 May 2001 22:54:31 -0000 Date: Tue, 15 May 2001 00:54:31 +0200 From: Erik Trulsson To: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp Message-ID: <20010515005431.A40399@student.uu.se> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <3B0015E5.2E1AED1B@centtech.com> <20010515002124.A647@dude.dsl.ru.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515002124.A647@dude.dsl.ru.ac.za>; from dom@dude.dsl.ru.ac.za on Tue, May 15, 2001 at 12:21:24AM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 12:21:24AM +0200, Dominic Parry wrote: > > Just a thought, you could in your bios set password and then boot only of > the hdd. That way no one could boot of a stiffy etc. Yes, they could. Assuming they can open the case they could either reset the BIOS password (almost all mobo have some jumper or similar that can be used to reset the password), or they could just connect their own hdd and boot from that. It is quite a bit more work and would probably stop those who are merely driven by idle curiosity. Stopping a determined and knowledgeable person who have physical access to the computer from getting root access ranges from difficult to nearly impossible. > > On Mon 2001-05-14 (14:02), Rob Simmons wrote: > //> -----BEGIN PGP SIGNED MESSAGE----- > //> Hash: RIPEMD160 > //> > //> You could set the console to insecure in /etc/ttys. That way single user > //> mode will ask for the root password. You still can't prevent someone from > //> booting with their own floppy disk and making changes that way. I think > //> the only way to prevent that is to use an encrypted filesystem of some > //> sort. > //> -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 15:56:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by hub.freebsd.org (Postfix) with SMTP id E9B1B37B423 for ; Mon, 14 May 2001 15:56:37 -0700 (PDT) (envelope-from educatee2001@yahoo.com) Received: from unknown (HELO co3018900a) (210.7.158.144) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 May 2001 22:56:37 -0000 X-Apparently-From: Message-ID: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> From: "Educatee" To: "ipfilter" , "FreeBSD questions" , "FreeBSD security" Subject: any software to stop melicious attack? Date: Tue, 15 May 2001 08:58:47 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Can anyone let me know if there are any softare that could run on FreeBSD 4.x which could enable me to stop any melicious attack on my machine? Thank you. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 16: 4:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 469C837B422; Mon, 14 May 2001 16:04:07 -0700 (PDT) (envelope-from mike@sentex.net) Received: from chimp (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.2/8.11.1) with ESMTP id f4EN44I85379; Mon, 14 May 2001 19:04:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <4.2.2.20010514185814.032fd6f8@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 14 May 2001 19:04:03 -0400 To: "Educatee" , , "FreeBSD security" From: Mike Tancsa Subject: Re: any software to stop melicious attack? In-Reply-To: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:58 AM 5/15/2001 +1000, Educatee wrote: >Hi! Can anyone let me know if there are any softare that could run on >FreeBSD 4.x which could enable me to stop any melicious attack on my >machine? Thank you. Its generally considered rude to post to so many lists at once. As to your question, its the same thing as asking, is there any medicine that can stop any illnesses. There is no one medicine to stop everything. And like the metaphor of medicine, prevention is the best approach.... Start with man 7 security There is much to learn. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Network Administration, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 16: 6:19 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.islandnet.com (mail.islandnet.com [199.175.106.4]) by hub.freebsd.org (Postfix) with ESMTP id 007AD37B422 for ; Mon, 14 May 2001 16:06:15 -0700 (PDT) (envelope-from rb@islandnet.com) Received: from [199.175.106.243] (helo=newwilly.islandnet.com) by mail.islandnet.com with SMTP id 14zRPl-000Nkx-00 ; Mon, 14 May 2001 16:06:09 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Ron Brogden Reply-To: rb@islandnet.com Organization: Islandnet.com To: Subject: Re: any software to stop melicious attack? Date: Mon, 14 May 2001 16:00:57 +0000 X-Mailer: KMail [version 1.2] References: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> In-Reply-To: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> Cc: "Educatee" MIME-Version: 1.0 Message-Id: <0105141600570A.37594@newwilly.islandnet.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday 14 May 2001 22:58, you wrote: > Hi! Can anyone let me know if there are any softare that could run on > FreeBSD 4.x which could enable me to stop any melicious attack on my > machine? Thank you. You could try the following: sync sync halt That should do it I think. =) I am assuming that your post was a joke but if not, you should start by reading the FreeBSD handbook at www.freebsd.org and narrowing things down a bit since your question is infinitely too vague to get a proper answer. Cheers -- ----------------------------------------------------------------------------- Island Net AMT Solutions Group Inc. Telephone: 250 383-0096 1412 Quadra Street Toll Free: 1 800 331-3055 Victoria, B.C. Fax: 250 383-6698 V8W 2L1 E-Mail: support@islandnet.com Canada WWW: http://www.islandnet.com/ ----------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 16: 9:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from bilbo.w-link.net (bilbo.w-link.net [206.98.114.20]) by hub.freebsd.org (Postfix) with ESMTP id A4BFE37B422 for ; Mon, 14 May 2001 16:09:26 -0700 (PDT) (envelope-from miesterio@w-link.net) Received: from c91133c (lLrlcgQ@dial053.w-link.net [206.98.114.82]) by bilbo.w-link.net (8.9.3/8.9.3) with SMTP id QAA26492; Mon, 14 May 2001 16:05:55 -0700 (PDT) Message-ID: <008001c0dcca$1da17940$0c0d0041@home> Reply-To: "Zachary Gates" From: "Zachary Gates" To: "Educatee" , References: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> Subject: Re: any software to stop melicious attack? Date: Mon, 14 May 2001 16:03:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sorta reminds me of all your base are belong to us. ----- Original Message ----- From: "Educatee" To: "ipfilter" ; "FreeBSD questions" ; "FreeBSD security" Sent: Monday, May 14, 2001 3:58 PM Subject: any software to stop melicious attack? > Hi! Can anyone let me know if there are any softare that could run on > FreeBSD 4.x which could enable me to stop any melicious attack on my > machine? Thank you. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 16:19:44 2001 Delivered-To: freebsd-security@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id C15CF37B423 for ; Mon, 14 May 2001 16:19:40 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: by arg1.demon.co.uk (Postfix, from userid 300) id 123AF9B06; Tue, 15 May 2001 00:19:39 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 0A1675D1C; Tue, 15 May 2001 00:19:39 +0100 (BST) Date: Tue, 15 May 2001 00:19:38 +0100 (BST) From: Andrew Gordon X-X-Sender: To: Forrest Houston Cc: "'freebsd-security@freebsd.org'" Subject: Re: nfs mounts / su / yp In-Reply-To: Message-ID: <20010514235938.P10632-100000@server.arg.sj.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 May 2001, Forrest Houston wrote: > The problem is further complicated though when you want the user to have > root access. We have some people around here who need/want total access > to their machine. However there is still the concern of the NFS > mounts. What do you do in these circumstances? I have a similar situation - workstations on an untrusted network. The other solutions suggested in this thread are of no use to us: - physical security/BIOS etc: While we can probably trust the users not to take a can opener to the machines, they don't need to bother: just unplug the network cable and substitute their laptop and masquerade as the machine in question. - keep user's home directories on their own workstations: useless for us, these are open-access ("terminal room") machines with an itinerant user population. At the moment, the open access machines are limited to being X-terminals to a small number of trusted (securely located) server machines, which NFS mount the home directories. However, I want to allow some of the machines to run applications locally to take load off the servers. I am planning to do this: - On the NFS server, have entries explicitly exporting the /home partition explicitly to each of the 'terminal' machines. Initally, these exports will all be "mapall=nobody". So far, this is no loss of security, as all the users with physical access to the terminal rooms have accounts on the main servers. - On the terminals, use a PAM module to hook the login process and obtain the username/password. This will then perform a transaction with the server, quoting the password, and the server will change the export to be "mappall=xxx". I'm not quite sure how best to implement this; one possibility is to use ssh (in password-authenticated mode) to execute a setuid program on the server - the setuid program will then adjust the export based on the real uid with which the program is executed. Using ssh has the merit of protecting the password across the network without the trouble of inventing my own scheme (& the related risk of cockup in the design). There may be some DoS risks in this scheme, but in our environment that's fairly acceptable - there are plenty of ways for users to DoS already, and so long as we have audit trail we can beat them up accordingly. If anyone can see glaring holes in this, I'd be glad to know about it before I get started! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 17:20: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id A68D537B422 for ; Mon, 14 May 2001 17:19:58 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f4F0JKU13835; Mon, 14 May 2001 20:19:20 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Mon, 14 May 2001 20:19:17 -0400 (EDT) From: Rob Simmons To: Andrew Gordon Cc: Forrest Houston , freebsd-security@freebsd.org Subject: Re: nfs mounts / su / yp In-Reply-To: <20010514235938.P10632-100000@server.arg.sj.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 You could prevent someone from unplugging the machine and masquerading as it by using a wireless network. That could get costly, since I would assume these type of machines will be located in the basement of dormitories, or somewhere in the public library :) Robert Simmons Systems Administrator http://www.wlcg.com/ On Tue, 15 May 2001, Andrew Gordon wrote: > On Mon, 14 May 2001, Forrest Houston wrote: > > > The problem is further complicated though when you want the user to have > > root access. We have some people around here who need/want total access > > to their machine. However there is still the concern of the NFS > > mounts. What do you do in these circumstances? > > I have a similar situation - workstations on an untrusted network. > > The other solutions suggested in this thread are of no use to us: > > - physical security/BIOS etc: While we can probably trust the users > not to take a can opener to the machines, they don't need to bother: > just unplug the network cable and substitute their laptop and > masquerade as the machine in question. > > - keep user's home directories on their own workstations: useless for > us, these are open-access ("terminal room") machines with an itinerant > user population. > > At the moment, the open access machines are limited to being X-terminals > to a small number of trusted (securely located) server machines, which NFS > mount the home directories. > > However, I want to allow some of the machines to run applications locally > to take load off the servers. I am planning to do this: > > - On the NFS server, have entries explicitly exporting the /home > partition explicitly to each of the 'terminal' machines. > Initally, these exports will all be "mapall=nobody". > So far, this is no loss of security, as all the users with physical > access to the terminal rooms have accounts on the main servers. > > - On the terminals, use a PAM module to hook the login process > and obtain the username/password. This will then perform a > transaction with the server, quoting the password, and the server > will change the export to be "mappall=xxx". > > I'm not quite sure how best to implement this; one possibility is to use > ssh (in password-authenticated mode) to execute a setuid program on the > server - the setuid program will then adjust the export based on the real > uid with which the program is executed. Using ssh has the merit of > protecting the password across the network without the trouble of > inventing my own scheme (& the related risk of cockup in the design). > There may be some DoS risks in this scheme, but in our environment that's > fairly acceptable - there are plenty of ways for users to DoS already, and > so long as we have audit trail we can beat them up accordingly. > > If anyone can see glaring holes in this, I'd be glad to know about it > before I get started! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AHYIv8Bofna59hYRA9mKAKCj0s+mI2agiFXGMvu9pbAT7dhRawCgheRl /kMa5fvd2gSeRb/1xcaMy3c= =6AsY -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 17:48: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from bryden.apana.org.au (bryden.apana.org.au [203.3.126.129]) by hub.freebsd.org (Postfix) with ESMTP id 4FB4337B422; Mon, 14 May 2001 17:47:59 -0700 (PDT) (envelope-from dougy@brizzie.org) Received: from oracle ([192.168.0.3]) by bryden.apana.org.au (8.9.3/8.9.3) with SMTP id KAA50079; Tue, 15 May 2001 10:46:37 +1000 (EST) (envelope-from dougy@brizzie.org) Message-ID: <01ff01c0dcd8$a8d127a0$0300a8c0@oracle> From: "Doug Young" To: "Educatee" , "ipfilter" , "FreeBSD questions" , "FreeBSD security" References: <005d01c0dcc9$701c3d50$0100c8c8@co3018900a> Subject: Re: any software to stop melicious attack? Date: Tue, 15 May 2001 10:47:44 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ppp -nat is a good start, then portsentry, maybe ipfw and / or ipf for the paranoid ----- Original Message ----- From: "Educatee" To: "ipfilter" ; "FreeBSD questions" ; "FreeBSD security" Sent: Tuesday, May 15, 2001 8:58 AM Subject: any software to stop melicious attack? > Hi! Can anyone let me know if there are any softare that could run on > FreeBSD 4.x which could enable me to stop any melicious attack on my > machine? Thank you. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 18:41: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id 0931637B42C for ; Mon, 14 May 2001 18:40:56 -0700 (PDT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA18490; Tue, 15 May 2001 08:38:13 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id IAA13223; Tue, 15 May 2001 08:40:51 +0700 (ICT) Date: Tue, 15 May 2001 08:40:51 +0700 (ICT) Message-Id: <200105150140.IAA13223@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: rsimmons@wlcg.com Cc: anderson@centtech.com, JOulman@iphrase.com, freebsd-security@FreeBSD.ORG In-reply-to: (message from Rob Simmons on Mon, 14 May 2001 14:02:15 -0400 (EDT)) Subject: Re: nfs mounts / su / yp References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What about mounting only the user's disk space, and after he has logged in? If the user authenticate, then the NFS server will export his home directory to him only. Would need a mechanism to know when the user logs out too, to reverse the process. Beside, why does users need root account? >I'm running FreeBSD client machines and mixed NFS servers. My clients >nfs mount (or automount) the shares from the servers, and all are using To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 18:44:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id F2B7837B42C for ; Mon, 14 May 2001 18:44:27 -0700 (PDT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA18522; Tue, 15 May 2001 08:41:39 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id IAA13231; Tue, 15 May 2001 08:44:17 +0700 (ICT) Date: Tue, 15 May 2001 08:44:17 +0700 (ICT) Message-Id: <200105150144.IAA13231@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: fhouston@east.isi.edu Cc: ertr1013@student.uu.se, anderson@centtech.com, JOulman@iphrase.com, freebsd-security@FreeBSD.ORG In-reply-to: (message from Forrest Houston on Mon, 14 May 2001 14:18:16 -0400 (Eastern Daylight Time)) Subject: Re: nfs mounts / su / yp References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >root access. We have some people around here who need/want total access >to their machine. However there is still the concern of the NFS >mounts. What do you do in these circumstances? As a system/security manager, you tell them that they cannot integrate with others, so they have their root password and are isolated. Those who make such request are always the ones knowing less about system administration, but who think they know it all, so if they know it all they are able to live their own life. Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 19:36:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns.morning.ru (ns.morning.ru [195.161.98.5]) by hub.freebsd.org (Postfix) with ESMTP id 12F8537B42C for ; Mon, 14 May 2001 19:36:23 -0700 (PDT) (envelope-from poige@morning.ru) Received: from NIC1 ([195.161.98.236]) by ns.morning.ru (8.9.3/8.9.3) with ESMTP id KAA32395; Tue, 15 May 2001 10:36:19 +0800 (KRAST) (envelope-from poige@morning.ru) Date: Tue, 15 May 2001 10:39:09 +0700 From: Igor Podlesny X-Mailer: The Bat! (v1.52 Beta/7) UNREG / CD5BF9353B3B7091 Organization: Morning Network X-Priority: 3 (Normal) Message-ID: <10967731793.20010515103909@morning.ru> To: Peter Pentchev Cc: freebsd-security@FreeBSD.ORG Subject: Re[2]: ipfw rules and securelevel In-Reply-To: <20010514180201.C453@ringworld.oblivion.bg> References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote: >> >> >> > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: >> >> >> >> >> Dear friends, >> >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I >> >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When >> >> >> I run a command >> >> >> >> >> sysctl -w net.inet.ip.fw.enable=0 >> >> >> >> >> It disables the ipfw rules. >> >> >> >> >> Is it a feature or hole in freebsd. >> >> >> >> > doesn't matter how it is called, only matters how it hurts... (it does) >> >> >> >> >> please help >> >> >> >> the "patch" (hard to call it a patch, but nevertheless) is adding >> >> CTLFLAG_SECURE to the relevant definition of the node: >> >> >> >> this diff out is for 3.5 stable: >> >> >> >> 92c92 >> >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, >> >> --- >> >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, >> >> > Patches/diffs are usually much easier to review and apply if they are >> > in context or unified diff format - this helps when the patch is made >> > against a possibly changed file :) And.. well.. it might be obvious >> > to you (in this case it's pretty obvious to figure out ;), but still >> > it helps a lot to mention which file(s) the patch is against :) >> >> oh, you're right :) >> >> it was >> /usr/src/sys/netinet/ip_fw.c >> >> unified diff: >> >> --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 >> +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 >> @@ -89,7 +89,7 @@ >> >> #ifdef SYSCTL_NODE >> SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); >> -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, >> +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, >> &fw_enable, 0, "Enable ipfw"); >> SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, >> &fw_one_pass, 0, > Yup, this patch is much clearer, and I see no real reason against > committing it. My quick patch letter was for a person asking for help -- he asked and I tried to answer. I'm not a member of FreeBSD developer team, just a user/amateur :) > Actually, I think that even more of those sysctl's > should be flagged as 'secure' - e.g. the ones related to logging. I deem it is a business of the core team to decide what sysctls to be protected depending on the securelevel value... cause it is theirs design :) -- Igor mailto:poige@morning.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon May 14 21:27: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from dell.dannyland.org (dell.dannyland.org [64.81.36.13]) by hub.freebsd.org (Postfix) with ESMTP id 082AE37B422 for ; Mon, 14 May 2001 21:27:05 -0700 (PDT) (envelope-from dannyman@toldme.com) Received: by dell.dannyland.org (Postfix, from userid 1001) id D98DF5BFE; Mon, 14 May 2001 21:26:26 -0700 (PDT) Date: Mon, 14 May 2001 21:26:26 -0700 From: dannyman To: Erik Trulsson Cc: freebsd-security@FreeBSD.ORG Subject: Re: nfs mounts / su / yp Message-ID: <20010514212626.I53429@dell.dannyland.org> References: <3B0015E5.2E1AED1B@centtech.com> <20010515002124.A647@dude.dsl.ru.ac.za> <20010515005431.A40399@student.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010515005431.A40399@student.uu.se>; from ertr1013@student.uu.se on Tue, May 15, 2001 at 12:54:31AM +0200 X-Loop: djhoward@uiuc.edu X-URL: http://www.dannyland.org/~dannyman/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 12:54:31AM +0200, Erik Trulsson wrote: > On Tue, May 15, 2001 at 12:21:24AM +0200, Dominic Parry wrote: > > > > Just a thought, you could in your bios set password and then boot only of > > the hdd. That way no one could boot of a stiffy etc. > > Yes, they could. Assuming they can open the case they could either reset > the BIOS password (almost all mobo have some jumper or similar that can > be used to reset the password), or they could just connect their own hdd > and boot from that. > > It is quite a bit more work and would probably stop those who are merely > driven by idle curiosity. > > Stopping a determined and knowledgeable person who have physical access > to the computer from getting root access ranges from difficult to nearly > impossible. NFS is the problem, IMO. A user could just bring in a laptop, plug it in to Network, munge MAC address, if necessary, and then get the job done. Were I truly uptight I'd allow NFS access only on a physically secured network, and the user can "check out" their files via rsync, or the like. Ugly for a lab environment. In a lab environment I'd just lock the machines down as much as physically possible, which helps discourage the from wandering off, and have supervisory personnel keep tabs who is trying to plug unauthorized equipment in. Maybe provide an isolated, maybe wireless, network for people bringing laptops in. -danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 4:10:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 15BBC37B424; Tue, 15 May 2001 04:09:47 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4FB9iK42189; Tue, 15 May 2001 14:09:44 +0300 (EEST) (envelope-from ru) Date: Tue, 15 May 2001 14:09:43 +0300 From: Ruslan Ermilov To: Bill Fumerola , Luigi Rizzo Cc: ipfw@FreeBSD.org Subject: Re: ipfw rules and securelevel Message-ID: <20010515140943.A41014@sunbay.com> Mail-Followup-To: Bill Fumerola , Luigi Rizzo , ipfw@FreeBSD.org References: <10320318256.20010514212856@morning.ru> <19322552168.20010514220610@morning.ru> <20010514170927.A849@ringworld.oblivion.bg> <5523460344.20010514222118@morning.ru> <20010514180201.C453@ringworld.oblivion.bg> <20010514180928.A52742@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010514180928.A52742@sunbay.com>; from ru@FreeBSD.org on Mon, May 14, 2001 at 06:09:28PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Redirected to -ipfw] On Mon, May 14, 2001 at 06:09:28PM +0300, Ruslan Ermilov wrote: > On Mon, May 14, 2001 at 06:02:02PM +0300, Peter Pentchev wrote: > > On Mon, May 14, 2001 at 10:21:18PM +0700, Igor Podlesny wrote: > > > > > > > > > > On Mon, May 14, 2001 at 10:06:10PM +0700, Igor Podlesny wrote: > > > >> > > > >> >> Dear friends, > > > >> >> Even in securelevel 3 I can bypass ipfw rules. In securelevel 3 I > > > >> >> as root can change the variable "net.inet.ip.fw.enable" using sysctl. When > > > >> >> I run a command > > > >> > > > >> >> sysctl -w net.inet.ip.fw.enable=0 > > > >> > > > >> >> It disables the ipfw rules. > > > >> > > > >> >> Is it a feature or hole in freebsd. > > > >> > > > >> > doesn't matter how it is called, only matters how it hurts... (it does) > > > >> > > > >> >> please help > > > >> > > > >> the "patch" (hard to call it a patch, but nevertheless) is adding > > > >> CTLFLAG_SECURE to the relevant definition of the node: > > > >> > > > >> this diff out is for 3.5 stable: > > > >> > > > >> 92c92 > > > >> < SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > > >> --- > > > >> > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > > > > > Patches/diffs are usually much easier to review and apply if they are > > > > in context or unified diff format - this helps when the patch is made > > > > against a possibly changed file :) And.. well.. it might be obvious > > > > to you (in this case it's pretty obvious to figure out ;), but still > > > > it helps a lot to mention which file(s) the patch is against :) > > > > > > oh, you're right :) > > > > > > it was > > > /usr/src/sys/netinet/ip_fw.c > > > > > > unified diff: > > > > > > --- /usr/src/sys/netinet/ip_fw.c.orig Fri Mar 23 19:44:27 2001 > > > +++ /usr/src/sys/netinet/ip_fw.c Mon May 14 22:15:55 2001 > > > @@ -89,7 +89,7 @@ > > > > > > #ifdef SYSCTL_NODE > > > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > > > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > > > +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW|CTLFLAG_SECURE, > > > &fw_enable, 0, "Enable ipfw"); > > > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > > > &fw_one_pass, 0, > > > > Yup, this patch is much clearer, and I see no real reason against > > committing it. Actually, I think that even more of those sysctl's > > should be flagged as 'secure' - e.g. the ones related to logging. > > > Hmm, but I think that for (securelevel < 3) the transition should > still be allowed. The correct fix then would be: > > Index: ip_fw.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v > retrieving revision 1.164 > diff -u -p -r1.164 ip_fw.c > --- ip_fw.c 2001/04/06 06:52:25 1.164 > +++ ip_fw.c 2001/05/14 15:04:12 > @@ -96,9 +96,19 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f > MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); > > #ifdef SYSCTL_NODE > + > +static int > +sysctl_fw_enable(SYSCTL_HANDLER_ARGS) > +{ > + > + if (req->newptr && securelevel >= 3) > + return (EPERM); > + return sysctl_handle_int(oidp, arg1, arg2, req); > +} > + > SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); > -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, > - &fw_enable, 0, "Enable ipfw"); > +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW, > + &fw_enable, 0, sysctl_fw_enable, "I", "Enable ipfw"); > SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, > &fw_one_pass, 0, > "Only do a single pass through ipfw when using dummynet(4)"); > Here is a slightly reworked version of the above patch. It prohibits all MIB modifications under net.inet.ip.fw node except a few ones: debug, verbose, and verbose_limit that shouldn't affect security. Please review. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.164 diff -u -p -r1.164 ip_fw.c --- ip_fw.c 2001/04/06 06:52:25 1.164 +++ ip_fw.c 2001/05/15 10:57:41 @@ -96,11 +96,21 @@ LIST_HEAD (ip_fw_head, ip_fw_chain) ip_f MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); #ifdef SYSCTL_NODE + +static int +sysctl_fw_securelevel_check(SYSCTL_HANDLER_ARGS) +{ + + if (req->newptr && securelevel >= 3) + return (EPERM); + return sysctl_handle_int(oidp, arg1, arg2, req); +} + SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, - &fw_enable, 0, "Enable ipfw"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, - &fw_one_pass, 0, +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, enable, CTLTYPE_INT|CTLFLAG_RW, + &fw_enable, 0, sysctl_fw_securelevel_check, "I", "Enable ipfw"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, one_pass, CTLTYPE_INT|CTLFLAG_RW, + &fw_one_pass, 0, sysctl_fw_securelevel_check, "I", "Only do a single pass through ipfw when using dummynet(4)"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, &fw_debug, 0, "Enable printing of debug ip_fw statements"); @@ -108,8 +118,9 @@ SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, ve &fw_verbose, 0, "Log matches to ipfw rules"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, &fw_verbose_limit, 0, "Set upper limit of matches of ipfw rules logged"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLFLAG_RW, - &fw_permanent_rules, 0, "Set rule number, below which rules are permanent"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLTYPE_INT|CTLFLAG_RW, + &fw_permanent_rules, 0, sysctl_fw_securelevel_check, "I", + "Set rule number, below which rules are permanent"); /* * Extension for stateful ipfw. @@ -163,24 +174,31 @@ static u_int32_t dyn_rst_lifetime = 5 ; static u_int32_t dyn_short_lifetime = 30 ; static u_int32_t dyn_count = 0 ; static u_int32_t dyn_max = 1000 ; -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, - &dyn_buckets, 0, "Number of dyn. buckets"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, - &curr_dyn_buckets, 0, "Current Number of dyn. buckets"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_count, CTLFLAG_RD, - &dyn_count, 0, "Number of dyn. rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLFLAG_RW, - &dyn_max, 0, "Max number of dyn. rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, - &dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW, - &dyn_syn_lifetime, 0, "Lifetime of dyn. rules for syn"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLFLAG_RW, - &dyn_fin_lifetime, 0, "Lifetime of dyn. rules for fin"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLFLAG_RW, - &dyn_rst_lifetime, 0, "Lifetime of dyn. rules for rst"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, CTLFLAG_RW, - &dyn_short_lifetime, 0, "Lifetime of dyn. rules for other situations"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLTYPE_INT|CTLFLAG_RW, + &dyn_buckets, 0, sysctl_fw_securelevel_check, "IU", + "Number of dyn. buckets"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLTYPE_INT|CTLFLAG_RD, + &curr_dyn_buckets, 0, sysctl_fw_securelevel_check, "IU", + "Current Number of dyn. buckets"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_count, CTLTYPE_INT|CTLFLAG_RD, + &dyn_count, 0, sysctl_fw_securelevel_check, "IU", "Number of dyn. rules"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLTYPE_INT|CTLFLAG_RW, + &dyn_max, 0, sysctl_fw_securelevel_check, "IU", "Max number of dyn. rules"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_ack_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for acks"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_syn_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for syn"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_fin_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for fin"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLTYPE_INT|CTLFLAG_RW, + &dyn_rst_lifetime, 0, sysctl_fw_securelevel_check, "IU", + "Lifetime of dyn. rules for rst"); +SYSCTL_PROC(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, + CTLTYPE_INT|CTLFLAG_RW, &dyn_short_lifetime, 0, sysctl_fw_securelevel_check, + "IU", "Lifetime of dyn. rules for other situations"); #endif --tThc/1wpZn/ma/RB-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 6:19:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from kottan-labs.bgsu.edu (kottan-labs.bgsu.edu [129.1.133.123]) by hub.freebsd.org (Postfix) with ESMTP id C50F137B422 for ; Tue, 15 May 2001 06:19:23 -0700 (PDT) (envelope-from memphis_ms@gmx.net) Received: (qmail 1482 invoked from network); 15 May 2001 09:21:50 -0400 Received: from m133-122.bgsu.edu (HELO gmx.net) (129.1.133.122) by kottan-labs.bgsu.edu with RC4-MD5 encrypted SMTP; 15 May 2001 09:21:50 -0400 Message-ID: <3B012DB2.DF11CF12@gmx.net> Date: Tue, 15 May 2001 09:22:58 -0400 From: Raoul Schroeder X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Szilveszter Adam Cc: freebsd-security@FreeBSD.org Subject: Re: Warnings while compiling Samba References: <3AFFE661.5D6015EA@comune.arzignano.vi.it> <20010514162605.C3213@petra.hos.u-szeged.hu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This warning is always triggered if the linker encounters this function > name since often it is used unsafely and since FreeBSD provides a better > alternative. But this is for the programmer/porter who might consider if he > better swap mktemp() to mkstemp() or not. Unfortunately, it is not as easy > as switching the two words... so I do not think you should be very > concerned about this. Hmm, actually, with Samba-TNG, I really did just switched the functions to mkstemp() and it worked fine. I cannot guarantuee anything though. Just personal experience.. Raoul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 6:51:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from beheer2.iae.nl (orion.officenet.iae.nl [212.61.20.140]) by hub.freebsd.org (Postfix) with ESMTP id 9F1B337B509 for ; Tue, 15 May 2001 06:51:32 -0700 (PDT) (envelope-from axel@orion.iae.nl) Received: by beheer2.iae.nl (Postfix, from userid 1000) id 436D9C3CB3; Tue, 15 May 2001 15:51:31 +0200 (CEST) Date: Tue, 15 May 2001 15:51:31 +0200 From: Axel Scheepers To: freebsd-security@FreeBSD.org Subject: Re: Warnings while compiling Samba Message-ID: <20010515155130.D40513@beheer2.iae.nl> Mail-Followup-To: Axel Scheepers , freebsd-security@FreeBSD.org References: <3AFFE661.5D6015EA@comune.arzignano.vi.it> <20010514162605.C3213@petra.hos.u-szeged.hu> <3B012DB2.DF11CF12@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B012DB2.DF11CF12@gmx.net>; from memphis_ms@gmx.net on Tue, May 15, 2001 at 09:22:58AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, man mkstemp brings me the the man page of mkstemp so I guess i'ts save to just replace the mktemp call with mkstemp. I don't have the time right now to look into the source so I can't be 100% sure about this... anyone? Gr, Axel On Tue, May 15, 2001 at 09:22:58AM -0400, Raoul Schroeder wrote: > > This warning is always triggered if the linker encounters this function > > name since often it is used unsafely and since FreeBSD provides a better > > alternative. But this is for the programmer/porter who might consider if he > > better swap mktemp() to mkstemp() or not. Unfortunately, it is not as easy > > as switching the two words... so I do not think you should be very > > concerned about this. > > Hmm, actually, with Samba-TNG, I really did just switched the functions to > mkstemp() and it worked fine. > I cannot guarantuee anything though. Just personal experience.. > > Raoul > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Met vriendelijke groet, VIA NET.WORKS Nederland Axel Scheepers Operations phone +31 40 239 33 93 fax +31 40 239 33 11 e-mail eindhoven.beheer@vianetworks.nl http://www.vianetworks.nl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 7: 3:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id A770437B422 for ; Tue, 15 May 2001 07:03:03 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 16963 invoked by uid 1000); 15 May 2001 14:02:21 -0000 Date: Tue, 15 May 2001 17:02:21 +0300 From: Peter Pentchev To: Axel Scheepers Cc: freebsd-security@FreeBSD.org Subject: Re: Warnings while compiling Samba Message-ID: <20010515170221.K11592@ringworld.oblivion.bg> Mail-Followup-To: Axel Scheepers , freebsd-security@FreeBSD.org References: <3AFFE661.5D6015EA@comune.arzignano.vi.it> <20010514162605.C3213@petra.hos.u-szeged.hu> <3B012DB2.DF11CF12@gmx.net> <20010515155130.D40513@beheer2.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515155130.D40513@beheer2.iae.nl>; from axel@beheer2.iae.nl on Tue, May 15, 2001 at 03:51:31PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 03:51:31PM +0200, Axel Scheepers wrote: > Well, man mkstemp brings me the the man page of mkstemp so I guess i'ts save > to just replace the mktemp call with mkstemp. I don't have the time right now > to look into the source so I can't be 100% sure about this... anyone? 'man mkstemp' brings up the manual page for mktemp(3), mkstemp(3), mkstemps(3) and mkdtemp(3) functions. Just one look at the prototypes, though, should tell you that the mktemp() and mkstemp() functions are NOT equivalent - mktemp() returns a char *, mkstemp() returns an int. Further down the manpage describes that mktemp() and mkstemp() really do return different objects - mktemp() returns the filename of the new file (which it does not create), mkstemp() actually creates the file and returns a file descriptor. It is only with difficulty that I can imagine a situation in which the mkstemp() return value could be used as if it were returned by mktemp() - programs using mktemp() expect a pointer to a string, while mkstemp() returns a small integer. An attempt to create a file with that "name" would most probably result in an immediate segmentation fault or bus error. G'luck, Peter -- What would this sentence be like if pi were 3? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 7:12:58 2001 Delivered-To: freebsd-security@freebsd.org Received: from beheer2.iae.nl (orion.officenet.iae.nl [212.61.20.140]) by hub.freebsd.org (Postfix) with ESMTP id 7455B37B422 for ; Tue, 15 May 2001 07:12:53 -0700 (PDT) (envelope-from axel@orion.iae.nl) Received: by beheer2.iae.nl (Postfix, from userid 1000) id B17B1C3CB3; Tue, 15 May 2001 16:12:52 +0200 (CEST) Date: Tue, 15 May 2001 16:12:52 +0200 From: Axel Scheepers To: freebsd-security@freebsd.org Subject: Re: Warnings while compiling Samba Message-ID: <20010515161252.E40513@beheer2.iae.nl> Mail-Followup-To: Axel Scheepers , freebsd-security@freebsd.org References: <3AFFE661.5D6015EA@comune.arzignano.vi.it> <20010514162605.C3213@petra.hos.u-szeged.hu> <3B012DB2.DF11CF12@gmx.net> <20010515155130.D40513@beheer2.iae.nl> <20010515170221.K11592@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515170221.K11592@ringworld.oblivion.bg>; from roam@orbitel.bg on Tue, May 15, 2001 at 05:02:21PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for clearing this up for all of us and an excuse for my behaviour, trying to read the manpage in 10secs and then shouting out it should be same etc.. I'm almost starting to feel like a windows user ... :-( Gr, Axel On Tue, May 15, 2001 at 05:02:21PM +0300, Peter Pentchev wrote: > On Tue, May 15, 2001 at 03:51:31PM +0200, Axel Scheepers wrote: > > Well, man mkstemp brings me the the man page of mkstemp so I guess i'ts save > > to just replace the mktemp call with mkstemp. I don't have the time right now > > to look into the source so I can't be 100% sure about this... anyone? > > 'man mkstemp' brings up the manual page for mktemp(3), mkstemp(3), mkstemps(3) > and mkdtemp(3) functions. Just one look at the prototypes, though, should > tell you that the mktemp() and mkstemp() functions are NOT equivalent - > mktemp() returns a char *, mkstemp() returns an int. > > Further down the manpage describes that mktemp() and mkstemp() really do > return different objects - mktemp() returns the filename of the new file > (which it does not create), mkstemp() actually creates the file and returns > a file descriptor. > > It is only with difficulty that I can imagine a situation in which > the mkstemp() return value could be used as if it were returned by mktemp() - > programs using mktemp() expect a pointer to a string, while mkstemp() returns > a small integer. An attempt to create a file with that "name" would most > probably result in an immediate segmentation fault or bus error. > > G'luck, > Peter > > -- > What would this sentence be like if pi were 3? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Met vriendelijke groet, VIA NET.WORKS Nederland Axel Scheepers Operations phone +31 40 239 33 93 fax +31 40 239 33 11 e-mail eindhoven.beheer@vianetworks.nl http://www.vianetworks.nl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 8:37:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from bart.esiee.fr (bart.esiee.fr [147.215.1.20]) by hub.freebsd.org (Postfix) with ESMTP id 1D1A237B422 for ; Tue, 15 May 2001 08:37:08 -0700 (PDT) (envelope-from bonnetf@bart.esiee.fr) Received: (from bonnetf@localhost) by bart.esiee.fr (8.11.1/8.11.1) id f4FFb5624682 for freebsd-security@freebsd.org; Tue, 15 May 2001 17:37:05 +0200 (MEST) From: Frank Bonnet Message-Id: <200105151537.f4FFb5624682@bart.esiee.fr> Subject: pam_ldap at 4.3-R ? To: freebsd-security@freebsd.org Date: Tue, 15 May 2001 17:37:05 +0200 (MEST) X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I'm trying to use PAM and LDAP to authenticate users on a FreeBSD 4.3R machine. It SEEMS to work 90% ;-) ... The login session seems ok and in fact is logged into /var/log/messages BUT I cannot get a login session the system, it just returns to login promt. I feel some misconfiguration somewhere but cannot find where /etc/pam.conf seems correct The ldap server is Netscape Directory server if it matters. Thanks for any infos/pointers . -- Frank Bonnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 8:41:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 7957737B423 for ; Tue, 15 May 2001 08:41:33 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 18166 invoked by uid 1000); 15 May 2001 15:40:53 -0000 Date: Tue, 15 May 2001 18:40:53 +0300 From: Peter Pentchev To: Frank Bonnet Cc: freebsd-security@freebsd.org Subject: Re: pam_ldap at 4.3-R ? Message-ID: <20010515184053.U11592@ringworld.oblivion.bg> Mail-Followup-To: Frank Bonnet , freebsd-security@freebsd.org References: <200105151537.f4FFb5624682@bart.esiee.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105151537.f4FFb5624682@bart.esiee.fr>; from bonnetf@bart.esiee.fr on Tue, May 15, 2001 at 05:37:05PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, May 15, 2001 at 05:37:05PM +0200, Frank Bonnet wrote: > Hi > > I'm trying to use PAM and LDAP to authenticate users > on a FreeBSD 4.3R machine. > > It SEEMS to work 90% ;-) ... > > The login session seems ok and in fact is logged > into /var/log/messages > BUT I cannot get a login session > the system, it just returns to login promt. > > I feel some misconfiguration somewhere but cannot find where > /etc/pam.conf seems correct > > The ldap server is Netscape Directory server if it matters. > > Thanks for any infos/pointers . Yes, the problems that login(1) has with PAM are known and analyzed. Take a look at http://www.FreeBSD.org/cgi-bin/query-pr?pr=27153 and see if the attached patches solve your problems, or at least help a little. G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 14:35:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from MCSMTP2.MC.VANDERBILT.EDU (mcsmtp2.mc.Vanderbilt.Edu [160.129.93.208]) by hub.freebsd.org (Postfix) with ESMTP id 8BD2C37B422 for ; Tue, 15 May 2001 14:35:46 -0700 (PDT) (envelope-from George.Giles@mcmail.vanderbilt.edu) Subject: off topic ssh To: freebsd-security@freebsd.org X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: George.Giles@mcmail.vanderbilt.edu Date: Tue, 15 May 2001 16:35:17 -0500 X-MIMETrack: Serialize by Router on MCSMTP2.MC.vanderbilt.edu/VUMC/Vanderbilt(Release 5.0.3 |March 21, 2000) at 05/15/2001 04:31:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I beg your indulgence, but I find this list to be the most knowledgeable about ssh/openssh. My ssh clients and servers work as expected when connecting between my FreeBSD boxes (4.3 Release). When I try to connect to my Win2K box running the cygwin distribution, I always get the error: Access Denied I am running in password mode. The /etc/passwd file exists and has the correct password. I am starting the server by hand so there are no service/inetd issues. The same error occurs if I run the OpenSSH portable code, compiled under cygwin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 17:29: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f72.law11.hotmail.com [64.4.17.72]) by hub.freebsd.org (Postfix) with ESMTP id 1622237B423 for ; Tue, 15 May 2001 17:29:02 -0700 (PDT) (envelope-from ronnetron@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 May 2001 17:29:01 -0700 Received: from 209.179.94.84 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 16 May 2001 00:29:01 GMT X-Originating-IP: [209.179.94.84] From: "Ron Smith" To: freebsd-security@FreeBSD.ORG Subject: Lost Password Date: Tue, 15 May 2001 17:29:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 May 2001 00:29:01.0904 (UTC) FILETIME=[34A37500:01C0DD9F] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All, I may have a post that is slightly off-topic, but I'm hoping someone can help me anyway. I've got a mixed network of FreeBSD, MACs, WinNT and Win2k. One of the WinNT boxes can be logged into under two separate domains at the login screen. We can log in and out of one of the domains with no problem, but nobody knows the password to the administrator's account under the other domain. Has anyone out ther had any experience in retrieving passwords. Or, if this is the wrong place to post this message, could you point me in the right direction? Ron _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 17:38:36 2001 Delivered-To: freebsd-security@freebsd.org Received: from istar.ca (d141-119-162.home.cgocable.net [24.141.119.162]) by hub.freebsd.org (Postfix) with ESMTP id 5909137B422 for ; Tue, 15 May 2001 17:38:32 -0700 (PDT) (envelope-from genisis@istar.ca) Received: (from genisis@localhost) by istar.ca (8.11.1/8.11.1) id f4G0gSo12434; Tue, 15 May 2001 20:42:28 -0400 (EDT) (envelope-from genisis) Date: Tue, 15 May 2001 20:42:27 -0400 (EDT) From: Dru To: Ron Smith Cc: freebsd-security@FreeBSD.ORG Subject: Re: Lost Password In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org l0pht is probably the easiest way to do this; read the FAQ first to find out how to get the SAM. www.securitysoftwaretech.com On Tue, 15 May 2001, Ron Smith wrote: > Hi All, > > I may have a post that is slightly off-topic, but I'm hoping someone can > help me anyway. > > I've got a mixed network of FreeBSD, MACs, WinNT and Win2k. One of the WinNT > boxes can be logged into under two separate domains at the login screen. We > can log in and out of one of the domains with no problem, but nobody knows > the password to the administrator's account under the other domain. > > Has anyone out ther had any experience in retrieving passwords. Or, if this > is the wrong place to post this message, could you point me in the right > direction? > > Ron > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 17:48: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id 58BFC37B42C for ; Tue, 15 May 2001 17:47:57 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id QAA28125 for ; Tue, 15 May 2001 16:45:50 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma028120; Tue, 15 May 01 16:45:42 -0500 Message-ID: <3B01A386.53176DF8@centtech.com> Date: Tue, 15 May 2001 16:45:42 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: risks of ip-forwarding, without ipf/ipfw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What are the risks of having a dual-homed machine (2 NIC's), one on the big bad internet and one on a home lan, with ip forwarding enabled, without ipf or ipfw running? Is this a very bad thing? Is this easily "hopped" to access the internal net? The one way I can think of that would be fairly easy to do is to use the box as a gateway to the internal home net, and that would allow access to the internal net.. (this is in theory, since I haven't set this up and tested this yet).. Thoughts? Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 18: 7:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id 9FCBF37B422 for ; Tue, 15 May 2001 18:07:44 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GDELSA00.IA7; Tue, 15 May 2001 18:07:22 -0700 Message-ID: <3B01D2DD.C1DEBD2E@globalstar.com> Date: Tue, 15 May 2001 18:07:41 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: anderson@centtech.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: risks of ip-forwarding, without ipf/ipfw References: <3B01A386.53176DF8@centtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eric Anderson wrote: > > What are the risks of having a dual-homed machine (2 NIC's), one on the > big bad internet and one on a home lan, with ip forwarding enabled, > without ipf or ipfw running? A.k.a. a router. All it means is that every machine on the home LAN must be hardened and treated as if it were directly connected to the Internet 'cause, well, it is. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 18:24: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from radix.cryptio.net (radix.cryptio.net [199.181.107.213]) by hub.freebsd.org (Postfix) with ESMTP id E78ED37B422 for ; Tue, 15 May 2001 18:23:59 -0700 (PDT) (envelope-from emechler@radix.cryptio.net) Received: (from emechler@localhost) by radix.cryptio.net (8.11.3/8.11.3) id f4G1NqN57321; Tue, 15 May 2001 18:23:52 -0700 (PDT) (envelope-from emechler) Date: Tue, 15 May 2001 18:23:51 -0700 From: Erick Mechler To: Dru Cc: freebsd-security@FreeBSD.ORG Subject: Re: Lost Password Message-ID: <20010515182351.A57269@techometer.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Dru on Tue, May 15, 2001 at 08:42:27PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While this help is all nice and good and useful, posting NT questions to a FreeBSD list is probably considered "the wrong place to post this message". In the future, I might suggest using Deja to get your answers. Regards, Erick At Tue, May 15, 2001 at 08:42:27PM -0400, Dru said this: :: :: l0pht is probably the easiest way to do this; read the FAQ first to find :: out how to get the SAM. :: :: www.securitysoftwaretech.com :: :: :: On Tue, 15 May 2001, Ron Smith wrote: :: :: > Hi All, :: > :: > I may have a post that is slightly off-topic, but I'm hoping someone can :: > help me anyway. :: > :: > I've got a mixed network of FreeBSD, MACs, WinNT and Win2k. One of the WinNT :: > boxes can be logged into under two separate domains at the login screen. We :: > can log in and out of one of the domains with no problem, but nobody knows :: > the password to the administrator's account under the other domain. :: > :: > Has anyone out ther had any experience in retrieving passwords. Or, if this :: > is the wrong place to post this message, could you point me in the right :: > direction? :: > :: > Ron :: > :: > _________________________________________________________________ :: > Get your FREE download of MSN Explorer at http://explorer.msn.com :: > :: > :: > To Unsubscribe: send mail to majordomo@FreeBSD.org :: > with "unsubscribe freebsd-security" in the body of the message :: > :: > :: > :: > :: :: :: To Unsubscribe: send mail to majordomo@FreeBSD.org :: with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 18:34:18 2001 Delivered-To: freebsd-security@freebsd.org Received: from saturn.cranehome.net (mkc-65-26-118-19.kc.rr.com [65.26.118.19]) by hub.freebsd.org (Postfix) with ESMTP id 013C937B423 for ; Tue, 15 May 2001 18:34:15 -0700 (PDT) (envelope-from kcrane@kcsaturn.homeip.net) Received: from kcranemobile (saturn.cranehome.net [192.168.0.1]) by saturn.cranehome.net (Postfix) with SMTP id ECBDA24D02 for ; Tue, 15 May 2001 20:34:12 -0500 (CDT) Message-ID: <002101c0dda8$d3b3e400$3401a8c0@kcranemobile> From: "Kyle Crane" To: References: <3B01A386.53176DF8@centtech.com> Subject: Re: risks of ip-forwarding, without ipf/ipfw Date: Tue, 15 May 2001 20:37:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would think long and hard before doing that. There are numerous ways to hop through a gateway to the nice juicey targets behind it. You end up allowing everyone out there to fire away at anything you have running. In practical terms it so much easier to secure a single gateway than to secure a gateway plus N number of internal workstations. Learn and run ipf or ipfw. You will be very happy you did. Kyle ----- Original Message ----- From: "Eric Anderson" To: Sent: Tuesday, May 15, 2001 4:45 PM Subject: risks of ip-forwarding, without ipf/ipfw > What are the risks of having a dual-homed machine (2 NIC's), one on the > big bad internet and one on a home lan, with ip forwarding enabled, > without ipf or ipfw running? > > Is this a very bad thing? Is this easily "hopped" to access the > internal net? > The one way I can think of that would be fairly easy to do is to use the > box as a gateway to the internal home net, and that would allow access > to the internal net.. (this is in theory, since I haven't set this up > and tested this yet).. > > Thoughts? > > > > Eric > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 19:47:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f203.law11.hotmail.com [64.4.17.203]) by hub.freebsd.org (Postfix) with ESMTP id DC9EC37B422 for ; Tue, 15 May 2001 19:47:23 -0700 (PDT) (envelope-from ronnetron@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 15 May 2001 19:47:23 -0700 Received: from 24.130.49.190 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 16 May 2001 02:47:23 GMT X-Originating-IP: [24.130.49.190] From: "Ron Smith" To: freebsd-security@FreeBSD.ORG Date: Tue, 15 May 2001 19:47:23 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 May 2001 02:47:23.0771 (UTC) FILETIME=[88EFD4B0:01C0DDB2] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks, to everyone who respoded. I have been gently chastised for posting an NT question on this list. *Point taken*. I've gotten enough leads from those who responded, so I would like to close out this thread. Thanks, to all :-). _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue May 15 20: 7:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp2.jaring.my (smtp2.jaring.my [192.228.128.47]) by hub.freebsd.org (Postfix) with ESMTP id 3F04937B422 for ; Tue, 15 May 2001 20:07:40 -0700 (PDT) (envelope-from mglory@po.jaring.my) Received: from svr.mgsb.domain ([202.187.194.33]) by smtp2.jaring.my (8.10.1/8.10.1) with SMTP id f4G37Xg05739; Wed, 16 May 2001 11:07:33 +0800 (MYT) Content-Type: text/plain; charset="iso-8859-1" From: K Karthik Reply-To: kar_alerts@mglorysb.com Organization: Multimedia Glory Sdn Bhd To: ronnetron@hotmail.com Subject: Re: Lost Password Date: Wed, 16 May 2001 11:09:44 +0000 X-Mailer: KMail [version 1.2] Cc: freebsd-security@freebsd.org X-Chameleon-Return-To: kar_alerts@mglorysb.com MIME-Version: 1.0 Message-Id: <01051611094400.04345@svr.mgsb.domain> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org try www.lostpassword.com ---- Hi All, I may have a post that is slightly off-topic, but I'm hoping someone can help me anyway. I've got a mixed network of FreeBSD, MACs, WinNT and Win2k. One of the WinNT boxes can be logged into under two separate domains at the login screen. We can log in and out of one of the domains with no problem, but nobody knows the password to the administrator's account under the other domain. Has anyone out ther had any experience in retrieving passwords. Or, if this is the wrong place to post this message, could you point me in the right direction? Ron _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message -------- End of forwarded message -------- ------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 0:30:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from beheer2.iae.nl (orion.officenet.iae.nl [212.61.20.140]) by hub.freebsd.org (Postfix) with ESMTP id 8AA2837B423 for ; Wed, 16 May 2001 00:30:00 -0700 (PDT) (envelope-from axel@orion.iae.nl) Received: by beheer2.iae.nl (Postfix, from userid 1000) id 93F18C3B9F; Wed, 16 May 2001 09:29:59 +0200 (CEST) Date: Wed, 16 May 2001 09:29:59 +0200 From: Axel Scheepers To: freebsd-security@freebsd.org Subject: Re: risks of ip-forwarding, without ipf/ipfw Message-ID: <20010516092959.A42898@beheer2.iae.nl> Mail-Followup-To: freebsd-security@freebsd.org References: <3B01A386.53176DF8@centtech.com> <002101c0dda8$d3b3e400$3401a8c0@kcranemobile> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002101c0dda8$d3b3e400$3401a8c0@kcranemobile>; from kcrane@kcsaturn.homeip.net on Tue, May 15, 2001 at 08:37:53PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I would rethink that, at home i have a similar configuration which consists of 3 boxes. One is an old 486 which has an ppp uplink (will be replaced by cable soon ;-). I suggest that you use ipf on your internet gateway/router and block the services you don't intend to run. You can safely keepstate on outgoing connections so you can acces the internet without troubles. With this setup you'll need natd or something similar too. Probably a bit more complicated to install/setup but a much safer environnement afterwards. Grz, Axel On Tue, May 15, 2001 at 08:37:53PM -0500, Kyle Crane wrote: > I would think long and hard before doing that. There are numerous ways to > hop through a gateway to the nice juicey targets behind it. You end up > allowing everyone out there to fire away at anything you have running. In > practical terms it so much easier to secure a single gateway than to secure > a gateway plus N number of internal workstations. Learn and run ipf or > ipfw. You will be very happy you did. > > Kyle > > ----- Original Message ----- > From: "Eric Anderson" > To: > Sent: Tuesday, May 15, 2001 4:45 PM > Subject: risks of ip-forwarding, without ipf/ipfw > > > > What are the risks of having a dual-homed machine (2 NIC's), one on the > > big bad internet and one on a home lan, with ip forwarding enabled, > > without ipf or ipfw running? > > > > Is this a very bad thing? Is this easily "hopped" to access the > > internal net? > > The one way I can think of that would be fairly easy to do is to use the > > box as a gateway to the internal home net, and that would allow access > > to the internal net.. (this is in theory, since I haven't set this up > > and tested this yet).. > > > > Thoughts? > > > > > > > > Eric > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Met vriendelijke groet, VIA NET.WORKS Nederland Axel Scheepers Operations phone +31 40 239 33 93 fax +31 40 239 33 11 e-mail eindhoven.beheer@vianetworks.nl http://www.vianetworks.nl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 8:56:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from web14503.mail.yahoo.com (web14503.mail.yahoo.com [216.136.224.66]) by hub.freebsd.org (Postfix) with SMTP id 8663737B422 for ; Wed, 16 May 2001 08:56:26 -0700 (PDT) (envelope-from jedovaty@yahoo.com) Message-ID: <20010516155615.40395.qmail@web14503.mail.yahoo.com> Received: from [63.204.248.100] by web14503.mail.yahoo.com; Wed, 16 May 2001 08:56:15 PDT Date: Wed, 16 May 2001 08:56:15 -0700 (PDT) From: Jano Lukac Subject: Re: risks of ip-forwarding, without ipf/ipfw To: freebsd-security@freebsd.org In-Reply-To: <20010516092959.A42898@beheer2.iae.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If your IP changes (e.g. in a PPP or PPPoE link), do you have to rerun ipf/ipfw/natd everytime? Or is freebsd smart about this (unlike the unnamed arctic semi-counterpart which uses ipchains/iptables)? --- Axel Scheepers wrote: > Hi, > I would rethink that, at home i have a similar configuration which consists > of 3 boxes. One is an old 486 which has an ppp uplink (will be replaced by > cable soon ;-). > I suggest that you use ipf on your internet gateway/router and block the > services you don't intend to run. You can safely keepstate on outgoing > connections so you can acces the internet without troubles. > With this setup you'll need natd or something similar too. > Probably a bit more complicated to install/setup but a much safer > environnement afterwards. > Grz, > Axel > > On Tue, May 15, 2001 at 08:37:53PM -0500, Kyle Crane wrote: > > I would think long and hard before doing that. There are numerous ways to > > hop through a gateway to the nice juicey targets behind it. You end up > > allowing everyone out there to fire away at anything you have running. In > > practical terms it so much easier to secure a single gateway than to secure > > a gateway plus N number of internal workstations. Learn and run ipf or > > ipfw. You will be very happy you did. > > > > Kyle > > > > ----- Original Message ----- > > From: "Eric Anderson" > > To: > > Sent: Tuesday, May 15, 2001 4:45 PM > > Subject: risks of ip-forwarding, without ipf/ipfw > > > > > > > What are the risks of having a dual-homed machine (2 NIC's), one on the > > > big bad internet and one on a home lan, with ip forwarding enabled, > > > without ipf or ipfw running? > > > > > > Is this a very bad thing? Is this easily "hopped" to access the > > > internal net? > > > The one way I can think of that would be fairly easy to do is to use the > > > box as a gateway to the internal home net, and that would allow access > > > to the internal net.. (this is in theory, since I haven't set this up > > > and tested this yet).. > > > > > > Thoughts? > > > > > > > > > > > > Eric > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > -- > Met vriendelijke groet, > VIA NET.WORKS Nederland > > Axel Scheepers > Operations > phone +31 40 239 33 93 > fax +31 40 239 33 11 > e-mail eindhoven.beheer@vianetworks.nl > http://www.vianetworks.nl/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 9: 9:27 2001 Delivered-To: freebsd-security@freebsd.org Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by hub.freebsd.org (Postfix) with ESMTP id E2FAD37B422 for ; Wed, 16 May 2001 09:09:22 -0700 (PDT) (envelope-from Antoine.Beaupre@ericsson.ca) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f4GG9L823151 for ; Wed, 16 May 2001 11:09:21 -0500 (CDT) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f4GG9Ki10775 for ; Wed, 16 May 2001 11:09:20 -0500 (CDT) Received: from lmc35.lmc.ericsson.se (lmc35.lmc.ericsson.se [142.133.16.175]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id f4GG9JG02848 for ; Wed, 16 May 2001 12:09:20 -0400 (EDT) Received: by lmc35.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 12:09:19 -0400 Received: from lmc.ericsson.se (lmcpc100455.pc.lmc.ericsson.se [142.133.23.150]) by LMC37.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQDZQ7S7; Wed, 16 May 2001 12:09:14 -0400 From: "Antoine Beaupre (LMC)" To: freebsd-security@FreeBSD.ORG Message-ID: <3B02A627.533CD030@lmc.ericsson.se> Date: Wed, 16 May 2001 12:09:11 -0400 Organization: LMC, Ericsson Research Canada X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,fr-CA,fr MIME-Version: 1.0 Subject: Re: risks of ip-forwarding, without ipf/ipfw References: <20010516155615.40395.qmail@web14503.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There's a few issues with that here... You can run natd with -dynamic: -dynamic If the -n or -interface option is used, natd will monitor the routing socket for alterations to the interface passed. If the interface's IP number is changed, natd will dynamically alter its concept of the alias address. For the matching rules, you can use the "me" keyword that: src and dst: any | me | [not]
[ports] Specifying me makes the rule match any IP number configured on an interface in the system. This is a computationally semi-expen­ sive check which should be used with care. So yes, it's smart. A. Jano Lukac wrote: > > If your IP changes (e.g. in a PPP or PPPoE link), do you have to rerun > ipf/ipfw/natd everytime? Or is freebsd smart about this (unlike the unnamed > arctic semi-counterpart which uses ipchains/iptables)? -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 9:55:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from covert.iadfw.net (covert.black-ring.iadfw.net [209.196.123.142]) by hub.freebsd.org (Postfix) with SMTP id 611A937B423 for ; Wed, 16 May 2001 09:55:54 -0700 (PDT) (envelope-from datazone@airmail.net) Received: from scab.caprolite.org from [207.136.36.203] by covert.iadfw.net (/\##/\ Smail3.1.30.16 #30.49) with smtp for freebsd-security@freebsd.org sender: id ; Wed, 16 May 2001 11:56:18 -0500 (CDT) Message-Id: Date: Wed, 16 May 2001 11:56:18 -0500 (CDT) To: Jano Lukac Cc: freebsd-security@freebsd.org From: datazone@airmail.net Subject: Re: risks of ip-forwarding, without ipf/ipfw X-Mailer: Gmail 0.7.0pre5 (http://gmail.linuxpower.org) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If your IP changes (e.g. in a PPP or PPPoE link), do you have to rerun > ipf/ipfw/natd everytime? Or is freebsd smart about this (unlike the unnamed > arctic semi-counterpart which uses ipchains/iptables)? > I know you are not implying that you need to do that with iptables! cause that sounds like a personal issue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 10:55:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp1.amigo.net (smtp1.amigo.net [209.94.64.30]) by hub.freebsd.org (Postfix) with ESMTP id AD97437B423 for ; Wed, 16 May 2001 10:55:45 -0700 (PDT) (envelope-from randys@amigo.net) Received: from amigo.net (billing.amigo.net [209.94.67.250]) by smtp1.amigo.net (8.11.2/8.11.2) with ESMTP id f4GI2uY36946 for ; Wed, 16 May 2001 12:02:57 -0600 (MDT) (envelope-from randys@amigo.net) Message-ID: <3B02BF17.7060106@amigo.net> Date: Wed, 16 May 2001 11:55:35 -0600 From: Randy Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.3-STABLE i386; en-US; 0.8) Gecko/20010314 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: require NFS to use IPsec Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I have an NFS server talking to a couple of clients over IPsec. This works just fine. However, I would like to require all NFS connections to use IPsec. Is it possible to do this and if so does anyone have instructions posted online? Thanks for your help. -- Randy Smith Amigo.Net Systems Administrator 719-589-6100 ext. 4185 http://www.amigo.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 16:37:29 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id E7AFE37B422 for ; Wed, 16 May 2001 16:37:25 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id PAA28837; Wed, 16 May 2001 15:35:24 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma028835; Wed, 16 May 01 15:35:18 -0500 Message-ID: <3B02E486.4E6870AE@centtech.com> Date: Wed, 16 May 2001 15:35:18 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Crist Clark Cc: freebsd-security@freebsd.org Subject: Re: risks of ip-forwarding, without ipf/ipfw References: <3B01A386.53176DF8@centtech.com> <3B01D2DD.C1DEBD2E@globalstar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No, I'm not actually doing this, I was more curious than anything. I use ipfilter myself. Thanks for the good thoughts everyone. Crist Clark wrote: > > Eric Anderson wrote: > > > > What are the risks of having a dual-homed machine (2 NIC's), one on the > > big bad internet and one on a home lan, with ip forwarding enabled, > > without ipf or ipfw running? > > A.k.a. a router. > > All it means is that every machine on the home LAN must be hardened > and treated as if it were directly connected to the Internet 'cause, > well, it is. > -- > Crist J. Clark Network Security Engineer > crist.clark@globalstar.com Globalstar, L.P. > (408) 933-4387 FAX: (408) 933-4926 > > The information contained in this e-mail message is confidential, > intended only for the use of the individual or entity named above. If > the reader of this e-mail is not the intended recipient, or the employee > or agent responsible to deliver it to the intended recipient, you are > hereby notified that any review, dissemination, distribution or copying > of this communication is strictly prohibited. If you have received this > e-mail in error, please contact postmaster@globalstar.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- ------------------------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 17:37:55 2001 Delivered-To: freebsd-security@freebsd.org Received: from smtp2.mbox.com.au (smtp2.mbox.com.au [203.103.80.178]) by hub.freebsd.org (Postfix) with ESMTP id BD04C37B422 for ; Wed, 16 May 2001 17:37:49 -0700 (PDT) (envelope-from das@mbox.com.au) Received: from nms2.mbox.com.au (webmail.i7mail.com.au [192.168.20.4]) by smtp2.mbox.com.au (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with ESMTP id <0GDG005B1F1Y6Q@smtp2.mbox.com.au> for freebsd-security@FreeBSD.ORG; Thu, 17 May 2001 08:37:11 +0800 (WST) Received: from mbox.com.au ([127.0.0.1]) by nms2.mbox.com.au (Netscape Messaging Server 4.15) with ESMTP id GDGF1Y02.S6B for ; Thu, 17 May 2001 08:37:10 +0800 Date: Thu, 17 May 2001 10:37:10 +1000 From: Dave Seddon Subject: RE: risks of ip-forwarding, without ipf/ipfw To: freebsd-security@FreeBSD.ORG Message-id: <3e9a343ed668.3ed6683e9a34@mbox.com.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I run a FreeBSD router/firewall for my home network, sharing cable. If I wasn't actually packet filtering, how would somebody attack my internal machines (assuming the gateway box was secure and people couldn't telnet, etc, into it)? Doesn't natd provide a lot of protection anyway? Natd dynamically keeps track of outgoing connections, then maps these back on the way back in. So if somebody tries to start a connection inbound, it will hit the router, natd will look through it's table, say to itself "no match" and drop the packet (s). I assume that natd actually tracks the close of a tcp connection and removes entries? or is this done by some sort of timeout? Is the way to attack: Sit on the Cable Ethernet network, address frames to target site's ethernet address, address packets to the (guessed) internal addresses of the target site, and set the return packet address to your box? (assuming no firewall) Just wondering... Dave Seddon -----Original Message----- From: owner-freebsd-security@FreeBSD.ORG [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Eric Anderson Sent: Thursday, 17 May 2001 6:35 To: Crist Clark Cc: freebsd-security@FreeBSD.ORG Subject: Re: risks of ip-forwarding, without ipf/ipfw No, I'm not actually doing this, I was more curious than anything. I use ipfilter myself. Thanks for the good thoughts everyone. Crist Clark wrote: > > Eric Anderson wrote: > > > > What are the risks of having a dual-homed machine (2 NIC's), one on the > > big bad internet and one on a home lan, with ip forwarding enabled, > > without ipf or ipfw running? > > A.k.a. a router. > > All it means is that every machine on the home LAN must be hardened > and treated as if it were directly connected to the Internet 'cause, > well, it is. > -- > Crist J. Clark Network Security Engineer > crist.clark@globalstar.com Globalstar, L.P. > (408) 933-4387 FAX: (408) 933-4926 > > The information contained in this e-mail message is confidential, > intended only for the use of the individual or entity named above. If > the reader of this e-mail is not the intended recipient, or the employee > or agent responsible to deliver it to the intended recipient, you are > hereby notified that any review, dissemination, distribution or copying > of this communication is strictly prohibited. If you have received this > e-mail in error, please contact postmaster@globalstar.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- ------------------------------------------------------------------------ ------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------ ------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message ---------------------------------------- Want to hear your email over the phone? faxes+voicemail+email = http://mbox.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 18: 4:52 2001 Delivered-To: freebsd-security@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id 2A56D37B423 for ; Wed, 16 May 2001 18:04:49 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GDGGBE00.0FK; Wed, 16 May 2001 18:04:26 -0700 Message-ID: <3B0323AF.E1FD1EC1@globalstar.com> Date: Wed, 16 May 2001 18:04:47 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Seddon Cc: freebsd-security@FreeBSD.ORG Subject: Re: risks of ip-forwarding, without ipf/ipfw References: <3e9a343ed668.3ed6683e9a34@mbox.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dave Seddon wrote: > > I run a FreeBSD router/firewall for my home network, sharing cable. > > If I wasn't actually packet filtering, how would somebody attack my > internal machines (assuming the gateway box was secure and people > couldn't telnet, etc, into it)? Doesn't natd provide a lot of > protection anyway? The original poster said nothing about doing NAT. Under natd(8) or ipnat(8) on FreeBSD, you'd need to be running ipfw(8) or ipf(8) anyway. > Natd dynamically keeps track of outgoing > connections, then maps these back on the way back in. So if somebody > tries to start a connection inbound, it will hit the router, natd will > look through it's table, say to itself "no match" and drop the packet > (s). natd(8) does not filter packets. If it has an entry in its NAT table for a packet, it rewrites the headers appropriately before reinjecting it into the IP stack. If it does not, it reinjects it into the stack without touching it. > I assume that natd actually tracks the close of a tcp connection > and removes entries? or is this done by some sort of timeout? Can't recall the mechanism off of the top of my head. > Is the way to attack: > Sit on the Cable Ethernet network, address frames to target site's > ethernet address, address packets to the (guessed) internal addresses > of the target site, and set the return packet address to your box? > (assuming no firewall) Anyone who can get packets with destination addresses bound for your internal LAN to the outer interface of your NAT machine has full access to your LAN. If someone on your coax cable LAN guessed your "private" network used the block, 192.168.128.0/24, all he would need to do is, # route add 192.168.128.0/24 To get total access to your LAN. If you are using RFC1918 addresses, you are afforded the slight protection that people "far away" on the Internet cannot route packets to your network, but anyone close by can do so with trivial effort. Adding a simple, # ipfw add drop ip from any to 192.168.128.0/24 in via Before the divert(4) rule is a _very_ good idea. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 19:15:37 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id D9E8437B422 for ; Wed, 16 May 2001 19:15:34 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 4134 invoked by uid 0); 17 May 2001 02:15:29 -0000 Received: from pd9508861.dip.t-dialin.net (HELO speedy.gsinet) (217.80.136.97) by mail.gmx.net (mp030-rz3) with SMTP; 17 May 2001 02:15:29 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id VAA02047 for freebsd-security@freebsd.org; Wed, 16 May 2001 21:31:54 +0200 Date: Wed, 16 May 2001 21:31:54 +0200 From: Gerhard Sittig To: freebsd-security@freebsd.org Subject: Re: risks of ip-forwarding, without ipf/ipfw Message-ID: <20010516213154.A253@speedy.gsinet> Mail-Followup-To: freebsd-security@freebsd.org References: <20010516092959.A42898@beheer2.iae.nl> <20010516155615.40395.qmail@web14503.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010516155615.40395.qmail@web14503.mail.yahoo.com>; from jedovaty@yahoo.com on Wed, May 16, 2001 at 08:56:15AM -0700 Organization: System Defenestrators Inc. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, May 16, 2001 at 08:56 -0700, Jano Lukac wrote: > > If your IP changes (e.g. in a PPP or PPPoE link), do you have > to rerun ipf/ipfw/natd everytime? Or is freebsd smart about > this (unlike the unnamed arctic semi-counterpart which uses > ipchains/iptables)? Since the original question was heavily crossposted and went to the ipfilter list as well, I would like to point out that ipf(4) has to be "pushed" when interfaces should change their parameters. Read "man 8 ipf" and look at the -y switch. Plus look at the notion of specifying 0.0.0.0/32 addresses in the numerous examples shipped with ipfilter. Read "man 8 ppp" for where to hook things in (ppp.link{up,down}, I assume). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed May 16 23:54: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from eniac.cable.net.co (eniac.cable.net.co [196.27.25.66]) by hub.freebsd.org (Postfix) with ESMTP id B431537B43E for ; Wed, 16 May 2001 23:53:30 -0700 (PDT) (envelope-from servicios@digitecnia.com) Received: from localhost ([209.88.49.106]) by eniac.cable.net.co (Post.Office MTA v3.5.3 release 223 ID# 637-71558U30000L25000S0V35) with ESMTP id co for ; Thu, 17 May 2001 01:58:33 -0500 X-Sender: servicios@digitecnia.com From: digitecnia.com To: freebsd-security@freebsd.org Date: Thu, 17 May 2001 01:53:48 -0500 Subject: Su negocio esta al aire?... o en el aire? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__38124568_6828,66" Message-Id: <20010517065330.B431537B43E@hub.freebsd.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a Multipart MIME message. ------=_NextPart_000_001__38124568_6828,66 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__38124568_6828,66 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5XRUJQQUNLIERJR0lURUNOSUE8L3RpdGxlPg0KPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9aXNvLTg4NTktMSI+DQo8U1RZTEU+DQo8IS0tDQphOmxpbmsgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOmFjdGl2ZSB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KYTpob3ZlciB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KLS0+DQo8L1NUWUxFPg0KPC9oZWFkPg0K DQo8Ym9keSA8Ym9keSBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTog MTAgcHQiIGJnY29sb3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiIGxpbms9IiMwMDAwOTki IHZsaW5rPSIjQ0NDQ0ZGIiBhbGluaz0iI0NDQ0NGRiINCiA+DQoNCjxwIGFsaWduPSJjZW50 ZXIiPg0KPGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL3d3dy5kaWdpdGVjbmlhLmNvbS9p bWFnZXMvMWEuZ2lmIiB3aWR0aD0iNDY4IiBoZWlnaHQ9IjYwIj48L3A+DQoNCjxwIGFsaWdu PSJjZW50ZXIiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuZGlnaXRlY25pYS5j b20vaW1hZ2VzL3dlYnBhY2tfMDEuZ2lmIiB3aWR0aD0iMTYwIiBoZWlnaHQ9IjQwIj48L3A+ DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPkVsIDxp PldFQlBBQ0s8L2k+Jm5ic3A7IGVzIHVuYSANCnNvbHVjafNuIGludGVncmFsIGNvbXB1ZXN0 YSBwb3IgbG9zIHNlcnZpY2lvcyBi4XNpY29zIG5lY2VzYXJpb3MgcGFyYSB0ZW5lciB1biAN CnNpdGlvIGVuIEludGVybmV0IGRlIHVuYSBmb3JtYSBy4XBpZGEsIGVjb27zbWljYSB5IHBy b2Zlc2lvbmFsLCBlc3RhIGNvbXB1ZXN0byANCnBvcjo8L2ZvbnQ+PC9wPg0KPHAgYWxpZ249 ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5Ob21icmUgZGUgRG9taW5pbzwvYj48 L2ZvbnQ+IFJlZ2lzdHJvIA0KcG9yIDEgYfFvJm5ic3A7IC0tIDxmb250IGNvbG9yPSIjRkZG RkZGIj4gPGEgaHJlZj0iaHR0cDovL3d3dy5zdS1lbXByZXNhLmNvbSI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+d3d3LnN1LWVtcHJlc2EuY29tPC9mb250PjwvYT48L2ZvbnQ+IC0tPC9w Pg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5EaXNl8W8gV2Vi PC9iPjwvZm9udD4gDQpQb3J0YWRhIGluaWNpYWwsIDUgcGFnaW5hcyBhZGljaW9uYWxlcywg bG9nb3RpcG8geSAyIEZvcm11bGFyaW9zPC9wPg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNv bG9yPSIjMDA2NkZGIj48Yj5Ib3N0aW5nIFdlYjwvYj48L2ZvbnQ+IDEgYfFvIGRlIHNlcnZp Y2lvIGluY2x1aWRvLCBjb24gMjAgTUIgZGUgZXNwYWNpbzwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij48Zm9udCBjb2xvcj0iIzAwNjZGRiI+PGI+NSBCdXpvbmVzIGRlIENvcnJlbyBFbGVjdHLz bmljbzwvYj48L2ZvbnQ+PC9wPg0KPGZvbnQgY29sb3I9IiNGRkZGMDAiPg0KPHAgYWxpZ249 ImxlZnQiPjwvZm9udD48Yj48Zm9udCBjb2xvcj0iIzAwNjZGRiI+VmFsb3I8L2ZvbnQ+IDQ5 MCBE82xhcmVzPC9iPjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGln bj0iY2VudGVyIj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGI+QWRpY2lvbmVzIGFsIFdFQlBB Q0s6PC9iPjwvZm9udD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAw MDAiPjxiPk51ZXZvISANClBsdWcgQ29tZXJjaWFsIDwvYj48L2ZvbnQ+Q29uc2lzdGUgZW4g dW4gcGFxdWV0ZSANCmFkaWNpb25hbCwgcXVlIHBlcm1pdGUgbGEgaW1wbGVtZW50YWNp824g ZGUgY29tZXJjaW8gZWxlY3Ry825pY28gZW4gc3Ugc2l0aW8gDQpXZWIuIEVzdGEgY29tcHVl c3RvIHBvciBlbCBzaXN0ZW1hIGRlIGNhdGFsb2dvIGVuIGztbmVhLCBjYXJyaXRvIGRlIGNv bXByYXMsIA0KbW9kdWxvIGRlIGFkbWluaXN0cmFjafNuIHkgdW4gY3Vyc28gdmlydHVhbCBk ZSBjb21lcmNpbyBlbGVjdHLzbmljby4gMSBh8W8gZGUgDQpzZXJ2aWNpbyBpbmNsdWlkby4g PGZvbnQgY29sb3I9IiNGRjAwMDAiPlZhbG9yIDIxMCBE82xhcmVzPC9mb250PjwvcD4NCjxw IGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+RGlzZfFvIGRlIFBhZ2luYSBh ZGljaW9uYWw6PC9mb250PiAzMCBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48 Zm9udCBjb2xvcj0iI0ZGMDAwMCI+Rm9ybXVsYXJpbyBjb24gZW52aW8gZGUgcmVzdWx0YWRv cyBhIHVuIA0KZW1haWw6PC9mb250PiAyNSBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJs ZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiMwMDY2RkYi PlNpIGVzdGEgaW50ZXJlc2FkbyBlbiBlbCBXRUJQQUNLLCBwb3IgDQpmYXZvciBsbGVuZSBl bCBzaWd1aWVudGUgZm9ybXVsYXJpbzo8L2ZvbnQ+PC9wPg0KDQogICAgICAgICAgPEZPUk0g YWN0aW9uPWh0dHA6Ly82My4xNjYuMTE3LjQxL3NlbmRtYWlsLmNmbSBtZXRob2Q9cG9zdD4N CiAgICAgICAgICAgIDxJTlBVVCANCiAgICAgIG5hbWU9ZW1haWx0byB0eXBlPWhpZGRlbiB2 YWx1ZT12ZW50YXNAZGlnaXRlY25pYS5jb20+DQogICAgICAgICAgICA8SU5QVVQgbmFtZT1l bWFpbGZyb20gDQogICAgICB0eXBlPWhpZGRlbiB2YWx1ZT13ZWJwYWNrPg0KICAgICAgICAg ICAgPElOUFVUIG5hbWU9ZW1haWxzdWJqZWN0IHR5cGU9aGlkZGVuIA0KICAgICAgdmFsdWU9 d2VicGFjaz4NCiAgICAgICAgICAgIDxJTlBVVCBuYW1lPWVtYWlsY29uZmlybSB0eXBlPWhp ZGRlbiANCiAgICAgIHZhbHVlPWh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vY29uZmlybWFj aW9uLmh0bT4NCjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogY29sbGFwc2UiIGJvcmRlcmNvbG9yPSIj MTExMTExIiB3aWR0aD0iMTAwJSIgaWQ9IkF1dG9OdW1iZXIxIj4NCiAgICA8dHI+DQogICAg ICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPk5vbWJy ZTwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1dCB0eXBlPSJ0ZXh0 IiBuYW1lPSJub21icmUiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0K ICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2NkZGIj5F bXByZXNhPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGlucHV0IHR5cGU9 InRleHQiIG5hbWU9ImVtcHJlc2EiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAg PHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2 NkZGIj5DaXVkYWQ8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj48aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iY2l1ZGFkIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+UGHtczwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1 dCB0eXBlPSJ0ZXh0IiBuYW1lPSJwYWlzIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+RGlyZWNjafNuPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+ PGlucHV0IHR5cGU9InRleHQiIG5hbWU9ImRpcmVjY2lvbiIgc2l6ZT0iMjAiPjwvdGQ+DQog ICAgPC90cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMwMDY2RkYiPlRlbOlmb25vPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lk dGg9Ijg0JSI+PGlucHV0IHR5cGU9InRleHQiIG5hbWU9InRlbGVmb25vIiBzaXplPSIyMCI+ PC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+ZW1haWw8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0 ZCB3aWR0aD0iODQlIj48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjIw Ij48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrIiB2YWx1ZT0i T04iPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+V0VCUEFDSzwvZm9u dD48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrcGx1Z2NvbWVy Y2lhbCIgdmFsdWU9Ik9OIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYi PldFQlBBQ0sgDQogICAgICArIFBsdWcgQ29tZXJjaWFsPC9mb250PjwvdGQ+DQogICAgPC90 cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+DQogIDxpbnB1dCB0eXBlPSJz dWJtaXQiIHZhbHVlPSJPSyIgbmFtZT0iQjEiIHN0eWxlPSJmbG9hdDogcmlnaHQiPjxwPjwv cD4NCiAgPHA+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj4NCiAgICAgIDxibG9ja3F1 b3RlPg0KJm5ic3A7PHA+PGZvbnQgc2l6ZT0iMiI+Tm90YTogRXMgcG9zaWJsZSBxdWUgZXN0 ZSBmb3JtdWxhcmlvIG5vIGZ1bmNpb25lIGNvcnJlY3RhbWVudGUgDQplbiBhbGd1bm9zIHBy b2dyYW1hcyBkZSBjb3JyZW8gDQogICAgICBlbGVjdHLzbmljby4gUHVlZGUgY29tcGxldGFy bG8gZW4gbO1uZWEgZW46IGh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vd2VicGFjay5odG0g PC9mb250PjwvcD4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvdGQ+DQogICAgPC90 cj4NCiAgPC90YWJsZT4NCiAgPHAgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICA8L3A+ DQo8L2Zvcm0+DQo8cCBhbGlnbj0ibGVmdCI+PGI+byBjb250YWN0YXJzZSBhIDogdmVudGFz QGRpZ2l0ZWNuaWEuY29tPC9iPjwvcD4NCg0KPHAgYWxpZ249ImxlZnQiPiZuYnNwOzwvcD4N Cg0KPHAgYWxpZ249ImNlbnRlciI+d3d3LmRpZ2l0ZWNuaWEuY29tPC9wPg0KPHAgYWxpZ249 ImNlbnRlciI+PGZvbnQgc2l6ZT0iMSI+U0kgTk8gREVTRUEgUkVDSUJJUiBPRkVSVEFTIERF IERJR0lURUNOSUEsIA0KQ09OVEVTVEUgRVNURSBFTUFJTCBDT04gTEEgUEFMQUJSQSBSRU1P VkVSIENPTU8gQVNVTlRPLjwvZm9udD48L3A+DQoNCjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_000_001__38124568_6828,66-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 2: 5:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by hub.freebsd.org (Postfix) with ESMTP id A492A37B422 for ; Thu, 17 May 2001 02:05:54 -0700 (PDT) (envelope-from sparvu@beta.hut.fi) Received: from beta.hut.fi (sparvu@beta.hut.fi [130.233.224.51]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id MAA02133 for ; Thu, 17 May 2001 12:05:53 +0300 (EET DST) Date: Thu, 17 May 2001 12:05:47 +0300 (EET DST) From: Stefan Parvu To: freebsd-security@freebsd.org Subject: FBI and EU plans Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org An interesting link: http://www.statewatch.org/soseurope.htm stefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 8: 4:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from alcatraz.iptelecom.net.ua (alcatraz.iptelecom.net.ua [212.9.224.15]) by hub.freebsd.org (Postfix) with ESMTP id 195DC37B422 for ; Thu, 17 May 2001 08:03:57 -0700 (PDT) (envelope-from seorge@rostokgroup.com) Received: from dialup7-45.iptelecom.net.ua (dialup7-45.iptelecom.net.ua [212.9.227.173]) by alcatraz.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id SAA46020 for ; Thu, 17 May 2001 18:03:39 +0300 (EEST) (envelope-from seorge@rostokgroup.com) Date: Thu, 17 May 2001 18:05:26 +0300 From: Seorge X-Mailer: The Bat! (v1.44) Reply-To: Seorge X-Priority: 3 (Normal) Message-ID: <8130809667.20010517180526@myhost.com> To: freebsd-security@FreeBSD.ORG Subject: Cofiguring ports in firewall... A problem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The System is FreeBSD 4.3 There is an internal network of the type: 192.168.1.0 with its own DNS There is an external IP with its own DNS natd is started ipfrw is started The question is how to let users from local network via all protocols (http, ftp, mail, etc) while closing all ports excepting several ones from external access (20, 21, 22, 53, 80, 110). Now it is made as follows: (the kernel closes all ports as default, rl0 - external interface, rl1 - internal) If I put a comment on the rule 2000 and take the comment off the second 2000 and the rule No 4000 in rc.firewall, it does not work at all. How to solve this problem? What should I configure and how to get it working? //rc.conf ############################################################# network_interfaces="lo0 rl0 rl1" ifconfig_lo0="inet 127.0.0.1" ifconfig_rl0="inet 212.212.212.5 netmask 255.255.255.240" ifconfig_rl1="inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255" hostname="name.domain.net" named_enable="YES" gateway_enable="YES" defaultrouter="212.212.212.1" firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_type="EE" firewall_quiet="NO" natd_program="/sbin/natd" natd_enable="YES" natd_interface="rl0" natd_flags="-f /etc/natd.conf" tcp_extensions="NO" tcp_drop_synfin="YES" icmp_drop_redirect="YES" icmp_log_redirect="YES" ########################################################## //natd.conf ########################################################## log no deny_incoming no same_ports yes use_sockets yes verbose no port natd unregistered_only yes ########################################################## //rc.firewall ########################################################## case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} fi ;; esac ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 case ${firewall_type} in [Ee][Ee]) ${fwcmd} add 400 pass udp from any to any 33434-33523 ${fwcmd} add 500 deny ICMP from any to any frag ${fwcmd} add 600 pass ICMP from any to any ${fwcmd} add 700 pass tcp from any to any 20,21,25,53,80,110,119,443,3128 ${fwcmd} add 800 pass tcp from any 20,21,25,53,80,110,119,443,3128 to any ${fwcmd} add 1000 pass all from any to any via rl1 ${fwcmd} add 1100 allow all from any to any via rl1 ${fwcmd} add 2000 pass all from any to any via rl0 #${fwcmd} add 2000 pass all from any 20,21,22,25,53,80,110,119,443,3128,8668 to any via rl0 #${fwcmd} add 4000 pass all from any to any 20,21,22,25,53,80,110,119,443,3128,8668 via rl0 ;; [Uu][Nn][Kk][Nn][Oo][Ww][Nn]) ;; *) if [ -r "${firewall_type}" ]; then ${fwcmd} ${firewall_flags} ${firewall_type} fi ;; esac ########################################################## Looking forward to hearing from you soon, Best regards, Seorge mailto:seorge@rostokgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 10:55:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from stella.pyramus.com (stella.pyramus.com [206.129.206.3]) by hub.freebsd.org (Postfix) with ESMTP id 7095237B422 for ; Thu, 17 May 2001 10:55:18 -0700 (PDT) (envelope-from turtle@pyramus.com) Received: from pyramus.com (jerry.pyramus.com [206.129.206.8]) by stella.pyramus.com (8.9.3/8.9.3) with ESMTP id KAA63227 for ; Thu, 17 May 2001 10:58:22 -0700 (PDT) (envelope-from turtle@pyramus.com) Message-ID: <3B041115.F4C3DF78@pyramus.com> Date: Thu, 17 May 2001 10:57:41 -0700 From: Bill Mitcheson X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: Port 1023. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We noticed unauthorized activity yesterday. After investigating we found that there was someone coming in from Asia and they were trying to access port 1023. I could not find much info on that port and was wondering if anyone knows of that port, what common attacks to that port are, and how to stop future attacks? Bill Mitcheson. Network Administrator, Pyramus Online. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 11:18:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from q.closedsrc.org (ip233.gte15.rb1.bel.nwlink.com [209.20.244.233]) by hub.freebsd.org (Postfix) with ESMTP id E9BDA37B422 for ; Thu, 17 May 2001 11:18:08 -0700 (PDT) (envelope-from lplist@closedsrc.org) Received: by q.closedsrc.org (Postfix, from userid 1003) id 1ADE255407; Thu, 17 May 2001 11:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by q.closedsrc.org (Postfix) with ESMTP id 0AF9451610; Thu, 17 May 2001 11:09:07 -0700 (PDT) Date: Thu, 17 May 2001 11:09:07 -0700 (PDT) From: Linh Pham To: Bill Mitcheson Cc: Subject: Re: Port 1023. In-Reply-To: <3B041115.F4C3DF78@pyramus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2001-05-17, Bill Mitcheson scribbled: # We noticed unauthorized activity yesterday. After investigating we found # that there was someone coming in from Asia and they were trying to # access port 1023. I could not find much info on that port and was # wondering if anyone knows of that port, what common attacks to that port # are, and how to stop future attacks? If I remember correctly, port 1023/tcp is a reserved port set aside... port 1022/tcp and 1024/tcp as well. I don't know of a program that uses 1023/tcp... sorry :( -- Linh Pham [lplist@closedsrc.org] // 404b - Brain not found To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 11:18:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id 1084537B43F for ; Thu, 17 May 2001 11:18:27 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f4HIHq020224; Thu, 17 May 2001 14:17:52 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Thu, 17 May 2001 14:17:48 -0400 (EDT) From: Rob Simmons To: Bill Mitcheson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Port 1023. In-Reply-To: <3B041115.F4C3DF78@pyramus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Were you running any services on that port? The command "sockstat" should tell you if there is anything listening on that port. If there is nothing listening on the port, you don't have to worry about them poking at that port. Robert Simmons Systems Administrator http://www.wlcg.com/ On Thu, 17 May 2001, Bill Mitcheson wrote: > We noticed unauthorized activity yesterday. After investigating we found > that there was someone coming in from Asia and they were trying to > access port 1023. I could not find much info on that port and was > wondering if anyone knows of that port, what common attacks to that port > are, and how to stop future attacks? > > Bill Mitcheson. > Network Administrator, > Pyramus Online. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7BBXQv8Bofna59hYRAwgNAJ0WjqRSOsNgHibg59s7JJjPOovwAACeNExx xntXYcmqMvzu6ER22/biI5I= =WrEW -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 12: 1:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from stella.pyramus.com (stella.pyramus.com [206.129.206.3]) by hub.freebsd.org (Postfix) with ESMTP id CCE6537B423 for ; Thu, 17 May 2001 12:01:07 -0700 (PDT) (envelope-from turtle@pyramus.com) Received: from pyramus.com (jerry.pyramus.com [206.129.206.8]) by stella.pyramus.com (8.9.3/8.9.3) with ESMTP id MAA63722 for ; Thu, 17 May 2001 12:04:14 -0700 (PDT) (envelope-from turtle@pyramus.com) Message-ID: <3B042085.39247322@pyramus.com> Date: Thu, 17 May 2001 12:03:33 -0700 From: Bill Mitcheson X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: New info on our Port 1023 problem. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I ran sockstat and came up with the following: root ypserv 117 5 tcp *.1023 *.* Ypserv was also running on a couple of other ports as UDP instead of TCP. Is this bad? Rob Simmons wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Were you running any services on that port? The command "sockstat" should > tell you if there is anything listening on that port. If there is nothing > listening on the port, you don't have to worry about them poking at that > port. > > Robert Simmons > Systems Administrator > http://www.wlcg.com/ > > On Thu, 17 May 2001, Bill Mitcheson wrote: > > > We noticed unauthorized activity yesterday. After investigating we found > > that there was someone coming in from Asia and they were trying to > > access port 1023. I could not find much info on that port and was > > wondering if anyone knows of that port, what common attacks to that port > > are, and how to stop future attacks? > > > > Bill Mitcheson. > > Network Administrator, > > Pyramus Online. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.5 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE7BBXQv8Bofna59hYRAwgNAJ0WjqRSOsNgHibg59s7JJjPOovwAACeNExx > xntXYcmqMvzu6ER22/biI5I= > =WrEW > -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 12: 2:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from ambar.ofermundo.com.ar (h066060007247.isol.net.ar [66.60.7.247]) by hub.freebsd.org (Postfix) with ESMTP id 9F8E337B422 for ; Thu, 17 May 2001 12:02:09 -0700 (PDT) (envelope-from freebsd@grunblatt.com.ar) Received: from dialup202.icatel.net (dialup202.icatel.net [200.47.39.202]) by ambar.ofermundo.com.ar (8.9.3/8.8.7) with ESMTP id QAA08662; Thu, 17 May 2001 16:01:34 -0300 Date: Thu, 17 May 2001 19:02:48 -0300 (ART) From: Daniel X-X-Sender: To: Linh Pham Cc: Bill Mitcheson , Subject: Re: Port 1023. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 17 May 2001, Linh Pham wrote: mountd uses 1023/tcp: # sockstat ***cut*** root mountd 243 7 udp4 *:1020 *:* root mountd 243 8 tcp4 *:1022 *:* root mountd 243 11 udp4 *:1021 *:* root mountd 243 12 tcp4 *:1023 *:* ***cut*** Bill: may be a tcpwrapper would help you d.- > Date: Thu, 17 May 2001 11:09:07 -0700 (PDT) > From: Linh Pham > To: Bill Mitcheson > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: Port 1023. > > On 2001-05-17, Bill Mitcheson scribbled: > > # We noticed unauthorized activity yesterday. After investigating we found > # that there was someone coming in from Asia and they were trying to > # access port 1023. I could not find much info on that port and was > # wondering if anyone knows of that port, what common attacks to that port > # are, and how to stop future attacks? > > If I remember correctly, port 1023/tcp is a reserved port set aside... > port 1022/tcp and 1024/tcp as well. > > I don't know of a program that uses 1023/tcp... sorry :( > > -- > Linh Pham > [lplist@closedsrc.org] > > // 404b - Brain not found > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 12: 3:30 2001 Delivered-To: freebsd-security@freebsd.org Received: from prox.centtech.com (moat2.centtech.com [206.196.95.21]) by hub.freebsd.org (Postfix) with ESMTP id A043637B422 for ; Thu, 17 May 2001 12:03:26 -0700 (PDT) (envelope-from anderson@centtech.com) Received: (from smap@localhost) by prox.centtech.com (8.9.3+Sun/8.9.3) id OAA28136; Thu, 17 May 2001 14:03:25 -0500 (CDT) Received: from proton.centtech.com(10.177.173.77) by prox via smap (V2.1+anti-relay+anti-spam) id xma028134; Thu, 17 May 01 14:03:21 -0500 Message-ID: <3B042079.AC957064@centtech.com> Date: Thu, 17 May 2001 14:03:21 -0500 From: Eric Anderson Reply-To: anderson@centtech.com Organization: Centaur Technology X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Mitcheson Cc: freebsd-security@freebsd.org Subject: Re: New info on our Port 1023 problem. References: <3B042085.39247322@pyramus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's typically pretty insecure. If you aren't running NIS/YP on your machines, you can get rid of it. If you do need it, you should be filtering it with ipfw or ipfilter. Eric Bill Mitcheson wrote: > > I ran sockstat and came up with the following: > > root ypserv 117 5 tcp *.1023 *.* > > Ypserv was also running on a couple of other ports as UDP instead of TCP. Is > this bad? > > Rob Simmons wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > Were you running any services on that port? The command "sockstat" should > > tell you if there is anything listening on that port. If there is nothing > > listening on the port, you don't have to worry about them poking at that > > port. > > > > Robert Simmons > > Systems Administrator > > http://www.wlcg.com/ > > > > On Thu, 17 May 2001, Bill Mitcheson wrote: > > > > > We noticed unauthorized activity yesterday. After investigating we found > > > that there was someone coming in from Asia and they were trying to > > > access port 1023. I could not find much info on that port and was > > > wondering if anyone knows of that port, what common attacks to that port > > > are, and how to stop future attacks? > > > > > > Bill Mitcheson. > > > Network Administrator, > > > Pyramus Online. > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.0.5 (FreeBSD) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQE7BBXQv8Bofna59hYRAwgNAJ0WjqRSOsNgHibg59s7JJjPOovwAACeNExx > > xntXYcmqMvzu6ER22/biI5I= > > =WrEW > > -----END PGP SIGNATURE----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- ------------------------------------------------------------------------------- Eric Anderson anderson@centtech.com Centaur Technology (512) 418-5792 The idea is to die young as late as possible. ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 12: 9: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from poontang.schulte.org (poontang.schulte.org [209.134.156.197]) by hub.freebsd.org (Postfix) with ESMTP id 75E8E37B423 for ; Thu, 17 May 2001 12:08:56 -0700 (PDT) (envelope-from christopher@schulte.org) Received: from schulte-laptop.schulte.org (nb40.netbriefings.com [64.183.199.40]) by poontang.schulte.org (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4HJ8iWB022941; Thu, 17 May 2001 14:08:45 -0500 (CDT) Message-Id: <5.1.0.14.0.20010517140530.034218f8@pop.schulte.org> X-Sender: schulte@pop.schulte.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 May 2001 14:07:43 -0500 To: anderson@centtech.com, Bill Mitcheson From: Christopher Schulte Subject: Re: New info on our Port 1023 problem. Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <3B042079.AC957064@centtech.com> References: <3B042085.39247322@pyramus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don't forget /var/yp/securenets man ypserv(8) will help you. If NIS is not used, kill it. In any event, do a full service audit and turn off all unused services. This is a basic sysadmin principle. At 02:03 PM 5/17/2001 -0500, Eric Anderson wrote: >It's typically pretty insecure. If you aren't running NIS/YP on your >machines, you can get rid of it. If you do need it, you should be >filtering it with ipfw or ipfilter. > >Eric > > > >Bill Mitcheson wrote: > > > > I ran sockstat and came up with the following: > > > > root ypserv 117 5 tcp *.1023 *.* > > > > Ypserv was also running on a couple of other ports as UDP instead of > TCP. Is > > this bad? > > > > Rob Simmons wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: RIPEMD160 > > > > > > Were you running any services on that port? The command "sockstat" > should > > > tell you if there is anything listening on that port. If there is > nothing > > > listening on the port, you don't have to worry about them poking at that > > > port. > > > > > > Robert Simmons > > > Systems Administrator > > > http://www.wlcg.com/ > > > > > > On Thu, 17 May 2001, Bill Mitcheson wrote: > > > > > > > We noticed unauthorized activity yesterday. After investigating we > found > > > > that there was someone coming in from Asia and they were trying to > > > > access port 1023. I could not find much info on that port and was > > > > wondering if anyone knows of that port, what common attacks to that > port > > > > are, and how to stop future attacks? > > > > > > > > Bill Mitcheson. > > > > Network Administrator, > > > > Pyramus Online. > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.0.5 (FreeBSD) > > > Comment: For info see http://www.gnupg.org > > > > > > iD8DBQE7BBXQv8Bofna59hYRAwgNAJ0WjqRSOsNgHibg59s7JJjPOovwAACeNExx > > > xntXYcmqMvzu6ER22/biI5I= > > > =WrEW > > > -----END PGP SIGNATURE----- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > >-- >------------------------------------------------------------------------------- >Eric Anderson anderson@centtech.com Centaur Technology (512) >418-5792 >The idea is to die young as late as possible. >------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 15:20:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.noyznet.com (bdsl.66.12.97.75.gte.net [66.12.97.75]) by hub.freebsd.org (Postfix) with ESMTP id 8F71D37B42C for ; Thu, 17 May 2001 15:20:10 -0700 (PDT) (envelope-from bandit@noyznet.com) Received: from d850 (bdsl.66.12.97.76.gte.net [66.12.97.76]) by ns1.noyznet.com (8.10.1/8.8.7) with SMTP id f4HFGZG03716 for ; Thu, 17 May 2001 08:16:35 -0700 Message-ID: <000a01c0df1f$cf2543c0$4c610c42@d850> From: "Bandit" To: Subject: copyright violation Date: Thu, 17 May 2001 15:22:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0DEE5.22A04620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0DEE5.22A04620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to inform you that a IRC Network is useing your domain = name. you should put a stop to this unless if you are actually with the = group. Please keep this email classified thanks John Aka (Bandit) here is the violation. =BB=BB=BB=BB=BB=BB /Whois info for: FreeBSD =AB=AB=AB=AB=AB=AB =BB=BBAddress=AB=AB Services@freebsd.org =BB=BBReal Name=AB=AB Look at how sexy iam... =BB=BBServer=AB=AB services.wildabar.net =BB=BBChannels=AB=AB @#sweden @#CyberHackers +#services @#gamez =BB=BB=BB=BB=BB=BB End of /Whois for: FreeBSD =AB=AB=AB=AB=AB=AB P.S. i am puttin up a BSD box and it will host my webpage may i have = your permission to run your BSD banners. the powered by ones if so = please email back thanks ------=_NextPart_000_0007_01C0DEE5.22A04620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I would like to inform you that a IRC = Network is=20 useing your domain name. you should put a stop to this unless if you are = actually with the group. Please keep this email classified thanks John = Aka=20 (Bandit)
 
here is the violation.
 
=BB=BB=BB=BB=BB=BB /Whois info for: = FreeBSD=20 =AB=AB=AB=AB=AB=AB
=BB=BBAddress=AB=AB Services@freebsd.org
=BB=BBRe= al Name=AB=AB=20 Look at how sexy iam...
=BB=BBServer=AB=AB = services.wildabar.net
=BB=BBChannels=AB=AB=20 @#sweden @#CyberHackers +#services @#gamez
=BB=BB=BB=BB=BB=BB End of = /Whois for: FreeBSD=20 =AB=AB=AB=AB=AB=AB
 
P.S. i am puttin up a BSD box and it = will host my=20 webpage may i have your permission to run your BSD banners. the powered = by ones=20 if so please email back thanks
------=_NextPart_000_0007_01C0DEE5.22A04620-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 15:25:40 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.noyznet.com (bdsl.66.12.97.75.gte.net [66.12.97.75]) by hub.freebsd.org (Postfix) with ESMTP id A5C2237B422 for ; Thu, 17 May 2001 15:25:36 -0700 (PDT) (envelope-from bandit@noyznet.com) Received: from d850 (bdsl.66.12.97.76.gte.net [66.12.97.76]) by ns1.noyznet.com (8.10.1/8.8.7) with SMTP id f4HFM1G03727 for ; Thu, 17 May 2001 08:22:01 -0700 Message-ID: <001601c0df20$919ae950$4c610c42@d850> From: "Bandit" To: Subject: Extra info on the Copyright Violators Date: Thu, 17 May 2001 15:27:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C0DEE5.E5209A10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C0DEE5.E5209A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sorry i forgot to give you the irc server addy it is irc.wildabar.net=20 ------=_NextPart_000_0013_01C0DEE5.E5209A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
sorry i forgot to give you the irc = server=20 addy
it is irc.wildabar.net =
------=_NextPart_000_0013_01C0DEE5.E5209A10-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 15:26: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.fpsn.net (mail.fpsn.net [63.224.69.57]) by hub.freebsd.org (Postfix) with ESMTP id 2203837B423 for ; Thu, 17 May 2001 15:25:56 -0700 (PDT) (envelope-from cfaber@fpsn.net) Received: from fpsn.net (control.fpsn.net [63.224.69.60]) by mail.fpsn.net (8.9.3/8.9.3) with ESMTP id QAA01716; Thu, 17 May 2001 16:25:44 -0600 (MDT) (envelope-from cfaber@fpsn.net) Message-ID: <3B044FCE.312B15B1@fpsn.net> Date: Thu, 17 May 2001 16:25:18 -0600 From: Colin Faber Reply-To: cfaber@fpsn.net Organization: fpsn.net, Inc. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bandit Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: copyright violation References: <000a01c0df1f$cf2543c0$4c610c42@d850> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org What does this have to do with security concerns? > Bandit wrote: > > I would like to inform you that a IRC Network is useing your domain > name. you should put a stop to this unless if you are actually with > the group. Please keep this email classified thanks John Aka (Bandit) > > here is the violation. > > »»»»»» /Whois info for: FreeBSD «««««« > »»Address«« Services@freebsd.org > »»Real Name«« Look at how sexy iam... > »»Server«« services.wildabar.net > »»Channels«« @#sweden @#CyberHackers +#services @#gamez > »»»»»» End of /Whois for: FreeBSD «««««« > > P.S. i am puttin up a BSD box and it will host my webpage may i have > your permission to run your BSD banners. the powered by ones if so > please email back thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 15:29: 5 2001 Delivered-To: freebsd-security@freebsd.org Received: from bilbo.w-link.net (bilbo.w-link.net [206.98.114.20]) by hub.freebsd.org (Postfix) with ESMTP id CF75537B628 for ; Thu, 17 May 2001 15:28:54 -0700 (PDT) (envelope-from miesterio@w-link.net) Received: from c91133c (dial054.w-link.net [206.98.114.83]) by bilbo.w-link.net (8.9.3/8.9.3) with SMTP id PAA28641; Thu, 17 May 2001 15:25:06 -0700 (PDT) Message-ID: <003501c0df1f$e87473a0$0c0d0041@home> Reply-To: "Zachary Gates" From: "Zachary Gates" To: , "Bandit" Cc: References: <000a01c0df1f$cf2543c0$4c610c42@d850> <3B044FCE.312B15B1@fpsn.net> Subject: Re: copyright violation Date: Thu, 17 May 2001 15:22:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org i was just getting ready to ask that one ----- Original Message ----- From: "Colin Faber" To: "Bandit" Cc: Sent: Thursday, May 17, 2001 3:25 PM Subject: Re: copyright violation What does this have to do with security concerns? > Bandit wrote: > > I would like to inform you that a IRC Network is useing your domain > name. you should put a stop to this unless if you are actually with > the group. Please keep this email classified thanks John Aka (Bandit) > > here is the violation. > > »»»»»» /Whois info for: FreeBSD «««««« > »»Address«« Services@freebsd.org > »»Real Name«« Look at how sexy iam... > »»Server«« services.wildabar.net > »»Channels«« @#sweden @#CyberHackers +#services @#gamez > »»»»»» End of /Whois for: FreeBSD «««««« > > P.S. i am puttin up a BSD box and it will host my webpage may i have > your permission to run your BSD banners. the powered by ones if so > please email back thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 16:48:17 2001 Delivered-To: freebsd-security@freebsd.org Received: from casimir.physics.purdue.edu (casimir.physics.purdue.edu [128.210.146.111]) by hub.freebsd.org (Postfix) with ESMTP id 7FDD437B422; Thu, 17 May 2001 16:48:15 -0700 (PDT) (envelope-from will@physics.purdue.edu) Received: by casimir.physics.purdue.edu (Postfix, from userid 1000) id 4D36E18A47; Thu, 17 May 2001 18:48:02 -0500 (EST) Date: Thu, 17 May 2001 18:48:02 -0500 From: Will Andrews To: Bandit Cc: Jordan Hubbard Subject: Re: Extra info on the Copyright Violators Message-ID: <20010517184802.K26877@casimir.physics.purdue.edu> Reply-To: Will Andrews References: <001601c0df20$919ae950$4c610c42@d850> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <001601c0df20$919ae950$4c610c42@d850>; from bandit@noyznet.com on Thu, May 17, 2001 at 03:27:33PM -0700 X-Operating-System: Linux 2.2.18 sparc64 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org On Thu, May 17, 2001 at 03:22:07PM -0700, Bandit wrote: > I would like to inform you that a IRC Network is useing your domain > name. you should put a stop to this unless if you are actually with > the group. Please keep this email classified thanks John Aka (Bandit) > here is the violation. > > ?????? /Whois info for: FreeBSD ?????? > ??Address?? Services@freebsd.org > ??Real Name?? Look at how sexy iam... > ??Server?? services.wildabar.net > ??Channels?? @#sweden @#CyberHackers +#services @#gamez > ?????? End of /Whois for: FreeBSD ?????? > > P.S. i am puttin up a BSD box and it will host my webpage may i have > your permission to run your BSD banners. the powered by ones if so > please email back thanks On Thu, May 17, 2001 at 03:27:33PM -0700, Bandit wrote: > sorry i forgot to give you the irc server addy > it is irc.wildabar.net This has nothing to do with security. If you have copyright concerns, address them to FreeBSD's PR guy, Jordan Hubbard . So I've Cc:'d him. If you ask me, that an IRC network is using FreeBSD.org's domain name doesn't constitute copyright violation, particularly since it doesn't resolve to anything belonging to them. Regardless, perhaps a little visit might succeed in persuading them to remove the name. Also, I don't think you need permission to use any of the FreeBSD banners available on www.FreeBSD.org, unless you are going to alter them in some way. Then you'll almost certainly need Marshall Kirk McKusick's permission. See http://www.FreeBSD.org/copyright/ for more information. -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 16:59:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from awww.jeah.net (awww.jeah.net [216.111.239.130]) by hub.freebsd.org (Postfix) with ESMTP id 410B637B423 for ; Thu, 17 May 2001 16:59:37 -0700 (PDT) (envelope-from chris@awww.jeah.net) Received: (from chris@localhost) by awww.jeah.net (8.11.3/8.11.3) id f4HNvSp13730 for freebsd-security@freebsd.org; Thu, 17 May 2001 18:57:28 -0500 (CDT) (envelope-from chris) Date: Thu, 17 May 2001 18:57:28 -0500 (CDT) From: Chris Byrnes Message-Id: <200105172357.f4HNvSp13730@awww.jeah.net> To: freebsd-security@freebsd.org Subject: Re: Extra info on the Copyright Violators Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org I honestly think the post was nothing more than an out-of-the-ordinary spam, and all the attention we're giving it is exactly the intention. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 17: 1:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from euphoria.digitalextreme.org (euphoria.digitalextreme.org [204.212.149.31]) by hub.freebsd.org (Postfix) with SMTP id 6D34D37B423 for ; Thu, 17 May 2001 17:01:54 -0700 (PDT) (envelope-from subscribed@de-net.org) Received: (qmail 12294 invoked by uid 504); 17 May 2001 16:57:37 -0000 Received: from unknown (HELO extremist) (204.212.149.57) by euphoria.digitalextreme.org with SMTP; 17 May 2001 16:57:37 -0000 From: "Dan Graaff" To: "Zachary Gates" , , "Bandit" Cc: Subject: RE: copyright violation Date: Thu, 17 May 2001 17:01:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <003501c0df1f$e87473a0$0c0d0041@home> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org and the price of beer in chine too.. dont forget that -Dan Graaff / Digital The DE-Network Majority Owner and Founder http://www.digitalextreme.org (Main) http://www.de-network.com (Hosting) -----Original Message----- From: owner-freebsd-security@FreeBSD.ORG [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Zachary Gates Sent: Thursday, May 17, 2001 3:23 PM To: cfaber@fpsn.net; Bandit Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: copyright violation i was just getting ready to ask that one ----- Original Message ----- From: "Colin Faber" To: "Bandit" Cc: Sent: Thursday, May 17, 2001 3:25 PM Subject: Re: copyright violation What does this have to do with security concerns? > Bandit wrote: > > I would like to inform you that a IRC Network is useing your domain > name. you should put a stop to this unless if you are actually with > the group. Please keep this email classified thanks John Aka (Bandit) > > here is the violation. > > »»»»»» /Whois info for: FreeBSD «««««« > »»Address«« Services@freebsd.org > »»Real Name«« Look at how sexy iam... > »»Server«« services.wildabar.net > »»Channels«« @#sweden @#CyberHackers +#services @#gamez > »»»»»» End of /Whois for: FreeBSD «««««« > > P.S. i am puttin up a BSD box and it will host my webpage may i have > your permission to run your BSD banners. the powered by ones if so > please email back thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 18:16:42 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id A8A7237B422 for ; Thu, 17 May 2001 18:16:37 -0700 (PDT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (on@banyan.cs.ait.ac.th [192.41.170.5]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id IAA08676; Fri, 18 May 2001 08:13:48 +0700 (GMT+0700) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.8.5/8.8.5) id IAA18654; Fri, 18 May 2001 08:16:32 +0700 (ICT) Date: Fri, 18 May 2001 08:16:32 +0700 (ICT) Message-Id: <200105180116.IAA18654@banyan.cs.ait.ac.th> X-Authentication-Warning: banyan.cs.ait.ac.th: on set sender to on@banyan.cs.ait.ac.th using -f From: Olivier Nicole To: rsimmons@wlcg.com Cc: turtle@pyramus.com, freebsd-security@FreeBSD.ORG In-reply-to: (message from Rob Simmons on Thu, 17 May 2001 14:17:48 -0400 (EDT)) Subject: Re: Port 1023. References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org It seems 1023 could be NIS server. Olivier > Were you running any services on that port? The command "sockstat" should > tell you if there is anything listening on that port. If there is nothing > listening on the port, you don't have to worry about them poking at that > port. > > Robert Simmons > Systems Administrator > http://www.wlcg.com/ > > On Thu, 17 May 2001, Bill Mitcheson wrote: > > > We noticed unauthorized activity yesterday. After investigating we found > > that there was someone coming in from Asia and they were trying to > > access port 1023. I could not find much info on that port and was > > wondering if anyone knows of that port, what common attacks to that port > > are, and how to stop future attacks? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 18:17:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.fpsn.net (mail.fpsn.net [63.224.69.57]) by hub.freebsd.org (Postfix) with ESMTP id 9D9AE37B423 for ; Thu, 17 May 2001 18:17:43 -0700 (PDT) (envelope-from cfaber@fpsn.net) Received: from fpsn.net (control.fpsn.net [63.224.69.60]) by mail.fpsn.net (8.9.3/8.9.3) with ESMTP id TAA02374; Thu, 17 May 2001 19:17:36 -0600 (MDT) (envelope-from cfaber@fpsn.net) Message-ID: <3B047819.A12DB503@fpsn.net> Date: Thu, 17 May 2001 19:17:13 -0600 From: Colin Faber Reply-To: cfaber@fpsn.net Organization: fpsn.net, Inc. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Graaff Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: copyright violation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org heh, They have beer in china now?! Dan Graaff wrote: > > and the price of beer in chine too.. dont forget that > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 18:19:40 2001 Delivered-To: freebsd-security@freebsd.org Received: from euphoria.digitalextreme.org (euphoria.digitalextreme.org [204.212.149.31]) by hub.freebsd.org (Postfix) with SMTP id 49FE737B423 for ; Thu, 17 May 2001 18:19:38 -0700 (PDT) (envelope-from subscribed@de-net.org) Received: (qmail 13469 invoked by uid 504); 17 May 2001 18:15:21 -0000 Received: from unknown (HELO extremist) (204.212.149.57) by euphoria.digitalextreme.org with SMTP; 17 May 2001 18:15:21 -0000 From: "Dan Graaff" To: Cc: Subject: RE: copyright violation Date: Thu, 17 May 2001 18:18:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3B047819.A12DB503@fpsn.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org -----Original Message----- From: Colin Faber [mailto:cfaber@fpsn.net] Sent: Thursday, May 17, 2001 6:17 PM To: Dan Graaff Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: copyright violation heh, They have beer in china now?! Dan Graaff wrote: > > and the price of beer in chine too.. dont forget that > Yeah, its called Bud Rice To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 18:24:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from bilbo.w-link.net (bilbo.w-link.net [206.98.114.20]) by hub.freebsd.org (Postfix) with ESMTP id 0C2CD37B423 for ; Thu, 17 May 2001 18:24:46 -0700 (PDT) (envelope-from miesterio@w-link.net) Received: from c91133c (dial054.w-link.net [206.98.114.83]) by bilbo.w-link.net (8.9.3/8.9.3) with SMTP id SAA00800; Thu, 17 May 2001 18:21:13 -0700 (PDT) Message-ID: <000b01c0df38$7e6e62e0$0c0d0041@home> Reply-To: "Zachary Gates" From: "Zachary Gates" To: , "Dan Graaff" Cc: References: <3B047819.A12DB503@fpsn.net> Subject: Re: copyright violation Date: Thu, 17 May 2001 18:18:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org mmmmmm beeeeeeeerrrr ----- Original Message ----- From: "Colin Faber" To: "Dan Graaff" Cc: Sent: Thursday, May 17, 2001 6:17 PM Subject: Re: copyright violation heh, They have beer in china now?! Dan Graaff wrote: > > and the price of beer in chine too.. dont forget that > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu May 17 18:34:57 2001 Delivered-To: freebsd-security@freebsd.org Received: from euphoria.digitalextreme.org (euphoria.digitalextreme.org [204.212.149.31]) by hub.freebsd.org (Postfix) with SMTP id 83A5E37B422 for ; Thu, 17 May 2001 18:34:54 -0700 (PDT) (envelope-from subscribed@de-net.org) Received: (qmail 13742 invoked by uid 504); 17 May 2001 18:30:38 -0000 Received: from unknown (HELO extremist) (204.212.149.57) by euphoria.digitalextreme.org with SMTP; 17 May 2001 18:30:38 -0000 From: "Dan Graaff" To: "Zachary Gates" , Cc: Subject: RE: copyright violation Date: Thu, 17 May 2001 18:34:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <000b01c0df38$7e6e62e0$0c0d0041@home> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.org FreeBSD and Beer have alot in common.. - would get you kicked out of a windows XP public debut - fills you up and never lets you down - can come between you and your girlfriend - certain chicks dig it, others run in fear - gives you that warm fuzzy feeling - used all over the world to acheive the affects of more expensive products > mmmmmm beeeeeeeerrrr ----- Original Message ----- From: "Colin Faber" To: "Dan Graaff" Cc: Sent: Thursday, May 17, 2001 6:17 PM Subject: Re: copyright violation heh, They have beer in china now?! Dan Graaff wrote: > > and the price of beer in chine too.. dont forget that > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 7:42:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from public.guangzhou.gd.cn (mail2-smtp.guangzhou.gd.cn [202.105.65.222]) by hub.freebsd.org (Postfix) with SMTP id 418ED37B42C for ; Fri, 18 May 2001 07:42:32 -0700 (PDT) (envelope-from huacheng@public.guangzhou.gd.cn) Received: from slack([61.140.49.6]) by public.guangzhou.gd.cn(JetMail 2.5.3.0) with SMTP id jm53b0586d5; Fri, 18 May 2001 14:40:58 -0000 Message-ID: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> From: "edwin chan" To: Subject: AUTH and sendmail Date: Fri, 18 May 2001 22:42:25 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org we found use 4.3freebsd sendmail default setup is a safer choice for our mailserver. But we have many staff outside want to access our mailserver by dialup, but with default sendmail conf they can't relay the mail they sent when they stay outside. (use pop3 receive mail not problem), now we advise staff outsite use our mailserver receive mail but use local ISP's mailserver send mail. I want to know if someone have good idea to resolve the problem ? I heared newer sendmail support AUTH function, if user can pass the authentication, mailserver can relay the mail they sent from everywhere: 1. use AUTH function is a good idea ? 2. use AUTH function can give us propriety security ? 3. if outlook express support it, in what kind of auth ? 4. does anybody experience it ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 8:12:53 2001 Delivered-To: freebsd-security@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id C007637B423 for ; Fri, 18 May 2001 08:12:44 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:TNn9i6n2dAL6W1nysxyoKezN4TGG02j3rPeYe0V3GNTCJfJMJijfg0QdyWMAI1bV@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f4IFAF122814; Sat, 19 May 2001 00:10:15 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 19 May 2001 00:10:15 +0900 (JST) Message-Id: <20010519.001015.48821893.ume@mahoroba.org> To: huacheng@public.guangzhou.gd.cn Cc: freebsd-security@FreeBSD.ORG Subject: Re: AUTH and sendmail From: Hajimu UMEMOTO In-Reply-To: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> References: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 18 May 2001 22:42:25 +0800 >>>>> "edwin chan" said: huacheng> I want to know if someone have good idea to resolve the problem ? huacheng> I heared newer sendmail support AUTH function, if user can pass the huacheng> authentication, mailserver can relay the mail they sent from everywhere: huacheng> 1. use AUTH function is a good idea ? I think so. But, your favorite mailer may have no support of SMTP AUTH, yet. huacheng> 2. use AUTH function can give us propriety security ? SMTP AUTH is superior to POP before SMTP. huacheng> 3. if outlook express support it, in what kind of auth ? Outlook Express supports LOGIN only. Since it uses plain password, you may want to use TLS in conjunction with SMTP AUTH. huacheng> 4. does anybody experience it ? We are using it in day-by-day use. But, though we are enabling TLS, we don't enable plain password such as PLAIN and LOGIN. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 8:19:43 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id 9715737B424 for ; Fri, 18 May 2001 08:19:35 -0700 (PDT) (envelope-from Olivier.Nicole@ait.ac.th) Received: from bazooka.cs.ait.ac.th (on@bazooka.cs.ait.ac.th [192.41.170.2]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id WAA13071; Fri, 18 May 2001 22:17:00 +0700 (GMT+0700) From: Olivier Nicole Received: (from on@localhost) by bazooka.cs.ait.ac.th (8.8.5/8.8.5) id WAA12362; Fri, 18 May 2001 22:18:54 +0700 (ICT) Date: Fri, 18 May 2001 22:18:54 +0700 (ICT) Message-Id: <200105181518.WAA12362@bazooka.cs.ait.ac.th> To: huacheng@public.guangzhou.gd.cn Cc: freebsd-security@FreeBSD.ORG In-reply-to: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> (huacheng@public.guangzhou.gd.cn) Subject: Re: AUTH and sendmail Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Funny enough I worked on that last week and finished buddling a web age for my users today (http://www.cs.ait.ac.th/laboratory/email/) I use poprelayd, from http://poprelay.sourceforge.net (with some little modif) that is a perl script that reads /var/log/maillog (it goes fine with the newsyslog) and extract pop/imap authetication information. The it adds a temporary open relay for the client IP in a table, for 15 minutes, as mail prgram typically check email every 10 minutes, relay is open as long as the mail program is running. There could be a 15 minutes window where someone else could connect using the same IP and could use your email server as an open relay... risk is very unlikely. Advantage: it working with plain pop or imap, so basically any client. Olivier > we found use 4.3freebsd sendmail default setup is a safer choice for our > mailserver. But we have many staff outside want to access our mailserver by > dialup, but with default sendmail conf they can't relay the mail they sent > when they stay outside. (use pop3 receive mail not problem), now we > advise staff outsite use our mailserver receive mail but use local ISP's > mailserver send mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 8:29:33 2001 Delivered-To: freebsd-security@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id C004037B424 for ; Fri, 18 May 2001 08:29:28 -0700 (PDT) (envelope-from never@mail.uic-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4IFU8E18221; Fri, 18 May 2001 18:30:10 +0300 (EEST) (envelope-from never@mail.uic-in.net) Received: (from never@localhost) by mail.uic-in.net (8.11.3/8.11.3) id f4IFSuD34547; Fri, 18 May 2001 18:28:56 +0300 (EEST) (envelope-from never) Date: Fri, 18 May 2001 18:28:56 +0300 From: "Alexandr P. Kovalenko" To: Hajimu UMEMOTO Cc: huacheng@public.guangzhou.gd.cn, freebsd-security@FreeBSD.ORG Subject: Re: AUTH and sendmail Message-ID: <20010518182856.C17041@uic-in.net> References: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> <20010519.001015.48821893.ume@mahoroba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519.001015.48821893.ume@mahoroba.org>; from ume@mahoroba.org on Sat, May 19, 2001 at 12:10:15AM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Hajimu UMEMOTO! On Sat, May 19, 2001 at 12:10:15AM +0900, you wrote: > huacheng> 2. use AUTH function can give us propriety security ? > > SMTP AUTH is superior to POP before SMTP. Sorry, this question is asked many times, but, maybe someone can give some advices to set up pop-before-smtp in real situation for me in private e-mail?.. I've seen drac but I'm wondering how should I apply it in real situation, need some examples. And also how can I get ip of connecting client if my daemon (pop3 for ex.) is started from inetd? man what function? -- NEVE-RIPE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 8:57: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id BC94A37B424 for ; Fri, 18 May 2001 08:56:59 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:L5Ur2HTvFMevUxwXMYjHE0v/GN6MS2BAg0DypngVx2TyIyRDmXZV7mC2QLUQmv9X@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f4IFt8160234; Sat, 19 May 2001 00:55:08 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 19 May 2001 00:55:07 +0900 (JST) Message-Id: <20010519.005507.115923389.ume@mahoroba.org> To: never@uic-in.net Cc: huacheng@public.guangzhou.gd.cn, freebsd-security@FreeBSD.ORG Subject: Re: AUTH and sendmail From: Hajimu UMEMOTO In-Reply-To: <20010518182856.C17041@uic-in.net> References: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> <20010519.001015.48821893.ume@mahoroba.org> <20010518182856.C17041@uic-in.net> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 18 May 2001 18:28:56 +0300 >>>>> "Alexandr P. Kovalenko" said: never> Sorry, this question is asked many times, but, maybe someone can give never> some advices to set up pop-before-smtp in real situation for me never> in private e-mail?.. I've seen drac but I'm wondering how should never> I apply it in real situation, need some examples. There are some implementations to do pop-before-smtp. I'm using poprelayd in one of the sites I maintain. poprelayd is mentioned by Olivier Nicole in this thread. Recentry, DRAC seems to be well known. In anyway, I don't like pop-before-smtp. :-) never> And also how can I get ip of connecting client if my daemon (pop3 never> for ex.) is started from inetd? man what function? When POP connection comes, the POP server saves the IP address where connection comes into access control database. Then, SMTP connection comes, it is allowed by check_relay rule of sendmail.cf. Since Qpopper 4.X has DRAC support, you don't need extra patch. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 9: 3:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id E386337B424; Fri, 18 May 2001 09:03:14 -0700 (PDT) (envelope-from never@mail.uic-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4IG4KE19660; Fri, 18 May 2001 19:04:22 +0300 (EEST) (envelope-from never@mail.uic-in.net) Received: (from never@localhost) by mail.uic-in.net (8.11.3/8.11.3) id f4IG38p34835; Fri, 18 May 2001 19:03:08 +0300 (EEST) (envelope-from never) Date: Fri, 18 May 2001 19:03:08 +0300 From: "Alexandr P. Kovalenko" To: Hajimu UMEMOTO Cc: freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: AUTH and sendmail Message-ID: <20010518190308.A34705@uic-in.net> References: <002c01c0dfa8$c6ae8600$9201a8c0@home.net> <20010519.001015.48821893.ume@mahoroba.org> <20010518182856.C17041@uic-in.net> <20010519.005507.115923389.ume@mahoroba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519.005507.115923389.ume@mahoroba.org>; from ume@mahoroba.org on Sat, May 19, 2001 at 12:55:07AM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Hajimu UMEMOTO! On Sat, May 19, 2001 at 12:55:07AM +0900, you wrote: > never> And also how can I get ip of connecting client if my daemon (pop3 > never> for ex.) is started from inetd? man what function? > > When POP connection comes, the POP server saves the IP address where > connection comes into access control database. Then, SMTP connection > comes, it is allowed by check_relay rule of sendmail.cf. Since > Qpopper 4.X has DRAC support, you don't need extra patch. You see, I don't use qpopper, I don't use any of pop daemons by third party, we wrote our own for use with freemail system. I like drac because it needs only minimal patches and beacuse of it's standalone daemon which can be informed through network to do /etc/mail/access updates. And the question about ip was not about access control but about general inetd behavour. I mean in which way inetd gives ip to daemon. This is not question for -security, so I cc-ed it to -questions. P.S. I'm sorry for my lameness... :( -- NEVE-RIPE ICQ: 36925929 http://www.nevermind.kiev.ua/ Powered by caffeine. Made with beer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 9:13:25 2001 Delivered-To: freebsd-security@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 2374C37B422; Fri, 18 May 2001 09:13:17 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:mMylMsL61Rpok5xenCVNuhY4pSIpT0MPjzufQXw1VRnNJQWKiDq+NVijTlsX9Cqq@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f4IGDA197363; Sat, 19 May 2001 01:13:10 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 19 May 2001 01:13:10 +0900 (JST) Message-Id: <20010519.011310.48516133.ume@mahoroba.org> To: never@uic-in.net Cc: freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: AUTH and sendmail From: Hajimu UMEMOTO In-Reply-To: <20010518190308.A34705@uic-in.net> References: <20010518182856.C17041@uic-in.net> <20010519.005507.115923389.ume@mahoroba.org> <20010518190308.A34705@uic-in.net> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 18 May 2001 19:03:08 +0300 >>>>> "Alexandr P. Kovalenko" said: never> You see, I don't use qpopper, I don't use any of pop daemons by third party, we never> wrote our own for use with freemail system. I like drac because it needs only never> minimal patches and beacuse of it's standalone daemon which can be informed never> through network to do /etc/mail/access updates. never> And the question about ip was not about access control but about general inetd never> behavour. I mean in which way inetd gives ip to daemon. This is not question never> for -security, so I cc-ed it to -questions. I see. You can obtain client IP address by getpeername(2). -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 10:32:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from ritchie.loop.com (ritchie.loop.com [207.211.60.70]) by hub.freebsd.org (Postfix) with ESMTP id 6BF4C37B422 for ; Fri, 18 May 2001 10:32:43 -0700 (PDT) (envelope-from dwplists@loop.com) Received: from Elektra.loop.com (elektra.loop.com [207.211.60.33]) by ritchie.loop.com (8.9.3/8.9.3) with SMTP id KAA15118 for ; Fri, 18 May 2001 10:32:42 -0700 (PDT) Message-ID: <046c01c0dfc0$833e7fc0$213cd3cf@loop.com> From: "D. W. Piper" To: References: <200105181518.WAA12362@bazooka.cs.ait.ac.th> Subject: IPFW Rule -1 Always = Attack? Date: Fri, 18 May 2001 10:32:24 -0700 Organization: The Loop Internet MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi everyone, If I understand things correctly from the archives and the IPFW man page, IPFW rule -1 is built into the firewall, and only applies to rejecting IP fragments with a fragment offset of one. The man page further states, "This is a valid packet, but it only has one use, to try to circumvent firewalls." Does that mean that every packet dropped by rule -1 indicates a deliberate attempt to circumvent the firewall, and should be reported to the appropriate network administrator for the source IP address? TIA, David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 12: 2:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.wlcg.com (mail.wlcg.com [207.226.17.4]) by hub.freebsd.org (Postfix) with ESMTP id 5E11437B424 for ; Fri, 18 May 2001 12:02:19 -0700 (PDT) (envelope-from rsimmons@wlcg.com) Received: from localhost (rsimmons@localhost) by mail.wlcg.com (8.11.3/8.11.3) with ESMTP id f4IJ1pN55847; Fri, 18 May 2001 15:01:51 -0400 (EDT) (envelope-from rsimmons@wlcg.com) Date: Fri, 18 May 2001 15:01:47 -0400 (EDT) From: Rob Simmons To: Olivier Nicole Cc: huacheng@public.guangzhou.gd.cn, freebsd-security@FreeBSD.ORG Subject: Re: AUTH and sendmail In-Reply-To: <200105181518.WAA12362@bazooka.cs.ait.ac.th> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 If you have a firewall, it should be setup to block internal IPs coming in through the external interface. If you also only allow port 25 on your mx servers, it is safe to put all your internal IPs in /etc/mail/access as open relays. Spammers wouldn't be able to spoof one of your internal IPs since the firewall would drop it. Robert Simmons Systems Administrator http://www.wlcg.com/ On Fri, 18 May 2001, Olivier Nicole wrote: > Hi, > > Funny enough I worked on that last week and finished buddling a web > age for my users today (http://www.cs.ait.ac.th/laboratory/email/) > > I use poprelayd, from http://poprelay.sourceforge.net (with some > little modif) that is a perl script that reads /var/log/maillog (it > goes fine with the newsyslog) and extract pop/imap authetication > information. > > The it adds a temporary open relay for the client IP in a table, for > 15 minutes, as mail prgram typically check email every 10 minutes, > relay is open as long as the mail program is running. There could be a > 15 minutes window where someone else could connect using the same IP > and could use your email server as an open relay... risk is very > unlikely. > > Advantage: it working with plain pop or imap, so basically any client. > > Olivier > > > we found use 4.3freebsd sendmail default setup is a safer choice for our > > mailserver. But we have many staff outside want to access our mailserver by > > dialup, but with default sendmail conf they can't relay the mail they sent > > when they stay outside. (use pop3 receive mail not problem), now we > > advise staff outsite use our mailserver receive mail but use local ISP's > > mailserver send mail. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7BXGfv8Bofna59hYRA3nbAJ4lvskjb2PF0k/cEz1yHoNVPGqJBACfSzSq FBXFcUy9ouV0ghH0rVdEKi0= =8cBp -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 17:33:56 2001 Delivered-To: freebsd-security@freebsd.org Received: from virginia.yamato.ibm.co.jp (virginia.yamato.ibm.co.jp [203.141.89.165]) by hub.freebsd.org (Postfix) with ESMTP id E0F3237B42C for ; Fri, 18 May 2001 17:32:38 -0700 (PDT) (envelope-from etoh@trl.ibm.co.jp) Received: from ns.trl.ibm.com (ns.trl.ibm.com [9.116.48.18]) by virginia.yamato.ibm.co.jp (8.9.3/3.7W/GW3.3) with ESMTP id JAA10162 for ; Sat, 19 May 2001 09:32:28 +0900 Received: from localhost by ns.trl.ibm.com (AIX4.3/8.9.3/TRL4.5SRV) id JAA23958; Sat, 19 May 2001 09:32:27 +0900 To: security@FreeBSD.ORG Subject: Base system with gcc stack-smashing protector X-Mailer: Mew version 1.94b48 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_May_19_09:32:24_2001_518)--" Content-Transfer-Encoding: 7bit Message-Id: <20010519093227T.etoh@trl.ibm.com> Date: Sat, 19 May 2001 09:32:27 +0900 From: Hiroaki Etoh X-Dispatcher: imput version 990813(IM119) Lines: 2686 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----Next_Part(Sat_May_19_09:32:24_2001_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit At last, I have completed GCC extension for protectiong applications against stack smashing attack. It works on Intel x86 processor and IBM powerpc. I also updated the patch for protecting FreeBSD 4.3 system from stack smashing attack. - support FreeBSD 4.3 - syslog output at the detection of stack smashing attack - kernel protection The attached file is a patch against the system 4.3-RELEASE. See http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html for details. (to be appered in the next week) Hiroaki Etoh, Tokyo Research Laboratory, IBM Japan ----Next_Part(Sat_May_19_09:32:24_2001_518)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="protector43.patch" ? contrib/gcc/protector.h ? contrib/gcc/protector.c ? lib/libc/.depend ? sys/libkern/stack_smash_handler.c Index: contrib/gcc/Makefile.in =================================================================== RCS file: /home/ncvs/src/contrib/gcc/Makefile.in,v retrieving revision 1.4.2.1 diff -c -r1.4.2.1 Makefile.in *** contrib/gcc/Makefile.in 2001/04/10 19:22:57 1.4.2.1 --- contrib/gcc/Makefile.in 2001/05/18 23:54:35 *************** *** 685,691 **** insn-peep.o reorg.o $(SCHED_PREFIX)sched.o final.o recog.o reg-stack.o \ insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o lcm.o \ profile.o insn-attrtab.o $(out_object_file) getpwd.o $(EXTRA_OBJS) convert.o \ ! mbchar.o dyn-string.o splay-tree.o graph.o sbitmap.o resource.o hash.o # GEN files are listed separately, so they can be built before doing parallel # makes for cc1 or cc1plus. Otherwise sequent parallel make attempts to load --- 685,691 ---- insn-peep.o reorg.o $(SCHED_PREFIX)sched.o final.o recog.o reg-stack.o \ insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o lcm.o \ profile.o insn-attrtab.o $(out_object_file) getpwd.o $(EXTRA_OBJS) convert.o \ ! mbchar.o dyn-string.o splay-tree.o graph.o sbitmap.o resource.o hash.o protector.o # GEN files are listed separately, so they can be built before doing parallel # makes for cc1 or cc1plus. Otherwise sequent parallel make attempts to load *************** *** 736,742 **** _fixtfdi _fixunstfdi _floatditf \ __gcc_bcmp _varargs __dummy _eprintf \ _bb _shtab _clear_cache _trampoline __main _exit \ ! _ctors _pure LIB2FUNCS_EH = _eh --- 736,742 ---- _fixtfdi _fixunstfdi _floatditf \ __gcc_bcmp _varargs __dummy _eprintf \ _bb _shtab _clear_cache _trampoline __main _exit \ ! _ctors _pure _stack_smash_handler LIB2FUNCS_EH = _eh *************** *** 1138,1144 **** if [ $${name}.asm = $${file} ]; then \ cp $${file} $${name}.s || exit 1; file=$${name}.s; \ else true; fi; \ ! $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) $(INCLUDES) -c $${file}; \ if [ $$? -eq 0 ] ; then true; else exit 1; fi; \ $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) tmplibgcc2.a $${oname}$(objext); \ rm -f $${name}.s $${oname}$(objext); \ --- 1138,1144 ---- if [ $${name}.asm = $${file} ]; then \ cp $${file} $${name}.s || exit 1; file=$${name}.s; \ else true; fi; \ ! $(GCC_FOR_TARGET) -fno-stack-protector $(LIBGCC2_CFLAGS) $(INCLUDES) -c $${file}; \ if [ $$? -eq 0 ] ; then true; else exit 1; fi; \ $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) tmplibgcc2.a $${oname}$(objext); \ rm -f $${name}.s $${oname}$(objext); \ *************** *** 1465,1471 **** dwarf2out.h sdbout.h dbxout.h $(EXPR_H) $(BASIC_BLOCK_H) \ $(lang_options_files) $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $(MAYBE_USE_COLLECT2) \ ! -DTARGET_NAME=\"$(target_alias)\" \ -c `echo $(srcdir)/toplev.c | sed 's,^\./,,'` rtl.o : rtl.c $(CONFIG_H) system.h $(RTL_H) bitmap.h --- 1465,1471 ---- dwarf2out.h sdbout.h dbxout.h $(EXPR_H) $(BASIC_BLOCK_H) \ $(lang_options_files) $(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $(MAYBE_USE_COLLECT2) \ ! -DSTACK_PROTECTOR -DTARGET_NAME=\"$(target_alias)\" \ -c `echo $(srcdir)/toplev.c | sed 's,^\./,,'` rtl.o : rtl.c $(CONFIG_H) system.h $(RTL_H) bitmap.h Index: contrib/gcc/cse.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/cse.c,v retrieving revision 1.1.1.6.2.1 diff -c -r1.1.1.6.2.1 cse.c *** contrib/gcc/cse.c 2001/04/10 19:23:04 1.1.1.6.2.1 --- contrib/gcc/cse.c 2001/05/18 23:54:39 *************** *** 6483,6488 **** --- 6483,6492 ---- if (SET_DEST (x) == pc_rtx && GET_CODE (SET_SRC (x)) == LABEL_REF) ; + else if (x->volatil) { + make_new_qty (REGNO (SET_DEST (x))); + qty_mode[REG_QTY (REGNO (SET_DEST (x)))] = GET_MODE (SET_DEST (x)); + } /* Don't count call-insns, (set (reg 0) (call ...)), as a set. The hard function value register is used only once, to copy to Index: contrib/gcc/dbxout.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/dbxout.c,v retrieving revision 1.4 diff -c -r1.4 dbxout.c *** contrib/gcc/dbxout.c 1999/10/26 08:47:58 1.4 --- contrib/gcc/dbxout.c 2001/05/18 23:54:40 *************** *** 2253,2258 **** --- 2253,2261 ---- for (; parms; parms = TREE_CHAIN (parms)) if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) { + /* change the debug info of escaped argument for stack protection */ + update_debuginfo_using_escaped_arg_list (parms); + dbxout_prepare_symbol (parms); /* Perform any necessary register eliminations on the parameter's rtl, Index: contrib/gcc/expr.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/expr.c,v retrieving revision 1.1.1.4.2.2 diff -c -r1.1.1.4.2.2 expr.c *** contrib/gcc/expr.c 2001/04/10 19:23:06 1.1.1.4.2.2 --- contrib/gcc/expr.c 2001/05/18 23:54:45 *************** *** 41,46 **** --- 41,47 ---- #include "typeclass.h" #include "defaults.h" #include "toplev.h" + #include "protector.h" #define CEIL(x,y) (((x) + (y) - 1) / (y)) *************** *** 6316,6322 **** && modifier != EXPAND_MEMORY_USE_WO) return GEN_INT (TREE_STRING_POINTER (string)[i]); ! op0 = expand_expr (exp1, NULL_RTX, VOIDmode, EXPAND_SUM); op0 = memory_address (mode, op0); if (current_function_check_memory_usage && !AGGREGATE_TYPE_P (TREE_TYPE (exp))) --- 6317,6323 ---- && modifier != EXPAND_MEMORY_USE_WO) return GEN_INT (TREE_STRING_POINTER (string)[i]); ! op0 = expand_expr (exp1, NULL_RTX, VOIDmode, flag_propolice_protection?ro_modifier:EXPAND_SUM); op0 = memory_address (mode, op0); if (current_function_check_memory_usage && !AGGREGATE_TYPE_P (TREE_TYPE (exp))) *************** *** 8796,8802 **** mem = gen_rtx_MEM (BLKmode, memory_address (BLKmode, expand_expr (exp, NULL_RTX, ! ptr_mode, EXPAND_SUM))); RTX_UNCHANGING_P (mem) = TREE_READONLY (exp); --- 8797,8803 ---- mem = gen_rtx_MEM (BLKmode, memory_address (BLKmode, expand_expr (exp, NULL_RTX, ! ptr_mode, flag_propolice_protection?EXPAND_NORMAL:EXPAND_SUM))); RTX_UNCHANGING_P (mem) = TREE_READONLY (exp); Index: contrib/gcc/function.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/function.c,v retrieving revision 1.6.2.2 diff -c -r1.6.2.2 function.c *** contrib/gcc/function.c 2001/04/10 19:23:08 1.6.2.2 --- contrib/gcc/function.c 2001/05/18 23:54:47 *************** *** 60,65 **** --- 60,66 ---- #include "obstack.h" #include "toplev.h" #include "hash.h" + #include "protector.h" #ifndef TRAMPOLINE_ALIGNMENT #define TRAMPOLINE_ALIGNMENT FUNCTION_BOUNDARY *************** *** 432,437 **** --- 433,440 ---- /* The size of the slot, including extra space for alignment. This info is for combine_temp_slots. */ HOST_WIDE_INT full_size; + /* Boundary mark of a character array and the others. This info is for ProPolice */ + int boundary_mark; }; /* List of all temporaries allocated, both available and in use. */ *************** *** 451,456 **** --- 454,464 ---- until no longer needed. CLEANUP_POINT_EXPRs define the lifetime of TARGET_EXPRs. */ int target_temp_slot_level; + + /* Current boundary mark for character arrays. */ + + int temp_boundary_mark; + /* This structure is used to record MEMs or pseudos used to replace VAR, any SUBREGs of VAR, and any MEMs containing VAR as an address. We need to *************** *** 933,938 **** --- 941,950 ---- int align; int alias_set; struct temp_slot *p, *best_p = 0; + int char_array = type && (TREE_TYPE (type)==char_type_node + || (TREE_TYPE (type) + && TREE_CODE (TREE_TYPE (type)) == INTEGER_TYPE + && TYPE_PRECISION (TREE_TYPE (type)) == 8)); /* If SIZE is -1 it means that somebody tried to allocate a temporary of a variable size. */ *************** *** 965,971 **** && (!flag_strict_aliasing || (alias_set && p->alias_set == alias_set)) && (best_p == 0 || best_p->size > p->size ! || (best_p->size == p->size && best_p->align > p->align))) { if (p->align == align && p->size == size) { --- 977,984 ---- && (!flag_strict_aliasing || (alias_set && p->alias_set == alias_set)) && (best_p == 0 || best_p->size > p->size ! || (best_p->size == p->size && best_p->align > p->align)) ! && (! char_array || p->boundary_mark != 0)) { if (p->align == align && p->size == size) { *************** *** 1003,1008 **** --- 1016,1022 ---- p->align = best_p->align; p->address = 0; p->rtl_expr = 0; + p->boundary_mark = best_p->boundary_mark; p->next = temp_slots; temp_slots = p; *************** *** 1064,1069 **** --- 1078,1084 ---- p->full_size = frame_offset - frame_offset_old; #endif p->address = 0; + p->boundary_mark = char_array?++temp_boundary_mark:0; p->next = temp_slots; temp_slots = p; } *************** *** 1188,1201 **** int delete_q = 0; if (! q->in_use && GET_MODE (q->slot) == BLKmode) { ! if (p->base_offset + p->full_size == q->base_offset) { /* Q comes after P; combine Q into P. */ p->size += q->size; p->full_size += q->full_size; delete_q = 1; } ! else if (q->base_offset + q->full_size == p->base_offset) { /* P comes after Q; combine P into Q. */ q->size += p->size; --- 1203,1218 ---- int delete_q = 0; if (! q->in_use && GET_MODE (q->slot) == BLKmode) { ! if (p->base_offset + p->full_size == q->base_offset && ! p->boundary_mark == q->boundary_mark) { /* Q comes after P; combine Q into P. */ p->size += q->size; p->full_size += q->full_size; delete_q = 1; } ! else if (q->base_offset + q->full_size == p->base_offset && ! p->boundary_mark == q->boundary_mark) { /* P comes after Q; combine P into Q. */ q->size += p->size; *************** *** 1704,1710 **** if (regno < max_parm_reg) new = parm_reg_stack_loc[regno]; if (new == 0) ! new = assign_stack_local (decl_mode, GET_MODE_SIZE (decl_mode), 0); } PUT_MODE (reg, decl_mode); --- 1721,1727 ---- if (regno < max_parm_reg) new = parm_reg_stack_loc[regno]; if (new == 0) ! new = assign_stack_local_for_pseudo_reg (decl_mode, GET_MODE_SIZE (decl_mode), 0); } PUT_MODE (reg, decl_mode); *************** *** 7035,7038 **** --- 7052,7061 ---- } } #endif /* HAVE_prologue or HAVE_epilogue */ + } + + tree + query_trampoline_list() + { + return trampoline_list; } Index: contrib/gcc/gcc.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/gcc.c,v retrieving revision 1.17.2.1 diff -c -r1.17.2.1 gcc.c *** contrib/gcc/gcc.c 2001/04/10 19:23:09 1.17.2.1 --- contrib/gcc/gcc.c 2001/05/18 23:54:49 *************** *** 768,774 **** %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\ %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\ %{static:} %{L*} %D %o\ ! %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\ %{!A:%{!nostdlib:%{!nostartfiles:%E}}}\ %{T*}\ \n }}}}}}"; --- 768,774 ---- %{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\ %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\ %{static:} %{L*} %D %o\ ! %{!nostdlib:%{!nodefaultlibs:%G %L %G %L}}\ %{!A:%{!nostdlib:%{!nostartfiles:%E}}}\ %{T*}\ \n }}}}}}"; Index: contrib/gcc/gcse.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/gcse.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 gcse.c *** contrib/gcc/gcse.c 1999/11/01 08:26:03 1.1.1.3 --- contrib/gcc/gcse.c 2001/05/18 23:54:51 *************** *** 3718,3724 **** /* Find an assignment that sets reg_used and is available at the start of the block. */ set = find_avail_set (regno, insn); ! if (! set) continue; pat = set->expr; --- 3718,3724 ---- /* Find an assignment that sets reg_used and is available at the start of the block. */ set = find_avail_set (regno, insn); ! if (! set || set->expr->volatil) continue; pat = set->expr; Index: contrib/gcc/integrate.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/integrate.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 integrate.c *** contrib/gcc/integrate.c 1999/10/16 06:05:22 1.1.1.3 --- contrib/gcc/integrate.c 2001/05/18 23:54:53 *************** *** 38,43 **** --- 38,44 ---- #include "function.h" #include "toplev.h" #include "intl.h" + #include "protector.h" #include "obstack.h" #define obstack_chunk_alloc xmalloc *************** *** 1503,1512 **** arg_vals[i] = convert_modes (GET_MODE (loc), TYPE_MODE (TREE_TYPE (arg)), expand_expr (arg, NULL_RTX, mode, ! EXPAND_SUM), TREE_UNSIGNED (TREE_TYPE (formal))); else ! arg_vals[i] = expand_expr (arg, NULL_RTX, mode, EXPAND_SUM); } else arg_vals[i] = 0; --- 1504,1513 ---- arg_vals[i] = convert_modes (GET_MODE (loc), TYPE_MODE (TREE_TYPE (arg)), expand_expr (arg, NULL_RTX, mode, ! flag_propolice_protection?EXPAND_NORMAL:EXPAND_SUM), TREE_UNSIGNED (TREE_TYPE (formal))); else ! arg_vals[i] = expand_expr (arg, NULL_RTX, mode, flag_propolice_protection?EXPAND_NORMAL:EXPAND_SUM); } else arg_vals[i] = 0; Index: contrib/gcc/libgcc2.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/libgcc2.c,v retrieving revision 1.4 diff -c -r1.4 libgcc2.c *** contrib/gcc/libgcc2.c 1999/10/27 09:45:47 1.4 --- contrib/gcc/libgcc2.c 2001/05/18 23:54:54 *************** *** 4014,4016 **** --- 4014,4086 ---- __terminate (); } #endif + + #ifdef L_stack_smash_handler + #include + #include + #include + + #if defined(HAVE_SYSLOG) + #include + #include + #include + + #include + #ifndef _PATH_LOG + #define _PATH_LOG "/dev/log" + #endif + #endif + + char __guard[32] = {0,0,0,0,0,0,0,0}; + static void __guard_setup (void) __attribute__ ((constructor)) ; + static void __guard_setup (void) + { + int fd; + if (((int*)__guard)[0]!=0) return; + fd = open ("/dev/urandom", 0); + if (fd != -1) { + ssize_t size = read (fd, &__guard, sizeof(__guard)); + close (fd) ; + if (size == sizeof(__guard)) return; + } + /* If a random generator can't be used, the protector switches the guard + to the "terminator canary" */ + __guard[0] = 0; __guard[1] = 0; __guard[2] = '\n'; __guard[3] = 255; + } + void __stack_smash_handler (char func[], int damaged) + { + #if defined (__GNU_LIBRARY__) + extern char * __progname; + #endif + char message[] = ": stack smashing attack in function "; + int bufsz = 256, len; + char buf[bufsz]; + #if defined(HAVE_SYSLOG) + int LogFile; + struct sockaddr_un SyslogAddr; /* AF_UNIX address of local logger */ + #endif + + strcpy(buf, "<2>"); len=3; /* send LOG_CRIT */ + #if defined (__GNU_LIBRARY__) + strncat(buf, __progname, bufsz-len); len = strlen(buf); + #endif + if (bufsz>len) strncat(buf, message, bufsz-len); len = strlen(buf); + if (bufsz>len) strncat(buf, func, bufsz-len); len = strlen(buf); + + /* print error message */ + write (STDERR_FILENO, buf+3, len-3); + #if defined(HAVE_SYSLOG) + if ((LogFile = socket(AF_UNIX, SOCK_DGRAM, 0)) != -1) { + + /* + * Send "found" message to the "/dev/log" path + */ + SyslogAddr.sun_family = AF_UNIX; + (void)strncpy(SyslogAddr.sun_path, _PATH_LOG, + sizeof SyslogAddr.sun_path); + sendto(LogFile, buf, strlen(buf), 0, (struct sockaddr *)&SyslogAddr, sizeof(SyslogAddr)); + } + #endif + abort(); + } + #endif Index: contrib/gcc/reload1.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/reload1.c,v retrieving revision 1.1.1.4.2.1 diff -c -r1.1.1.4.2.1 reload1.c *** contrib/gcc/reload1.c 2001/04/10 19:23:13 1.1.1.4.2.1 --- contrib/gcc/reload1.c 2001/05/18 23:54:58 *************** *** 39,44 **** --- 39,45 ---- #include "output.h" #include "real.h" #include "toplev.h" + #include "protector.h" #if !defined PREFERRED_STACK_BOUNDARY && defined STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY STACK_BOUNDARY *************** *** 2424,2430 **** if (from_reg == -1) { /* No known place to spill from => no slot to reuse. */ ! x = assign_stack_local (GET_MODE (regno_reg_rtx[i]), total_size, inherent_size == total_size ? 0 : -1); if (BYTES_BIG_ENDIAN) /* Cancel the big-endian correction done in assign_stack_local. --- 2425,2431 ---- if (from_reg == -1) { /* No known place to spill from => no slot to reuse. */ ! x = assign_stack_local_for_pseudo_reg (GET_MODE (regno_reg_rtx[i]), total_size, inherent_size == total_size ? 0 : -1); if (BYTES_BIG_ENDIAN) /* Cancel the big-endian correction done in assign_stack_local. Index: contrib/gcc/toplev.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/toplev.c,v retrieving revision 1.6.2.3 diff -c -r1.6.2.3 toplev.c *** contrib/gcc/toplev.c 2001/04/10 19:23:16 1.6.2.3 --- contrib/gcc/toplev.c 2001/05/18 23:54:59 *************** *** 777,782 **** --- 777,789 ---- int flag_no_ident = 0; + #ifdef STACK_PROTECTOR + /* Nonzero means use ProPolice as a stack protection method */ + int flag_propolice_protection = 1; + #else + int flag_propolice_protection = 0; + #endif + /* Table of supported debugging formats. */ static struct { *************** *** 986,992 **** {"leading-underscore", &flag_leading_underscore, 1, "External symbols have a leading underscore" }, {"ident", &flag_no_ident, 0, ! "Process #ident directives"} }; #define NUM_ELEM(a) (sizeof (a) / sizeof ((a)[0])) --- 993,1003 ---- {"leading-underscore", &flag_leading_underscore, 1, "External symbols have a leading underscore" }, {"ident", &flag_no_ident, 0, ! "Process #ident directives"}, ! {"stack-protector", &flag_propolice_protection, 1, ! "Enables stack protection" }, ! {"no-stack-protector", &flag_propolice_protection, 0, ! "Disables stack protection" }, }; #define NUM_ELEM(a) (sizeof (a) / sizeof ((a)[0])) *************** *** 3652,3657 **** --- 3663,3670 ---- insns = get_insns (); + if (flag_propolice_protection) prepare_stack_protection (); + /* Dump the rtl code if we are dumping rtl. */ if (rtl_dump) Index: gnu/lib/libgcc/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/lib/libgcc/Makefile,v retrieving revision 1.31.2.1 diff -c -r1.31.2.1 Makefile *** gnu/lib/libgcc/Makefile 2001/01/06 23:16:54 1.31.2.1 --- gnu/lib/libgcc/Makefile 2001/05/18 23:55:23 *************** *** 49,55 **** _fixtfdi _fixunstfdi _floatditf \ __gcc_bcmp _varargs __dummy _eprintf \ _bb _shtab _clear_cache _trampoline __main _exit _ctors \ ! _eh _pure # Library members defined in new1.cc. NEW1FUNCS= _op_new _op_newnt --- 49,55 ---- _fixtfdi _fixunstfdi _floatditf \ __gcc_bcmp _varargs __dummy _eprintf \ _bb _shtab _clear_cache _trampoline __main _exit _ctors \ ! _eh _pure _stack_smash_handler # Library members defined in new1.cc. NEW1FUNCS= _op_new _op_newnt *************** *** 65,70 **** --- 65,71 ---- .if ${OBJFORMAT} != aout CFLAGS+= -D_PTHREADS -fPIC -DGTHREAD_USE_WEAK .endif + CFLAGS+= -DHAVE_SYSLOG CXXFLAGS+= -I${GCCDIR}/cp/inc CXXFLAGS+= -nostdinc++ Index: gnu/usr.bin/cc/cc_int/Makefile =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_int/Makefile,v retrieving revision 1.25.2.1 diff -c -r1.25.2.1 Makefile *** gnu/usr.bin/cc/cc_int/Makefile 2000/07/04 05:41:39 1.25.2.1 --- gnu/usr.bin/cc/cc_int/Makefile 2001/05/18 23:55:26 *************** *** 22,28 **** toplev.c tree.c unroll.c varasm.c version.c xcoffout.c \ alias.c bitmap.c dwarf2out.c dyn-string.c except.c \ gcse.c genrtl.c profile.c regmove.c varray.c \ ! ${OUT_FILE} .if defined(USE_EGCS_HAIFA) && ${USE_EGCS_HAIFA} == 1 SRCS+= haifa-sched.c .else --- 22,28 ---- toplev.c tree.c unroll.c varasm.c version.c xcoffout.c \ alias.c bitmap.c dwarf2out.c dyn-string.c except.c \ gcse.c genrtl.c profile.c regmove.c varray.c \ ! ${OUT_FILE} protector.c .if defined(USE_EGCS_HAIFA) && ${USE_EGCS_HAIFA} == 1 SRCS+= haifa-sched.c .else Index: libexec/rtld-elf/Makefile =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/Makefile,v retrieving revision 1.10.2.3 diff -c -r1.10.2.3 Makefile *** libexec/rtld-elf/Makefile 2000/07/20 11:16:05 1.10.2.3 --- libexec/rtld-elf/Makefile 2001/05/18 23:55:37 *************** *** 30,35 **** --- 30,49 ---- DPADD= ${LIBC} LDADD= -lc .else + + OBJS+= _stack_smash_handler.o + CLEANFILES+= tconfig.h tm.h + _stack_smash_handler.o: ${.CURDIR}/../../contrib/gcc/libgcc2.c + echo '#include "gansidecl.h"' > tconfig.h + echo '#include "${MACHINE_ARCH}/xm-${MACHINE_ARCH}.h"' >> tconfig.h + echo '#include "i386/i386.h"' > tm.h + echo '#include "i386/att.h"' >> tm.h + echo '#include "svr4.h"' >> tm.h + echo '#include ' >> tm.h + echo '#include "i386/freebsd.h"'>> tm.h + echo '#include "i386/perform.h"'>> tm.h + $(CC) $(CFLAGS) -DIN_GCC -DL_stack_smash_handler -I${.CURDIR}/../../contrib/gcc -I${.CURDIR}/../../contrib/gcc/config -I. -fexceptions -c $> -o $@ + CFLAGS+= -fpic -DPIC LDFLAGS+= -shared -Wl,-Bsymbolic DPADD= ${LIBC_PIC} Index: sys/boot/i386/loader/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/loader/Makefile,v retrieving revision 1.41.2.6 diff -c -r1.41.2.6 Makefile *** sys/boot/i386/loader/Makefile 2000/12/19 01:18:34 1.41.2.6 --- sys/boot/i386/loader/Makefile 2001/05/18 23:55:47 *************** *** 125,131 **** ${BASE}.sym: ${OBJS} ${LIBI386} ${LIBSTAND} ${LIBFICL} vers.o ${CC} ${LDFLAGS} -o ${.TARGET} ${BTXCRT} ${OBJS} vers.o \ ! ${LIBFICL} ${LIBI386} ${LIBSTAND} # If it's not there, don't consider it a target .if exists(${.CURDIR}/../../../i386/include) --- 125,131 ---- ${BASE}.sym: ${OBJS} ${LIBI386} ${LIBSTAND} ${LIBFICL} vers.o ${CC} ${LDFLAGS} -o ${.TARGET} ${BTXCRT} ${OBJS} vers.o \ ! ${LIBFICL} ${LIBI386} ${LIBSTAND} -lgcc -lc # If it's not there, don't consider it a target .if exists(${.CURDIR}/../../../i386/include) Index: sys/conf/files =================================================================== RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.340.2.51 diff -c -r1.340.2.51 files *** sys/conf/files 2001/03/05 05:33:20 1.340.2.51 --- sys/conf/files 2001/05/18 23:55:52 *************** *** 1223,1225 **** --- 1223,1226 ---- libkern/strtoq.c standard libkern/strtoul.c standard libkern/strtouq.c standard + libkern/stack_smash_handler.c standard *** /dev/null Sat May 19 03:36:36 2001 --- contrib/gcc/protector.h Tue May 15 18:39:54 2001 *************** *** 0 **** --- 1,46 ---- + /* Top level of GNU C compiler + Copyright (C) 1987, 88, 89, 92-7, 1998 Free Software Foundation, Inc. + + This file is part of GNU CC. + + GNU CC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GNU CC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU CC; see the file COPYING. If not, write to + the Free Software Foundation, 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + + /* declaration of GUARD variable */ + #define GUARD_m SImode + #define UNITS_PER_GUARD GET_MODE_SIZE (GUARD_m) + + + #ifndef L_stack_smash_handler + + /* insert a guard variable before a character buffer and change the order + of pointer variables, character buffers and pointer arguments */ + + extern void prepare_stack_protection PARAMS ((void)); + + /* allocate a local variable in the stack area before character buffers + to avoid the corruption of it */ + + extern rtx assign_stack_local_for_pseudo_reg PARAMS ((enum machine_mode, HOST_WIDE_INT, int)); + + /* Update the debug information of the function argument pointed by 'old' */ + extern void set_debuginfo_of_escaped_arg PARAMS ((rtx new, rtx old)); + + + /* Nonzero means use propolice as a stack protection method */ + extern int flag_propolice_protection; + + #endif *** /dev/null Sat May 19 03:36:36 2001 --- contrib/gcc/protector.c Tue May 15 18:39:54 2001 *************** *** 0 **** --- 1,1877 ---- + /* Top level of GNU C compiler + Copyright (C) 1987, 88, 89, 92-7, 1998 Free Software Foundation, Inc. + + This file is part of GNU CC. + + GNU CC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + GNU CC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU CC; see the file COPYING. If not, write to + the Free Software Foundation, 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + #include "config.h" + #include "system.h" + + #include "rtl.h" + #include "tree.h" + #include "regs.h" + #include "flags.h" + #include "insn-config.h" + #include "insn-flags.h" + #include "expr.h" + #include "output.h" + #include "recog.h" + #include "hard-reg-set.h" + #include "real.h" + #include "except.h" + #include "function.h" + #include "toplev.h" + #include "conditions.h" + #include "insn-attr.h" + #include "c-tree.h" + #include "protector.h" + + + rtx assign_stack_local_for_pseudo_reg PARAMS ((enum machine_mode, HOST_WIDE_INT, int)); + void set_debuginfo_of_escaped_arg PARAMS ((rtx old, rtx new)); + void update_debuginfo_using_escaped_arg_list PARAMS ((tree parms)); + + + /* Round a value to the lowest integer less than it that is a multiple of + the required alignment. Avoid using division in case the value is + negative. Assume the alignment is a power of two. */ + #define FLOOR_ROUND(VALUE,ALIGN) ((VALUE) & ~((ALIGN) - 1)) + + /* Similar, but round to the next highest integer that meets the + alignment. */ + #define CEIL_ROUND(VALUE,ALIGN) (((VALUE) + (ALIGN) - 1) & ~((ALIGN)- 1)) + + + /* Nonzero means use propolice as a stack protection method */ + extern int flag_propolice_protection; + + /* List of trampolines */ + extern tree query_trampoline_list PARAMS ((void)); + + typedef struct { rtx original; rtx escaped; } arg_status; + + /* This file contains several memory arrangement functions to protect + the return address and the frame pointer of the stack + from a stack-smashing attack. It also + provides the function that protects pointer variables. */ + + /* Nonzero if function being compiled can define string buffers that may be + damaged by the stack-smash attack */ + static int current_function_defines_vulnerable_string; + static int current_function_has_variable_string; + + static rtx guard_area, _guard; + static rtx function_first_insn, prologue_insert_point; + + /* */ + static HOST_WIDE_INT sweep_frame_offset; + static arg_status* escaped_arg_list = 0; + static int escaped_arg_list_size = 0; + static int guard_has_legitimate_address; + + static int search_string_from_argsandvars PARAMS ((void)); + static int search_string_from_local_vars PARAMS ((tree block)); + static int search_string_def PARAMS ((tree names)); + static int search_pointer_def PARAMS ((tree names)); + static int search_func_pointer PARAMS ((tree type, int mark)); + static void reset_used_flags_for_insns PARAMS ((rtx insn)); + static void reset_used_flags_for_decls PARAMS ((tree block)); + static void reset_used_flags_of_plus PARAMS ((rtx x)); + static void rtl_prologue PARAMS ((rtx insn)); + static void rtl_epilogue PARAMS ((rtx fnlastinsn)); + static void arrange_var_order PARAMS ((tree blocks)); + static void copy_args_for_protection PARAMS ((void)); + static void sweep_string_variable PARAMS ((rtx sweep_var, int var_size)); + static void sweep_string_in_decls PARAMS ((tree block, int sweep_offset, int size)); + static void sweep_string_in_args PARAMS ((tree parms, int sweep_offset, int size)); + static void sweep_string_use_of_insns PARAMS ((rtx insn, int sweep_offset, int size)); + static void sweep_string_in_operand PARAMS ((rtx orig, int sweep_offset, int size)); + static void move_arg_location PARAMS ((rtx insn, rtx orig, rtx new, int var_size)); + static void change_arg_use_of_insns PARAMS ((rtx insn, rtx orig, rtx new, int size)); + static void change_arg_use_in_operand PARAMS ((rtx x, rtx orig, rtx new, int size)); + static void expand_value_return PARAMS ((rtx val)); + static int replace_return_reg PARAMS ((rtx insn, rtx return_save)); + + + #define SUSPICIOUS_BUF_SIZE 8 + + #define DEBUGGER_AUTO_BASEPTR(X) \ + (GET_CODE (X) == PLUS ? XEXP (X, 0) : X) + #define DEBUGGER_AUTO_OFFSET(X) \ + (GET_CODE (X) == PLUS ? INTVAL (XEXP (X, 1)) : 0) + #define PARM_PASSED_IN_MEMORY(PARM) \ + (GET_CODE (DECL_INCOMING_RTL (PARM)) == MEM) + + + + void + prepare_stack_protection (void) + { + tree blocks = DECL_INITIAL (current_function_decl); + current_function_has_variable_string = FALSE; + + /* + skip the protection if the function has no block or it is an inline function + */ + if (! blocks || DECL_INLINE (current_function_decl)) return; + + current_function_defines_vulnerable_string = search_string_from_argsandvars (); + + if (current_function_defines_vulnerable_string) + { + HOST_WIDE_INT previous_frame_offset, offset; + function_first_insn = get_insns (); + + if (query_trampoline_list ()) return; + + sweep_frame_offset = 0; + + #ifdef STACK_GROWS_DOWNWARD + /* + frame_offset: offset to end of allocated area of stack frame. + It is defined in the function.c + */ + previous_frame_offset = frame_offset; + + /* the location must be before buffers */ + guard_area = assign_stack_local (GUARD_m, UNITS_PER_GUARD, 0); + MEM_VOLATILE_P (guard_area) = 1; + + /* check if the address of the guard has legitimate address */ + guard_has_legitimate_address = 1; + GO_IF_LEGITIMATE_ADDRESS(GUARD_m, guard_area, has_legitimate_address); + guard_has_legitimate_address = 0; + has_legitimate_address: + + #ifndef FRAME_GROWS_DOWNWARD + sweep_frame_offset = frame_offset; + #endif + + /* For making room for guard value, scan all insns and fix the offset address + of the variable that is based on frame pointer. + Scan all declarations of variables and fix the offset address of the variable that + is based on the frame pointer */ + sweep_string_variable (guard_area, UNITS_PER_GUARD); + + + /* the location of guard area moves to the beginning of stack frame */ + offset = DEBUGGER_AUTO_OFFSET(XEXP (guard_area, 0)); + XEXP (XEXP (guard_area, 0), 1) = gen_rtx_CONST_INT (VOIDmode, sweep_frame_offset); + + + /* Insert prologue rtl instructions */ + rtl_prologue (function_first_insn); + + if (! current_function_has_variable_string) + { + /* Generate argument saving instruction */ + copy_args_for_protection (); + + #ifndef FRAME_GROWS_DOWNWARD + /* If frame grows upward, character string copied from an arg stays top of + the guard variable. So sweep the guard variable again */ + sweep_frame_offset = frame_offset; + sweep_string_variable (guard_area, UNITS_PER_GUARD); + #endif + } + #endif + + if (! current_function_has_variable_string + && guard_has_legitimate_address) + { + /* Arrange the order of local variables */ + arrange_var_order (blocks); + } + + #ifdef STACK_GROWS_DOWNWARD + /* Insert epilogue rtl instructions */ + rtl_epilogue (get_last_insn ()); + #endif + } + } + + + static int + search_string_from_argsandvars (void) + { + tree blocks, parms; + int string_p; + + /* + search a string variable from local variables + */ + blocks = DECL_INITIAL (current_function_decl); + string_p = search_string_from_local_vars (blocks); + if (string_p) return TRUE; + + + #ifdef FRAME_GROWS_DOWNWARD + /* + search a string variable from arguments + */ + parms = DECL_ARGUMENTS (current_function_decl); + + for (; parms; parms = TREE_CHAIN (parms)) + if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) + { + if (PARM_PASSED_IN_MEMORY (parms) && DECL_NAME (parms)) + { + string_p = search_string_def (TREE_TYPE(parms)); + if (string_p) return TRUE; + } + } + #endif + + return FALSE; + } + + + static int + search_string_from_local_vars (block) + tree block; + { + tree types; + int found = FALSE; + + while (block) + { + types = BLOCK_VARS(block); + + while (types) + { + /* skip the declaration that refers an external variable */ + if (! DECL_EXTERNAL (types) && ! TREE_STATIC (types) + && TREE_CODE (types) == VAR_DECL + && DECL_RTL (types) && GET_CODE (DECL_RTL (types)) == MEM) + { + + if (search_string_def (TREE_TYPE (types))) + { + rtx home = DECL_RTL (types); + + if (GET_CODE (home) == MEM + && (GET_CODE (XEXP (home, 0)) == MEM + || (GET_CODE (XEXP (home, 0)) == REG + && REGNO (XEXP (home, 0)) != HARD_FRAME_POINTER_REGNUM + && REGNO (XEXP (home, 0)) != STACK_POINTER_REGNUM + #if ARG_POINTER_REGNUM != HARD_FRAME_POINTER_REGNUM + && REGNO (XEXP (home, 0)) != ARG_POINTER_REGNUM + #endif + ))) + /* If the value is indirect by memory or by a register + that isn't the frame pointer + then it means the object is variable-sized and address through + that register or stack slot. The protection has no way to hide pointer variables + behind the array, so all we can do is staying the order of variables and arguments. */ + { + current_function_has_variable_string = TRUE; + } + + found = TRUE; + } + } + + types = TREE_CHAIN(types); + } + + if (search_string_from_local_vars (BLOCK_SUBBLOCKS (block))) + { + found = TRUE; + } + + block = BLOCK_CHAIN (block); + } + + return found; + } + + static int + search_string_def (type) + tree type; + { + tree tem; + + /* Mark it as defined, so that if it is self-referent + we will not get into an infinite recursion of definitions. */ + + switch (TREE_CODE (type)) + { + case ARRAY_TYPE: + if (TREE_TYPE (type) == char_type_node + || (TREE_TYPE (type) + && TREE_CODE (TREE_TYPE (type)) == INTEGER_TYPE + && TYPE_PRECISION (TREE_TYPE (type)) == 8)) + { + /* Check if the string is a variable string */ + if (TYPE_DOMAIN (type) == 0 || + TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (type))) == NOP_EXPR) + return TRUE; + + /* Check if the string size is greater than SUSPICIOUS_BUF_SIZE */ + if (TREE_INT_CST_LOW(TYPE_MAX_VALUE(TYPE_DOMAIN(type)))+1 >= SUSPICIOUS_BUF_SIZE) + return TRUE; + } + return search_string_def(TREE_TYPE(type)); + + case UNION_TYPE: + case QUAL_UNION_TYPE: + case RECORD_TYPE: + /* Output the name, type, position (in bits), size (in bits) of each + field. */ + for (tem = TYPE_FIELDS (type); tem; tem = TREE_CHAIN (tem)) + { + /* Omit here local type decls until we know how to support them. */ + if ((TREE_CODE (tem) == TYPE_DECL) + || (TREE_CODE (tem) == VAR_DECL && TREE_STATIC (tem))) + continue; + + if (search_string_def(TREE_TYPE(tem))) return TRUE; + } + break; + + case POINTER_TYPE: + case REFERENCE_TYPE: + /* I'm not sure whether OFFSET_TYPE needs this treatment, + so I'll play safe and return 1. */ + case OFFSET_TYPE: + default: + break; + } + + return FALSE; + } + + + static int + search_pointer_def (type) + tree type; + { + tree tem; + + /* Mark it as defined, so that if it is self-referent + we will not get into an infinite recursion of definitions. */ + + switch (TREE_CODE (type)) + { + case UNION_TYPE: + case QUAL_UNION_TYPE: + case RECORD_TYPE: + /* Output the name, type, position (in bits), size (in bits) of each + field. */ + for (tem = TYPE_FIELDS (type); tem; tem = TREE_CHAIN (tem)) + { + /* Omit here local type decls until we know how to support them. */ + if ((TREE_CODE (tem) == TYPE_DECL) + || (TREE_CODE (tem) == VAR_DECL && TREE_STATIC (tem))) + continue; + + if (search_pointer_def (TREE_TYPE(tem))) return TRUE; + } + break; + + case ARRAY_TYPE: + return search_pointer_def (TREE_TYPE(type)); + + case POINTER_TYPE: + case REFERENCE_TYPE: + /* I'm not sure whether OFFSET_TYPE needs this treatment, + so I'll play safe and return 1. */ + case OFFSET_TYPE: + if (TYPE_READONLY (TREE_TYPE (type))) + { + int funcp = search_func_pointer (TREE_TYPE (type), 1); + /* Un-mark the type as having been visited already */ + search_func_pointer (TREE_TYPE (type), 0); + return funcp; + } + return TRUE; + + default: + break; + } + + return FALSE; + } + + + static int + search_func_pointer (type, mark) + tree type; + int mark; + { + tree tem; + + /* Mark it as defined, so that if it is self-referent + we will not get into an infinite recursion of definitions. */ + + switch (TREE_CODE (type)) + { + case UNION_TYPE: + case QUAL_UNION_TYPE: + case RECORD_TYPE: + if (TREE_ASM_WRITTEN (type) != mark) + { + /* mark the type as having been visited already */ + TREE_ASM_WRITTEN (type) = mark; + + /* Output the name, type, position (in bits), size (in bits) of + each field. */ + for (tem = TYPE_FIELDS (type); tem; tem = TREE_CHAIN (tem)) + { + /* Omit here local type decls until we know how to support them. */ + if (TREE_CODE (tem) == FIELD_DECL + && search_func_pointer (TREE_TYPE(tem), mark)) return TRUE; + } + } + break; + + case ARRAY_TYPE: + return search_func_pointer (TREE_TYPE(type), mark); + + case POINTER_TYPE: + case REFERENCE_TYPE: + /* I'm not sure whether OFFSET_TYPE needs this treatment, + so I'll play safe and return 1. */ + case OFFSET_TYPE: + return TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE; + + default: + break; + } + + return FALSE; + } + + + static void + reset_used_flags_for_insns (insn) + rtx insn; + { + register int i, j; + register enum rtx_code code; + register const char *format_ptr; + + for (; insn; insn = NEXT_INSN (insn)) + if (GET_CODE (insn) == INSN || GET_CODE (insn) == JUMP_INSN + || GET_CODE (insn) == CALL_INSN) + { + code = GET_CODE (insn); + insn->used = 0; + format_ptr = GET_RTX_FORMAT (code); + + for (i = 0; i < GET_RTX_LENGTH (code); i++) + { + switch (*format_ptr++) { + case 'e': + reset_used_flags_of_plus (XEXP (insn, i)); + break; + + case 'E': + for (j = 0; j < XVECLEN (insn, i); j++) + reset_used_flags_of_plus (XVECEXP (insn, i, j)); + break; + } + } + } + } + + static void + reset_used_flags_for_decls (block) + tree block; + { + tree types; + rtx home; + + while (block) + { + types = BLOCK_VARS(block); + + while (types) + { + /* skip the declaration that refers an external variable and + also skip an global variable */ + if (! DECL_EXTERNAL (types)) + { + home = DECL_RTL (types); + if (home == 0) goto next; + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == PLUS + && GET_CODE (XEXP (XEXP (home, 0), 1)) == CONST_INT) + { + XEXP (home, 0)->used = 0; + } + } + next: + types = TREE_CHAIN(types); + } + + reset_used_flags_for_decls (BLOCK_SUBBLOCKS (block)); + + block = BLOCK_CHAIN (block); + } + } + + /* Clear the USED bits only of type PLUS in X */ + + static void + reset_used_flags_of_plus (x) + rtx x; + { + register int i, j; + register enum rtx_code code; + register const char *format_ptr; + + if (x == 0) + return; + + code = GET_CODE (x); + + /* These types may be freely shared so we needn't do any resetting + for them. */ + + switch (code) + { + case REG: + case QUEUED: + case CONST_INT: + case CONST_DOUBLE: + case SYMBOL_REF: + case CODE_LABEL: + case PC: + case CC0: + return; + + case INSN: + case JUMP_INSN: + case CALL_INSN: + case NOTE: + case LABEL_REF: + case BARRIER: + /* The chain of insns is not being copied. */ + return; + + case PLUS: + x->used = 0; + break; + + case CALL_PLACEHOLDER: + reset_used_flags_for_insns (XEXP (x, 0)); + reset_used_flags_for_insns (XEXP (x, 1)); + reset_used_flags_for_insns (XEXP (x, 2)); + break; + + default: + break; + } + + format_ptr = GET_RTX_FORMAT (code); + for (i = 0; i < GET_RTX_LENGTH (code); i++) + { + switch (*format_ptr++) + { + case 'e': + reset_used_flags_of_plus (XEXP (x, i)); + break; + + case 'E': + for (j = 0; j < XVECLEN (x, i); j++) + reset_used_flags_of_plus (XVECEXP (x, i, j)); + break; + } + } + } + + + static void + rtl_prologue (insn) + rtx insn; + { + for (; insn; insn = NEXT_INSN (insn)) + if (GET_CODE (insn) == NOTE && NOTE_LINE_NUMBER (insn) == NOTE_INSN_FUNCTION_BEG) + { + rtx _val; + + prologue_insert_point = NEXT_INSN (insn); /* mark the next insn of FUNCTION_BEG insn */ + + start_sequence (); + + _guard = gen_rtx_MEM (GUARD_m, gen_rtx_SYMBOL_REF (Pmode, "__guard")); + emit_move_insn ( guard_area, _guard); + + _val = gen_sequence (); + end_sequence (); + + emit_insn_before (_val, prologue_insert_point); + break; + } + } + + static void + rtl_epilogue (insn) + rtx insn; + { + /* Like STACK_BOUNDARY but in units of bytes, not bits. */ + #define STACK_BYTES (STACK_BOUNDARY / BITS_PER_UNIT) + + rtx if_false_label; + rtx _val, handler, funcname, addr; + tree funcstr; + HOST_WIDE_INT args_size; + enum machine_mode arg1mode; + rtx return_reg = DECL_RTL (DECL_RESULT (current_function_decl)), return_save; + + handler = gen_rtx_MEM (FUNCTION_MODE, gen_rtx (SYMBOL_REF, Pmode, "__stack_smash_handler")); + + start_sequence (); + + if (return_reg + && ! (current_function_returns_struct + || current_function_returns_pcc_struct)) + { + return_save = gen_reg_rtx (GET_MODE (return_reg)); + + if (! replace_return_reg (prologue_insert_point, return_save)) + emit_move_insn (return_save, return_reg); + } + + compare_from_rtx (guard_area, _guard, NE, 0, GUARD_m, 0, 0); /* if (guard_area != _guard) */ + + if_false_label = gen_label_rtx (); /* { */ + emit_jump_insn ( gen_beq(if_false_label)); + + /* + In the function force_const_mem in varasm.c of egcs-1.1.2-30, there is a + failure to assign the guard_area variable to eax register, which destroys + the return value of the function. + + The BUG preceding comment is an apropriate processes. + When the bug is fixed, removes the comment + */ + + /* generate string for the current function name */ + funcstr = build_string (strlen(current_function_name)+1, current_function_name); + TREE_TYPE (funcstr) = build_array_type (char_type_node, 0);/* = char_array_type_node;*/ + funcname = output_constant_def (funcstr); + + addr = gen_push_operand (); + emit_move_insn (gen_rtx_MEM (GUARD_m, addr), guard_area); /* push the value of guard area */ + + arg1mode = GET_MODE (XEXP (funcname, 0)); + addr = gen_push_operand (); + emit_move_insn (gen_rtx_MEM (arg1mode, addr), XEXP (funcname, 0)); /* push current_function_name */ + + /* calculate the stack size of two arguments */ + args_size = GET_MODE_SIZE (arg1mode) + GET_MODE_SIZE (GUARD_m); + #ifdef PUSH_ROUNDING + args_size = PUSH_ROUNDING (GET_MODE_SIZE (arg1mode)) + PUSH_ROUNDING (GET_MODE_SIZE (GUARD_m)); + #endif + #ifdef STACK_BOUNDARY + args_size = (((args_size + (STACK_BYTES - 1)) / STACK_BYTES) * STACK_BYTES); + #endif + + /* jump to the stack smash handler */ + emit_call_insn (gen_call (handler, GEN_INT (args_size), const0_rtx)); + + /* generate RTL to return from the current function */ + + emit_barrier (); /* } */ + emit_label (if_false_label); + + /* generate RTL to return from the current function */ + if (return_reg) + { + if (!current_function_returns_struct && !current_function_returns_pcc_struct) + expand_value_return (return_save); + + + /* If returning a structure, arrange to return the address of the value + in a place where debuggers expect to find it. + + If returning a structure PCC style, + the caller also depends on this value. + And current_function_returns_pcc_struct is not necessarily set. */ + else + { + rtx value_address = XEXP (DECL_RTL (DECL_RESULT (current_function_decl)), 0); + tree type = TREE_TYPE (DECL_RESULT (current_function_decl)); + #ifdef FUNCTION_OUTGOING_VALUE + rtx outgoing + = FUNCTION_OUTGOING_VALUE (build_pointer_type (type), + current_function_decl); + #else + rtx outgoing + = FUNCTION_VALUE (build_pointer_type (type), + current_function_decl); + #endif + + /* Mark this as a function return value so integrate will delete the + assignment and USE below when inlining this function. */ + REG_FUNCTION_VALUE_P (outgoing) = 1; + + emit_move_insn (outgoing, value_address); + use_variable (outgoing); + } + } + + _val = gen_sequence (); + end_sequence (); + + emit_insn_after (_val, insn); + } + + + static void + arrange_var_order (block) + tree block; + { + tree types; + int offset; + + while (block) + { + types = BLOCK_VARS (block); + + while (types) + { + /* skip the declaration that refers an external variable */ + if (! DECL_EXTERNAL (types) && ! TREE_STATIC (types) + && TREE_CODE (types) == VAR_DECL + && GET_CODE (DECL_RTL (types)) == MEM) + { + if (search_string_def (TREE_TYPE (types))) + { + /* found a string variable */ + int var_size = + ((TREE_INT_CST_LOW (DECL_SIZE (types)) + BITS_PER_UNIT - 1) + / BITS_PER_UNIT); + + if (GET_MODE (DECL_RTL (types)) == BLKmode) + { + int alignment = BIGGEST_ALIGNMENT / BITS_PER_UNIT; + var_size = CEIL_ROUND (var_size, alignment); + } + + /* skip the variable if it is top of the region + specified by sweep_frame_offset */ + offset = DEBUGGER_AUTO_OFFSET (XEXP (DECL_RTL (types), 0)); + if (offset >= sweep_frame_offset - var_size) + sweep_frame_offset -= var_size; + + else + sweep_string_variable (DECL_RTL (types), var_size); + } + } + + types = TREE_CHAIN(types); + } + + arrange_var_order (BLOCK_SUBBLOCKS (block)); + + block = BLOCK_CHAIN (block); + } + } + + + static void + copy_args_for_protection (void) + { + tree parms = DECL_ARGUMENTS (current_function_decl); + rtx temp_rtx; + int idx; + + escaped_arg_list_size = 0; + + /* count the number of argument passed in memory */ + for (; parms; parms = TREE_CHAIN (parms)) + if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) + { + if (PARM_PASSED_IN_MEMORY (parms)) + escaped_arg_list_size ++; + } + + if (escaped_arg_list) free (escaped_arg_list); + escaped_arg_list = xmalloc (sizeof (arg_status) * escaped_arg_list_size); + + parms = DECL_ARGUMENTS (current_function_decl); + for (idx = 0; parms; parms = TREE_CHAIN (parms), idx++) + if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) + { + if (PARM_PASSED_IN_MEMORY (parms) && DECL_NAME (parms)) + { + int string_p; + + /* + skip arguemnt protection if the last argument is used + for the variable argument + */ + /* + tree fntype; + if (TREE_CHAIN (parms) == 0) + { + fntype = TREE_TYPE (current_function_decl); + + if ((TYPE_ARG_TYPES (fntype) != 0 && + TREE_VALUE (tree_last (TYPE_ARG_TYPES (fntype))) != void_type_node) + || current_function_varargs) + continue; + } + */ + + escaped_arg_list[idx].original = 0; + escaped_arg_list[idx].escaped = 0; + + string_p = search_string_def (TREE_TYPE(parms)); + + /* check if it is a candidate to move */ + if (string_p || search_pointer_def (TREE_TYPE (parms))) + { + int arg_size + = ((TREE_INT_CST_LOW (DECL_SIZE (parms)) + BITS_PER_UNIT - 1) + / BITS_PER_UNIT); + + start_sequence (); + + if (GET_CODE (DECL_RTL (parms)) == REG) + { + rtx movinsn; + rtx safe = gen_reg_rtx (GET_MODE (DECL_RTL (parms))); + + /* generate codes for copying the content */ + movinsn = emit_move_insn (safe, DECL_RTL (parms)); + PATTERN (movinsn)->volatil = 1; /* avoid register elimination in gcse.c (COPY-PROP)*/ + + change_arg_use_of_insns (prologue_insert_point, DECL_RTL (parms), safe, 0); + + /* save debugger info */ + escaped_arg_list[idx].original = DECL_RTL (parms); + escaped_arg_list[idx].escaped = safe; + } + + else if (GET_CODE (DECL_RTL (parms)) == MEM + && GET_CODE (XEXP (DECL_RTL (parms), 0)) == ADDRESSOF) + { + rtx movinsn; + rtx safe = gen_reg_rtx (GET_MODE (DECL_RTL (parms))); + + /* generate codes for copying the content */ + movinsn = emit_move_insn (safe, DECL_INCOMING_RTL (parms)); + PATTERN (movinsn)->volatil = 1; /* avoid register elimination in gcse.c (COPY-PROP)*/ + + /* change the addressof information to the newly allocated pseudo register */ + emit_move_insn (DECL_RTL (parms), safe); + + /* save debugger info */ + escaped_arg_list[idx].original = DECL_RTL (parms); + escaped_arg_list[idx].escaped = safe; + } + + else + { + /* declare temporary local variable DECL_NAME (parms) for it */ + temp_rtx + = assign_stack_local (DECL_MODE (parms), arg_size, + DECL_MODE (parms) == BLKmode ? -1 : 0); + + MEM_IN_STRUCT_P (temp_rtx) = AGGREGATE_TYPE_P (TREE_TYPE (parms)); + MEM_ALIAS_SET (temp_rtx) = get_alias_set (parms); + + /* generate codes for copying the content */ + store_expr (parms, temp_rtx, 0); + + /* change the reference for each instructions */ + move_arg_location (prologue_insert_point, DECL_RTL (parms), + temp_rtx, arg_size); + + /* change the location of parms variable */ + DECL_RTL (parms) = temp_rtx; + + /* change debugger info */ + DECL_INCOMING_RTL (parms) = temp_rtx; + } + + emit_insn_before (gen_sequence (), prologue_insert_point); + end_sequence (); + + #ifndef FRAME_GROWS_DOWNWARD + /* process the string argument */ + if (string_p) + { + if (DECL_MODE (parms) == BLKmode) + { + int alignment = BIGGEST_ALIGNMENT / BITS_PER_UNIT; + arg_size = CEIL_ROUND (arg_size, alignment); + } + + /* change the reference for each instructions */ + sweep_string_variable (DECL_RTL (parms), arg_size); + } + #endif + } + } + } + } + + + /* + sweep a string variable to the local variable addressed by sweep_frame_offset, that is + a last position of string variables. + */ + static void + sweep_string_variable (sweep_var, var_size) + int var_size; + rtx sweep_var; + { + int sweep_offset = DEBUGGER_AUTO_OFFSET(XEXP (sweep_var, 0)); + + /* scan all declarations of variables and fix the offset address of + the variable based on the frame pointer */ + sweep_string_in_decls (DECL_INITIAL (current_function_decl), sweep_offset, var_size); + + /* scan all argument variable and fix the offset address based on the frame pointer */ + sweep_string_in_args (DECL_ARGUMENTS (current_function_decl), sweep_offset, var_size); + + /* For making room for sweep variable, scan all insns and fix the offset address + of the variable that is based on frame pointer*/ + sweep_string_use_of_insns (function_first_insn, sweep_offset, var_size); + + + /* Clear all the USED bits in operands of all insns and declarations of local vars */ + reset_used_flags_for_decls (DECL_INITIAL (current_function_decl)); + reset_used_flags_for_insns (function_first_insn); + + sweep_frame_offset -= var_size; + } + + + + /* + move an argument to the local variable addressed by frame_offset + */ + static void + move_arg_location (insn, orig, new, var_size) + rtx insn, orig, new; + int var_size; + { + /* For making room for sweep variable, scan all insns and fix the offset address + of the variable that is based on frame pointer*/ + change_arg_use_of_insns (insn, orig, new, var_size); + + + /* Clear all the USED bits in operands of all insns and declarations of local vars */ + reset_used_flags_for_insns (insn); + } + + + static void + sweep_string_in_decls (block, sweep_offset, sweep_size) + tree block; + int sweep_offset, sweep_size; + { + tree types; + HOST_WIDE_INT offset; + rtx home; + + while (block) + { + types = BLOCK_VARS(block); + + while (types) + { + /* skip the declaration that refers an external variable and + also skip an global variable */ + if (! DECL_EXTERNAL (types) && ! TREE_STATIC (types)) { + + home = DECL_RTL (types); + if (home == 0) goto next; + + /* process for static local variable */ + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == SYMBOL_REF) + goto next; + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == REG) + { + goto next; + } + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == MEM) + { + /* process for dynamically allocated aray */ + home = XEXP (home, 0); + } + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == PLUS + && GET_CODE (XEXP (XEXP (home, 0), 1)) == CONST_INT) + { + if (! XEXP (home, 0)->used) + { + offset = DEBUGGER_AUTO_OFFSET(XEXP (home, 0)); + + /* the operand related to the sweep variable */ + if (sweep_offset <= offset + && offset < sweep_offset + sweep_size) + { + + offset += sweep_frame_offset - sweep_size - sweep_offset; + XEXP (XEXP (home, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + XEXP (home, 0)->used = 1; + } + else if (sweep_offset <= offset + && offset < sweep_frame_offset) + { /* the rest of variables under sweep_frame_offset, + so shift the location */ + + XEXP (XEXP (home, 0), 1) + = gen_rtx_CONST_INT (VOIDmode, offset - sweep_size); + + /* mark */ + XEXP (home, 0)->used = 1; + } + } + } + + } + next: + types = TREE_CHAIN(types); + } + + sweep_string_in_decls (BLOCK_SUBBLOCKS (block), sweep_offset, sweep_size); + block = BLOCK_CHAIN (block); + } + } + + + static void + sweep_string_in_args (parms, sweep_offset, sweep_size) + tree parms; + int sweep_offset, sweep_size; + { + rtx home; + HOST_WIDE_INT offset; + + for (; parms; parms = TREE_CHAIN (parms)) + if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) + { + if (PARM_PASSED_IN_MEMORY (parms) && DECL_NAME (parms)) + { + home = DECL_INCOMING_RTL (parms); + + if (XEXP (home, 0)->used) continue; + + offset = DEBUGGER_AUTO_OFFSET(XEXP (home, 0)); + + /* the operand related to the sweep variable */ + if (DEBUGGER_AUTO_BASEPTR (XEXP (home, 0)) == virtual_stack_vars_rtx) + { + if (sweep_offset <= offset + && offset < sweep_offset + sweep_size) + { + offset += sweep_frame_offset - sweep_size - sweep_offset; + XEXP (XEXP (home, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + XEXP (home, 0)->used = 1; + } + else if (sweep_offset <= offset + && offset < sweep_frame_offset) + { /* the rest of variables under sweep_frame_offset, so shift the location */ + XEXP (XEXP (home, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset - sweep_size); + + /* mark */ + XEXP (home, 0)->used = 1; + } + } + } + } + } + + + static void + sweep_string_use_of_insns (insn, sweep_offset, sweep_size) + rtx insn; + int sweep_offset, sweep_size; + { + for (; insn; insn = NEXT_INSN (insn)) + if (GET_CODE (insn) == INSN || GET_CODE (insn) == JUMP_INSN + || GET_CODE (insn) == CALL_INSN) + { + sweep_string_in_operand (PATTERN (insn), sweep_offset, sweep_size); + } + } + + + static void + sweep_string_in_operand (orig, sweep_offset, sweep_size) + rtx orig; + int sweep_offset, sweep_size; + { + register rtx x = orig; + register enum rtx_code code; + int offset, i, j; + const char *fmt; + + if (x == 0) + return; + + code = GET_CODE (x); + + switch (code) + { + case CONST_INT: + case CONST_DOUBLE: + case CONST: + case SYMBOL_REF: + case CODE_LABEL: + case PC: + case CC0: + case ASM_INPUT: + case ADDR_VEC: + case ADDR_DIFF_VEC: + case RETURN: + case REG: + case ADDRESSOF: + return; + + case SET: + break; + + case PLUS: + /* Handle special case of frame register plus constant. */ + if (CONSTANT_P (XEXP (x, 1)) + && XEXP (x, 0) == virtual_stack_vars_rtx + && ! x->used) + { + offset = DEBUGGER_AUTO_OFFSET(x); + + /* the operand related to the sweep variable */ + if (sweep_offset <= offset + && offset < sweep_offset + sweep_size) + { + offset += sweep_frame_offset - sweep_size - sweep_offset; + + XEXP (x, 0) = virtual_stack_vars_rtx; + XEXP (x, 1) = gen_rtx_CONST_INT (VOIDmode, offset); + x->used = 1; + + return; + } + else if (sweep_offset <= offset + && offset < sweep_frame_offset) + { /* the rest of variables under sweep_frame_offset, so shift the location */ + XEXP (x, 1) = gen_rtx_CONST_INT (VOIDmode, offset - sweep_size); + x->used = 1; + + return; + } + + /* + process further subtree: + Example: (plus:SI (mem/s:SI (plus:SI (reg:SI 17) (const_int 8))) + (const_int 5)) + */ + } + break; + + case CALL_PLACEHOLDER: + sweep_string_use_of_insns (XEXP (x, 0), sweep_offset, sweep_size); + sweep_string_use_of_insns (XEXP (x, 1), sweep_offset, sweep_size); + sweep_string_use_of_insns (XEXP (x, 2), sweep_offset, sweep_size); + break; + + default: + break; + } + + /* Scan all subexpressions. */ + fmt = GET_RTX_FORMAT (code); + for (i = 0; i < GET_RTX_LENGTH (code); i++, fmt++) + if (*fmt == 'e') + { + sweep_string_in_operand (XEXP (x, i), sweep_offset, sweep_size); + } + else if (*fmt == 'E') + for (j = 0; j < XVECLEN (x, i); j++) + sweep_string_in_operand (XVECEXP (x, i, j), sweep_offset, sweep_size); + } + + + /* + change a argument variable to the local variable addressed by the "new" variable. + */ + static void + change_arg_use_of_insns (insn, orig, new, size) + rtx insn, orig, new; + int size; + { + for (; insn; insn = NEXT_INSN (insn)) + if (GET_CODE (insn) == INSN || GET_CODE (insn) == JUMP_INSN + || GET_CODE (insn) == CALL_INSN) + { + change_arg_use_in_operand (PATTERN (insn), orig, new, size); + } + } + + + static void + change_arg_use_in_operand (x, orig, new, size) + rtx x, orig, new; + int size; + { + register enum rtx_code code; + int offset, i, j; + const char *fmt; + + if (x == 0) + return; + + code = GET_CODE (x); + + switch (code) + { + case CONST_INT: + case CONST_DOUBLE: + case CONST: + case SYMBOL_REF: + case CODE_LABEL: + case PC: + case CC0: + case ASM_INPUT: + case ADDR_VEC: + case ADDR_DIFF_VEC: + case RETURN: + case REG: + case ADDRESSOF: + return; + + case PLUS: + /* Handle special case of frame register plus constant. */ + if (GET_CODE (orig) == MEM /* skip if orig is register variable in the optimization */ + && XEXP (x, 0) == virtual_incoming_args_rtx && CONSTANT_P (XEXP (x, 1)) + && ! x->used) + { + offset = DEBUGGER_AUTO_OFFSET(x); + + /* the operand related to the sweep variable */ + if (DEBUGGER_AUTO_OFFSET(XEXP (orig, 0)) <= offset && + offset < DEBUGGER_AUTO_OFFSET(XEXP (orig, 0)) + size) { + + offset += frame_offset - DEBUGGER_AUTO_OFFSET(XEXP (orig, 0)); + + XEXP (x, 0) = virtual_stack_vars_rtx; + XEXP (x, 1) = gen_rtx_CONST_INT (VOIDmode, offset); + x->used = 1; + + return; + } + + /* + process further subtree: + Example: (plus:SI (mem/s:SI (plus:SI (reg:SI 17) (const_int 8))) + (const_int 5)) + */ + } + break; + + case CALL_PLACEHOLDER: + change_arg_use_of_insns (XEXP (x, 0), orig, new, size); + change_arg_use_of_insns (XEXP (x, 1), orig, new, size); + change_arg_use_of_insns (XEXP (x, 2), orig, new, size); + break; + + default: + break; + } + + /* Scan all subexpressions. */ + fmt = GET_RTX_FORMAT (code); + for (i = 0; i < GET_RTX_LENGTH (code); i++, fmt++) + if (*fmt == 'e') + { + if (XEXP (x, i) == orig) + { + XEXP (x, i) = new; + continue; + } + change_arg_use_in_operand (XEXP (x, i), orig, new, size); + } + else if (*fmt == 'E') + for (j = 0; j < XVECLEN (x, i); j++) + { + + if (XVECEXP (x, i, j) == orig) + { + XVECEXP (x, i, j) = new; + continue; + } + change_arg_use_in_operand (XVECEXP (x, i, j), orig, new, size); + } + } + + static int + replace_return_reg (first, return_save) + rtx first, return_save; + { + rtx return_reg = DECL_RTL (DECL_RESULT (current_function_decl)); + rtx insn; + + /* comfirm that insn patterns are the expected order */ + for (insn = first; insn; insn = NEXT_INSN (insn)) + { + if (GET_RTX_CLASS (GET_CODE (insn)) == 'i') + { + + rtx prev; + + if (PREV_INSN (insn)) prev = PREV_INSN (insn); + + if (GET_CODE (PATTERN (insn)) == USE && XEXP (PATTERN (insn), 0) == return_reg) + if (!(prev && GET_CODE (PATTERN (prev)) == SET && XEXP (PATTERN (prev), 0) == return_reg)) + return FALSE; + } + } + + /* replace return register */ + for (insn = first; insn; insn = NEXT_INSN (insn)) + { + if (GET_RTX_CLASS (GET_CODE (insn)) == 'i') + { + rtx prev; + + if (PREV_INSN (insn)) prev = PREV_INSN (insn); + if (GET_CODE (PATTERN (insn)) == USE + && XEXP (PATTERN (insn), 0) == return_reg + && prev + && GET_CODE (PATTERN (prev)) == SET + && XEXP (PATTERN (prev), 0) == return_reg) + { + XEXP (PATTERN (prev), 0) = return_save; + + /* change use insn to NOTE_INSN_DELETED */ + PUT_CODE (insn, NOTE); + NOTE_SOURCE_FILE (insn) = 0; + NOTE_LINE_NUMBER (insn) = NOTE_INSN_DELETED; + } + } + } + + return TRUE; + } + + + /* + Generate RTL to return from the current function, with value VAL. + It is copied and modified based on expand_value_return function of stmt.c + */ + + static void + expand_value_return (val) + rtx val; + { + rtx return_reg = DECL_RTL (DECL_RESULT (current_function_decl)); + + /* Copy the value to the return location + unless it's already there. */ + + if (return_reg != val) + { + #ifdef PROMOTE_FUNCTION_RETURN + tree type = TREE_TYPE (DECL_RESULT (current_function_decl)); + int unsignedp = TREE_UNSIGNED (type); + enum machine_mode mode + = promote_mode (type, DECL_MODE (DECL_RESULT (current_function_decl)), + &unsignedp, 1); + + if (GET_MODE (val) != VOIDmode && GET_MODE (val) != mode) + convert_move (return_reg, val, unsignedp); + else + #endif + emit_move_insn (return_reg, val); + } + if (GET_CODE (return_reg) == REG + && REGNO (return_reg) < FIRST_PSEUDO_REGISTER) + emit_insn (gen_rtx_USE (VOIDmode, return_reg)); + /* Handle calls that return values in multiple non-contiguous locations. + The Irix 6 ABI has examples of this. */ + else if (GET_CODE (return_reg) == PARALLEL) + { + int i; + + for (i = 0; i < XVECLEN (return_reg, 0); i++) + { + rtx x = XEXP (XVECEXP (return_reg, 0, i), 0); + + if (GET_CODE (x) == REG + && REGNO (x) < FIRST_PSEUDO_REGISTER) + emit_insn (gen_rtx_USE (VOIDmode, x)); + } + } + } + + + + + /* + The following codes are invoked after the instantiation of pseuso registers. + + Reorder local variables to place a peudo register after buffers to avoid + the corruption of local variables that could be used to further corrupt + arbitrary memory locations. + */ + #ifndef FRAME_GROWS_DOWNWARD + static void push_frame PARAMS ((int var_size)); + static void push_frame_in_decls PARAMS ((tree block, int push_size)); + static void push_frame_in_args PARAMS ((tree parms, int push_size)); + static void push_frame_of_insns PARAMS ((rtx insn, int push_size)); + static void push_frame_in_operand PARAMS ((rtx orig, int push_size)); + static void push_frame_of_reg_equiv_memory_loc PARAMS ((int push_size)); + static void push_frame_of_reg_equiv_constant PARAMS ((int push_size)); + static void reset_used_flags_for_push_frame PARAMS ((void)); + #endif + + rtx + assign_stack_local_for_pseudo_reg (mode, size, align) + enum machine_mode mode; + HOST_WIDE_INT size; + int align; + { + #ifdef FRAME_GROWS_DOWNWARD + return assign_stack_local (mode, size, align); + #else + tree blocks = DECL_INITIAL (current_function_decl); + rtx new; + HOST_WIDE_INT previous_frame_offset, offset; + + previous_frame_offset = frame_offset; + new = assign_stack_local (mode, size, align); + if (! flag_propolice_protection + || size == 0 + || ! blocks || TREE_CODE (blocks) != BLOCK + || DECL_INLINE (current_function_decl) + || ! search_string_from_argsandvars () + || query_trampoline_list()) + return new; + + push_frame (frame_offset - previous_frame_offset); + + /* If we have already instantiated virtual registers, return the actual + address relative to the frame pointer. */ + /*if (virtuals_instantiated) {*/ + offset = DEBUGGER_AUTO_OFFSET(XEXP (new, 0)); + + offset -= previous_frame_offset; + XEXP (XEXP (new, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + /*}*/ + + return new; + #endif + } + + + #ifndef FRAME_GROWS_DOWNWARD + /* + push frame infomation for instantiating pseudo register at the top of stack. + This is only for the "frame grows upward", it means FRAME_GROWS_DOWNWARD is + not defined. + + It is called by purge_addressof function and global_alloc (or reload) + function. + */ + static void + push_frame (var_size) + int var_size; + { + reset_used_flags_for_push_frame(); + + /* scan all declarations of variables and fix the offset address of the variable based on the frame pointer */ + push_frame_in_decls (DECL_INITIAL (current_function_decl), var_size); + + /* scan all argument variable and fix the offset address based on the frame pointer */ + push_frame_in_args (DECL_ARGUMENTS (current_function_decl), var_size); + + /* scan all operands of all insns and fix the offset address based on the frame pointer */ + push_frame_of_insns (get_insns (), var_size); + + /* scan all reg_equiv_memory_loc and reg_equiv_constant*/ + push_frame_of_reg_equiv_memory_loc (var_size); + push_frame_of_reg_equiv_constant (var_size); + + reset_used_flags_for_push_frame(); + } + + static void + reset_used_flags_for_push_frame() + { + int i; + extern rtx *reg_equiv_memory_loc; + extern rtx *reg_equiv_constant; + + /* Clear all the USED bits in operands of all insns and declarations of local vars */ + reset_used_flags_for_decls (DECL_INITIAL (current_function_decl)); + reset_used_flags_for_insns (get_insns ()); + + + /* The following codes are processed if the push_frame is called from + global_alloc (or reload) function */ + if (reg_equiv_memory_loc == 0) return; + + for (i=LAST_VIRTUAL_REGISTER+1; i < max_regno; i++) + if (reg_equiv_memory_loc[i]) + { + rtx x = reg_equiv_memory_loc[i]; + + if (GET_CODE (x) == MEM + && GET_CODE (XEXP (x, 0)) == PLUS + && DEBUGGER_AUTO_BASEPTR (XEXP (x, 0)) == frame_pointer_rtx) + { + /* reset */ + XEXP (x, 0)->used = 0; + } + } + + + if (reg_equiv_constant == 0) return; + + for (i=LAST_VIRTUAL_REGISTER+1; i < max_regno; i++) + if (reg_equiv_constant[i]) + { + rtx x = reg_equiv_constant[i]; + + if (GET_CODE (x) == PLUS + && DEBUGGER_AUTO_BASEPTR (x) == frame_pointer_rtx) + { + /* reset */ + x->used = 0; + } + } + } + + static void + push_frame_in_decls (block, push_size) + tree block; + int push_size; + { + tree types; + HOST_WIDE_INT offset; + rtx home; + + while (block) + { + types = BLOCK_VARS(block); + + while (types) + { + /* skip the declaration that refers an external variable and + also skip an global variable */ + if (! DECL_EXTERNAL (types) && ! TREE_STATIC (types)) + { + + home = DECL_RTL (types); + if (home == 0) goto next; + + /* process for static local variable */ + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == SYMBOL_REF) + goto next; + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == REG) + { + goto next; + } + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == MEM) + { + + /* process for dynamically allocated aray */ + home = XEXP (home, 0); + } + + if (GET_CODE (home) == MEM + && GET_CODE (XEXP (home, 0)) == PLUS + && GET_CODE (XEXP (XEXP (home, 0), 1)) == CONST_INT) + { + if (! XEXP (home, 0)->used) + { + offset = DEBUGGER_AUTO_OFFSET(XEXP (home, 0)); + + offset += push_size; + XEXP (XEXP (home, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + XEXP (home, 0)->used = 1; + } + } + + } + next: + types = TREE_CHAIN(types); + } + + push_frame_in_decls (BLOCK_SUBBLOCKS (block), push_size); + block = BLOCK_CHAIN (block); + } + } + + + static void + push_frame_in_args (parms, push_size) + tree parms; + int push_size; + { + rtx home; + HOST_WIDE_INT offset; + + for (; parms; parms = TREE_CHAIN (parms)) + if (DECL_NAME (parms) && TREE_TYPE (parms) != error_mark_node) + { + if (PARM_PASSED_IN_MEMORY (parms) && DECL_NAME (parms)) + { + home = DECL_INCOMING_RTL (parms); + + if (XEXP (home, 0)->used) continue; + + offset = DEBUGGER_AUTO_OFFSET(XEXP (home, 0)); + + /* the operand related to the sweep variable */ + if (DEBUGGER_AUTO_BASEPTR (XEXP (home, 0)) == frame_pointer_rtx) + { + offset += push_size; + XEXP (XEXP (home, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + XEXP (home, 0)->used = 1; + } + } + } + } + + + static void + push_frame_of_insns (insn, push_size) + rtx insn; + int push_size; + { + for (; insn; insn = NEXT_INSN (insn)) + if (GET_CODE (insn) == INSN || GET_CODE (insn) == JUMP_INSN + || GET_CODE (insn) == CALL_INSN) + { + push_frame_in_operand (PATTERN (insn), push_size); + + /* push frame in NOTE */ + push_frame_in_operand (REG_NOTES (insn), push_size); + + /* push frame in CALL EXPR_LIST */ + if (GET_CODE (insn) == CALL_INSN) + push_frame_in_operand (CALL_INSN_FUNCTION_USAGE (insn), push_size); + } + } + + + static void + push_frame_in_operand (orig, push_size) + rtx orig; + int push_size; + { + register rtx x = orig; + register enum rtx_code code; + int offset, i, j; + const char *fmt; + + if (x == 0) + return; + + code = GET_CODE (x); + + switch (code) + { + case CONST_INT: + case CONST_DOUBLE: + case CONST: + case SYMBOL_REF: + case CODE_LABEL: + case PC: + case CC0: + case ASM_INPUT: + case ADDR_VEC: + case ADDR_DIFF_VEC: + case RETURN: + case REG: + case ADDRESSOF: + return; + + case SET: + break; + + case PLUS: + /* Handle special case of frame register plus constant. */ + if (CONSTANT_P (XEXP (x, 1)) + && XEXP (x, 0) == frame_pointer_rtx + && ! x->used) + { + offset = DEBUGGER_AUTO_OFFSET(x); + + offset += push_size; + + /* XEXP (x, 0) is frame_pointer_rtx */ + XEXP (x, 1) = gen_rtx_CONST_INT (VOIDmode, offset); + x->used = 1; + + return; + } + /* + process further subtree: + Example: (plus:SI (mem/s:SI (plus:SI (reg:SI 17) (const_int 8))) + (const_int 5)) + */ + break; + + case CALL_PLACEHOLDER: + push_frame_of_insns (XEXP (x, 0), push_size); + push_frame_of_insns (XEXP (x, 1), push_size); + push_frame_of_insns (XEXP (x, 2), push_size); + break; + + default: + break; + } + + /* Scan all subexpressions. */ + fmt = GET_RTX_FORMAT (code); + for (i = 0; i < GET_RTX_LENGTH (code); i++, fmt++) + if (*fmt == 'e') + { + push_frame_in_operand (XEXP (x, i), push_size); + } + else if (*fmt == 'E') + for (j = 0; j < XVECLEN (x, i); j++) + push_frame_in_operand (XVECEXP (x, i, j), push_size); + } + + static void + push_frame_of_reg_equiv_memory_loc (push_size) + int push_size; + { + int i; + extern rtx *reg_equiv_memory_loc; + + /* This function is processed if the push_frame is called from + global_alloc (or reload) function */ + if (reg_equiv_memory_loc == 0) return; + + for (i=LAST_VIRTUAL_REGISTER+1; i < max_regno; i++) + if (reg_equiv_memory_loc[i]) + { + rtx x = reg_equiv_memory_loc[i]; + int offset; + + if (GET_CODE (x) == MEM + && GET_CODE (XEXP (x, 0)) == PLUS + && XEXP (XEXP (x, 0), 0) == frame_pointer_rtx) + { + if (! XEXP (x, 0)->used) + { + offset = DEBUGGER_AUTO_OFFSET(XEXP (x, 0)); + + offset += push_size; + XEXP (XEXP (x, 0), 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + XEXP (x, 0)->used = 1; + } + } + } + } + + static void + push_frame_of_reg_equiv_constant (push_size) + int push_size; + { + int i; + extern rtx *reg_equiv_constant; + + /* This function is processed if the push_frame is called from + global_alloc (or reload) function */ + if (reg_equiv_constant == 0) return; + + for (i=LAST_VIRTUAL_REGISTER+1; i < max_regno; i++) + if (reg_equiv_constant[i]) + { + rtx x = reg_equiv_constant[i]; + int offset; + + if (GET_CODE (x) == PLUS + && XEXP (x, 0) == frame_pointer_rtx) + { + if (! x->used) + { + offset = DEBUGGER_AUTO_OFFSET(x); + + offset += push_size; + XEXP (x, 1) = gen_rtx_CONST_INT (VOIDmode, offset); + + /* mark */ + x->used = 1; + } + } + } + } + #endif + + + void + set_debuginfo_of_escaped_arg (rtx new, rtx old) + { + int idx; + + if (flag_propolice_protection) + for (idx = 0; idx < escaped_arg_list_size; idx++) + if (escaped_arg_list[idx].original == old) + { + /* change debugger info */ + escaped_arg_list[idx].escaped = new; + } + } + + + void + update_debuginfo_using_escaped_arg_list (tree parms) + { + rtx orig = DECL_RTL (parms); + int idx; + + if (flag_propolice_protection && PARM_PASSED_IN_MEMORY (parms)) + for (idx = 0; idx < escaped_arg_list_size; idx++) + if (escaped_arg_list[idx].original == orig) + { + rtx escaped = escaped_arg_list[idx].escaped; + + /* skip in the case where the escaped register was deleted */ + if (GET_CODE (escaped) == REG + && REGNO (escaped) >= FIRST_PSEUDO_REGISTER) + break; + + DECL_INCOMING_RTL (parms) = escaped; + break; + } + } *** /dev/null Sat May 19 03:36:36 2001 --- sys/libkern/stack_smash_handler.c Fri May 18 15:22:09 2001 *************** *** 0 **** --- 1,7 ---- + int __guard = '\0\0\n\777'; + + void __stack_smash_handler (int damaged, char func[]) + { + static char *message = "propolice detects %x at function %s.\n" ; + panic (message, damaged, func); + } ----Next_Part(Sat_May_19_09:32:24_2001_518)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 18:13: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from femail9.sdc1.sfba.home.com (femail9.sdc1.sfba.home.com [24.0.95.89]) by hub.freebsd.org (Postfix) with ESMTP id 7BE4137B422 for ; Fri, 18 May 2001 18:13:03 -0700 (PDT) (envelope-from mixtim@home.com) Received: from cg392862-a.adubn1.nj.home.com ([65.2.79.221]) by femail9.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010519011302.GUCB17191.femail9.sdc1.sfba.home.com@cg392862-a.adubn1.nj.home.com>; Fri, 18 May 2001 18:13:02 -0700 Received: (from mixtim@localhost) by cg392862-a.adubn1.nj.home.com (8.11.3/8.11.3) id f4J1D1n53784; Fri, 18 May 2001 21:13:01 -0400 (EDT) (envelope-from mixtim) Date: Fri, 18 May 2001 21:13:01 -0400 From: Mixtim To: Hiroaki Etoh Cc: security@FreeBSD.ORG Subject: Re: Base system with gcc stack-smashing protector Message-ID: <20010518211301.A53682@home.com> References: <20010519093227T.etoh@trl.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519093227T.etoh@trl.ibm.com>; from etoh@trl.ibm.co.jp on Sat, May 19, 2001 at 09:32:27AM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, May 19, 2001 at 09:32:27AM +0900, Hiroaki Etoh wrote: > At last, I have completed GCC extension for protectiong applications > against stack smashing attack. It works on Intel x86 processor and IBM > powerpc. Have you seen Phrack Magazine issue 56, article 5? The title is "Bypassing StackGuard and StackShield." "This article is an attempt to demonstrate that it is possible to exploit stack overflow vulnerabilities on systems secured by StackGuard or StackShield even in hostile environments (such as when the stack is non-executable)." Does your patch address their concerns? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri May 18 21: 5:22 2001 Delivered-To: freebsd-security@freebsd.org Received: from cs4.cs.ait.ac.th (cs4.cs.ait.ac.th [192.41.170.16]) by hub.freebsd.org (Postfix) with ESMTP id 4CAFA37B42C; Fri, 18 May 2001 21:05:14 -0700 (PDT) (envelope-from Olivier.Nicole@ait.ac.th) Received: from bazooka.cs.ait.ac.th (on@bazooka.cs.ait.ac.th [192.41.170.2]) by cs4.cs.ait.ac.th (8.9.3/8.9.3) with ESMTP id LAA15828; Sat, 19 May 2001 11:02:21 +0700 (GMT+0700) From: Olivier Nicole Received: (from on@localhost) by bazooka.cs.ait.ac.th (8.8.5/8.8.5) id LAA13512; Sat, 19 May 2001 11:04:17 +0700 (ICT) Date: Sat, 19 May 2001 11:04:17 +0700 (ICT) Message-Id: <200105190404.LAA13512@bazooka.cs.ait.ac.th> To: never@uic-in.net Cc: ume@mahoroba.org, freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG In-reply-to: <20010518190308.A34705@uic-in.net> (never@uic-in.net) Subject: Re: AUTH and sendmail Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org HI, What I enjoy about poprelayd is that it does not need any patch to th pop/imap server. It reads the syslog output. And as it is written in Perl, it i pretty straight forward to adapt it to nearly any form of log message, even for non standard pop/imap server just throw a regular expression in. I use it with UW-imap myself. (my concern was how to modify sendmail.cf to include the checking of the open relay table :) I recon that having a Perl process running all the time to check the syslog file is not the nicest solution, a friends reports that on his ISP email server it uses up to 15% of the resources, but they are handling thousands of emails every minute. In my case, it should not proceed more than one connection every day so the process will not be overloaded... :) I would accept a pointer to drac, just to have a look. Best regards, Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat May 19 9:29: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from cocoja.holywar.net (cocoja.holywar.net [211.232.190.142]) by hub.freebsd.org (Postfix) with ESMTP id B2CF837B440 for ; Sat, 19 May 2001 09:28:56 -0700 (PDT) (envelope-from lala@cocoja.holywar.net) Received: (from lala@localhost) by cocoja.holywar.net (8.11.3/8.11.1) id f4JGSsw57747 for freebsd-security@freebsd.org; Sun, 20 May 2001 01:28:54 +0900 (KST) (envelope-from lala) Date: Sun, 20 May 2001 01:28:53 +0900 From: hosang yoon To: freebsd-security@freebsd.org Subject: Re: SRA.. Message-ID: <20010520012853.A57656@cocoja.holywar.net> Reply-To: hosang yoon Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010507123414.X2167-100000@citadel.simphost.com>; from jlschwab@simphost.com on Mon, May 07, 2001 at 12:35:47PM -0400 Organization: x-of-charm-and-honesty PGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCFC8D3FA PGP-Fingerprint: FCD2 3E42 5DF1 AC68 4C29 DDD2 684A 3438 CFC8 D3FA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org to disable the SRA feature, edit telnetd line of /etc/inetd.conf like below, [snip] /usr/libexec/telnetd telnetd -a off -X sra cheers, @ jlschwab wrote: : Heya Guys and Gals; : : Trying any.of.my.machines.ips... : Connected to X.X.X.X. : Escape character is '^]'. : Trying SRA secure login: : User (root): Password: : : what is SRA, secure telnet login? : and how can I disable this? : : I also noticed it only works from freebsd -> freebsd boxes : : thanks. -- http://lara.xocah.org:1919 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat May 19 11:57:53 2001 Delivered-To: freebsd-security@freebsd.org Received: from be-well.ilk.org (lowellg.ne.mediaone.net [24.147.184.128]) by hub.freebsd.org (Postfix) with ESMTP id DB19B37B42C for ; Sat, 19 May 2001 11:57:50 -0700 (PDT) (envelope-from lowell@be-well.ilk.org) Received: (from lowell@localhost) by be-well.ilk.org (8.11.3/8.11.3) id f4JIvoG32866; Sat, 19 May 2001 14:57:50 -0400 (EDT) (envelope-from lowell) To: freebsd-security@freebsd.org Subject: Re: IPFW Rule -1 Always = Attack? References: <200105181518.WAA12362@bazooka.cs.ait.ac.th> <046c01c0dfc0$833e7fc0$213cd3cf@loop.com> From: Lowell Gilbert Date: 19 May 2001 14:57:50 -0400 In-Reply-To: dwplists@loop.com's message of "18 May 2001 19:32:59 +0200" Message-ID: <44y9rtf9ox.fsf@lowellg.ne.mediaone.net> Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org dwplists@loop.com (D. W. Piper) writes: > If I understand things correctly from the archives and the IPFW man > page, IPFW rule -1 is built into the firewall, and only applies to > rejecting IP fragments with a fragment offset of one. The man page > further states, "This is a valid packet, but it only has one use, to try > to circumvent firewalls." > > Does that mean that every packet dropped by rule -1 indicates a > deliberate attempt to circumvent the firewall, and should be reported to > the appropriate network administrator for the source IP address? It's *possible* that the rule could be triggered by something that wasn't an attack. Thinking about it briefly, it seems slightly more likely that it's part of a probe, rather than an actual attack However, reporting to the network administrator for that address is almost certainly useless in any case, because an attacker would probably have spoofed that address anyway. [An attacker wouldn't ever get any response from that packet in any case.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message