From owner-freebsd-security Sun Mar 9 09:09:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA00920 for security-outgoing; Sun, 9 Mar 1997 09:09:41 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA00915 for ; Sun, 9 Mar 1997 09:09:37 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id JAA00702; Sun, 9 Mar 1997 09:08:59 -0800 (PST) Message-Id: <199703091708.JAA00702@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd000699; Sun Mar 9 17:08:51 1997 Reply-to: cys@mailhost.wlc.com X-Mailer: MH To: Garrett Wollman cc: "Daniel O'Callaghan" , freebsd-security@freebsd.org Subject: Re: 4.4BSD NFS File Handles (fwd) In-reply-to: Your message of "Fri, 07 Mar 1997 09:30:13 EST." <9703071430.AA26267@halloran-eldar.lcs.mit.edu> Date: Sun, 09 Mar 1997 09:08:50 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > < said: > > > if (suser(p->p_ucred, &p->p_acflag)) { > > sb->st_gen = 0; > > } else { > > sb->st_gen = vap->va_gen; > > } > > This test is bogus. The problem is that is causes p_acflag to get the > ``used superuser privileges'' bit set every time a root process calls > stat(). Since most processes call stat() at least once in their > lifetime, this would make p_acflag completely useless. Agreed. Replacing the "if (suser(p->p_ucred, &p->p_acflag)) {" in the patch with "if (p->p_cred->pc_ucred->cr_uid == 0) {" should address this concern. > > I'm certainly willing to live with not making this information > available through the stat(2) interface at all. Any process with > appropriate privilege can simply read the information off the disk > anyway, so I don't see any benefit in having it here. (A process with > appropriate privilege can also call getfh(2) and parse the returned > handle.) I disagree. This field is returned by other UNICES, notably DEC UNIX among others. Removing it would cause some portability concerns in some cases, e.g. some code may not compile right-out-of-the-box. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Sun Mar 9 11:55:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07554 for security-outgoing; Sun, 9 Mar 1997 11:55:01 -0800 (PST) Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07545 for ; Sun, 9 Mar 1997 11:54:51 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id LAA00737; Sun, 9 Mar 1997 11:54:43 -0800 (PST) Message-Id: <199703091954.LAA00737@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd000734; Sun Mar 9 19:54:41 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: freebsd-security@freebsd.org cc: Garrett Wollman , "Daniel O'Callaghan" Subject: Re: 4.4BSD NFS File Handles (fwd) In-reply-to: Your message of "Sun, 09 Mar 1997 09:08:50 PST." <199703091708.JAA00702@cwsys.cwent.com> Date: Sun, 09 Mar 1997 11:54:41 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have tested my suggestion below on both of my 2.1.6 systems using the following test program; #include #include #include main() { struct stat sb; if (stat("/usr",&sb)) { perror("stat error"); exit(1); } printf("%ud\n",sb.st_gen); } The modified patch returns zero in sb.st_gen for non-root users, yet does not set the flag indicating the use of superuser powers. (I agree with Garret that filling a field via a commonly used system call does not quailfy to set the superuser-power-used flag). The patch is based on 2.1.6 as distributed on CDROM. --- sys/kern/vfs_vnops.c.orig Thu Oct 26 02:17:22 1995 +++ sys/kern/vfs_vnops.c Sun Mar 9 09:28:11 1997 @@ -395,7 +395,10 @@ sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; - sb->st_gen = vap->va_gen; + if (p->p_cred->pc_ucred->cr_uid == 0) + sb->st_gen = vap->va_gen; + else + sb->st_gen = 0; sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } Since I maintain a diverse range of platforms at work, five different vendors at last count, and since I build infrastructure or at least test some concepts at home, maintaining compatibility with these platforms is important to me as it reduces the number customizations I need to do for to get the same package to work on all platforms. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." > > < hilink.com.au> said: > > > > > if (suser(p->p_ucred, &p->p_acflag)) { > > > sb->st_gen = 0; > > > } else { > > > sb->st_gen = vap->va_gen; > > > } > > > > This test is bogus. The problem is that is causes p_acflag to get the > > ``used superuser privileges'' bit set every time a root process calls > > stat(). Since most processes call stat() at least once in their > > lifetime, this would make p_acflag completely useless. > > Agreed. Replacing the "if (suser(p->p_ucred, &p->p_acflag)) {" in the > patch with "if (p->p_cred->pc_ucred->cr_uid == 0) {" should address this > concern. > > > > > I'm certainly willing to live with not making this information > > available through the stat(2) interface at all. Any process with > > appropriate privilege can simply read the information off the disk > > anyway, so I don't see any benefit in having it here. (A process with > > appropriate privilege can also call getfh(2) and parse the returned > > handle.) > > I disagree. This field is returned by other UNICES, notably DEC UNIX among > others. Removing it would cause some portability concerns in some cases, > e.g. some code may not compile right-out-of-the-box. From owner-freebsd-security Sun Mar 9 14:37:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16960 for security-outgoing; Sun, 9 Mar 1997 14:37:06 -0800 (PST) Received: from smtp.connectnet.com (smtp.connectnet.com [207.110.0.12]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16955 for ; Sun, 9 Mar 1997 14:37:04 -0800 (PST) Received: from wink.connectnet.com (Studded@wink.connectnet.com [206.251.156.23]) by smtp.connectnet.com (8.8.5/Connectnet-2.2) with SMTP id OAA14069; Sun, 9 Mar 1997 14:37:58 -0800 (PST) Message-Id: <199703092237.OAA14069@smtp.connectnet.com> From: "That Doug Guy" To: "namedroppers@internic.net" Cc: "freebsd-security@freebsd.org" Date: Sun, 09 Mar 97 14:36:53 -0800 Reply-To: "That Doug Guy" Priority: Normal X-Mailer: That Doug Guy's Registered PMMail 1.9 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Fwd: BIND-4.9.5-P1 Denial of service attack Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is forwarded here with permission. I run a secondary dns that uses 4.9.4-P1, so I'm wondering if this vulnerability exists there as well. Thank you, Doug PS, also forwarded to freebsd-security since the upcoming 2.2-Release version makes use of Bind 4.9.5-P1 to my knowledge. ==================BEGIN FORWARDED MESSAGE================== >Date: Sun, 9 Mar 1997 03:22:59 -0500 >Reply-To: Jared Mauch >From: Jared Mauch >Subject: BIND-4.9.5-P1 DoS Attack >To: BUGTRAQ@NETSPACE.ORG From the bind-workers list. This includes the relevant patch to fix the problem. - Jared ----- Forwarded message from Mark.Andrews@cmis.csiro.au ----- >From bind-workers-request@vix.com Sun Mar 9 03:21:17 1997 Message-Id: <9703090551.AA14395@dmssyd.syd.dms.CSIRO.AU> To: Irwin Tillman Cc: bind-workers@vix.com From: Mark.Andrews@cmis.csiro.au Subject: Re: BIND-4.9.5-P1 possible denial of service attack In-Reply-To: Your message of "Wed, 05 Mar 1997 09:48:20 EST." <199703051448.JAA06909@scramble.Princeton.EDU> Date: Sun, 09 Mar 1997 16:51:11 +1100 Sender: Precedence: bulk Reply-To: Mark.Andrews@cmis.csiro.au > I'm forwarding this to bind-workers, since I've just seen > a report related to this bug in comp.protocols.tcp-ip-domains. > > /irwin > > ------- Forwarded Message > > Date: Mon, 24 Feb 1997 16:47:50 -0500 > From: Irwin Tillman > To: Paul Vixie > Subject: BIND-4.9.5-P1 possible denial of service attack > > I ran into what looks like a bug in BIND-4.9.5-P1. I apologize in > advance for mailing this to you rather than to bind-workers. I thought > I should try this first, since the bug looks like it opens a potential > denial of service attack, as well as a way to cause performance > problems on hosts running named. If you feel I should send this > to bind-workers or somewhere else instead, just let me know. > > > To reproduce: > > From a SunOS client, I telnetted to port 53 of a host running BIND-4.9.5-P1. > Once the connection was open, entered "foobar", hit return, then closed > the telnet connection (control-rightbracket 'quit'). > > The symptoms you see on the server is that named will no longer accept any > TCP connections (zone transfers from the server fail, as well as simple > TCP-based queries). The named process may also consume lots of CPU now, > affecting the rest of the system. > > Tracing the named process shows that when it receives this bogus message, it > tries (and keeps trying) to read and write this socket, first resulting in > a ECONNRESET, and then result in repeated EPIPE. It appears to be in a prett > y > tight loop, presumably accounting for the system-wide impact. > > BIND-4.9.3-P1 doesn't have this problem. It just closed the socket and went > back to the main polling loop. > > > I tested on the following platform: > Sun SPARCstation 5 running SunOS 4.1.4 > BIND-4.9.5-P1 > Default options.h file > Default Makefile, with the standard sunos4.1.x section in the Makefile > uncommented, using /usr/bin/cc, and not building the shared library version > > of libresolv. > (Also tested on Solaris 2.5.1 with gcc.) > > > -- > > Irwin Tillman, irwin@princeton.edu > CIT Network Systems, Princeton University > > > > ------- End of Forwarded Message > > > > Apply the following patch. This is from inspection of the code. If the socket has a non blocking error or EOF is detected just close rather than trying to send a error message on the socket. Mark *** ns_main.c.001 Tue Jan 7 15:06:17 1997 --- ns_main.c Sun Mar 9 16:46:53 1997 *************** *** 866,871 **** --- 866,877 ---- sp->s_bufp += n; sp->s_size -= n; } + if ((n == -1) && (errno == PORT_WOULDBLK)) + continue; + if (n <= 0) { + sqrm(sp); + continue; + } /* * we don't have enough memory for the query. * if we have a query id, then we will send an *************** *** 909,920 **** HFIXEDSZ); } continue; - } - if ((n == -1) && (errno == PORT_WOULDBLK)) - continue; - if (n <= 0) { - sqrm(sp); - continue; } /* * Consult database to get the answer. --- 915,920 ---- -- Mark Andrews, CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews ----- End of forwarded message from Mark.Andrews@cmis.csiro.au ----- -- To err is human, to forgive is Not Company Policy. -- Jared Mauch - CICNet - jared@cic.net - http://www.cic.net/ - visit my personal page at http://puck.nether.net/~jared/ ===================END FORWARDED MESSAGE=================== From owner-freebsd-security Mon Mar 10 01:11:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA05446 for security-outgoing; Mon, 10 Mar 1997 01:11:32 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA05438 for ; Mon, 10 Mar 1997 01:11:24 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id KAA11966; Mon, 10 Mar 1997 10:10:03 +0100 (MET) From: Guido van Rooij Message-Id: <199703100910.KAA11966@gvr.win.tue.nl> Subject: Re: 4.4BSD NFS File Handles (fwd) In-Reply-To: <199703091954.LAA00737@cwsys.cwent.com> from Cy Schubert at "Mar 9, 97 11:54:41 am" To: cschuber@uumail.gov.bc.ca Date: Mon, 10 Mar 1997 10:10:03 +0100 (MET) Cc: freebsd-security@freebsd.org, wollman@lcs.mit.edu, danny@panda.hilink.com.au X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Cy Schubert wrote: > --- sys/kern/vfs_vnops.c.orig Thu Oct 26 02:17:22 1995 > +++ sys/kern/vfs_vnops.c Sun Mar 9 09:28:11 1997 > @@ -395,7 +395,10 @@ > sb->st_ctimespec = vap->va_ctime; > sb->st_blksize = vap->va_blocksize; > sb->st_flags = vap->va_flags; > - sb->st_gen = vap->va_gen; > + if (p->p_cred->pc_ucred->cr_uid == 0) > + sb->st_gen = vap->va_gen; > + else > + sb->st_gen = 0; > sb->st_blocks = vap->va_bytes / S_BLKSIZE; > return (0); > } > This was added last friday though slightly modified: if (p->p_ucred->cr_uid == 0) ... -Guido From owner-freebsd-security Tue Mar 11 04:53:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA28146 for security-outgoing; Tue, 11 Mar 1997 04:53:14 -0800 (PST) Received: from enteract.com (root@enteract.com [206.54.252.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA28136 for ; Tue, 11 Mar 1997 04:53:10 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id GAA14875 for freebsd-security@freebsd.org; Tue, 11 Mar 1997 06:53:09 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703111253.GAA14875@enteract.com> Subject: NFS security issue... To: freebsd-security@freebsd.org Date: Tue, 11 Mar 1997 06:53:07 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As we all know, the mount daemon can be configured to ignore mount procs originating on non-reserved ports. MOUNTPROC_NULL will time out from callrpc() if I'm a normal user requesting the service over loopback. Unfortunately, the same consideration doesn't seem to be given to NFS requests - I can successfully complete an NFSPROC_NULL through callrpc() as a normal user, can't find any code in sys/nfs/nfs_socket.c that ever checks the port on which NFS requests are originating, and can only assume that any arbitrary user on my system, with knowledge of an NFS file handle, can complete NFS transactions. Is there a reason why nfssvc() can't be told to check the port on incoming NFS requests? This seems to me to be a major loophole in the manner in which NFS RPC requests are validated. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?" From owner-freebsd-security Tue Mar 11 05:57:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA04046 for security-outgoing; Tue, 11 Mar 1997 05:57:30 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA04041 for ; Tue, 11 Mar 1997 05:57:24 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id OAA27007; Tue, 11 Mar 1997 14:57:13 +0100 (MET) From: Guido van Rooij Message-Id: <199703111357.OAA27007@gvr.win.tue.nl> Subject: Re: NFS security issue... In-Reply-To: <199703111253.GAA14875@enteract.com> from "Thomas H. Ptacek" at "Mar 11, 97 06:53:07 am" To: tqbf@enteract.com Date: Tue, 11 Mar 1997 14:57:13 +0100 (MET) Cc: freebsd-security@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Thomas H. Ptacek wrote: > > As we all know, the mount daemon can be configured to ignore mount procs > originating on non-reserved ports. MOUNTPROC_NULL will time out from > callrpc() if I'm a normal user requesting the service over loopback. > > Unfortunately, the same consideration doesn't seem to be given to NFS > requests - I can successfully complete an NFSPROC_NULL through callrpc() > as a normal user, can't find any code in sys/nfs/nfs_socket.c that ever > checks the port on which NFS requests are originating, and can only assume > that any arbitrary user on my system, with knowledge of an NFS file > handle, can complete NFS transactions. > > Is there a reason why nfssvc() can't be told to check the port on incoming > NFS requests? This seems to me to be a major loophole in the manner in > which NFS RPC requests are validated. > I agre. But this is only true for special setups where no systems are involved that you do not control. I still think it is a valid point you make. I made somethig using a syscvtl variable. Perhaps the discussion should be done againb... -Guido From owner-freebsd-security Tue Mar 11 17:28:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA29191 for security-outgoing; Tue, 11 Mar 1997 17:28:38 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA29173 for ; Tue, 11 Mar 1997 17:28:33 -0800 (PST) From: tqbf@char-star.rdist.org Received: from char-star.rdist.org by mail.crl.com with SMTP id AA05575 (5.65c/IDA-1.5 for ); Tue, 11 Mar 1997 17:20:40 -0800 Received: (qmail 206 invoked by uid 1001); 12 Mar 1997 01:19:54 -0000 Date: 12 Mar 1997 01:19:54 -0000 Message-Id: <19970312011954.205.qmail@char-star.rdist.org> To: guido@gvr.win.tue.nl, freebsd-security@freebsd.org Subject: Re: NFS security issue... In-Reply-To: <199703111357.OAA27007@gvr.win.tue.nl> Reply-To: tqbf@enteract.com Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199703111357.OAA27007@gvr.win.tue.nl>, you wrote: >I agre. But this is only true for special setups where no systems are involved I don't agree with you here. The NFS client code in the kernel even acknowledges that there are servers that require NFS requests to come in on privileged ports (I believe it's a mount option); I know this is the case with Suns. Given that the default is to disallow MOUNT service requests coming from unprivileged ports, I think there's an inconsistancy happening here. What's more, the fact that NFS requests work from unprivileged ports means that users with shell accounts on the NFS server can rapidly guess file handles over the loopback interface; nothing I can do with packet filtering or network partitioning can prevent this. Bad. >made somethig using a syscvtl variable. Perhaps the discussion should >be done againb... Ok, here's my take. Someone needs to document informally the procedure for creating a sysctl int at arbitrary positions in the kernel MIB - the sysctl code is a nightmare, and I get the impression that I don't really need to know how it works to add more object IDs. Once we know how to do that, the change to sys/nfs/nfs_socket.c to check privileged ports if "net.inet.nfs.secure" is on is trivial, and can be committed and tested immediately. This seems fairly urgent to me. Can I get some information about this? Thanks! -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ)); From owner-freebsd-security Wed Mar 12 05:06:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA09093 for security-outgoing; Wed, 12 Mar 1997 05:06:07 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA08975; Wed, 12 Mar 1997 05:03:16 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id OAA19396; Wed, 12 Mar 1997 14:03:00 +0100 (MET) From: Guido van Rooij Message-Id: <199703121303.OAA19396@gvr.win.tue.nl> Subject: Re: NFS security issue... In-Reply-To: <19970312011954.205.qmail@char-star.rdist.org> from "tqbf@char-star.rdist.org" at "Mar 12, 97 01:19:54 am" To: tqbf@enteract.com Date: Wed, 12 Mar 1997 14:03:00 +0100 (MET) Cc: freebsd-security@freebsd.org, core@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk tqbf@char-star.rdist.org wrote: > In article <199703111357.OAA27007@gvr.win.tue.nl>, you wrote: > >I agre. But this is only true for special setups where no systems are involved > > I don't agree with you here. The NFS client code in the kernel even > acknowledges that there are servers that require NFS requests to come in > on privileged ports (I believe it's a mount option); I know this is the > case with Suns. > > Given that the default is to disallow MOUNT service requests coming from > unprivileged ports, I think there's an inconsistancy happening here. > What's more, the fact that NFS requests work from unprivileged ports means > that users with shell accounts on the NFS server can rapidly guess file > handles over the loopback interface; nothing I can do with packet > filtering or network partitioning can prevent this. > > Bad. I do agree with you. The criticism given was that almost every environment you also have PC's where you can do the same. > > >made somethig using a syscvtl variable. Perhaps the discussion should > >be done againb... > > Ok, here's my take. Someone needs to document informally the procedure for > creating a sysctl int at arbitrary positions in the kernel MIB - the > sysctl code is a nightmare, and I get the impression that I don't really > need to know how it works to add more object IDs. > > Once we know how to do that, the change to sys/nfs/nfs_socket.c to check > privileged ports if "net.inet.nfs.secure" is on is trivial, and can be > committed and tested immediately. > Well it is really straightforwrad to do. In fact I had it lying around. I'll see what I can do. -Guido Cc: core From owner-freebsd-security Wed Mar 12 07:31:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA19532 for security-outgoing; Wed, 12 Mar 1997 07:31:00 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA19080; Wed, 12 Mar 1997 07:25:37 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA18864; Wed, 12 Mar 1997 10:25:11 -0500 Date: Wed, 12 Mar 1997 10:25:11 -0500 From: Garrett Wollman Message-Id: <9703121525.AA18864@halloran-eldar.lcs.mit.edu> To: Guido van Rooij Cc: freebsd-security@freebsd.org, core@freebsd.org Subject: Re: NFS security issue... In-Reply-To: <199703121303.OAA19396@gvr.win.tue.nl> References: <19970312011954.205.qmail@char-star.rdist.org> <199703121303.OAA19396@gvr.win.tue.nl> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: >> Once we know how to do that, the change to sys/nfs/nfs_socket.c to check >> privileged ports if "net.inet.nfs.secure" is on is trivial, and can be >> committed and tested immediately. >> > Well it is really straightforwrad to do. In fact I had it lying around. Except, of course, that it doesn't belong under net, it belongs under [v]fs.nfs. At this point, you may want to fix P-HK's breakage of sysctl variables for LKM filesystems. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Wed Mar 12 07:43:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA20602 for security-outgoing; Wed, 12 Mar 1997 07:43:49 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA19656; Wed, 12 Mar 1997 07:32:54 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA18955; Wed, 12 Mar 1997 10:32:48 -0500 Date: Wed, 12 Mar 1997 10:32:48 -0500 From: Garrett Wollman Message-Id: <9703121532.AA18955@halloran-eldar.lcs.mit.edu> To: Guido van Rooij Cc: freebsd-security@freebsd.org, core@freebsd.org Subject: Re: NFS security issue... In-Reply-To: <9703121525.AA18864@halloran-eldar.lcs.mit.edu> References: <19970312011954.205.qmail@char-star.rdist.org> <199703121303.OAA19396@gvr.win.tue.nl> <9703121525.AA18864@halloran-eldar.lcs.mit.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < Except, of course, that it doesn't belong under net, it belongs under > [v]fs.nfs. At this point, you may want to fix P-HK's breakage of > sysctl variables for LKM filesystems. One thing I forgot to mention... I am right now contemplating changing the socket interface to pass user credentials down to pru_bind(). This could be used, for example, to provide a more sophisticated access-control model for local port numbers (like blocking user attempts to bind to port 2049). Hopefully we can get rid of SS_PRIV completely... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-security Wed Mar 12 11:22:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA04738 for security-outgoing; Wed, 12 Mar 1997 11:22:35 -0800 (PST) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04427; Wed, 12 Mar 1997 11:16:36 -0800 (PST) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id UAA23339; Wed, 12 Mar 1997 20:16:25 +0100 (MET) From: Guido van Rooij Message-Id: <199703121916.UAA23339@gvr.win.tue.nl> Subject: Re: NFS security issue... In-Reply-To: <9703121532.AA18955@halloran-eldar.lcs.mit.edu> from Garrett Wollman at "Mar 12, 97 10:32:48 am" To: wollman@lcs.mit.edu (Garrett Wollman) Date: Wed, 12 Mar 1997 20:16:25 +0100 (MET) Cc: freebsd-security@freebsd.org, core@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman wrote: > < > > Except, of course, that it doesn't belong under net, it belongs under > > [v]fs.nfs. At this point, you may want to fix P-HK's breakage of > > sysctl variables for LKM filesystems. > > One thing I forgot to mention... > > I am right now contemplating changing the socket interface to pass > user credentials down to pru_bind(). This could be used, for example, > to provide a more sophisticated access-control model for local port > numbers (like blocking user attempts to bind to port 2049). Hopefully > we can get rid of SS_PRIV completely... > the local hackery is just an example. The same check for reserved ports also holds for non-local nfs requests. -Guido From owner-freebsd-security Fri Mar 14 14:53:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA16807 for security-outgoing; Fri, 14 Mar 1997 14:53:49 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA16759; Fri, 14 Mar 1997 14:52:38 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA14470; Fri, 14 Mar 1997 23:51:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id XAA21664; Fri, 14 Mar 1997 23:49:32 +0100 (MET) Message-ID: <19970314234929.RN36549@uriah.heep.sax.de> Date: Fri, 14 Mar 1997 23:49:29 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: schneider@zib.de (Wolfram Schneider) Cc: committers@freebsd.org, security@freebsd.org Subject: Re: ktrace security problem References: <199703141959.UAA09558@soft13.zib.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199703141959.UAA09558@soft13.zib.de>; from Wolfram Schneider on Mar 14, 1997 20:59:03 +0100 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Wolfram Schneider wrote: > Now the user wosch (I) can read all information from sendmail ;-( > IMHO ktrace should not overrides foreign ktrace.out files. Somebody please review this: cvs diff: Diffing /ktrace Index: ktrace/ktrace.c =================================================================== RCS file: /home/ncvs/src/usr.bin/ktrace/ktrace.c,v retrieving revision 1.8 diff -u -u -r1.8 ktrace.c --- ktrace.c 1997/02/22 19:55:27 1.8 +++ ktrace.c 1997/03/14 22:47:09 @@ -72,6 +72,7 @@ int append, ch, fd, inherit, ops, pid, pidset, trpoints; char *tracefile; mode_t omask; + struct stat sb; clear = NOTSET; append = ops = pidset = inherit = 0; @@ -140,8 +141,12 @@ } omask = umask(S_IRWXG|S_IRWXO); - if ((fd = open(tracefile, O_CREAT | O_WRONLY | (append ? 0 : O_TRUNC), - DEFFILEMODE)) < 0) + if (append) { + if (stat(tracefile, &sb) == 0 && sb.st_uid != getuid()) + errx(1, "Refuse to append to tracefile not owned by you"); + } else if (unlink(tracefile) == -1 && errno != ENOENT) + err(1, "Cannot unlink old tracefile"); + if ((fd = open(tracefile, O_CREAT | O_WRONLY, DEFFILEMODE)) < 0) err(1, tracefile); (void)umask(omask); (void)close(fd); -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)