From owner-freebsd-security Mon Mar 24 10:44:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA26221 for security-outgoing; Mon, 24 Mar 1997 10:44:29 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26211 for ; Mon, 24 Mar 1997 10:44:25 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id KAA07489 for ; Mon, 24 Mar 1997 10:46:33 -0800 (PST) Received: (qmail 2152 invoked by uid 110); 24 Mar 1997 18:43:54 -0000 Message-ID: <19970324184354.2150.qmail@suburbia.net> Subject: Re: cvs commit: src/lib/libtermcap pathnames.h termcap.c In-Reply-To: <228.859227442@critter> from Poul-Henning Kamp at "Mar 24, 97 07:17:22 pm" To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Tue, 25 Mar 1997 05:43:54 +1100 (EST) Cc: 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 > In message <97Mar24.094840pst.177486@crevenia.parc.xerox.com>, Bill Fenner writ > es: > >I think a lot would be solved by having a library function like > >access() that also accepts a UID. Then the don't-let-people-access- > >files-in-a-setuid-program-that-they-wouldn't-normally-have-access-to > >problem, instead of being solved in N different setuid programs, > >could be solved once. > > Well, access_as(2) alone will not do it, you would need a open_as(2), > unlink_as(2), rename_as(2) and so on... > > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. > Power and ignorance is a disgusting cocktail. > The access_as case is silly anyway, due to race conditions. From owner-freebsd-security Mon Mar 24 15:36:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19718 for security-outgoing; Mon, 24 Mar 1997 15:36:56 -0800 (PST) Received: from dns.pinpt.com (dns.pinpt.com [205.179.195.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19707 for ; Mon, 24 Mar 1997 15:36:53 -0800 (PST) Received: from rover4 (gatemaster.pinpt.com [205.179.195.65]) by dns.pinpt.com (8.6.12/8.6.12) with SMTP id PAA09107; Mon, 24 Mar 1997 15:34:59 -0800 Date: Mon, 24 Mar 97 15:35:23 Pacific Standard Time From: "Sean J. Schluntz" Subject: Re: =?ISO-8859-1?Q?=B4One_Direction=B4_Routed?= To: =?ISO-8859-1?Q?Ricardo_N=FA=F1ez?= , FreeBSD Security X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <19970321213136.AAA9659@telcel.telcel.net.ve> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I´d just want to know if the following project were possible with a FreeBSD > computer: > > If we could use a FreeBSD PC computer as a router between an Ethernet LAN > and Internet but in one direction. I mean: A LAN host could access > Internet, but an outside Internet host SHOULDN´T access an inside host, > just access that ´router´. An outside host could see the FreeBSD Web > Browser and anything else in the FreeBSD machine only. You could use a filter, or you could use a proxy (I prefur the proxy my self.) Look at http://www.tis.com look for The Fire Wall Tool Kit (FWTK). -Sean ---------------------------------------------------------------------- Sean J. Schluntz Manager, Support Services ph. 408.997.6900 x222 PinPoint Software Corporation fx. 408.323.2300 6155 Almaden Expressway, Suite 100 San Jose, CA. 95120 http://www.pinpt.com/ Local Time Sent: 03/24/97 15:35:24 ---------------------------------------------------------------------- From owner-freebsd-security Mon Mar 24 15:47:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA20565 for security-outgoing; Mon, 24 Mar 1997 15:47:35 -0800 (PST) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20560 for ; Mon, 24 Mar 1997 15:47:31 -0800 (PST) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id PAA17919; Mon, 24 Mar 1997 15:47:15 -0800 (PST) Message-Id: <3.0.32.19970324154830.00a93100@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 24 Mar 1997 15:48:30 -0800 To: skey-users@thumper.bellcore.com From: Ian Kallen Subject: building opie 2.31 on freeBSD 2.2 Cc: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The way stuff is cast in the header files seems to have changed from freeBSD 2.1.x to 2.2 -- what were previous "unsigned long" are now "u_int32_t" My efforts to compile opie 2.31 have been thwarted by "parse error ..." in dirent.h Anybody have a fix (a patch to opie?) or workaround that they'd recommend? thanks -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-security Tue Mar 25 03:56:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA07963 for security-outgoing; Tue, 25 Mar 1997 03:56:37 -0800 (PST) Received: from hq.admiral.ru (hq.admiral.ru [194.58.184.113]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA07956 for ; Tue, 25 Mar 1997 03:56:33 -0800 (PST) Received: from localhost.admiral.ru (localhost.admiral.ru [127.0.0.1]) by hq.admiral.ru (8.8.5/8.8.5.ADM) with SMTP id OAA08656 for ; Tue, 25 Mar 1997 14:55:50 +0300 (MSK) Message-Id: <199703251155.OAA08656@hq.admiral.ru> X-Authentication-Warning: hq.admiral.ru: localhost.admiral.ru [127.0.0.1] didn't use HELO protocol To: security@freebsd.org Date: Tue, 25 Mar 1997 14:55:50 +0300 From: Alex Krivoschokov Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe From owner-freebsd-security Tue Mar 25 11:40:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA03763 for security-outgoing; Tue, 25 Mar 1997 11:40:37 -0800 (PST) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03756 for ; Tue, 25 Mar 1997 11:40:34 -0800 (PST) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id LAA02406; Tue, 25 Mar 1997 11:40:05 -0800 (PST) Message-Id: <3.0.32.19970325114120.00816a20@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Mar 1997 11:41:33 -0800 To: skey-users@thumper.bellcore.com From: Ian Kallen Subject: Re: building opie 2.31 on freeBSD 2.2 Cc: freebsd-security@freebsd.org, cmetz@inner.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The fix seems to be: add #include as line 70 to opie_cfg.h so that it preceeds #include At 03:48 PM 3/24/97 -0800, Ian Kallen wrote: >The way stuff is cast in the header files seems to have changed from >freeBSD 2.1.x to 2.2 -- what were previous "unsigned long" are now >"u_int32_t" My efforts to compile opie 2.31 have been thwarted by "parse >error ..." in dirent.h Anybody have a fix (a patch to opie?) or workaround >that they'd recommend? > >thanks > > > >-- >Ian Kallen ian@gamespot.com > Director of Technology and Web Administration > SpotMedia Communications >http://www.gamespot.com/ http://www.videogamespot.com/ > > -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-security Tue Mar 25 22:08:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA18897 for security-outgoing; Tue, 25 Mar 1997 22:08:14 -0800 (PST) Received: from smtp.enteract.com (qmailr@char-star.rdist.org [206.54.252.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id WAA18891 for ; Tue, 25 Mar 1997 22:08:07 -0800 (PST) Received: (qmail 3784 invoked by uid 1001); 26 Mar 1997 06:07:51 -0000 Message-ID: <19970326060751.3783.qmail@smtp.enteract.com> From: tqbf@babel.enteract.com Subject: Privileged ports... To: freebsd-security@freebsd.org Date: Wed, 26 Mar 1997 00:07:51 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4ME+ PL31 (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 As part of a gradual effort to rid my kernel of suser() calls, I whipped up a quick patch to in_pcb.c that configurably removes the superuser restriction on binding privileged ports. This has the effect of removing the requirement for programs like rlogin and rsh to run with superuser privs, thus eliminating a few more SUID programs. In place of suser(), I've inserted two new sysctl OIDs under net.inet.ip - resv_uid and resv_gid. Any process running with an effective UID of "resv_uid" or belonging to group "resv_gid" can now bind low ports. The idea here is to set the system up so that a hole in "rlogin" or "rsh" no longer provides root access - instead, an attacker only has the ability to bind privileged ports. While this is a problem on some networks (obviously this breaks host trust), it's a benefit to networks that don't rely on the concept in the first place. Meanwhile, privileged ports are as restricted as they were before - the restrictions are just configurable. I'm interested in comments and suggestions regarding the implementation of more granularity in kernel-level privilege. Thanks to Guido van Rooij for showing me how FreeBSD's sysctl works. *** in_pcb.c-pre-tqbf Tue Mar 25 23:09:13 1997 --- in_pcb.c Tue Mar 25 23:39:34 1997 *************** *** 64,67 **** --- 64,69 ---- static void in_pcbinshash __P((struct inpcb *)); static void in_rtchange __P((struct inpcb *, int)); + static int in_okresvport __P((struct proc *)); + static int cred_isingroup __P((gid_t, struct proc *)); /* *************** *** 189,194 **** /* GROSS */ if (ntohs(lport) < IPPORT_RESERVED && ! (error = suser(p->p_ucred, &p->p_acflag))) ! return (EACCES); t = in_pcblookup(inp->inp_pcbinfo, zeroin_addr, 0, sin->sin_addr, lport, wild); --- 191,197 ---- /* GROSS */ if (ntohs(lport) < IPPORT_RESERVED && ! !in_okresvport(p)) ! return (EACCES); ! t = in_pcblookup(inp->inp_pcbinfo, zeroin_addr, 0, sin->sin_addr, lport, wild); *************** *** 209,213 **** lastport = &inp->inp_pcbinfo->lasthi; } else if (inp->inp_flags & INP_LOWPORT) { ! if (error = suser(p->p_ucred, &p->p_acflag)) return (EACCES); first = ipport_lowfirstauto; /* 1023 */ --- 212,216 ---- lastport = &inp->inp_pcbinfo->lasthi; } else if (inp->inp_flags & INP_LOWPORT) { ! if (!in_okresvport(p)) return (EACCES); first = ipport_lowfirstauto; /* 1023 */ *************** *** 747,749 **** --- 750,801 ---- LIST_INSERT_HEAD(head, inp, inp_hash); splx(s); + } + + static int resv_uid; + static int resv_gid; + + SYSCTL_INT(_net_inet_ip, + IPCTL_RESVUID, + resv_uid, + CTLFLAG_RW, + &resv_uid, + 0, + ""); + + SYSCTL_INT(_net_inet_ip, + IPCTL_RESVGID, + resv_gid, + CTLFLAG_RW, + &resv_gid, + 0, + ""); + + static int in_okresvport(struct proc *prc) { + int error; + + error = suser(prc->p_ucred, &prc->p_acflag); + if(!error) + return(1); + + if(resv_uid && + prc->p_ucred->cr_uid == resv_uid) + return(1); + + if(resv_gid && + cred_isingroup((gid_t) resv_gid, prc)) + return(1); + + return(0); + } + + int cred_isingroup(gid_t gid, struct proc *prc) { + struct ucred *uc = prc->p_ucred; + short i; + + for(i = 0; i < uc->cr_ngroups; i++) { + if(gid == uc->cr_groups[i]) + return(1); + } + + return(0); } *** in.h-pre-tqbf Tue Mar 25 23:46:16 1997 --- in.h Tue Mar 25 23:48:51 1997 *************** *** 304,307 **** --- 304,309 ---- #define IPCTL_INTRQDROPS 11 /* number of netisr q drops */ #define IPCTL_MAXID 12 + #define IPCTL_RESVUID 20 /* UID to bind privileged ports */ + #define IPCTL_RESVGID 21 /* GID to bind privileged ports */ #define IPCTL_NAMES { \ From owner-freebsd-security Tue Mar 25 23:31:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA22847 for security-outgoing; Tue, 25 Mar 1997 23:31:58 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA22832 for ; Tue, 25 Mar 1997 23:31:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id XAA10931; Tue, 25 Mar 1997 23:33:22 -0800 (PST) Message-Id: <199703260733.XAA10931@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: tqbf@enteract.com cc: freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-reply-to: Your message of "Wed, 26 Mar 1997 00:07:51 CST." <19970326060751.3783.qmail@smtp.enteract.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 25 Mar 1997 23:33:21 -0800 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >As part of a gradual effort to rid my kernel of suser() calls, I whipped >up a quick patch to in_pcb.c that configurably removes the superuser >restriction on binding privileged ports. > >This has the effect of removing the requirement for programs like rlogin >and rsh to run with superuser privs, thus eliminating a few more SUID >programs. In place of suser(), I've inserted two new sysctl OIDs under ...and creating a gaping security whole at the same time. I sure hope you're not doing this on any shell account machines and you completely trust any users that you have. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Mar 26 06:25:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11006 for security-outgoing; Wed, 26 Mar 1997 06:25:36 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA10994 for ; Wed, 26 Mar 1997 06:25:19 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id WAA29204; Wed, 26 Mar 1997 22:19:55 +0800 (WST) Date: Wed, 26 Mar 1997 22:19:55 +0800 (WST) From: Adrian Chadd To: David Greenman cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703260733.XAA10931@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 25 Mar 1997, David Greenman wrote: > >As part of a gradual effort to rid my kernel of suser() calls, I whipped > >up a quick patch to in_pcb.c that configurably removes the superuser > >restriction on binding privileged ports. > > Hmmm... > >This has the effect of removing the requirement for programs like rlogin > >and rsh to run with superuser privs, thus eliminating a few more SUID > >programs. In place of suser(), I've inserted two new sysctl OIDs under > > ...and creating a gaping security whole at the same time. I sure hope > you're not doing this on any shell account machines and you completely > trust any users that you have. > Agreed. I'm going to fiddle with this, but I have been fiddling with Linux's Transparent Proxy support (IPFilter does something similar), and redirecting traffic to a certain port (the one I'm working on is sendmail) to a non-priv'ed port. The original idea was running a socket redirector (which, although SUID, is quite small and much easier to secure), redirecting traffic to the not-suid-anymore program, however doing it in kernelland appeals much more to me. The only problem here is that it kinda defeats the whole purpose of prived ports in the first place. I guess the whole thing here is to write small programs that do the necessary SUID bit, then drop back down into nonrootland to continue. David (and anyone else interested) - I'd be very interested in hearing what security holes would be introduced by having a UID (or GID) to bind to priv'ed ports. Surely there must be a nicer way :) Adrian Chadd From owner-freebsd-security Wed Mar 26 06:40:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA11999 for security-outgoing; Wed, 26 Mar 1997 06:40:15 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA11987 for ; Wed, 26 Mar 1997 06:40:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id GAA12899; Wed, 26 Mar 1997 06:41:11 -0800 (PST) Message-Id: <199703261441.GAA12899@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Adrian Chadd cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-reply-to: Your message of "Wed, 26 Mar 1997 22:19:55 +0800." From: David Greenman Reply-To: dg@root.com Date: Wed, 26 Mar 1997 06:41:11 -0800 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >The only problem here is that it kinda defeats the whole purpose of prived >ports in the first place. I guess the whole thing here is to write small >programs that do the necessary SUID bit, then drop back down into >nonrootland to continue. > >David (and anyone else interested) - I'd be very interested in hearing >what security holes would be introduced by having a UID (or GID) to bind >to priv'ed ports. None that I can think of if I understand you correctly. The thing you want to prevent is regular users being able to bind to a privileged port. It would take an average cracker less than 5 minutes to whip up a couple of really nasty programs (such as one that pretends to be rlogin - claiming to be some other user). As long as you retain control over who/what can bind to the privileged ports, I don't see any problem. >Surely there must be a nicer way :) It would be nice if FreeBSD had account privileges ala VMS. You could then have fine grain control over what 'privileged' programs can do, thus limiting the vulnerabilites. I've been thinking about this on occasion for many years and have discussed the idea with several other people. There are a lot of details...it's not as easy as it might seem. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Mar 26 06:56:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA13155 for security-outgoing; Wed, 26 Mar 1997 06:56:22 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA12980 for ; Wed, 26 Mar 1997 06:54:25 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id WAA29309; Wed, 26 Mar 1997 22:50:30 +0800 (WST) Date: Wed, 26 Mar 1997 22:50:30 +0800 (WST) From: Adrian Chadd To: David Greenman cc: tqbf@enteract.com, adrian@deathstar.ml.org, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703261441.GAA12899@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Mar 1997, David Greenman wrote: > None that I can think of if I understand you correctly. The thing you > want to prevent is regular users being able to bind to a privileged port. > It would take an average cracker less than 5 minutes to whip up a couple > of really nasty programs (such as one that pretends to be rlogin - claiming > to be some other user). As long as you retain control over who/what can > bind to the privileged ports, I don't see any problem. > Agreed. > >Surely there must be a nicer way :) > > It would be nice if FreeBSD had account privileges ala VMS. You could then > have fine grain control over what 'privileged' programs can do, thus limiting > the vulnerabilites. I've been thinking about this on occasion for many years > and have discussed the idea with several other people. There are a lot of > details...it's not as easy as it might seem. > Sounds interesting. It would be an interesting project to take on, I'm sure. How about assigning each port number a userid which can bind with the port alongside root? Should be easy enough to implement, and powerful enough to not need suid root binaries to bind to priv'ed ports. > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > Enough from me on this, I have uni tomorrow^H^H^H^H^H^H^H^H^Hthis morning. :) *thwap* Night, -- Adrian Chadd | UNIX, MS-DOS and Windows ... | (also known as the Good, the bad and the | ugly..) From owner-freebsd-security Wed Mar 26 07:59:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18575 for security-outgoing; Wed, 26 Mar 1997 07:59:04 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18559 for ; Wed, 26 Mar 1997 07:58:52 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id IAA11421; Wed, 26 Mar 1997 08:58:17 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id IAA05917; Wed, 26 Mar 1997 08:58:10 -0700 (MST) Date: Wed, 26 Mar 1997 08:58:09 -0700 (MST) From: Marc Slemko To: Adrian Chadd cc: freebsd-security@freebsd.org Subject: Re: Privileged ports... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Mar 1997, Adrian Chadd wrote: > How about assigning each port number a userid which can bind with the > port alongside root? > > Should be easy enough to implement, and powerful enough to not need suid > root binaries to bind to priv'ed ports. It is trivial to implement and, even given various workarounds, would be handy but it needs some framework to slip nicely into. sysctl isn't really suited to it because it would need 1k entries which would make a sysctl -a very long. I use this on some boxes to allow things (eg. mail servers) to bind to their port (eg. 25) without needing root, but I only implement it hard-coded for the ports I need it for. From owner-freebsd-security Wed Mar 26 08:37:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA21821 for security-outgoing; Wed, 26 Mar 1997 08:37:14 -0800 (PST) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21806 for ; Wed, 26 Mar 1997 08:37:06 -0800 (PST) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id LAA15307; Wed, 26 Mar 1997 11:31:57 -0500 (EST) From: Adam Shostack Message-Id: <199703261631.LAA15307@homeport.org> Subject: Re: Privileged ports... In-Reply-To: <199703261441.GAA12899@root.com> from David Greenman at "Mar 26, 97 06:41:11 am" To: dg@root.com Date: Wed, 26 Mar 1997 11:31:57 -0500 (EST) Cc: adrian@obiwan.aceonline.com.au, tqbf@enteract.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (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 What if you allow anyone to bind to any port, and at the same time, make inted.conf much longer, so that theres a line of the form noservice-513 stream tcp nowait nobody /usr/sbin/close close for each low numbered port? It seems that (modulo configuration being a little painful) this offers the best of both worlds--control over low numbered ports, but anyone can bind to a port with root's permission. That permission is given in a config file for a program, not hard coded into the kernel. (It might also be possible to extend the inetd config language so that it recognized a noservice- token to mean bind to that port, and don't let anything else use it.) This has the nice(?) side effect of messing up a log of simple minded security scanners (like strobe). Adam David Greenman wrote: | >The only problem here is that it kinda defeats the whole purpose of prived | >ports in the first place. I guess the whole thing here is to write small | >programs that do the necessary SUID bit, then drop back down into | >nonrootland to continue. | > | >David (and anyone else interested) - I'd be very interested in hearing | >what security holes would be introduced by having a UID (or GID) to bind | >to priv'ed ports. | | None that I can think of if I understand you correctly. The thing you | want to prevent is regular users being able to bind to a privileged port. | It would take an average cracker less than 5 minutes to whip up a couple | of really nasty programs (such as one that pretends to be rlogin - claiming | to be some other user). As long as you retain control over who/what can | bind to the privileged ports, I don't see any problem. -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Wed Mar 26 09:36:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA28549 for security-outgoing; Wed, 26 Mar 1997 09:36:59 -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 JAA28540 for ; Wed, 26 Mar 1997 09:36:54 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id LAA18425; Wed, 26 Mar 1997 11:36:30 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703261736.LAA18425@enteract.com> Subject: Re: Privileged ports... To: dg@root.com Date: Wed, 26 Mar 1997 11:36:29 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: <199703260733.XAA10931@root.com> from "David Greenman" at Mar 25, 97 11:33:21 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ...and creating a gaping security whole at the same time. I sure hope > you're not doing this on any shell account machines and you completely > trust any users that you have. Read the entire message before responding, please. Again, obviously, if you're using ruserok() authenticating daemons, or anything else reliant on a binding to a privileged port as a sign of local privilege (such as the mount daemon's check), the ability to compromise resv_uid or resv_gid is a problem. Of course, it's absolutely no more of a problem than it is now - it's just as hard to compromise an individual UID as it is to compromise root. Either way, you're going to wind up doing it through a hole in rlogin or rsh. However, with configurable uids and gids for privileged port binding, a hole in rlogin isn't going to get you root... just the potential to get root via interactions with other daemons. However, if no such daemons are present on your system, the ability to bind a privileged port doesn't do much for you at all. A network without rlogind, rshd, and NFS shouldn't be too concerned, and there are other reasons to use the rlogin client besides the lame ruserok() trust thing. Incidentally, the patch I posted changes nothing in the way privileged ports work (by default). You'll still need suser() to get at a low port, unless you override it with sysctl, which was all I was going for. Thanks for your comments. ---------------- 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 Wed Mar 26 10:42:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA07230 for security-outgoing; Wed, 26 Mar 1997 10:42:02 -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 KAA07210 for ; Wed, 26 Mar 1997 10:41:52 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA27419; Wed, 26 Mar 1997 12:41:05 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703261841.MAA27419@enteract.com> Subject: Re: Privileged ports... To: adrian@obiwan.aceonline.com.au (Adrian Chadd) Date: Wed, 26 Mar 1997 12:41:03 -0600 (CST) Cc: dg@root.com, tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Adrian Chadd" at Mar 26, 97 10:19:55 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The original idea was running a socket redirector (which, although SUID, > is quite small and much easier to secure), redirecting traffic to the > not-suid-anymore program, however doing it in kernelland appeals much more > to me. Ok, this is the obvious way of dealing with this problem "within the system". INN does the same thing, to an extreme, with a small root-privileged program that opens a reserved port and passes it to an unprivileged process. The problem is that, at some point, you still need to run the program as root. If the past few months have taught me anything, they taught me that you can't rely solely on the application code for security. Every piece of code depended on by an SUID program is security critical as well. As far as I'm concerned, if you can't trust crt0 start(), you can't trust much else either. =) Regardless, it's probably not arguable that UID 0 is overloaded right now. It seems to me that an extremely worthwhile task would be to divide privilege up amongst UIDs and GIDs (reserved ports being a simple example), just as a primitive step towards distributing and compartmentalizing privilege. In any case, I don't think my patch introduces any "gaping security holes". I do think it gave me a lot of flexibility on my systems (I like how -r-xr-sr-x 1 root network 155648 Feb 3 00:13 /usr/bin/rlogin looks on my machines), and it's an exceedingly simple modification. The reserved port range already appears configurable (although I've never played with it), so this isn't a very drastic change. What's the issue with it? ---------------- 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 Wed Mar 26 10:45:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA07612 for security-outgoing; Wed, 26 Mar 1997 10:45:16 -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 KAA07600 for ; Wed, 26 Mar 1997 10:45:09 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA27813; Wed, 26 Mar 1997 12:43:53 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703261843.MAA27813@enteract.com> Subject: Re: Privileged ports... To: dg@root.com Date: Wed, 26 Mar 1997 12:43:52 -0600 (CST) Cc: adrian@obiwan.aceonline.com.au, tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: <199703261441.GAA12899@root.com> from "David Greenman" at Mar 26, 97 06:41:11 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > None that I can think of if I understand you correctly. The thing you > want to prevent is regular users being able to bind to a privileged port. Mr. Greenman, I know I'm being repetative here, but I'd like to re-assert that the patch I posted does not allow regular users to bind to a privileged port, nor have I ever suggested that regular users be granted the ability to bind to a privileged port. > It would be nice if FreeBSD had account privileges ala VMS. You could then > have fine grain control over what 'privileged' programs can do, thus limiting I have some more patches to post. Let's see how they do in OpenBSD first. I don't think the problem is as complicated as it seems. ---------------- 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 Wed Mar 26 10:47:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA07797 for security-outgoing; Wed, 26 Mar 1997 10:47:03 -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 KAA07782 for ; Wed, 26 Mar 1997 10:46:59 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA28107; Wed, 26 Mar 1997 12:45:42 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703261845.MAA28107@enteract.com> Subject: Re: Privileged ports... To: adrian@obiwan.aceonline.com.au (Adrian Chadd) Date: Wed, 26 Mar 1997 12:45:41 -0600 (CST) Cc: dg@root.com, tqbf@enteract.com, adrian@deathstar.ml.org, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Adrian Chadd" at Mar 26, 97 10:50:30 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > How about assigning each port number a userid which can bind with the > port alongside root? > Should be easy enough to implement, and powerful enough to not need suid > root binaries to bind to priv'ed ports. What does this win you? It is easy enough to do, especially if you can require those UIDs to be contiguous (just add an OID to net.inet.ip for the "start" of the range of UIDs that map to reserved ports), but it also seems to waste a lot of UIDs. ---------------- 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 Wed Mar 26 10:48:30 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08011 for security-outgoing; Wed, 26 Mar 1997 10:48:30 -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 KAA08001 for ; Wed, 26 Mar 1997 10:48:20 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA28329; Wed, 26 Mar 1997 12:47:35 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703261847.MAA28329@enteract.com> Subject: Re: Privileged ports... To: adam@homeport.org (Adam Shostack) Date: Wed, 26 Mar 1997 12:47:33 -0600 (CST) Cc: dg@root.com, adrian@obiwan.aceonline.com.au, tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: <199703261631.LAA15307@homeport.org> from "Adam Shostack" at Mar 26, 97 11:31:57 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > for each low numbered port? It seems that (modulo configuration being > a little painful) this offers the best of both worlds--control over > low numbered ports, but anyone can bind to a port with root's Not only is inetd's configuration much longer, but if it dies (or, more specifically, if an attacker can kill it), your system becomes completely insecure. I think it's a bad idea to have security issues rely on the survival of userland processes. Am I wrong? ---------------- 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 Wed Mar 26 13:38:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA28990 for security-outgoing; Wed, 26 Mar 1997 13:38:16 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA28952; Wed, 26 Mar 1997 13:38:06 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wA0Nz-0005pU-00; Wed, 26 Mar 1997 14:37:35 -0700 From: FreeBSD Security Officer To: freebsd-security-notifications@freebsd.org, freebsd-security@freebsd.org, first-teams@first.org, freebsd-announce@freebsd.org Subject: FreeBSD-SA-97:02: Buffer overflow in lpd Date: Wed, 26 Mar 1997 14:37:35 -0700 Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-97:02 Security Advisory FreeBSD, Inc. Topic: Buffer overflow in lpd Category: core Module: lpd Announced: 1997-03-xxx Affects: FreeBSD 2.1.7 and earlier and FreeBSD 2.2 snapshots before 1997/02/25 suffer from this problem. Corrected: FreeBSD-current as of 1997/02/25 FreeBSD 2.2 as of 1997/02/25 FreeBSD only: yes Patches: ftp://freebsd.org/pub/CERT/patches/SA-97:02/ ============================================================================= I. Background The lpd program is used to print local and remote print jobs. It is standard software in the FreeBSD operating system. II. Problem Description The lpd program runs as root. A remote attacker can exploit a buffer overflow to obtain root privs. III. Impact Remote users can gain root privs. IV. Workaround The only workaround is to disable lpd, which will have the effect of removing the printing functionality from the system. Since the buffer overflow happens before the connection is authenticated, using lpd's authentication methods will not affect the system vulnerability. V. Solution Apply the following patch, rebuild and install libc: (This patch can also be found on ftp://freebsd.org/pub/CERT/patches/SA-97:02/) Index: rcmd.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/net/rcmd.c,v retrieving revision 1.3.4.4 retrieving revision 1.3.4.5 diff -u -r1.3.4.4 -r1.3.4.5 --- rcmd.c 1997/02/09 06:57:54 1.3.4.4 +++ rcmd.c 1997/02/26 06:14:11 1.3.4.5 @@ -377,7 +377,8 @@ if ((hp = gethostbyaddr((char *)&raddr, sizeof(u_long), AF_INET)) == NULL) return (-1); - strcpy(hname, hp->h_name); + strncpy(hname, hp->h_name, sizeof(hname)); + hname[sizeof(hname) - 1] = '\0'; while (fgets(buf, sizeof(buf), hostf)) { p = buf; VI. Thanks This problem was brought to light by Oliver Friedrichs . ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org PGP Key: ftp://freebsd.org/pub/CERT/public_key.asc Security notifications: security-notifications@freebsd.org Security public discussion: security@freebsd.org Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMzmOqlUuHi5z0oilAQH1hAP/fSVklicjFNo4hLVO2dYLLiIPnB9uVWNl ocC2Ozu1sX6SH3Kz688QlTEnyDzjshkisI9nr+947A/CjwJDPwqQRbqmbAdI+qka HNQJmVQYWW2J6j70SJX8q0z1uQHoNsJB7VStQ1VX+4BD91CsjBr3lrU5xFyjqxYt uJMeNl0sa9A= =agxY -----END PGP SIGNATURE----- From owner-freebsd-security Wed Mar 26 14:18:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA03339 for security-outgoing; Wed, 26 Mar 1997 14:18:39 -0800 (PST) Received: from smtp.enteract.com (qmailr@char-star.rdist.org [206.54.252.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA03320 for ; Wed, 26 Mar 1997 14:18:32 -0800 (PST) Received: (qmail 19638 invoked by uid 1001); 26 Mar 1997 22:18:16 -0000 Message-ID: <19970326221816.19637.qmail@smtp.enteract.com> From: tqbf@babel.enteract.com Subject: More netinet suser() stuff... To: freebsd-security@freebsd.org Date: Wed, 26 Mar 1997 16:18:16 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4ME+ PL31 (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 An additional issue I'd like to bring up is the suser() requirement for opening raw ICMP sockets. The same division of privilege should apply to sending ICMP packets (thus removing the superuser requirement for ping and traceroute) - in other words, a hole in traceroute shouldn't comprimise anything but the ability to send and receive ICMP packets. Of course, modifying restrictions to raw sockets is trickier than port reservations, since there are many uses for raw sockets beyond ICMP. In particular, unrestricted access to a raw IP socket allows users to create *arbitrary* packets (using the "header included" socket option), which is an unacceptable privilege to give away. The patch I'm including adds another two OIDs (rawicmp_uid and gid). Users with those credentials can open raw sockets if the socket is created specifying IPPROTO_ICMP. Reviewing the code involved (particularly the ICMP protocol switch), I don't think checking the protocol is going to be adequate to ensure that the socket is only used for ICMP. I'd appreciate comments from people more familiar with the code than I. I've used and tested this patch for about 2 hours here. Out of the box it changes none of the privilege requirements for reserved ports or ICMP sockets (you still need to run as root to do either), but will allow through sysctl the ability to configure this. Thanks for listening! *** kern/uipc_socket.c-pre-tqbf Wed Mar 26 14:01:42 1997 --- kern/uipc_socket.c Wed Mar 26 14:06:32 1997 *************** *** 54,57 **** --- 54,59 ---- SYSCTL_INT(_kern, KERN_SOMAXCONN, somaxconn, CTLFLAG_RW, &somaxconn, 0, ""); + extern int in_okrawip(struct proc *p, struct protosw *prp); + /* * Socket operation routines. *************** *** 87,92 **** --- 89,100 ---- TAILQ_INIT(&so->so_comp); so->so_type = type; + + /* XXX hack hack hack */ + if (p->p_ucred->cr_uid == 0) so->so_state = SS_PRIV; + else if(in_okrawip(p, prp)) + so->so_state = SS_PRIV; + so->so_proto = prp; error = (*prp->pr_usrreqs->pru_attach)(so, proto); *** netinet/in.h-pre-tqbf Tue Mar 25 23:46:16 1997 --- netinet/in.h Wed Mar 26 14:11:29 1997 *************** *** 303,307 **** #define IPCTL_INTRQMAXLEN 10 /* max length of netisr queue */ #define IPCTL_INTRQDROPS 11 /* number of netisr q drops */ ! #define IPCTL_MAXID 12 #define IPCTL_NAMES { \ --- 303,309 ---- #define IPCTL_INTRQMAXLEN 10 /* max length of netisr queue */ #define IPCTL_INTRQDROPS 11 /* number of netisr q drops */ ! #define IPCTL_RESVUID 20 /* UID to bind privileged ports */ ! #define IPCTL_RESVGID 21 /* GID to bind privileged ports */ ! #define IPCTL_MAXID 22 #define IPCTL_NAMES { \ *** netinet/icmp_var.h-pre-tqbf Wed Mar 26 14:09:56 1997 --- netinet/icmp_var.h Wed Mar 26 14:11:02 1997 *************** *** 62,66 **** #define ICMPCTL_MASKREPL 1 /* allow replies to netmask requests */ #define ICMPCTL_STATS 2 /* statistics (read-only) */ ! #define ICMPCTL_MAXID 3 #define ICMPCTL_NAMES { \ --- 62,68 ---- #define ICMPCTL_MASKREPL 1 /* allow replies to netmask requests */ #define ICMPCTL_STATS 2 /* statistics (read-only) */ ! #define ICMPCTL_RAWUID 3 /* UID to open raw ICMP socket */ ! #define ICMPCTL_RAWGID 4 /* GID to open raw ICMP socket */ ! #define ICMPCTL_MAXID 5 #define ICMPCTL_NAMES { \ *** netinet/in_pcb.c-pre-tqbf Tue Mar 25 23:09:13 1997 --- netinet/in_pcb.c Wed Mar 26 14:13:42 1997 *************** *** 64,67 **** --- 64,70 ---- static void in_pcbinshash __P((struct inpcb *)); static void in_rtchange __P((struct inpcb *, int)); + static int in_okresvport __P((struct proc *)); + + int cred_isingroup __P((gid_t, struct proc *)); /* *************** *** 189,194 **** /* GROSS */ if (ntohs(lport) < IPPORT_RESERVED && ! (error = suser(p->p_ucred, &p->p_acflag))) ! return (EACCES); t = in_pcblookup(inp->inp_pcbinfo, zeroin_addr, 0, sin->sin_addr, lport, wild); --- 192,198 ---- /* GROSS */ if (ntohs(lport) < IPPORT_RESERVED && ! !in_okresvport(p)) ! return (EACCES); ! t = in_pcblookup(inp->inp_pcbinfo, zeroin_addr, 0, sin->sin_addr, lport, wild); *************** *** 209,213 **** lastport = &inp->inp_pcbinfo->lasthi; } else if (inp->inp_flags & INP_LOWPORT) { ! if (error = suser(p->p_ucred, &p->p_acflag)) return (EACCES); first = ipport_lowfirstauto; /* 1023 */ --- 213,217 ---- lastport = &inp->inp_pcbinfo->lasthi; } else if (inp->inp_flags & INP_LOWPORT) { ! if (!in_okresvport(p)) return (EACCES); first = ipport_lowfirstauto; /* 1023 */ *************** *** 747,749 **** --- 751,802 ---- LIST_INSERT_HEAD(head, inp, inp_hash); splx(s); + } + + static int resv_uid; + static int resv_gid; + + SYSCTL_INT(_net_inet_ip, + IPCTL_RESVUID, + resv_uid, + CTLFLAG_RW, + &resv_uid, + 0, + ""); + + SYSCTL_INT(_net_inet_ip, + IPCTL_RESVGID, + resv_gid, + CTLFLAG_RW, + &resv_gid, + 0, + ""); + + static int in_okresvport(struct proc *prc) { + int error; + + error = suser(prc->p_ucred, &prc->p_acflag); + if(!error) + return(1); + + if(resv_uid && + prc->p_ucred->cr_uid == resv_uid) + return(1); + + if(resv_gid && + cred_isingroup((gid_t) resv_gid, prc)) + return(1); + + return(0); + } + + int cred_isingroup(gid_t gid, struct proc *prc) { + struct ucred *uc = prc->p_ucred; + short i; + + for(i = 0; i < uc->cr_ngroups; i++) { + if(gid == uc->cr_groups[i]) + return(1); + } + + return(0); } *** netinet/ip_icmp.c-pre-tqbf Wed Mar 26 14:09:31 1997 --- netinet/ip_icmp.c Wed Mar 26 14:41:04 1997 *************** *** 45,48 **** --- 45,49 ---- #include #include + #include #include *************** *** 72,75 **** --- 73,85 ---- &icmpmaskrepl, 0, ""); + static int rawicmp_uid = 0; + static int rawicmp_gid = 0; + + SYSCTL_INT(_net_inet_icmp, ICMPCTL_RAWUID, rawicmp_uid, CTLFLAG_RW, + &rawicmp_uid, 0, ""); + + SYSCTL_INT(_net_inet_icmp, ICMPCTL_RAWGID, rawicmp_gid, CTLFLAG_RW, + &rawicmp_gid, 0, ""); + #ifdef ICMPPRINTFS int icmpprintfs = 0; *************** *** 80,83 **** --- 90,96 ---- static int ip_next_mtu __P((int, int)); + int in_okrawip __P((struct proc *, struct protosw *)); + extern int cred_isingroup(gid_t gid, struct proc *prc); + extern struct protosw inetsw[]; *************** *** 693,694 **** --- 706,738 ---- } #endif + + int in_okrawip(struct proc *p, struct protosw *psw) { + int error; + + /* superuser can always open raw sockets (redundant) */ + + error = suser(p->p_ucred, &p->p_acflag); + if(!error) + return(1); + + /* only allow raw sockets for ICMP (this is probably + * a futile gesture, as I'm unsure that the kernel is + * tight enough internally to prevent arbitrary network + * access, at least for sending packets, once a raw + * socket is allocated). + */ + + if(psw->pr_protocol != IPPROTO_ICMP) + return(0); + + if(rawicmp_uid && + p->p_ucred->cr_uid == rawicmp_uid) + return(1); + + if(rawicmp_gid && + cred_isingroup((gid_t) rawicmp_gid, p)) + return(1); + + return(0); + } + From owner-freebsd-security Wed Mar 26 17:22:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19794 for security-outgoing; Wed, 26 Mar 1997 17:22:23 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19786 for ; Wed, 26 Mar 1997 17:22:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id RAA16791; Wed, 26 Mar 1997 17:23:08 -0800 (PST) Message-Id: <199703270123.RAA16791@root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: tqbf@enteract.com cc: adrian@obiwan.aceonline.com.au, freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-reply-to: Your message of "Wed, 26 Mar 1997 12:43:52 CST." <199703261843.MAA27813@enteract.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 26 Mar 1997 17:23:08 -0800 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> None that I can think of if I understand you correctly. The thing you >> want to prevent is regular users being able to bind to a privileged port. > >Mr. Greenman, I know I'm being repetative here, but I'd like to re-assert >that the patch I posted does not allow regular users to bind to a >privileged port, nor have I ever suggested that regular users be granted >the ability to bind to a privileged port. Yes, I re-read your message and I see that now. Sorry about the confusion. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Mar 26 18:28:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA24584 for security-outgoing; Wed, 26 Mar 1997 18:28:09 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA24564 for ; Wed, 26 Mar 1997 18:28:05 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id SAA03271 for ; Wed, 26 Mar 1997 18:30:00 -0800 (PST) Received: (qmail 6055 invoked by uid 110); 26 Mar 1997 22:48:30 -0000 Message-ID: <19970326224830.6053.qmail@suburbia.net> Subject: Re: FreeBSD-SA-97:02: Buffer overflow in lpd In-Reply-To: from FreeBSD Security Officer at "Mar 26, 97 02:37:35 pm" To: security@freebsd.org Date: Thu, 27 Mar 1997 09:48:29 +1100 (EST) 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 -- Start of PGP signed section. > ============================================================================= > FreeBSD-SA-97:02 Security Advisory > FreeBSD, Inc. > > Topic: Buffer overflow in lpd > > Category: core > Module: lpd > Announced: 1997-03-xxx > Affects: FreeBSD 2.1.7 and earlier and FreeBSD 2.2 snapshots > before 1997/02/25 suffer from this problem. > Corrected: FreeBSD-current as of 1997/02/25 > FreeBSD 2.2 as of 1997/02/25 > FreeBSD only: yes > > Patches: ftp://freebsd.org/pub/CERT/patches/SA-97:02/ > > ============================================================================= > > I. Background > > The lpd program is used to print local and remote print jobs. It > is standard software in the FreeBSD operating system. > > II. Problem Description > > The lpd program runs as root. A remote attacker can exploit a > buffer overflow to obtain root privs. > > III. Impact > > Remote users can gain root privs. > Writing exploit code using only alpha-numeric characters, "." and "-" might be an interesting challenge. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@suburbia.net |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery From owner-freebsd-security Wed Mar 26 22:45:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA08687 for security-outgoing; Wed, 26 Mar 1997 22:45:38 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08682 for ; Wed, 26 Mar 1997 22:45:34 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id OAA01949; Thu, 27 Mar 1997 14:42:16 +0800 (WST) Date: Thu, 27 Mar 1997 14:42:16 +0800 (WST) From: Adrian Chadd To: Adam Shostack cc: freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703261631.LAA15307@homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Twould be nice, but remember inetd isn't the only place we want this applicable (eg sendmail runs as a daemon and binds to the port (25), it doesn't use inetd). Nice idea though. :) I was just thinking about saying "let uid 100 bind to port 0 (?), uid 101 bind to port 1, etc ..." upto 1024. Although its just the asme as having sysctl variable letting acertain UID have access to the priv'ed ports. However if you hack an account with THAT UID, you can access ALL ports, rather if you have seperate UIDs with access to one port each, you'd have to actually hack ALL of them (or a large number of the useful ports) to do harm. Good example - someone hacks sendmail (:).. but since it dosn't have root al lthey cand o is play with the sendmail binary, which isn't ever invoked as root anymore :) -- Adrian Chadd | UNIX, MS-DOS and Windows ... | (also known as the Good, the bad and the | ugly..) From owner-freebsd-security Wed Mar 26 23:24:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09848 for security-outgoing; Wed, 26 Mar 1997 23:24:24 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09841 for ; Wed, 26 Mar 1997 23:24:19 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id SAA00104; Thu, 27 Mar 1997 18:40:45 +1100 (EST) Date: Thu, 27 Mar 1997 18:40:43 +1100 (EST) From: "Daniel O'Callaghan" To: Adrian Chadd cc: Adam Shostack , freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ talk about non-root binding to privileged ports deleted] Julian Elischer, where are you? Didn't Julian actually get some association between packets and uid working for use in ipfw a few months ago? Danny From owner-freebsd-security Thu Mar 27 09:49:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01426 for security-outgoing; Thu, 27 Mar 1997 09:49:00 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01377 for ; Thu, 27 Mar 1997 09:48:52 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id IAA04702 for ; Thu, 27 Mar 1997 08:11:19 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id AAA02920; Fri, 28 Mar 1997 00:05:34 +0800 (WST) Date: Fri, 28 Mar 1997 00:05:33 +0800 (WST) From: Adrian Chadd To: "Daniel O'Callaghan" cc: adrian@deathstar.ml.org, Adam Shostack , freebsd-security@freebsd.org Subject: Re: Privileged ports... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I know where he is *grin* If he did do this, I'm going to totally kick myself. Besides, the originator of this thread already has put forward a couple of nice patches that I'm going to setup on a test box at work tomorrow. Cya, -- Adrian Chadd | UNIX, MS-DOS and Windows ... | (also known as the Good, the bad and the | ugly..) On Thu, 27 Mar 1997, Daniel O'Callaghan wrote: > > [ talk about non-root binding to privileged ports deleted] > > Julian Elischer, where are you? > > Didn't Julian actually get some association between packets and uid working > for use in ipfw a few months ago? > > Danny > From owner-freebsd-security Thu Mar 27 09:53:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02796 for security-outgoing; Thu, 27 Mar 1997 09:53:38 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02760 for ; Thu, 27 Mar 1997 09:53:32 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id FAA03815 for ; Thu, 27 Mar 1997 05:42:28 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id GAA05206; Thu, 27 Mar 1997 06:40:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id GAA13269; Thu, 27 Mar 1997 06:38:59 -0700 (MST) Date: Thu, 27 Mar 1997 06:38:58 -0700 (MST) From: Marc Slemko Reply-To: Marc Slemko To: "Thomas H. Ptacek" cc: freebsd-security@freebsd.org Subject: Re: Privileged ports... In-Reply-To: <199703261847.MAA28329@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 26 Mar 1997, Thomas H. Ptacek wrote: > > for each low numbered port? It seems that (modulo configuration being > > a little painful) this offers the best of both worlds--control over > > low numbered ports, but anyone can bind to a port with root's > > Not only is inetd's configuration much longer, but if it dies (or, more > specifically, if an attacker can kill it), your system becomes completely > insecure. I think it's a bad idea to have security issues rely on the > survival of userland processes. > > Am I wrong? I agree completely with you. It is a very bad thing. Start with the fact that, by default, inetd limits services to being called 256 times a minute and then shuts them off and then move on to more devious ways you could sometimes sneak in; it is relatively secure by Unix standards but if you are doing things that way for security it isn't secure enough. The proper way is to simply make a program (or extend sysctl to deal nicely with large ranges where you don't want to normally show items that are set to a particular default but still allow them to be changed) that handles setting it then add a few lines of code to the kernel to allow you to set the uid who can bind to each priv'd port. There are 1764 other things that it would be useful to be able to set in a similar way, although many of them can be implemented as sysctl variables right now without much hassle. From owner-freebsd-security Thu Mar 27 10:07:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02147 for security-outgoing; Thu, 27 Mar 1997 09:51:24 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02075 for ; Thu, 27 Mar 1997 09:51:11 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id HAA04241 for ; Thu, 27 Mar 1997 07:07:16 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wAGkB-00072F-00; Thu, 27 Mar 1997 08:05:35 -0700 To: proff@suburbia.net Subject: Re: FreeBSD-SA-97:02: Buffer overflow in lpd Cc: security@freebsd.org In-reply-to: Your message of "Thu, 27 Mar 1997 09:48:29 +1100." <19970326224830.6053.qmail@suburbia.net> References: <19970326224830.6053.qmail@suburbia.net> Date: Thu, 27 Mar 1997 08:05:35 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970326224830.6053.qmail@suburbia.net> proff@suburbia.net writes: : Writing exploit code using only alpha-numeric characters, "." and "-" might : be an interesting challenge. There have been reports in various lists that have exactly this kind of code, or at least pointers to this kind of code. Writing the egg for the buffer overflow is the hard part of this, but it has been done, at least for intel machines. Kinda scary. Then again, if you have the old ms-kermit program, look at boot.com. All printable characters and it does very useful things. While printable characters are a superset of a-zA-Z.-, there is no reason why you couldn't do it.... Warner From owner-freebsd-security Thu Mar 27 11:30:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA12700 for security-outgoing; Thu, 27 Mar 1997 11:30:56 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA12684; Thu, 27 Mar 1997 11:30:45 -0800 (PST) Received: by sovcom.kiae.su id AA13857 (5.65.kiae-1 ); Thu, 27 Mar 1997 22:19:41 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 27 Mar 97 22:19:40 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id WAA00894; Thu, 27 Mar 1997 22:17:58 +0300 (MSK) Date: Thu, 27 Mar 1997 22:17:56 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Joerg Wunsch , markm@freebsd.org Cc: security@freebsd.org Subject: ATTENTION: Initial state of random pool Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Recent Joerg report about fortune behaviour make me think about initial state of /dev/random, i.e. what happens when rndcontrol not called at all and no keys pressed (or the same key sequence, because it relays on scancode)? I fear that pool state is very predicted in this case. If I right, we need to do something to have true random in the pool even without rndcontrol tool (it called even after daemons started, so daemons can't use its advantages in any case!). I.e. add some timer randomness at the kernel boot state and allows rndcontrol-style IRQ set in kernel configure file. I see blkdev randomness commented out in the code, maybe we can re-activate it? If my fears are true, we need to fix it ASAP. Any ideas? -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Thu Mar 27 11:41:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA13960 for security-outgoing; Thu, 27 Mar 1997 11:41:33 -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 LAA13949 for ; Thu, 27 Mar 1997 11:41:27 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id NAA23050; Thu, 27 Mar 1997 13:41:04 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703271941.NAA23050@enteract.com> Subject: Re: Privileged ports... To: marcs@znep.com Date: Thu, 27 Mar 1997 13:41:03 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Marc Slemko" at Mar 27, 97 06:38:58 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I agree completely with you. It is a very bad thing. Start with the fact > that, by default, inetd limits services to being called 256 times a minute > and then shuts them off and then move on to more devious ways you could inetd doesn't release the socket address when it shuts the port off, so I doubt you'd be able to bind over something inetd's handling. You do have a potential problem with specific binds (over inetd's INADDR_ANY) in this configuration, though. The real problem, as I see it, is that if reserved ports are enough of a security concern for you that you'd dramatically complicate your inetd configuration to handle them, you're going to have a real security concern if inetd dies. I think it's bad to assume that an unprivileged user can't cause a daemon to die. > are set to a particular default but still allow them to be changed) that > handles setting it then add a few lines of code to the kernel to allow you > to set the uid who can bind to each priv'd port. There are 1764 other > things that it would be useful to be able to set in a similar way, Why do you want a UID per reserved port? What is this getting you? ---------------- 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 Thu Mar 27 11:42:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA14120 for security-outgoing; Thu, 27 Mar 1997 11:42:38 -0800 (PST) Received: from grackle.grondar.za (grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA14072; Thu, 27 Mar 1997 11:42:19 -0800 (PST) Received: from grackle.grondar.za (localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id VAA07001; Thu, 27 Mar 1997 21:41:44 +0200 (SAT) Message-Id: <199703271941.VAA07001@grackle.grondar.za> To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Joerg Wunsch , markm@freebsd.org, security@freebsd.org Subject: Re: ATTENTION: Initial state of random pool Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 1997 21:41:38 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > Recent Joerg report about fortune behaviour make me think about initial > state of /dev/random, i.e. what happens when rndcontrol not called > at all and no keys pressed (or the same key sequence, because it > relays on scancode)? I fear that pool state is very predicted in this > case. If I right, we need to do something to have true random in the > pool even without rndcontrol tool (it called even after daemons > started, so daemons can't use its advantages in any case!). I.e. add some > timer randomness at the kernel boot state > and allows rndcontrol-style IRQ set in kernel configure file. > I see blkdev randomness commented out in the code, maybe we can > re-activate it? I am very keen to vastly improve /dev/random. I have lots of ideas, but my time supply and clue supply are not so good. At the moment, the pool of randomness is stirred far too often by MD5. I have some more recent code by Ted Ts'o which uses SHA, and is improved in other ways. I want to make a buffer (of structures (or whatever)) into which bits of "harvested" entropy get thrown. Only when this entropy is required, will the "stir" happen. I also want to include bits from the namei cache, and from the network interfaces. I am dead-scared that I will slow down the system, so I need to provide a "turn this feature off" knob for the speed freaks. > If my fears are true, we need to fix it ASAP. Right now, I believe that the hard-earned randomness may be being used for trivial jobs. I do believe, though, that much more entropy can be provided. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Thu Mar 27 12:34:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19374 for security-outgoing; Thu, 27 Mar 1997 12:34:59 -0800 (PST) Received: from smokey.systemics.com (leased-line.systemics.com [193.67.124.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA19368; Thu, 27 Mar 1997 12:34:46 -0800 (PST) Received: from internal-mail.systemics.com (WrlJfwHuWfmbwwS7QPvrN2qTWUIxG8kH@internal-mail.systemics.com [193.67.124.74]) by smokey.systemics.com (8.6.12/8.6.12) with ESMTP id VAA03865; Thu, 27 Mar 1997 21:34:56 +0100 Received: from localhost (cc2tSQPlffHKRPNGwz97LKlhWcNtUBZg@localhost [127.0.0.1]) by internal-mail.systemics.com with SMTPid VAA13075; Thu, 27 Mar 1997 21:34:44 +0100 (MET) Message-Id: <199703272034.VAA13075@internal-mail.systemics.com> X-Authentication-Warning: kampai.systemics.com: cc2tSQPlffHKRPNGwz97LKlhWcNtUBZg@localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Joerg Wunsch , markm@freebsd.org, security@freebsd.org Subject: Re: ATTENTION: Initial state of random pool In-reply-to: Your message of "Thu, 27 Mar 1997 22:17:56 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 1997 21:34:43 +0100 From: Gary Howland Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Recent Joerg report about fortune behaviour make me think about initial > state of /dev/random, i.e. what happens when rndcontrol not called > at all and no keys pressed (or the same key sequence, because it > relays on scancode)? I fear that pool state is very predicted in this > case. If I right, we need to do something to have true random in the > pool even without rndcontrol tool (it called even after daemons > started, so daemons can't use its advantages in any case!). I.e. add some > timer randomness at the kernel boot state > and allows rndcontrol-style IRQ set in kernel configure file. Ideally it should "throw in some randomness" from the previous session, and not rely solely on the time. For instance, if a block of data could be "added" to the device at boot time, then it could still be useful for daemons. After booting is complete, then a new block of data could be generated for the next reboot. Comments? Gary From owner-freebsd-security Thu Mar 27 12:38:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19728 for security-outgoing; Thu, 27 Mar 1997 12:38:13 -0800 (PST) Received: from critter.dk.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19696; Thu, 27 Mar 1997 12:38:00 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id VAA00552; Thu, 27 Mar 1997 21:37:05 +0100 (CET) To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Joerg Wunsch , markm@freebsd.org, security@freebsd.org Subject: Re: ATTENTION: Initial state of random pool In-reply-to: Your message of "Thu, 27 Mar 1997 22:17:56 +0300." Date: Thu, 27 Mar 1997 21:37:05 +0100 Message-ID: <550.859495025@critter> From: Poul-Henning Kamp Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I see blkdev randomness commented out in the code, maybe we can >re-activate it? >If my fears are true, we need to fix it ASAP. >Any ideas? A semi-not-too-bad priming method could be: for dev in all diskmedia ts = time bno = ts.tv_usec & dssize(dev) read sector bno add sectore to random pool It will probably not be too great on machines with newly formatted disks, but otherwise it should do well... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-security Thu Mar 27 12:44:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA20454 for security-outgoing; Thu, 27 Mar 1997 12:44:25 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA20443 for ; Thu, 27 Mar 1997 12:44:22 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17089(7)>; Thu, 27 Mar 1997 12:43:34 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Thu, 27 Mar 1997 12:43:26 -0800 To: tqbf@enteract.com cc: freebsd-security@freebsd.org Subject: Re: More netinet suser() stuff... In-reply-to: Your message of "Wed, 26 Mar 97 14:18:16 PST." <19970326221816.19637.qmail@smtp.enteract.com> Date: Thu, 27 Mar 1997 12:43:22 PST From: Bill Fenner Message-Id: <97Mar27.124326pst.177486@crevenia.parc.xerox.com> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk tqbf@babel.enteract.com wrote: >+ /* only allow raw sockets for ICMP (this is probably >+ * a futile gesture, as I'm unsure that the kernel is >+ * tight enough internally to prevent arbitrary network >+ * access, at least for sending packets, once a raw >+ * socket is allocated). >+ */ This is indeed the case. This is more a portability issue than anything else; before there was an IP_HDRINCL socket option, there was IPPROTO_RAW sockets which implied IP_HDRINCL. However, something like the following might work: *** raw_ip.c.orig Thu Mar 27 20:33:40 1997 --- raw_ip.c Thu Mar 27 20:34:30 1997 *************** *** 204,209 **** --- 204,214 ---- m_freem(m); return EINVAL; } + if (inp->inp_ip.ip_p != IPPROTO_RAW && + ip->ip_p != inp->inp_ip.ip_p) { + m_freem(m); + return EACCESS; + } if (ip->ip_id == 0) ip->ip_id = htons(ip_id++); /* XXX prevent ip_output from overwriting header fields */ This allows IPPROTO_RAW sockets to continue to be used to write any protocol, but other raw sockets to only allow the protocol with which they were opened. Note that traceroute still uses an IPPROTO_RAW socket to send packets, so traceroute would need to be modified to be able to use this. It's probably as simple as saying "sndsock = s" isntead of opening a second socket. [Also note that traceroute does a setuid(getuid()) as the 4th thing in main(), so trying to protect it further might not be a good thing to be spending a lot of time on] Bill From owner-freebsd-security Thu Mar 27 13:46:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25821 for security-outgoing; Thu, 27 Mar 1997 13:46:29 -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 NAA25816 for ; Thu, 27 Mar 1997 13:46:26 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id PAA13555; Thu, 27 Mar 1997 15:45:55 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703272145.PAA13555@enteract.com> Subject: Re: More netinet suser() stuff... To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 27 Mar 1997 15:45:54 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@freebsd.org Reply-To: tqbf@enteract.com In-Reply-To: <97Mar27.124326pst.177486@crevenia.parc.xerox.com> from "Bill Fenner" at Mar 27, 97 12:43:22 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is indeed the case. This is more a portability issue than anything > else; before there was an IP_HDRINCL socket option, there was IPPROTO_RAW > sockets which implied IP_HDRINCL. However, something like the following > might work: Thanks for clarifying! Is there an obvious way to use an IPPROTO_ICMP raw socket to read packets other than ICMP? From what I can see, packets aren't ever passed through the socket code except through the protocol switches. > Note that traceroute still uses an IPPROTO_RAW socket to send packets, Only if it can't look up "icmp" in /etc/protocols, at least in version 1.3.2 (distributed with FreeBSD 3.0). It should by default open an IPPROTO_ICMP socket. > [Also note that traceroute does a setuid(getuid()) as the 4th thing > in main(), so trying to protect it further might not be a good thing > to be spending a lot of time on] This does nothing to resolve problems in the C runtime support library. The fewer SUID root programs on the system, the better, says I. =) ---------------- 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 Thu Mar 27 13:56:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA26884 for security-outgoing; Thu, 27 Mar 1997 13:56:19 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA26865 for ; Thu, 27 Mar 1997 13:56:12 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16005(3)>; Thu, 27 Mar 1997 13:55:39 PST Received: by crevenia.parc.xerox.com id <177486>; Thu, 27 Mar 1997 13:55:35 -0800 From: Bill Fenner To: fenner@parc.xerox.com, tqbf@enteract.com Subject: Re: More netinet suser() stuff... Cc: freebsd-security@freebsd.org Message-Id: <97Mar27.135535pst.177486@crevenia.parc.xerox.com> Date: Thu, 27 Mar 1997 13:55:33 PST Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Note that traceroute still uses an IPPROTO_RAW socket to send packets, > >Only if it can't look up "icmp" in /etc/protocols, at least in version >1.3.2 Check again. s is an IPPROTO_ICMP socket, sndsock is an IPPROTO_RAW socket. If it fails to look up "icmp" in /etc/protocols, then it opens no sockets at all. Bill From owner-freebsd-security Thu Mar 27 14:11:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27855 for security-outgoing; Thu, 27 Mar 1997 14:11:42 -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 OAA27843 for ; Thu, 27 Mar 1997 14:11:33 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id QAA17602; Thu, 27 Mar 1997 16:11:22 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703272211.QAA17602@enteract.com> Subject: Re: More netinet suser() stuff... To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 27 Mar 1997 16:11:21 -0600 (CST) Cc: fenner@parc.xerox.com, tqbf@enteract.com, freebsd-security@freebsd.org Reply-To: tqbf@enteract.com In-Reply-To: <97Mar27.135535pst.177486@crevenia.parc.xerox.com> from "Bill Fenner" at Mar 27, 97 01:55:33 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Check again. s is an IPPROTO_ICMP socket, sndsock is an IPPROTO_RAW > socket. If it fails to look up "icmp" in /etc/protocols, then it > opens no sockets at all. You're obviously right. Sorry about the confusion. Without any modifications to my kernel, traceroute continues to work using the same socket for sending and receiving (sndsock = s). I'll try returning EACCESS in the raw IP code for !IPPROTO_RAW and see if that breaks traceroute now. ---------------- 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 Thu Mar 27 14:35:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29333 for security-outgoing; Thu, 27 Mar 1997 14:35:53 -0800 (PST) Received: from smokey.systemics.com (leased-line.systemics.com [193.67.124.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA29325; Thu, 27 Mar 1997 14:35:39 -0800 (PST) Received: from internal-mail.systemics.com (WcNJIMOdqrtDjo5ra3Z6RQg3uUSHjKwR@internal-mail.systemics.com [193.67.124.74]) by smokey.systemics.com (8.6.12/8.6.12) with ESMTP id XAA04184; Thu, 27 Mar 1997 23:35:52 +0100 Received: from localhost (8Ak/r0rAfOt11oTox8zwHCwVUN9a4I/H@localhost [127.0.0.1]) by internal-mail.systemics.com with SMTPid XAA14106; Thu, 27 Mar 1997 23:35:40 +0100 (MET) Message-Id: <199703272235.XAA14106@internal-mail.systemics.com> X-Authentication-Warning: kampai.systemics.com: 8Ak/r0rAfOt11oTox8zwHCwVUN9a4I/H@localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: Mark Murray cc: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , Joerg Wunsch , markm@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: ATTENTION: Initial state of random pool In-reply-to: Your message of "Thu, 27 Mar 1997 21:41:38 +0200." <199703271941.VAA07001@grackle.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 1997 23:35:40 +0100 From: Gary Howland Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mark Murray wrote: > Right now, I believe that the hard-earned randomness may be being used for > trivial jobs. I do believe, though, that much more entropy can be provided. Aha! The solution may be to allow the hard-earned randomness to be used for trivial jobs, by using it only as a seed for a cryptographically secure random sequence generator (e.g. RC4). Comments? Gary From owner-freebsd-security Thu Mar 27 16:27:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA06183 for security-outgoing; Thu, 27 Mar 1997 16:27:26 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA06173; Thu, 27 Mar 1997 16:27:13 -0800 (PST) Received: by sovcom.kiae.su id AA05917 (5.65.kiae-1 ); Fri, 28 Mar 1997 03:17:59 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 28 Mar 97 03:17:59 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id DAA00574; Fri, 28 Mar 1997 03:06:15 +0300 (MSK) Date: Fri, 28 Mar 1997 03:06:13 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Poul-Henning Kamp Cc: Joerg Wunsch , markm@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: ATTENTION: Initial state of random pool In-Reply-To: <550.859495025@critter> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Mar 1997, Poul-Henning Kamp wrote: > A semi-not-too-bad priming method could be: > > for dev in all diskmedia > ts = time > bno = ts.tv_usec & dssize(dev) > read sector bno > add sectore to random pool We don't need more methods, all we need is _one_ true random method which generates at least _one_ random word initially, because pool hashed after it, i.e. it seeds MD5 RNG. Good guess will be timer method which already present. Looking in the code (not deeply), I can't say, is any true randomness added initially, I think somebody who knows it better (Mark?) can answer. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Thu Mar 27 16:27:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA06223 for security-outgoing; Thu, 27 Mar 1997 16:27:51 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA06203; Thu, 27 Mar 1997 16:27:37 -0800 (PST) Received: by sovcom.kiae.su id AA05931 (5.65.kiae-1 ); Fri, 28 Mar 1997 03:18:01 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 28 Mar 97 03:18:00 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id DAA00583; Fri, 28 Mar 1997 03:13:40 +0300 (MSK) Date: Fri, 28 Mar 1997 03:13:38 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Mark Murray Cc: Joerg Wunsch , markm@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: ATTENTION: Initial state of random pool In-Reply-To: <199703271941.VAA07001@grackle.grondar.za> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Mar 1997, Mark Murray wrote: > I am very keen to vastly improve /dev/random. > > I have lots of ideas, but my time supply and clue supply are not so good. > > At the moment, the pool of randomness is stirred far too often by MD5. I > have some more recent code by Ted Ts'o which uses SHA, and is improved in > other ways. Hmm, I not talk about improvements right now, only about bugfixes... To summarize what I want: 1) We need to check, if at least _one_ true random word added after boot just to be shure that daemons can use /dev/urandom. 2) If it happens, go to 4) 3) We need to add this random word, f.e. from timer. 4a) We need remove rndcontrol from rc.i386 (leaving it as user-land utility) and add all interrupts to kernel config file, i.e. something like: option RAND_INTS "5 7 10 11" or something more suitable. or 4b) We need to start rndcontrol as early as possible in /etc/rc (I think 4a is better) -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-security Thu Mar 27 19:06:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14703 for security-outgoing; Thu, 27 Mar 1997 19:06:51 -0800 (PST) Received: from sui.gda.itesm.mx (sui.gda.itesm.mx [132.254.53.124]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14698; Thu, 27 Mar 1997 19:06:47 -0800 (PST) Received: from rebi (dialup02.i-set.com.mx [200.34.46.132]) by sui.gda.itesm.mx (8.8.5/8.8.5) with ESMTP id VAA16646; Thu, 27 Mar 1997 21:10:01 -0600 (CST) Message-ID: <333B35DA.2BF3@sui.gda.itesm.mx> Date: Thu, 27 Mar 1997 21:07:06 -0600 From: "Alejandro Vázquez C." Organization: SUI - ITESM Campus Guadalajara X-Mailer: Mozilla 4.0b2 (Win95; I) MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Alejandro Vazquez , Carlos Mercado Subject: SetUID & Apache in 2.2-RELEASE... X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and them executed pretty well with Apache 1.1.1 & Perl 5.002. Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of the setuids cgis run (being executed by anybody but root). When I remove from them the setuid flag, they can be executed (but I need to execute them as setuids). Any Ideas? Thanx in advance... From owner-freebsd-security Thu Mar 27 20:06:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17345 for security-outgoing; Thu, 27 Mar 1997 20:06:50 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17337 for ; Thu, 27 Mar 1997 20:06:37 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id LAA00445; Fri, 28 Mar 1997 11:59:12 +0800 (WST) Date: Fri, 28 Mar 1997 11:59:12 +0800 (WST) From: Adrian Chadd To: "Thomas H. Ptacek" cc: marcs@znep.com, freebsd-security@freebsd.org Subject: Re: Privileged ports... In-Reply-To: <199703271941.NAA23050@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Mar 1997, Thomas H. Ptacek wrote: [cut] > Why do you want a UID per reserved port? What is this getting you? > Cause if someone breaks into sendmail (for example), in itself they couldn't do anything, but cause they are the same UID as all the other processes bound to priv'ed ports, its "lets-take-over-the-system-daemon" time .. maybe. Basically its so if someone finds a hole in a certain service, than that service would be affected, and not the others.. (Then you could implement nice checks on the process statistics, or something or other, to notice when a different program was started, or the executable was modified..) Can you tell I'm paranoid yet? :) > ---------------- > Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] > ---------------- > "If you're so special, why aren't you dead?" > > > -- Adrian Chadd | UNIX, MS-DOS and Windows ... | (also known as the Good, the bad and the | ugly..) From owner-freebsd-security Thu Mar 27 21:11:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA19812 for security-outgoing; Thu, 27 Mar 1997 21:11:21 -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 VAA19806; Thu, 27 Mar 1997 21:11:09 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id VAA00762; Thu, 27 Mar 1997 21:10:38 -0800 (PST) Message-Id: <199703280510.VAA00762@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd000756; Fri Mar 28 05:10:31 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: "Alejandro V\azquez C." cc: freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Carlos Mercado , cschuber@uumail.gov.bc.ca Subject: Re: SetUID & Apache in 2.2-RELEASE... In-reply-to: Your message of "Thu, 27 Mar 1997 21:07:06 CST." <333B35DA.2BF3@sui.gda.itesm.mx> Date: Thu, 27 Mar 1997 21:10:30 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of > the setuids cgis run (being executed by anybody but root). When I > remove from them the setuid flag, they can be executed (but I need to > execute them as setuids). Any Ideas? Thanx in advance... This is a Perl problem. I've encountered this with other Perl (5.003) scripts before, though I don't know what the solution is yet. 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 Thu Mar 27 22:06:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22149 for security-outgoing; Thu, 27 Mar 1997 22:06:57 -0800 (PST) Received: from obiwan.aceonline.com.au (obiwan.aceonline.com.au [203.103.90.67]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22144; Thu, 27 Mar 1997 22:06:51 -0800 (PST) Received: from localhost (adrian@localhost) by obiwan.aceonline.com.au (8.8.5/8.8.5) with SMTP id NAA01977; Fri, 28 Mar 1997 13:58:45 +0800 (WST) Date: Fri, 28 Mar 1997 13:58:44 +0800 (WST) From: Adrian Chadd To: cschuber@uumail.gov.bc.ca cc: "Alejandro Vazquez C." , freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Carlos Mercado Subject: Re: SetUID & Apache in 2.2-RELEASE... In-Reply-To: <199703280510.VAA00762@cwsys.cwent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Mar 1997, Cy Schubert wrote: > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > > This is a Perl problem. I've encountered this with other Perl (5.003) > scripts before, though I don't know what the solution is yet. > > Possibly.. does FreeBSD by default let you run suid scripts? Also , perl has a compile option from memory to enable setuid stuff. -- Adrian Chadd | UNIX, MS-DOS and Windows ... | (also known as the Good, the bad and the | ugly..) From owner-freebsd-security Thu Mar 27 22:18:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA22693 for security-outgoing; Thu, 27 Mar 1997 22:18:57 -0800 (PST) Received: from main.gbdata.com (USR2-1.detnet.com [207.113.12.31]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22685; Thu, 27 Mar 1997 22:18:52 -0800 (PST) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.5/8.8.5) id AAA11018; Fri, 28 Mar 1997 00:18:05 -0600 (CST) From: Gary Clark II Message-Id: <199703280618.AAA11018@main.gbdata.com> Subject: Re: SetUID & Apache in 2.2-RELEASE... To: cschuber@uumail.gov.bc.ca Date: Fri, 28 Mar 1997 00:18:04 -0600 (CST) Cc: alexv@sui.gda.itesm.mx, freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, cmercado@interface.com.mx, cschuber@uumail.gov.bc.ca In-Reply-To: <199703280510.VAA00762@cwsys.cwent.com> from Cy Schubert at "Mar 27, 97 09:10:30 pm" X-Mailer: ELM [version 2.4ME+ PL22 (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: > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > > > Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of > > the setuids cgis run (being executed by anybody but root). When I > > remove from them the setuid flag, they can be executed (but I need to > > execute them as setuids). Any Ideas? Thanx in advance... > > This is a Perl problem. I've encountered this with other Perl (5.003) > scripts before, though I don't know what the solution is yet. > The problem is that the port does not setup perl to do suid scripts. You have to enable this in the configure script. > > Cy Schubert Fax: (250)387-5766 Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups - http://WWW.GBData.com for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/FAQ.latin1 From owner-freebsd-security Thu Mar 27 23:14:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24744 for security-outgoing; Thu, 27 Mar 1997 23:14:08 -0800 (PST) Received: from grackle.grondar.za (grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24738; Thu, 27 Mar 1997 23:13:59 -0800 (PST) Received: from grackle.grondar.za (localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id JAA09258; Fri, 28 Mar 1997 09:13:20 +0200 (SAT) Message-Id: <199703280713.JAA09258@grackle.grondar.za> To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Mark Murray , Joerg Wunsch , markm@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: ATTENTION: Initial state of random pool Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Mar 1997 09:13:12 +0200 From: Mark Murray Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > > At the moment, the pool of randomness is stirred far too often by MD5. I > > have some more recent code by Ted Ts'o which uses SHA, and is improved in > > other ways. > > Hmm, I not talk about improvements right now, only about bugfixes... Oh, OK. I am planning a huge improvement in the long(ish) term. In the meanwhile, I am sure I can come up with some decent muck to prime the pool. > To summarize what I want: > > 1) We need to check, if at least _one_ true random word added after > boot just to be shure that daemons can use /dev/urandom. > > 2) If it happens, go to 4) > > 3) We need to add this random word, f.e. from timer. > > 4a) We need remove rndcontrol from rc.i386 (leaving it as user-land > utility) and add all interrupts to kernel config file, i.e. > something like: > option RAND_INTS "5 7 10 11" > or something more suitable. > > or > > 4b) We need to start rndcontrol as early as possible in /etc/rc > (I think 4a is better) Should be easy. I'll look at this over the next few days. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Thu Mar 27 23:20:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24946 for security-outgoing; Thu, 27 Mar 1997 23:20:50 -0800 (PST) Received: from sui.gda.itesm.mx (sui.gda.itesm.mx [132.254.53.124]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24941; Thu, 27 Mar 1997 23:20:46 -0800 (PST) Received: from rebi (dialup00.i-set.com.mx [200.34.46.130]) by sui.gda.itesm.mx (8.8.5/8.8.5) with ESMTP id BAA01146; Fri, 28 Mar 1997 01:24:09 -0600 (CST) Message-ID: <333B7166.7EAF@sui.gda.itesm.mx> Date: Fri, 28 Mar 1997 01:21:10 -0600 From: "Alejandro Vázquez C." Organization: SUI - ITESM Campus Guadalajara X-Mailer: Mozilla 4.0b2 (Win95; I) MIME-Version: 1.0 To: freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Alejandro Vazquez , Carlos Mercado Subject: Re: SetUID & Apache in 2.2-RELEASE... X-Priority: 3 (Normal) References: <333B35DA.2BF3@sui.gda.itesm.mx> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alejandro Vázquez C. wrote: I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and them executed pretty well with Apache 1.1.1 & Perl 5.002. Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of the setuids cgis run (being executed by anybody but root). When I remove from them the setuid flag, they can be executed (but I need to execute them as setuids). Any Ideas? Thanx in advance... New data about this: Other FBSD 2.2 boxes with Perl5.003 can do the job (execute a setuid cgi under Apache 1.2b7). I think it's a compatibility problem in the script itself (Larry, are you there? If so, why can't I use my old 5.002 setuid-scripts with 5.003). From owner-freebsd-security Thu Mar 27 23:26:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA25134 for security-outgoing; Thu, 27 Mar 1997 23:26:39 -0800 (PST) Received: from sui.gda.itesm.mx (sui.gda.itesm.mx [132.254.53.124]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA25128; Thu, 27 Mar 1997 23:26:37 -0800 (PST) Received: from rebi (dialup00.i-set.com.mx [200.34.46.130]) by sui.gda.itesm.mx (8.8.5/8.8.5) with ESMTP id BAA01372; Fri, 28 Mar 1997 01:28:01 -0600 (CST) Message-ID: <333B722D.32E5@sui.gda.itesm.mx> Date: Fri, 28 Mar 1997 01:24:29 -0600 From: "Alejandro Vázquez C." Organization: SUI - ITESM Campus Guadalajara X-Mailer: Mozilla 4.0b2 (Win95; I) MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: Adrian Chadd CC: cschuber@uumail.gov.bc.ca, freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Carlos Mercado Subject: Re: SetUID & Apache in 2.2-RELEASE... X-Priority: 3 (Normal) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Adrian Chadd wrote: On Thu, 27 Mar 1997, Cy Schubert wrote: > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > > This is a Perl problem. I've encountered this with other Perl (5.003) > scripts before, though I don't know what the solution is yet. Possibly.. does FreeBSD by default let you run suid scripts? No, but Perl uses a trick that enables us to do so... From owner-freebsd-security Fri Mar 28 00:04:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA26637 for security-outgoing; Fri, 28 Mar 1997 00:04:29 -0800 (PST) Received: from warp10.smartlink.net (smartlink.net [204.118.4.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA26632; Fri, 28 Mar 1997 00:04:25 -0800 (PST) Received: from localhost by warp10.smartlink.net(8.6.12/SMARTLINK-1.0) with id AAA28850 SMTP for on Fri, 28 Mar 1997 00:07:05 -0800 From: joe@vpop.net (Joe McDonald) To: "Alejandro Vázquez C." , mreimer@vpop.net Cc: freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, Alejandro Vazquez , Carlos Mercado Subject: Re: SetUID & Apache in 2.2-RELEASE... Date: Fri, 28 Mar 1997 00:04:17 -0800 Organization: VPOP Technologies Inc. Message-ID: <33857ad5.120712265@localhost> References: <333B35DA.2BF3@sui.gda.itesm.mx> <333B7166.7EAF@sui.gda.itesm.mx> In-Reply-To: <333B7166.7EAF@sui.gda.itesm.mx> X-Mailer: Forte Agent 1.0/32.390 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A co-worker ran into a similiar problem. He dug into the perl source and found that it checks it's name and if it's not perl, it won't go suid. So that: #!/usr/local/bin/perl5 would *not* work but #!/usr/local/bin/perl would work. I'm not sure of the version, but perhaps this is the problem? regards, -joe On Fri, 28 Mar 1997 01:21:10 -0600, "Alejandro Vázquez C." spaketh: >Alejandro Vázquez C. wrote: > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none > of > the setuids cgis run (being executed by anybody but root). When I > remove from them the setuid flag, they can be executed (but I need > to > execute them as setuids). Any Ideas? Thanx in advance... > >New data about this: >Other FBSD 2.2 boxes with Perl5.003 can do the job (execute a setuid cgi >under Apache 1.2b7). I think it's a compatibility problem in the script >itself (Larry, are you there? If so, why can't I use my old 5.002 >setuid-scripts with 5.003). > > ============================================================================= * NewsHub: Updated every 15 minutes/24 hours a day! * http://newshub.com/ From owner-freebsd-security Fri Mar 28 01:38:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA00154 for security-outgoing; Fri, 28 Mar 1997 01:38:45 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA00149 for ; Fri, 28 Mar 1997 01:38:42 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id CAA28556; Fri, 28 Mar 1997 02:38:39 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id CAA19194; Fri, 28 Mar 1997 02:25:54 -0700 (MST) Date: Fri, 28 Mar 1997 02:25:53 -0700 (MST) From: Marc Slemko To: "Thomas H. Ptacek" cc: freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703271941.NAA23050@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 27 Mar 1997, Thomas H. Ptacek wrote: > > I agree completely with you. It is a very bad thing. Start with the fact > > that, by default, inetd limits services to being called 256 times a minute > > and then shuts them off and then move on to more devious ways you could > > inetd doesn't release the socket address when it shuts the port off, so I > doubt you'd be able to bind over something inetd's handling. You do have a Yes it does. It close()es the socket. Try it. If it didn't, it would have no nice way of refusing connections other than accepting and rejecting them. $ nc -vv -l -p 1025 retrying local 0.0.0.0:1025 : Address already in use retrying local 0.0.0.0:1025 : Address already in use retrying local 0.0.0.0:1025 : Address already in use retrying local 0.0.0.0:1025 : Address already in use Can't grab 0.0.0.0:1025 with bind $ while true; do nc -z localhost 1025 Mar 28 02:18:45 host inetd[190]: blackjack/tcp server failing (looping), service terminated ^C $ nc -vv -l -p 1025 listening on [any] 1025 ... > potential problem with specific binds (over inetd's INADDR_ANY) in this > configuration, though. Yes. I had thought that this was fixed up, but I guess I was perhaps thinking of Linux. Not sure what solution is in place there, don't follow Linux networking any more. I know I have an archived message from Aleph One around here on the subject from one of the mailing lists around the start of '96. It was discussed on several FreeBSD lists at the time, but I'm not sure anything came of it. If inetd did not set SO_REUSEADDR, it wouldn't be a problem because anyone else would be prevented from binding. However, I don't think that inetd really has much choice. OpenBSD has the following in netinet/in_pcb.c: if (so->so_uid) { t = in_pcblookup(table, zeroin_addr, 0, sin->sin_addr, lport, INPLOOKUP_WILDCARD); if (t && (so->so_uid != t->inp_socket->so_uid)) return (EADDRINUSE); } ...which prevents a process running as a different user from binding to the same port. The other option is to simply disallow multiple processes from binding to the same port entirely, but that is a bit extreme and over restrictive. To emphasize; right now, anyone can steal any connections going to an unprivileged port that inetd listens on, unless you use something like the -a option to inetd. That is bad. I think something resembling the above OpenBSD change is a good idea. Anyone? It is a minor waste to add another in_pcblookup call, but a quick glance shows that it appears to be necessary. > The real problem, as I see it, is that if reserved ports are enough of a > security concern for you that you'd dramatically complicate your inetd > configuration to handle them, you're going to have a real security concern > if inetd dies. I think it's bad to assume that an unprivileged user can't > cause a daemon to die. Yup. All the issues above are simply examples; fixing them would not make it worthwhile setting up inetd to prevent other processes from binding to the port. > > > are set to a particular default but still allow them to be changed) that > > handles setting it then add a few lines of code to the kernel to allow you > > to set the uid who can bind to each priv'd port. There are 1764 other > > things that it would be useful to be able to set in a similar way, > > Why do you want a UID per reserved port? What is this getting you? It lets me run my mailer on port 25 as "mail". It lets me run my web server on port 80 as "www". It lets me run my print spooler on port 515 as "print". It lets me run my cybercash (whatever that is...) on port 551 as "cash". If someone compromises my www user, my web service is compromised but my ever-important cybercash service on port 551 is not. For many of these programs there are legit reasons why it needs root for other things and it is normally not as easy as just allowing a non-root uid to bind to the port, but you have to start somewhere. From owner-freebsd-security Fri Mar 28 07:35:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA15788 for security-outgoing; Fri, 28 Mar 1997 07:35:22 -0800 (PST) Received: from cold.org (cold.org [206.81.134.103]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA15783 for ; Fri, 28 Mar 1997 07:35:18 -0800 (PST) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id IAA09543 for ; Fri, 28 Mar 1997 08:35:19 -0700 (MST) Date: Fri, 28 Mar 1997 08:35:19 -0700 (MST) From: Brandon Gillespie To: freebsd-security@FreeBSD.ORG Subject: alternate approach (Re: Privileged ports...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I know I'm jumping into this a bit late, but a while back I suggested something similar, which I think would work as well in this situation. Its along the same lines of defining the allowed user (and possibly group) in inetd.conf, but why do it there? I would suggest doing it to another file, such as /etc/services, or something similar, and just having it be a generic port configuration file overall. This file would define who can use what ports up to 1024, and it would also open up ports beyond 1024. This would have the added benefit that admins could reconfigure it to not allow general users to bind to ANY ports, period--if they are having problems with generic users throwing up disallowed network daemons. The format could be very simple, such as: PORTSPEC user group Where portspec is simply a single port, or range of ports given as the actual port number or name, as specified in /etc/services, examples: 1-79 root system http webadm webadm 81-1024 root system Or perhaps have a directive as the first 'word' on the line, so you could expand on the functionality for different behaviour (also giving a default for different ranges, so you could have overlapping declarations, such as 1-1024 default to root:system and port 80 given to webadm). Just a thought. -Brandon Gillespie From owner-freebsd-security Fri Mar 28 09:57:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24022 for security-outgoing; Fri, 28 Mar 1997 09:57:25 -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 JAA24017 for ; Fri, 28 Mar 1997 09:57:23 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id LAA22483; Fri, 28 Mar 1997 11:56:42 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703281756.LAA22483@enteract.com> Subject: Re: Privileged ports... To: marcs@znep.com (Marc Slemko) Date: Fri, 28 Mar 1997 11:56:40 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Marc Slemko" at Mar 28, 97 02:25:53 am X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OpenBSD has the following in netinet/in_pcb.c: [ elided ] > To emphasize; right now, anyone can steal any connections going > to an unprivileged port that inetd listens on, unless you use something > like the -a option to inetd. That is bad. I think something > resembling the above OpenBSD change is a good idea. Anyone? Isn't FreeBSD already doing a PCB lookup on attempts to bind specific ports? Right under the privileged port check, it tries to find a PCB for the sockaddr passed to bind(), and checks it for SO_REUSEPORT. You could just stick the UID check in there, at no PCB lookup cost, neh? What are the ramifications of enforcing a UID check on a socket address bound REUSEPORT, incidentally? ---------------- 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 Fri Mar 28 11:22:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA28145 for security-outgoing; Fri, 28 Mar 1997 11:22:43 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28139 for ; Fri, 28 Mar 1997 11:22:39 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id MAA22865; Fri, 28 Mar 1997 12:22:24 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id MAA22813; Fri, 28 Mar 1997 12:18:33 -0700 (MST) Date: Fri, 28 Mar 1997 12:18:33 -0700 (MST) From: Marc Slemko To: Brandon Gillespie cc: freebsd-security@FreeBSD.ORG Subject: Re: alternate approach (Re: Privileged ports...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk That is one possible solution, but I don't think there is any point in adding such a specific config file when so many other things could benefit from similar functionality. It is a dupe of sysctl in a lot of ways, so it may be an ide ato look at extending sysctl to handle it nicely. You need some interface to the kernel; some program like ipfw that goes through the file and reads the rules and sets them up in the kernel. This program could be used for a lot of things; a good project would be extending sysctl to allow for less rigidly defined variables. eg. can define ranges, variables that don't show up in a list until changed, having sysctl being able to read variables from a file (although this can be done now with a script, just isn't as nice... To summarize: good idea, lots of things like that, but as I have been saying all along we need a better generalized interface to such things because it makes little sense to keep adding little control programs here and there. Perhaps someday.... On Fri, 28 Mar 1997, Brandon Gillespie wrote: > I know I'm jumping into this a bit late, but a while back I suggested > something similar, which I think would work as well in this situation. > Its along the same lines of defining the allowed user (and possibly group) > in inetd.conf, but why do it there? I would suggest doing it to another > file, such as /etc/services, or something similar, and just having it be a > generic port configuration file overall. This file would define who can > use what ports up to 1024, and it would also open up ports beyond 1024. > This would have the added benefit that admins could reconfigure it to not > allow general users to bind to ANY ports, period--if they are having > problems with generic users throwing up disallowed network daemons. The > format could be very simple, such as: > > PORTSPEC user group > > Where portspec is simply a single port, or range of ports given as the > actual port number or name, as specified in /etc/services, examples: > > 1-79 root system > http webadm webadm > 81-1024 root system > > Or perhaps have a directive as the first 'word' on the line, so you could > expand on the functionality for different behaviour (also giving a default > for different ranges, so you could have overlapping declarations, such as > 1-1024 default to root:system and port 80 given to webadm). > > Just a thought. > > -Brandon Gillespie > From owner-freebsd-security Fri Mar 28 12:07:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA00354 for security-outgoing; Fri, 28 Mar 1997 12:07:26 -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 MAA00302; Fri, 28 Mar 1997 12:06:16 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id IAA06347; Fri, 28 Mar 1997 08:55:14 -0800 (PST) Message-Id: <199703281655.IAA06347@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd006344; Fri Mar 28 16:55:09 1997 Reply-to: cys@wlc.com X-Mailer: MH To: Gary Clark II cc: cschuber@uumail.gov.bc.ca, alexv@sui.gda.itesm.mx, freebsd-bugs@freebsd.org, freebsd-security@freebsd.org, cmercado@interface.com.mx Subject: Re: SetUID & Apache in 2.2-RELEASE... In-reply-to: Your message of "Fri, 28 Mar 1997 00:18:04 CST." <199703280618.AAA11018@main.gbdata.com> Date: Fri, 28 Mar 1997 08:55:08 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Cy Schubert wrote: > > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > > > > > Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of > > > the setuids cgis run (being executed by anybody but root). When I > > > remove from them the setuid flag, they can be executed (but I need to > > > execute them as setuids). Any Ideas? Thanx in advance... > > > > This is a Perl problem. I've encountered this with other Perl (5.003) > > scripts before, though I don't know what the solution is yet. > > > The problem is that the port does not setup perl to do suid scripts. You > have to enable this in the configure script. The FreeBSD Perl 5.003 port does turn on the setuid emulation, however it still doesn't work. > > > > > Cy Schubert Fax: (250)387-5766 > > Gary 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 Fri Mar 28 13:19:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA04329 for security-outgoing; Fri, 28 Mar 1997 13:19:57 -0800 (PST) Received: from smtp.enteract.com (qmailr@char-star.rdist.org [206.54.252.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04312 for ; Fri, 28 Mar 1997 13:19:46 -0800 (PST) Received: (qmail 22481 invoked by uid 1001); 28 Mar 1997 21:19:36 -0000 Message-ID: <19970328211936.22480.qmail@smtp.enteract.com> From: tqbf@char-star.rdist.org Subject: Re: More on reserved ports... To: freebsd-security@freebsd.org Date: Fri, 28 Mar 1997 15:19:36 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4ME+ PL31 (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 Fri, 28 Mar 1997 08:35:19 -0700 (MST) brandon@cold.org: >in inetd.conf, but why do it there? I would suggest doing it to another >file, such as /etc/services, or something similar, and just having it be a >generic port configuration file overall. This file would define who can How do you propose to implement this in the kernel? Remember, you can't enforce this using userland processes. Would you add some kind of data structure in the kernel to track all these ports, and system calls to add and remove ports from consideration, and a check against it in in_pcb.c? It seems like things are getting a bit complex now. -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ)); From owner-freebsd-security Fri Mar 28 14:51:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA09169 for security-outgoing; Fri, 28 Mar 1997 14:51:44 -0800 (PST) Received: from cold.org (cold.org [206.81.134.103]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA09164 for ; Fri, 28 Mar 1997 14:51:41 -0800 (PST) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id PAA10343; Fri, 28 Mar 1997 15:51:36 -0700 (MST) Date: Fri, 28 Mar 1997 15:51:36 -0700 (MST) From: Brandon Gillespie To: Marc Slemko cc: freebsd-security@FreeBSD.ORG Subject: Re: alternate approach (Re: Privileged ports...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 28 Mar 1997, Marc Slemko wrote: > That is one possible solution, but I don't think there is any point in > adding such a specific config file when so many other things could benefit > from similar functionality. It is a dupe of sysctl in a lot of ways, so > it may be an ide ato look at extending sysctl to handle it nicely. > > You need some interface to the kernel; some program like ipfw that goes > through the file and reads the rules and sets them up in the kernel. This > program could be used for a lot of things; a good project would be > extending sysctl to allow for less rigidly defined variables. eg. can > define ranges, variables that don't show up in a list until changed, > having sysctl being able to read variables from a file (although this can > be done now with a script, just isn't as nice... > > To summarize: good idea, lots of things like that, but as I have been > saying all along we need a better generalized interface to such things > because it makes little sense to keep adding little control programs here > and there. Perhaps someday.... It would be easy enough to have /etc/netstart simply chew on the port config file and feed it to sysctl. One reason I like the idea of having a file for the config is for the visual aspect. Having a bunch of vars defined in /etc/sysconfig is OK, but not as visual as being able to map everything out through a whole file.. *shrug* From owner-freebsd-security Fri Mar 28 15:15:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA10742 for security-outgoing; Fri, 28 Mar 1997 15:15:10 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA10730 for ; Fri, 28 Mar 1997 15:15:08 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id QAA02015; Fri, 28 Mar 1997 16:15:02 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id QAA24158; Fri, 28 Mar 1997 16:14:43 -0700 (MST) Date: Fri, 28 Mar 1997 16:14:43 -0700 (MST) From: Marc Slemko To: "Thomas H. Ptacek" cc: freebsd-security@FreeBSD.ORG Subject: Re: Privileged ports... In-Reply-To: <199703281756.LAA22483@enteract.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Some mail I have been exchanging with Theo de Raadt has made it apparent that perhaps my suggestion could be taken in the wrong way. It is NOT really related to the question of having inetd bind to ports to prevent other processes from binding to them if you get rid of reserved ports, but is simply a general problem. It affects many processes including nfsd. Anyone feel like stealing traffic (or, more likely, worse...) from port 2049? No problem, any user can do that as things are now. I should also probably clarify that the suggested change is by no means complete, eg. you have to add the uid credential to sockets so you what uid bound to it in the first place to do the comparison. On Fri, 28 Mar 1997, Thomas H. Ptacek wrote: > > OpenBSD has the following in netinet/in_pcb.c: > > [ elided ] > > > To emphasize; right now, anyone can steal any connections going > > to an unprivileged port that inetd listens on, unless you use something > > like the -a option to inetd. That is bad. I think something > > resembling the above OpenBSD change is a good idea. Anyone? > > Isn't FreeBSD already doing a PCB lookup on attempts to bind specific > ports? Right under the privileged port check, it tries to find a PCB for > the sockaddr passed to bind(), and checks it for SO_REUSEPORT. You could > just stick the UID check in there, at no PCB lookup cost, neh? Except that doesn't always check for sockets bound to wildcard addresses (last parm to in_pcblookup) while we need to do that for the uid check. I see no obvious way to integrate the two calls; it could be implemented by rewriting in_pcblookup but that is a different matter... > > What are the ramifications of enforcing a UID check on a socket address > bound REUSEPORT, incidentally? Can't think of too many. If you had a program running from inetd that tried to bind to a port after being started you could run into some issues perhaps. From owner-freebsd-security Fri Mar 28 16:54:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18863 for security-outgoing; Fri, 28 Mar 1997 16:54:26 -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 QAA18858 for ; Fri, 28 Mar 1997 16:54:23 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id SAA13470; Fri, 28 Mar 1997 18:54:20 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199703290054.SAA13470@enteract.com> Subject: Re: Privileged ports... To: marcs@znep.com (Marc Slemko) Date: Fri, 28 Mar 1997 18:54:19 -0600 (CST) Cc: tqbf@enteract.com, freebsd-security@FreeBSD.ORG Reply-To: tqbf@enteract.com In-Reply-To: from "Marc Slemko" at Mar 28, 97 04:14:43 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > that perhaps my suggestion could be taken in the wrong way. It is NOT > really related to the question of having inetd bind to ports to prevent This is a moot point. I don't think anyone has made any comments that really indicate that using inetd as a form of port access-control is feasible. > is simply a general problem. It affects many processes including nfsd. > Anyone feel like stealing traffic (or, more likely, worse...) from port > 2049? No problem, any user can do that as things are now. This is not news, and isn't particularly germane to this discussion. Obviously, UDP/TCP 2049 is a problem; it's been brought up in quite a few discussion (though not this one) with respect to privileged port security (the SO_REUSEADDR/specific-bind thing last year leaps to mind). It is, however, interesting to note (as Mr. de Raadt did rather forcefully with me) that opening up the privileged port range to arbitrary users will probably subvert NFS in subtle ways; for instance, the portmapper is now fair game for attackers, and the possibility of NFS/portmapper dependancies needs to be addressed. However, I'll again re-assert that this isn't something I'm trying to solve; the patch I posted simply allows a different user besides root to bind privileged ports. I have yet to suggest that *every* user be able to do so, which is an impression I think many people are getting. Something that is probably worth discussing is the security of UID 0, compared to the security of any other arbitrary UID on the system. Is it safer to run a process as UID 0 (certain system calls could potentially check that a process is running as superuser and return EACCESS) than with any other credentials? > I should also probably clarify that the suggested change is by no means > complete, eg. you have to add the uid credential to sockets so you what > uid bound to it in the first place to do the comparison. I think anyone trying to implement that change would have noticed rather quickly that this is the case; whether FreeBSD is completely set up to drop that code in right now is irrelevant. Should the kernel check the owner of a socket, currently bound, if something else is trying to manipulate a potentially conflicting socket address? If this is the case, we should get that code working. If not, we should move on. Neh? [ re: ramifications of REUSEPORT and socket UID checks ] > Can't think of too many. If you had a program running from inetd that > tried to bind to a port after being started you could run into some issues > perhaps. The idea behind REUSEPORT is to allow multiple processes to read incoming packets, implementing something of a socket-level broadcasting facility. It seems to me that forcing all such sockets to be of the same credentials unreasonably restricts the usefulness of this feature. ---------------- 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 Fri Mar 28 20:50:43 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA08221 for security-outgoing; Fri, 28 Mar 1997 20:50:43 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA08216 for ; Fri, 28 Mar 1997 20:50:35 -0800 (PST) Received: from mailbox.nosc.mil by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0wAq5y-0008v9C; Fri, 28 Mar 97 20:50 PST Received: from localhost (swann@localhost) by mailbox.nosc.mil (8.8.3/8.8.3) with SMTP id XAA18980 for ; Fri, 28 Mar 1997 23:39:02 -0500 (EST) X-Authentication-Warning: mailbox.nosc.mil: swann owned process doing -bs Date: Fri, 28 Mar 1997 23:39:01 -0500 (EST) From: Bryan Swann X-Sender: swann@mailbox To: freebsd-security@freebsd.org Subject: Re: SetUID & Apache in 2.2-RELEASE... In-Reply-To: <199703280618.AAA11018@main.gbdata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Someone else originally setup a FBSD box that I now administer. It is running 2.1.5 FBSD and Apache 1.2b6. I was attempting to write a PERL suid CGI script as well. I found that the suid script would fail with NO error messages. I also found that a bourne shell suid script would not run either. I assume that suid scripts are not allowed in FBSD. If there is a way to allow suid scripts, please forward the information. BTW, I tried to get the PERL suid emulation working, but I would agree that this doesn't work yet. Although I didn't get any compile errors, the suid script still failed after I tried multiple times to compile the emulation into PERL. __________________________________________________________________________ | Bryan Swann (swann@nosc.mil) 803/974-4267 803/974-5080 (Fax) | | Eagan McAllister Associates, Inc. | | | | "Everything must be working perfectly, cause I don't smell any smoke" | -------------------------------------------------------------------------- On Fri, 28 Mar 1997, Gary Clark II wrote: > Cy Schubert wrote: > > > I used to have some setuids CGIs running with my 2.1.5 fbsdbox, and > > > them executed pretty well with Apache 1.1.1 & Perl 5.002. > > > > > > Now, I upgraded to 2.2-RELEASE, Apache 1.2b7 & Perl 5.003, and none of > > > the setuids cgis run (being executed by anybody but root). When I > > > remove from them the setuid flag, they can be executed (but I need to > > > execute them as setuids). Any Ideas? Thanx in advance... > > > > This is a Perl problem. I've encountered this with other Perl (5.003) > > scripts before, though I don't know what the solution is yet. > > > The problem is that the port does not setup perl to do suid scripts. You > have to enable this in the configure script. > > > > > Cy Schubert Fax: (250)387-5766 > > Gary > > -- > Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company > gclarkii@GBData.COM | Member of the FreeBSD Doc Team > Providing Internet and ISP startups - http://WWW.GBData.com for information > FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/FAQ.latin1 > From owner-freebsd-security Fri Mar 28 21:31:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA10074 for security-outgoing; Fri, 28 Mar 1997 21:31:45 -0800 (PST) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA10065; Fri, 28 Mar 1997 21:31:41 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id GAA21069; Sat, 29 Mar 1997 06:31:35 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id GAA10778; Sat, 29 Mar 1997 06:31:23 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id CAA13753; Sat, 29 Mar 1997 02:37:05 +0100 (CET) Message-ID: <19970329023703.12673@keltia.freenix.fr> Date: Sat, 29 Mar 1997 02:37:03 +0100 From: Ollivier Robert To: freebsd-bugs@freebsd.org, freebsd-security@freebsd.org Subject: Re: SetUID & Apache in 2.2-RELEASE... References: <199703280618.AAA11018@main.gbdata.com> <199703281655.IAA06347@cwsys.cwent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <199703281655.IAA06347@cwsys.cwent.com>; from Cy Schubert on Fri, Mar 28, 1997 at 08:55:08AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3153 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Cy Schubert: > The FreeBSD Perl 5.003 port does turn on the setuid emulation, however it > still doesn't work. The Perl 5.003 port still use POSIX saved uids where 2.2 and CURRENT have them disabled. Try using /usr/local/bin/suidperl directly instead. soon-to-be-5.004 will work out of the box with all versions of FreeBSD (I hope). -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #41: Sun Mar 23 23:01:22 CET 1997