From owner-freebsd-security Sun Feb 22 23:33:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03392 for freebsd-security-outgoing; Sun, 22 Feb 1998 23:33:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from odin.besys.net.au (root@odin.besys.net.au [203.103.239.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03387 for ; Sun, 22 Feb 1998 23:33:55 -0800 (PST) (envelope-from ingold@besys.net.au) Received: from ingold.besys.net.au (ingold.besys.net.au [203.103.239.196]) by odin.besys.net.au (8.8.7/8.8.7) with SMTP id SAA13755 for ; Mon, 23 Feb 1998 18:33:44 +1100 (EST) Message-Id: <3.0.5.32.19980223183214.008f1100@office.besys.net.au> X-Sender: ingold@office.besys.net.au (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 23 Feb 1998 18:32:14 +1100 To: freebsd-security@FreeBSD.ORG From: Peter Champas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk unsubscribe freebsd-security -- *---------------------[ http://www.besys.net.au/ ]---------------------* | Peter Champas | peter@besys.net.au | |----------------------------------------------------------------------| | I don't demand perfection, just something that's reasonably reliable | *----------------------------------------------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Mon Feb 23 09:56:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07798 for freebsd-security-outgoing; Mon, 23 Feb 1998 09:56:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07744 for ; Mon, 23 Feb 1998 09:55:58 -0800 (PST) (envelope-from cschuber@passer.osg.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id JAA02501; Mon, 23 Feb 1998 09:55:22 -0800 (PST) Message-Id: <199802231755.JAA02501@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaaCula; Mon Feb 23 09:55:13 1998 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: "David E. Tweten" cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab In-reply-to: Your message of "Sat, 21 Feb 1998 11:57:04 PST." <199802211957.LAA16982@ns.frihet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Feb 1998 09:54:35 -0800 From: Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > robert@cyrus.watson.org said: > >I have actually found that the best and most enjoyable solution to / > >tmp-cleaning is to use an MFS-based /tmp. > > I agree. I use it. My problem isn't /tmp cleaning. It's cleaning #* files, > *~ files, core files, etc. from wherever they hide. My exmh #* files, for > example, live under my home directory in the messages' original folders from > before they were "deleted" by exmh. > > The problem that used to be solved by find and rm, before we discovered that > they constitute unsafe computing, is (old) junk files wherever they may be > found. > > So, again, did FreeBSD decide to do anything more than comment out junk file > removal in /etc/daily? If so, is it done and what is it? If not, can I help Try the -delete flag of find. It is not atomic so a race condition, though much smaller, still exists. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Feb 24 08:30:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26246 for freebsd-security-outgoing; Tue, 24 Feb 1998 08:30:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26214 for ; Tue, 24 Feb 1998 08:30:18 -0800 (PST) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id IAA03017; Tue, 24 Feb 1998 08:02:35 -0800 (PST) (envelope-from tweten@ns.frihet.com) Message-Id: <199802241602.IAA03017@ns.frihet.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Cy Schubert - ITSD Open Systems Group cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Feb 1998 08:02:34 -0800 From: "David E. Tweten" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk cschuber@uumail.gov.bc.ca said: >Try the -delete flag of find. Perhaps I ought to read TFM next time ... Looks like this handles the rm half of the root-find-and-rm security hole. The original explanation featured two problems. The rm problem is that it follows directory symbolic links, even when find does not. Since find (as used for junk file cleaning) calls rm with a full path, rather than a current- directory-relative file name, a properly timed directory symbolic link insertion (after found and before rm'ed) can cause root to delete an unintended file. Since the find "-delete" option operates relative to find's current directory, it seems to me it should completely handle that part of the problem. Do you have any idea why the commented-out finds in /etc/daily haven't been changed to use "-delete" instead of "rm -f {} ;\"? >It is not atomic so a race condition, though much smaller, still exists. Care to expand on that? What is the race, and how could a cracker exploit it? The find documentation on "-delete" looks pretty safe to me. Of course, all this still leaves find vulnerable to confusion while working its way back out of a path that's been changed since find entered it. That part should be fixed in find. Is anybody working on it? -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue Feb 24 09:21:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03262 for freebsd-security-outgoing; Tue, 24 Feb 1998 09:21:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03249 for ; Tue, 24 Feb 1998 09:20:47 -0800 (PST) (envelope-from cschuber@passer.osg.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id JAA19354; Tue, 24 Feb 1998 09:20:11 -0800 (PST) Message-Id: <199802241720.JAA19354@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaanpua; Tue Feb 24 09:20:03 1998 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: "David E. Tweten" cc: Cy Schubert - ITSD Open Systems Group , Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab In-reply-to: Your message of "Tue, 24 Feb 1998 08:02:34 PST." <199802241602.IAA03017@ns.frihet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Feb 1998 09:19:21 -0800 From: Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > cschuber@uumail.gov.bc.ca said: > >Try the -delete flag of find. > > Perhaps I ought to read TFM next time ... Looks like this handles the rm > half of the root-find-and-rm security hole. > > The original explanation featured two problems. The rm problem is that it > follows directory symbolic links, even when find does not. Since find (as > used for junk file cleaning) calls rm with a full path, rather than a > current- directory-relative file name, a properly timed directory symbolic > link insertion (after found and before rm'ed) can cause root to delete an > unintended file. > > Since the find "-delete" option operates relative to find's current > directory, it seems to me it should completely handle that part of the > problem. Do you have any idea why the commented-out finds in /etc/daily > haven't been changed to use "-delete" instead of "rm -f {} ;\"? > > >It is not atomic so a race condition, though much smaller, still exists. > > Care to expand on that? What is the race, and how could a cracker exploit > it? The find documentation on "-delete" looks pretty safe to me. A race condition can exist because the time it takes, however small, between finding a file that should be deleted and issuing the remove(3) or unlink(2) call. The instruction stream in find could be interrupted and another process, possibly a process racing with find to insert a symlink into the tree, could get control. Giving find a high priority would help but is no guarantee either. I suppose /etc/daily could be changed to use -delete and have a comment (warning) indicating that this is unsafe. > > Of course, all this still leaves find vulnerable to confusion while working > its way back out of a path that's been changed since find entered it. That > part should be fixed in find. Is anybody working on it? How can find guarantee that the directory tree hasn't changed since it entered it? > -- > David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com > 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com > Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 > Those who make good products sell products; those who don't, sell solutions. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 07:02:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29304 for freebsd-security-outgoing; Wed, 25 Feb 1998 07:02:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29200 for ; Wed, 25 Feb 1998 07:01:37 -0800 (PST) (envelope-from pondemer@isty-info.uvsq.fr) Received: from athanase.isty-info.uvsq.fr (athanase.isty-info.uvsq.fr [193.51.33.2]) by soleil.uvsq.fr (8.8.6/jtpda-5.2.9.2) with ESMTP id QAA11184 for ; Wed, 25 Feb 1998 16:01:23 +0100 (MET) Received: from athanase (athanase.isty-info.uvsq.fr [193.51.33.2]) by athanase.isty-info.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id QAA12887 for ; Wed, 25 Feb 1998 16:01:22 +0100 (MET) Message-ID: <34F43241.4562@isty-info.uvsq.fr> Date: Wed, 25 Feb 1998 16:01:21 +0100 From: Nicolas Pondemer X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.01 9000/819) MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: Invisible Carbon Copy in mail.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hello, I have heard some rumours about a possible trick to insert an invisible Carbon Copy when you send an email... Is it just a rumour ?? Thanks in advance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 07:14:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02417 for freebsd-security-outgoing; Wed, 25 Feb 1998 07:14:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02293 for ; Wed, 25 Feb 1998 07:13:50 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id KAA27192; Wed, 25 Feb 1998 10:13:30 -0500 (EST) Date: Wed, 25 Feb 1998 10:11:42 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Nicolas Pondemer cc: freebsd-security@FreeBSD.ORG Subject: Re: Invisible Carbon Copy in mail.. In-Reply-To: <34F43241.4562@isty-info.uvsq.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 25 Feb 1998, Nicolas Pondemer wrote: > I have heard some rumours about a possible trick to > insert an invisible Carbon Copy when you send an email... > > Is it just a rumour ?? > > Thanks in advance. Bcc? Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message From owner-freebsd-security Wed Feb 25 07:30:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA05786 for freebsd-security-outgoing; Wed, 25 Feb 1998 07:30:51 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA05732 for ; Wed, 25 Feb 1998 07:30:20 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id QAA25674; Wed, 25 Feb 1998 16:30:14 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id QAA25401; Wed, 25 Feb 1998 16:29:24 +0100 (MET) Message-ID: <19980225162923.KC45188@mars.hsc.fr> Date: Wed, 25 Feb 1998 16:29:23 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: pondemer@isty-info.uvsq.fr (Nicolas Pondemer) Cc: freebsd-security@FreeBSD.ORG Subject: Re: Invisible Carbon Copy in mail.. References: <34F43241.4562@isty-info.uvsq.fr> X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 In-Reply-To: <34F43241.4562@isty-info.uvsq.fr>; from Nicolas Pondemer on Feb 25, 1998 16:01:21 +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk According to Nicolas Pondemer: > I have heard some rumours about a possible trick to > insert an invisible Carbon Copy when you send an email... Are you talking about Bcc: (Blind Carbon Copy) ? It's not a rumor. Most decent mail user agents implement this, and even less decent ones. -- Pierre.Beyssac@hsc.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 09:08:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24146 for freebsd-security-outgoing; Wed, 25 Feb 1998 09:08:29 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23881; Wed, 25 Feb 1998 09:07:54 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199802251707.JAA23881@hub.freebsd.org> Subject: Re: Invisible Carbon Copy in mail.. In-Reply-To: <34F43241.4562@isty-info.uvsq.fr> from Nicolas Pondemer at "Feb 25, 98 04:01:21 pm" To: pondemer@isty-info.uvsq.fr (Nicolas Pondemer) Date: Wed, 25 Feb 1998 09:07:53 -0800 (PST) Cc: 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 Nicolas Pondemer wrote: > Hello, > > I have heard some rumours about a possible trick to > insert an invisible Carbon Copy when you send an email... are your referring to "blind carbon copy"? this is not new. "mail -b
address" will do it for you. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 09:55:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06126 for freebsd-security-outgoing; Wed, 25 Feb 1998 09:55:25 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06079 for ; Wed, 25 Feb 1998 09:54:46 -0800 (PST) (envelope-from tweten@ns.frihet.com) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.8.8/8.8.8) with ESMTP id JAA05503; Wed, 25 Feb 1998 09:50:30 -0800 (PST) (envelope-from tweten@ns.frihet.com) Message-Id: <199802251750.JAA05503@ns.frihet.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Cy Schubert - ITSD Open Systems Group cc: freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 1998 09:50:29 -0800 From: "David E. Tweten" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Concerning use by root of find -delete, cschuber@uumail.gov.bc.ca said: >A race condition can exist because the time it takes, however small, >between finding a file that should be deleted and issuing the >remove(3) or unlink(2) call. The instruction stream in find could be >interrupted and another process, possibly a process racing with find >to insert a symlink into the tree, could get control. If I'm not misreading the man page and if it is an accurate reflection of the code, that race should not be a problem. Of "-delete", the man page says, "This executes from the current working directory as find recurses down the tree. It will not attempt to delete a filename with a ``/'' character in its pathname relative to "." for security reasons." Since the current working directory is held as an inode, not as a path, "-delete" should not be able to get out of sync with the rest of find, even if someone inserts a symbolic link into the path to the current working directory. It still looks safe to me. >I suppose /etc/daily could be changed to use -delete and have a >comment (warning) indicating that this is unsafe. The unsafety warning currently exists. The problem is just that the commented-out code is even less safe than it has to be. If others (like me) uncomment the code, they shouldn't get code that is more dangerous than it has to be to provide the functionality they desire. Initially quoting me, cschuber@uumail.gov.bc.ca continued: >>Of course, all this still leaves find vulnerable to confusion while working >>its way back out of a path that's been changed since find entered it. That >>part should be fixed in find. Is anybody working on it? > >How can find guarantee that the directory tree hasn't changed since it entered >it? Find can't guarantee that a path won't change. It can guarantee that it won't get confused. It could build a stack of name-inode-device combinations on its way into a path, and compare the current inode-device pair after each chdir(".."). If the pairs are different, find need only cd into the deepest directory it can, above the one it wants, and continue business. Actually, using "-delete", even this measure may not be absolutely necessary, since delete works from find's current working directory. The exploit discussed in the original Chris Layne e-mail depends upon find and rm disagreeing over which inode-device pair corresponds to the path leading to find's current working directory. Since -delete works out of find's current working directory, that difference of opinion is impossible. It still might be a good idea for find to use the stack I mentioned above, if only to be able to "-print" out the right path names. If my analysis is correct, after changing /etc/daily's commented-out find commands to use "-delete" instead of "-exec rm -f {} \;" the comment characters should simply be removed. It seems "find ... -delete" is safe. -- David E. Tweten | 2047-bit PGP fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 "Take my wife, please." Henny Youngman (1906-1998) May he rest in peace. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 10:00:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07157 for freebsd-security-outgoing; Wed, 25 Feb 1998 10:00:11 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07049 for ; Wed, 25 Feb 1998 09:59:36 -0800 (PST) (envelope-from cschuber@passer.osg.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id JAA23441 for ; Wed, 25 Feb 1998 09:59:31 -0800 (PST) Message-Id: <199802251759.JAA23441@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaawCva; Wed Feb 25 09:59:24 1998 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: freebsd-security@FreeBSD.ORG Subject: Re: Invisible Carbon Copy in mail.. In-reply-to: Your message of "Wed, 25 Feb 1998 16:01:21 +0100." <34F43241.4562@isty-info.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Feb 1998 09:58:43 -0800 From: Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk It's called a blind carbon copy. Use the "bcc:" header. I've bcc'd you on this note to give you an example of the output. Bcc has been handled by Sendmail for a number of years. Most of the time it's worked, sometimes it has not, e.g. under one old release of Sendmail bcc recipients had sometimes been listed in any messages. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca > Hello, > > I have heard some rumours about a possible trick to > insert an invisible Carbon Copy when you send an email... > > Is it just a rumour ?? > > Thanks in advance. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 11:46:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28124 for freebsd-security-outgoing; Wed, 25 Feb 1998 11:46:11 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28115 for ; Wed, 25 Feb 1998 11:46:06 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id LAA19018; Wed, 25 Feb 1998 11:44:53 -0800 (PST) To: Pierre.Beyssac@hsc.fr (Pierre Beyssac) cc: pondemer@isty-info.uvsq.fr (Nicolas Pondemer), freebsd-security@FreeBSD.ORG Subject: Re: Invisible Carbon Copy in mail.. In-reply-to: Your message of "Wed, 25 Feb 1998 16:29:23 +0100." <19980225162923.KC45188@mars.hsc.fr> Date: Wed, 25 Feb 1998 11:44:52 -0800 Message-ID: <19015.888435892@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Are you talking about Bcc: (Blind Carbon Copy) ? It's not a rumor. > Most decent mail user agents implement this, and even less decent > ones. I think this little story, courtesy of the USENET Oracle, pretty much explains the origins of the term: ---- The Usenet Oracle has pondered your question deeply. Your question was: > So Orrie old chum, what this "Bcc" business in the headers of my > document. And in response, thus spake the Usenet Oracle: } "Bcc" stands for Blind Carbon Copy. But that doesn't tell you much. } Sit back and learn a bit of Net lore. } } Back in the ancient, cloudy, misty days of the ancestors of the } Internet, back around 1979, an old, worn-out blues musician used to } warm his tired bones in the sun on Sproul Plaza at the University of } California, Berkeley, from time to time putting his old harmonica to } his mouth and playing a riff or two, and now and then saying "God } bless you" to some kind soul who had thrown a coin in his battered old } derby. } } Come December it grew cold, even in California, and the venerable } blues man began looking for a building he could doze in without being } thrown out. Eventually he discovered the Computer Center, an ideal } place because in those glorious days the only people using it were } True Hackers who worked at night and slept during the day, mostly face } down alongside their keyboards. Once our protagonist had rescued an } old Cal sweatshirt from a trash can and begun wearing it while he } napped at a terminal station, no one questioned his right to be there. } } This old blues man, of course, was none other than Blind Carbon Copy. } } He had picked up the majority of his nickname back in the '20s, when } as a boy he would sneak into the honky-tonks and listen to the sweet } Delta blues he heard there, then sneak back home and practice what } he'd learned. One night when a young Al Jolson was performing, Bcc } was so caught up in the music that he forgot to wait until he was home } to practice, and when Al and the boys came out the stage door they } found a young boy in the alley singing his heart out in a perfect } imitation of the Master. "Al, that boy just a carbon copy of you," } the bass man said, and the name stuck. } } Now Blind Carbon Copy wasn't blind, but did you ever hear of a Delta } blues man who wasn't nicknamed Blind something? } } --Well, after a few days of napping in the Berkeley lab Bcc got } curious about what all those red-eyed young-'uns was doing there, and } he started moving from monitor to monitor and reading over people's } shoulders. He couldn't make much out of FORTRAN or C code, but every } now and then he'd come upon someone reading his e-mail, and he'd read } the message, and make a song out of it if he could, walking off into } the center of the room and softly accompanying himself on his blues } harp: } } I've got a na-aasty bug, an' I'm feelin' mighty blue } } I said mah code's got a big bug, makes me feel so goddam blue } } Mah core's gone an' dumped me, said mah programmin' days was } through! } } His lyrics eventually worked their way into the bleary consciousnesses } of the Berkeley hackers. Dumbfounded at first, they quickly warmed to } the idea of improvisational blues e-mail, and pretty soon got in the } habit of calling Blind Carbon Copy over--when he was awake, of } course--when they had received a particularly promising message that } they wanted him to render. Some of the more musical of the group got } Bcc to teach them how to sing the blues too, and began doing their own } riffs when Bcc was asleep or away. } } Well, the Berkeley group split up, as all things will; Bcc went back } to Louisiana to live with his daughter's family, the hackers } graduated, or got jobs, or became bums. But whenever one of them sent } e-mail to someone working with one of the old crowd, they'd attach a } header reading, let's say, "Blind Carbon Copy: William Joy", to } indicate that the recipient should call Bill Joy over to do the blues } on the message. } } Before long the header was shortened to the standard "Bcc" in Berkeley } sendmail. But the tradition lives on. Mostly nowadays the Bcc } heading is just a ritual gesture, and few are the companies and } schools where people know enough Net history to call for one of their } colleagues to come sing their e-mail when they have a Bcc line. But } now you know, and you know what to do, and remember, above all, that } even if you get funny looks when someone's reading over your shoulder } and laying down that e-mail wail, there's an old Delta blues man, } lying in a bed in an old-folks home in Baton Rouge now, who hears and } is blessed every time you sing them. } } Blind Carbon Copy--part of your Internet heritage! } } (This Oracularity sponsored by the Internet Cultural Task Force, the } Corporation for Public Broadcasting, and the Louisiana Office of } Tourism.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed Feb 25 12:22:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06489 for freebsd-security-outgoing; Wed, 25 Feb 1998 12:22:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06430 for ; Wed, 25 Feb 1998 12:22:43 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id PAA01134; Wed, 25 Feb 1998 15:21:45 -0500 (EST) Date: Wed, 25 Feb 1998 15:19:54 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: "David E. Tweten" cc: Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: Find, Rm, and Root's Crontab In-Reply-To: <199802251750.JAA05503@ns.frihet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Wed, 25 Feb 1998, David E. Tweten wrote: > Concerning use by root of find -delete, cschuber@uumail.gov.bc.ca said: > >A race condition can exist because the time it takes, however small, > >between finding a file that should be deleted and issuing the > >remove(3) or unlink(2) call. The instruction stream in find could be > >interrupted and another process, possibly a process racing with find > >to insert a symlink into the tree, could get control. > > If I'm not misreading the man page and if it is an accurate reflection of the > code, that race should not be a problem. Of "-delete", the man page says, > "This executes from the current working directory as find recurses down the > tree. It will not attempt to delete a filename with a ``/'' character in its > pathname relative to "." for security reasons." Since the current working > directory is held as an inode, not as a path, "-delete" should not be able to > get out of sync with the rest of find, even if someone inserts a symbolic > link into the path to the current working directory. It still looks safe to > me. I am concerned that the following race condition may exist, but have not looked at the find code: 1) Find retrieves directory contents 2) Find determines which are directories, and recurses to them If find opens each directory entry, fstats the fd, then fchdirs to the fd, does business (recurding through and unlinking contents), and returns out unlinking on the way, all is well. If it retrieves contents and stats them, but then chdirs to them without using fchdir, find could suffer from a race attack if the directory were replaced with a symlink to another directory in between the two calls. For example, I create /tmp/beans; find begins executing and sees /tmp/beans -- it determines it is a directory. I remove /tmp/beans and replace it with a symlink to /var/log. Now find recurses into the directory and mayhem ensues. Note that I have not read the code and am merely talking about how it may be implemented, not how it is. :) This can occur even with the use of chdir to the directory for removal. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message From owner-freebsd-security Wed Feb 25 18:31:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03868 for freebsd-security-outgoing; Wed, 25 Feb 1998 18:31:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.iconz.co.nz (mail.iconz.co.nz [202.14.100.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03845 for ; Wed, 25 Feb 1998 18:31:30 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from [192.168.1.1] (a.mcn.actrix.gen.nz [203.96.56.128]) by mail.iconz.co.nz (8.8.7/8.8.7) with SMTP id PAA173260888460273 for ; Thu, 26 Feb 1998 15:31:13 +1300 (NZDT) X-Sender: squiz1@pop.actrix.gen.nz Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Feb 1998 15:32:50 +1300 To: freebsd-security@FreeBSD.ORG From: andrew@squiz.co.nz (Andrew McNaughton) Subject: Re: Find, Rm, and Root's Crontab Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk There's been several discussions on BUGTRAQ about race conditions when cleaning /tmp. A good explanation of the problem and suggestions for solutions can be found in an archive of the BUGTRAQ mailing list at: http://geek-girl.com/bugtraq/1996_2/0054.html In other postings there are a couple of programs referred to. This GPL solution was mentioned there and not shot down (as several others suggestions were): ftp://wuarchive.wustl.edu/systems/linux/redhat/redhat-4.2/SPRMS/tmpwatch-1.2 .1-1.rpm There's also a full listing of a largish perl script to do the job in the BUGTRAQ archive. No suggestion of it's being incorrect, but it's a fair size pile of code to go through. I have no personal experience of either of these /tmp cleanup programs as yet. Andrew McNaughton The effort to understand the universe is Andrew McNaughton one of the very few things that lifts ++64 4 389 6891 human life above the level of farce, andrew@squiz.co.nz and gives it some of the grace http://www.squiz.co.nz of tragedy - Steven Weinberg http://www.newsroom.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 00:16:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12292 for freebsd-security-outgoing; Thu, 26 Feb 1998 00:16:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from door.sniff.ct-net.de (door.sniff.ct-net.de [195.4.160.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA12285 for ; Thu, 26 Feb 1998 00:16:03 -0800 (PST) (envelope-from marc@sniff.ct-net.de) From: marc@sniff.ct-net.de Received: (from uucp@localhost) by door.sniff.ct-net.de (8.8.7/8.8.7/mb-b) with UUCP id IAA02361 for freebsd-security@freebsd.org; Thu, 26 Feb 1998 08:15:43 GMT Received: (from marc@localhost) by home.sniff.ct-net.de (8.8.7/8.8.7/mb-b) id IAA01580 for freebsd-security@freebsd.org; Thu, 26 Feb 1998 08:14:38 GMT Message-Id: <199802260814.IAA01580@home.sniff.ct-net.de> Subject: login.access weakness To: freebsd-security@FreeBSD.ORG (FreeBSD Security List) Date: Thu, 26 Feb 1998 08:14:37 +0000 (GMT) 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 Hello! (Never heard of this, so it should be new?) On a 2.2.2 box I found the following behaviour which I think is a bug: in /etc/login.access -:testuser: ALL EXCEPT ttyv0 ttyv1 ttyv2 ttyv3 ttyv4 ttyv5 ttyv6 ttyv7 and in 192.168.254.zone 10 IN PTR ttyv7. (192.168.254.x is the private address space I use for my small test-network. The file 192.168.254.zone is the reverse-mapping for the DNS bind) I expected the login.access line to prevent any login from the net. This works for a telnet from a system with e.g. 192.168.254.2. But from a computer with the IP address 192.168.254.10 one is able to login into testuser. Can anyone else confirm this? Is this a bug or did I do a mistake? The login process should look for at least do.main, right? Or is there anyone out in the internet with a toplevel hostname? ;) Regards, Marc -- Marc Binderberger 97076 Wuerzburg, Germany marc@sniff.ct-net.de Powered by FreeBSD ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 00:43:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA17313 for freebsd-security-outgoing; Thu, 26 Feb 1998 00:43:23 -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 AAA17298 for ; Thu, 26 Feb 1998 00:43:19 -0800 (PST) (envelope-from security@giga.lss.cp.philips.com) Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id JAA23956; Thu, 26 Feb 1998 09:43:09 +0100 Received: from smtprelay.nl.cis.philips.com(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma023127; Thu Feb 26 09:41:06 1998 Received: from giga.lss.cp.philips.com (giga.lss.cp.philips.com [130.144.199.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970402) with ESMTP id JAA01567; Thu, 26 Feb 1998 09:41:03 +0100 Received: (from security@localhost) by giga.lss.cp.philips.com (8.8.8/8.8.7/GIGA) id JAA02768; Thu, 26 Feb 1998 09:41:02 +0100 (MET) (envelope-from security) From: Walter Belgers for mailing lists Message-Id: <199802260841.JAA02768@giga.lss.cp.philips.com> Subject: Re: login.access weakness In-Reply-To: <199802260814.IAA01580@home.sniff.ct-net.de> from "marc@sniff.ct-net.de" at "Feb 26, 98 08:14:37 am" To: marc@sniff.ct-net.de Date: Thu, 26 Feb 1998 09:41:02 +0100 (MET) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk marc@sniff.ct-net.de writes: > > The login process should look for at least do.main, right? > Or is there anyone out in the internet with a toplevel hostname? ;) As a matter of fact, yes there is :) cd. 86400 A 194.38.74.11 > Regards, Marc Cheers, Walter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 04:38:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11650 for freebsd-security-outgoing; Thu, 26 Feb 1998 04:38:40 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11641 for ; Thu, 26 Feb 1998 04:38:33 -0800 (PST) (envelope-from pondemer@isty-info.uvsq.fr) Received: from athanase.isty-info.uvsq.fr (athanase.isty-info.uvsq.fr [193.51.33.2]) by soleil.uvsq.fr (8.8.6/jtpda-5.2.9.2) with ESMTP id NAA01066 for ; Thu, 26 Feb 1998 13:38:22 +0100 (MET) Received: from athanase (athanase.isty-info.uvsq.fr [193.51.33.2]) by athanase.isty-info.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA17253 for ; Thu, 26 Feb 1998 13:38:21 +0100 (MET) Message-ID: <34F5623C.3E6@isty-info.uvsq.fr> Date: Thu, 26 Feb 1998 13:38:20 +0100 From: Nicolas Pondemer X-Mailer: Mozilla 3.01 (X11; I; HP-UX B.10.01 9000/819) MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Subject: Thanks, but... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hello, Thanks for all answers, but my question doesn't match with your answers (not so self-confident, Chris "Troll" Yarnell). My question is (and that's why I've post this on freebsd-security mailing list) : Can anyone insert a trick to become a systematic CC recipient of your mail EVEN IF YOU DON'T WANT ??? Thanks in advance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 05:07:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA14449 for freebsd-security-outgoing; Thu, 26 Feb 1998 05:07:34 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (gXM93k73nnSSUTj9EKJpoQsqrwiPGoMh@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA14442 for ; Thu, 26 Feb 1998 05:07:31 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from oak71.doc.ic.ac.uk [146.169.46.71] ([pO7aiXvl9mO/RHKPfD3dqY0jULZEfhW0]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0y831q-0003ny-00; Thu, 26 Feb 1998 13:07:10 +0000 Received: from njs3 by oak71.doc.ic.ac.uk with local (Exim 1.62 #3) id 0y831l-0001tf-00; Thu, 26 Feb 1998 13:07:05 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 26 Feb 1998 13:07:04 +0000 In-Reply-To: Nicolas Pondemer "Thanks, but..." (Feb 26, 1:38pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Nicolas Pondemer , freebsd-security@FreeBSD.ORG Subject: Re: Thanks, but... Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Feb 26, 1:38pm, Nicolas Pondemer wrote: } Subject: Thanks, but... > Hello, > Thanks for all answers, but my question doesn't match with your > answers (not so self-confident, Chris "Troll" Yarnell). > > Can anyone insert a trick to become a systematic CC recipient of > your mail EVEN IF YOU DON'T WANT ??? Not "anyone", no. At least not to my knowledge. The system administrator of any SMTP host involved could of course do this, but that would be Unethical with a capital U. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 05:10:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15116 for freebsd-security-outgoing; Thu, 26 Feb 1998 05:10:49 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA15059 for ; Thu, 26 Feb 1998 05:10:39 -0800 (PST) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id PAA23592; Thu, 26 Feb 1998 15:59:25 +0100 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id OAA18001; Thu, 26 Feb 1998 14:18:18 +0100 (CET) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id OAA15842; Thu, 26 Feb 1998 14:09:34 +0100 (CET) Message-ID: <19980226140934.31437@deepo.prosa.dk> Date: Thu, 26 Feb 1998 14:09:34 +0100 From: Philippe Regnauld To: Nicolas Pondemer Cc: freebsd-security@FreeBSD.ORG Subject: Re: Thanks, but... References: <34F5623C.3E6@isty-info.uvsq.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <34F5623C.3E6@isty-info.uvsq.fr>; from Nicolas Pondemer on Thu, Feb 26, 1998 at 01:38:20PM +0100 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Nicolas Pondemer writes: > Hello, > Thanks for all answers, but my question doesn't match with your > answers That's a good way to see it. > (not so self-confident, Chris "Troll" Yarnell). ? > Can anyone insert a trick to become a systematic CC recipient of > your mail EVEN IF YOU DON'T WANT ??? Like, the Evil VT100 Bogus-Escape Sequence (the one and only!) that overwrites your screen and writes harmful things ? No. I don't see how user B can force user A to have a Bcc: automatically added to his headers. -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 05:28:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18041 for freebsd-security-outgoing; Thu, 26 Feb 1998 05:28:06 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dworkin.amber.org (mail@dworkin.amber.org [209.31.146.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18002 for ; Thu, 26 Feb 1998 05:28:00 -0800 (PST) (envelope-from petrilli@dworkin.amber.org) Received: (from mail@localhost) by dworkin.amber.org (8.8.7/8.8.7) id IAA28420; Thu, 26 Feb 1998 08:27:30 -0500 (EST) X-Authentication-Warning: dworkin.amber.org: mail set sender to using -f Received: from dworkin.amber.org(209.31.146.74) by dworkin.amber.org via smap (V1.3) id sma028418; Thu Feb 26 08:27:06 1998 Date: Thu, 26 Feb 1998 08:27:06 -0500 (EST) From: "Christopher G. Petrilli" To: Niall Smart cc: Nicolas Pondemer , freebsd-security@FreeBSD.ORG Subject: Re: Thanks, but... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, 26 Feb 1998, Niall Smart wrote: > Not "anyone", no. At least not to my knowledge. > > The system administrator of any SMTP host involved could of course > do this, but that would be Unethical with a capital U. As with any system with a single "deity" account, this will always be a problem.... you have to trust your administrators inplicitly, as there's no way to stop them from doing whatever they want... Like I said, this is aproblem with ALL single-level security mechanisms. Chris -- | Christopher Petrilli | petrilli@amber.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 05:58:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA21211 for freebsd-security-outgoing; Thu, 26 Feb 1998 05:58:00 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (PShNaK1AtUIENRLta2hg6Ry/EY28iA8v@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA21187 for ; Thu, 26 Feb 1998 05:57:47 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from oak71.doc.ic.ac.uk [146.169.46.71] ([LdV1r7GoGGAl3QQewsXsptyKupf/9+RM]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0y83oY-0004AG-00; Thu, 26 Feb 1998 13:57:30 +0000 Received: from njs3 by oak71.doc.ic.ac.uk with local (Exim 1.62 #3) id 0y83oS-0002Cm-00; Thu, 26 Feb 1998 13:57:24 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Thu, 26 Feb 1998 13:57:24 +0000 In-Reply-To: "Christopher G. Petrilli" "Re: Thanks, but..." (Feb 26, 8:27am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Christopher G. Petrilli" , Niall Smart Subject: Re: Thanks, but... Cc: Nicolas Pondemer , freebsd-security@FreeBSD.ORG Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Feb 26, 8:27am, "Christopher G. Petrilli" wrote: } Subject: Re: Thanks, but... > > As with any system with a single "deity" account, this will always be a > problem.... you have to trust your administrators inplicitly, as there's > no way to stop them from doing whatever they want... > > Like I said, this is aproblem with ALL single-level security mechanisms. It's apparent with ALL security mechanisms, not just single level ones. An MLS system doesn't solve this problem. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 09:44:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21571 for freebsd-security-outgoing; Thu, 26 Feb 1998 09:44:27 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from joshua.enteract.com (joshua.enteract.com [207.229.129.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA21556 for ; Thu, 26 Feb 1998 09:44:09 -0800 (PST) (envelope-from tqbf@secnet.com) From: tqbf@secnet.com Received: (qmail 3211 invoked by uid 1004); 26 Feb 1998 17:43:59 -0000 Message-ID: <19980226174359.3210.qmail@joshua.enteract.com> Subject: OpenBSD Security Advisory: mmap() Problem To: freebsd-security@FreeBSD.ORG Date: Thu, 26 Feb 1998 11:43:59 -0600 (CST) Reply-To: tqbf@secnet.com 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 ------------------------------------------------------------------------- OpenBSD Security Advisory February 20, 1998 4.4BSD mmap() Vulnerability ------------------------------------------------------------------------- SYNOPSIS Due to a 4.4BSD VM system problem, it is possible to memory-map a read-only descriptor to a character device in read-write mode. This allows group "kmem" programs to become root, and root to lower the system securelevel, both by writing to the kernel memory device. ------------------------------------------------------------------------- AFFECTED SYSTEMS This vulnerability has been confirmed against OpenBSD 2.2 (and below), FreeBSD 2.2.5 (and below), and BSDI 3.0. NetBSD-current (without UVM) and below is also affected. ------------------------------------------------------------------------- DETAILS The 4.4BSD VM system allows files to be "memory mapped", which causes the specified contents of a file to be made available to a process via its address space. Manipulations of that file can then be performed simply by manipulating memory, rather than using filesystem I/O calls. This technique is used to simplify code, speed up access to files, and provide interprocess communication. Memory mappings can be "private" or "shared". In a private memory mapping, changes to the mapped memory are not committed back to the original file. Multiple processes with private mappings of the same file will not see each other's changes. In a shared mapping, changes to the mapped memory are reflected in the original file, and all processes mapping the same file see each others's changes. In order to create a writeable mapping for a file descriptor, that file descriptor must be open in read-write mode. This prevents users from using read-only access to system files to change the system configuration (by taking the read-only descriptors and mapping them read-write). The 4.4BSD VM system verifies that an open file descriptor is read-write before allowing a shared read-write mapping. 4.4BSD does not perform this access check when the mapping is not shared; a process with a private mapping cannot modify the original file, so the potential for danger is minimized. Unfortunately, the 4.4BSD VM system automatically changes any private mapping of a character device to "shared", regardless of the flags passed to mmap(), after the access check is performed. This allows a user with read-only access to a character device to create a read-write mapping to that device, and thus write to the device. This can be used against the raw memory device ("/dev/mem") to write arbitrary bytes directly to physical memory; if a process has read-only access to "/dev/mem" (processes in group "kmem" have this access), it can become "root" by altering kernel data structures. Furthermore, a process with a read-write mapping on "/dev/mem" can rewrite the system securelevel back to zero after it has been raised. This allows an attacker to bypass the "immutable" and "append-only" filesystem flags, along with any other securelevel protections. ------------------------------------------------------------------------- TECHNICAL DETAILS The code exhibiting this problem is located in "sys/vm/vm_mmap.c", in the functions "mmap()" (the mmap system call handler), and "vm_mmap()", the VM function that actually performs memory mapping. The problem is due to a faulty access check in mmap(), combined with a side-effect of character device mapping in vm_mmap(). The mmap() system call handler performs a read-write access check by examining the file descriptor passed in as an argument to the system call. Before allowing a shared read-write mapping, the system verifies that the file being mapped is open in write mode: if (flags & MAP_SHARED) { if (fp->f_flag & FWRITE) maxprot |= VM_PROT_WRITE; else if (prot & PROT_WRITE) return (EACCES); } If the requested mapping is not shared, the access check against the file (the check for FWRITE in fp->f_flag, which is the file structure for the descriptor passed to mmap) is not performed. For regular files, this check is sufficient; a non-shared mapping will not allow a process to write to the actual file, only to a private copy in memory. The vm_mmap() kernel VM function handles memory mapping for all of the kernel facilities that require this capability, including execve(), System V shared memory, and the mmap() system call. vm_mmap() checks to see if a mapping is requested is associated with a character device, and, if so, automatically creates a shared mapping (comments from original source code): if (vp->v_type == VCHR) { type = OBJT_DEVICE; handle = (caddr_t) vp->v_rdev; } ... /* * Force device mappings to be shared. */ if (type == OBJT_DEVICE) { flags &= ~(MAP_PRIVATE|MAP_COPY); flags |= MAP_SHARED; } As a result of this code, it is possible to request a non-shared mapping of a character device (which will appear innocuous to the mmap() access checking code), and receive a shared, writeable mapping. This can be used to obtain write access to any readable character device. This problem is particularly serious when a hostile process has read access to kernel memory devices. The system status utilities "ps", "netstat", "systat", and others operate setgid "kmem", allowing them to use the KVM library to directly access kernel memory. A bug in any of these programs can allow an attacker to trivially obtain root access, by mmap()'ing a read-only descriptor to "/dev/mem" and altering process credential structures. This issue also directly subverts the system securelevel. 4.4BSD has a facility called "securelevels" which adds restrictions to the kernel that take effect only when a flag in the kernel (the "securelevel") is set. These restrictions include "immutable" files, which cannot be altered (even by root), and "append-only" files, which can only have data appended to. The former is useful for system binaries (to prevent attackers from backdooring libraries and executables), and the latter is useful for logs (to prevent attackers from covering their tracks by deleting log data). The 4.4BSD securelevel features are active when the securelevel is nonzero. The securelevel is set using the "sysctl" facility. The system does not allow the securelevel to be lowered once it is nonzero; if an attacker can lower the securelevel, she can evade securelevels protections by turning them off. The 4.4BSD kernel does not allow processes to write directly to kernel memory when the securelevel is nonzero; this prevents "root" from bypassing the securelevel simply by writing to "/dev/kmem". This is controlled by an access check in "sys/miscfs/specfs/spec_vnops.c", which provides vnode operations (open, read, write, etc) for special files (like character devices). The access check is performed in the "spec_open()" function, which handles the "open" system call for special files. When the securelevel is nonzero, the system explicitly checks for attempts to open devices in read-write mode, and prevents read-write opens for disk and kernel memory devices. Unfortunately, the mmap() bug allows a process to write to a descriptor even if it is open read-only; the assumption made in spec_open() thus fails to catch attempts to reset the securelevel using mmap(). ------------------------------------------------------------------------- RESOLUTION This is a kernel problem that can only be fixed by patching or upgrading the problematic system code. Patches for the OpenBSD operating system are provided in this advisory. The problem is fixed in OpenBSD-current and must be patched in versions 2.2 and below. The attached OpenBSD patch causes any attempt to create a private mapping of a character device to fail, and enhances access checking in mmap() to explicitly verify that the mapping requested is consistant with the open mode on the file descriptor being mapped. Accelerated X from X Inside relies on this bug to operate correctly; this patch thus breaks the Accelerated X server. Contact your Accelerated X vendor for more information about this. XFree86 is not believed to be affected by the problem. More information about the OpenBSD resolution to the problem is available at "http://www.openbsd.org/errata.html". ------------------------------------------------------------------------- CREDITS Documentation and testing of this problem was conducted by Theo de Raadt and Chuck Cranor. Theo de Raadt, Chuck Cranor, and Niklas Hallqvist of the OpenBSD project provided the OpenBSD patch for the problem. The developers at OpenBSD would like to extend their gratitude to Perry "Scare Bear" Metzger for his continued support of their efforts. ------------------------------------------------------------------------- OPENBSD PATCH Index: vm_mmap.c =================================================================== RCS file: /cvs/src/sys/vm/vm_mmap.c,v retrieving revision 1.10 retrieving revision 1.13 diff -u -9 -u -r1.10 -r1.13 --- vm_mmap.c 1997/11/14 20:56:08 1.10 +++ vm_mmap.c 1998/02/25 22:13:46 1.13 @@ -1,10 +1,10 @@ -/* $OpenBSD: vm_mmap.c,v 1.10 1997/11/14 20:56:08 deraadt Exp $ */ +/* $OpenBSD: vm_mmap.c,v 1.13 1998/02/25 22:13:46 deraadt Exp $ */ /* $NetBSD: vm_mmap.c,v 1.47 1996/03/16 23:15:23 christos Exp $ */ /* * Copyright (c) 1988 University of Utah. * Copyright (c) 1991, 1993 * The Regents of the University of California. All rights reserved. * * This code is derived from software contributed to Berkeley by * the Systems Programming Group of the University of Utah Computer @@ -207,48 +207,60 @@ * Mapping file, get fp for validation. * Obtain vnode and make sure it is of appropriate type. */ if (((unsigned)fd) >= fdp->fd_nfiles || (fp = fdp->fd_ofiles[fd]) == NULL) return (EBADF); if (fp->f_type != DTYPE_VNODE) return (EINVAL); vp = (struct vnode *)fp->f_data; - if (vp->v_type != VREG && vp->v_type != VCHR) - return (EINVAL); + /* * XXX hack to handle use of /dev/zero to map anon * memory (ala SunOS). */ if (vp->v_type == VCHR && iszerodev(vp->v_rdev)) { flags |= MAP_ANON; goto is_anon; } + + /* + * Only files and cdevs are mappable, and cdevs does not + * provide private mappings of any kind. + */ + if (vp->v_type != VREG && + (vp->v_type != VCHR || (flags & (MAP_PRIVATE|MAP_COPY)))) + return (EINVAL); /* * Ensure that file and memory protections are * compatible. Note that we only worry about * writability if mapping is shared; in this case, * current and max prot are dictated by the open file. * XXX use the vnode instead? Problem is: what * credentials do we use for determination? * What if proc does a setuid? */ maxprot = VM_PROT_EXECUTE; /* ??? */ if (fp->f_flag & FREAD) maxprot |= VM_PROT_READ; else if (prot & PROT_READ) + return (EACCES); + + /* + * If we are sharing potential changes (either via MAP_SHARED + * or via the implicit sharing of character device mappings), + * and we are trying to get write permission although we + * opened it without asking for it, bail out. + */ + if (((flags & MAP_SHARED) != 0 || vp->v_type == VCHR) && + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) return (EACCES); - if (flags & MAP_SHARED) { - if (fp->f_flag & FWRITE) - maxprot |= VM_PROT_WRITE; - else if (prot & PROT_WRITE) - return (EACCES); - } else + else maxprot |= VM_PROT_WRITE; handle = (caddr_t)vp; } else { /* * (flags & MAP_ANON) == TRUE * Mapping blank space is trivial. */ if (fd != -1) return (EINVAL); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 10:48:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01895 for freebsd-security-outgoing; Thu, 26 Feb 1998 10:48:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA01877; Thu, 26 Feb 1998 10:48:40 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id KAA06539; (8.8.8/RDY) Thu, 26 Feb 1998 10:48:26 -0800 (PST) Message-Id: <199802261848.KAA06539@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <19980226174359.3210.qmail@joshua.enteract.com> from "tqbf@secnet.com" at "Feb 26, 98 11:43:59 am" To: tqbf@secnet.com Date: Thu, 26 Feb 1998 10:48:26 -0800 (PST) Cc: freebsd-security@FreeBSD.ORG, commiters@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Is there anybody who's gonna review and commit this? tqbf@secnet.com writes: > > ------------------------------------------------------------------------- > > OpenBSD Security Advisory > > February 20, 1998 > > 4.4BSD mmap() Vulnerability > > ------------------------------------------------------------------------- > > SYNOPSIS > > Due to a 4.4BSD VM system problem, it is possible to memory-map a > read-only descriptor to a character device in read-write mode. This > allows group "kmem" programs to become root, and root to lower the > system securelevel, both by writing to the kernel memory device. > > ------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > This vulnerability has been confirmed against OpenBSD 2.2 (and below), > FreeBSD 2.2.5 (and below), and BSDI 3.0. NetBSD-current (without UVM) > and below is also affected. > > ------------------------------------------------------------------------- > > DETAILS > > The 4.4BSD VM system allows files to be "memory mapped", which causes > the specified contents of a file to be made available to a process via > its address space. Manipulations of that file can then be performed > simply by manipulating memory, rather than using filesystem I/O calls. > This technique is used to simplify code, speed up access to files, and > provide interprocess communication. > > Memory mappings can be "private" or "shared". In a private memory mapping, > changes to the mapped memory are not committed back to the original file. > Multiple processes with private mappings of the same file will not see > each other's changes. In a shared mapping, changes to the mapped memory > are reflected in the original file, and all processes mapping the same > file see each others's changes. > > In order to create a writeable mapping for a file descriptor, that file > descriptor must be open in read-write mode. This prevents users from using > read-only access to system files to change the system configuration (by > taking the read-only descriptors and mapping them read-write). The 4.4BSD > VM system verifies that an open file descriptor is read-write before > allowing a shared read-write mapping. > > 4.4BSD does not perform this access check when the mapping is not shared; > a process with a private mapping cannot modify the original file, so the > potential for danger is minimized. Unfortunately, the 4.4BSD VM system > automatically changes any private mapping of a character device to > "shared", regardless of the flags passed to mmap(), after the access check > is performed. > > This allows a user with read-only access to a character device to create a > read-write mapping to that device, and thus write to the device. This can > be used against the raw memory device ("/dev/mem") to write arbitrary > bytes directly to physical memory; if a process has read-only access to > "/dev/mem" (processes in group "kmem" have this access), it can become > "root" by altering kernel data structures. > > Furthermore, a process with a read-write mapping on "/dev/mem" can rewrite > the system securelevel back to zero after it has been raised. This allows > an attacker to bypass the "immutable" and "append-only" filesystem flags, > along with any other securelevel protections. > > ------------------------------------------------------------------------- > > TECHNICAL DETAILS > > The code exhibiting this problem is located in "sys/vm/vm_mmap.c", in the > functions "mmap()" (the mmap system call handler), and "vm_mmap()", the VM > function that actually performs memory mapping. The problem is due to a > faulty access check in mmap(), combined with a side-effect of character > device mapping in vm_mmap(). > > The mmap() system call handler performs a read-write access check by > examining the file descriptor passed in as an argument to the system call. > Before allowing a shared read-write mapping, the system verifies that the > file being mapped is open in write mode: > > if (flags & MAP_SHARED) { > if (fp->f_flag & FWRITE) > maxprot |= VM_PROT_WRITE; > else if (prot & PROT_WRITE) > return (EACCES); > } > > If the requested mapping is not shared, the access check against the > file (the check for FWRITE in fp->f_flag, which is the file structure > for the descriptor passed to mmap) is not performed. For regular files, > this check is sufficient; a non-shared mapping will not allow a process > to write to the actual file, only to a private copy in memory. > > The vm_mmap() kernel VM function handles memory mapping for all of the > kernel facilities that require this capability, including execve(), > System V shared memory, and the mmap() system call. vm_mmap() checks > to see if a mapping is requested is associated with a character device, > and, if so, automatically creates a shared mapping (comments from original > source code): > > if (vp->v_type == VCHR) { > type = OBJT_DEVICE; > handle = (caddr_t) vp->v_rdev; > } > > ... > > /* > * Force device mappings to be shared. > */ > if (type == OBJT_DEVICE) { > flags &= ~(MAP_PRIVATE|MAP_COPY); > flags |= MAP_SHARED; > } > > As a result of this code, it is possible to request a non-shared mapping > of a character device (which will appear innocuous to the mmap() access > checking code), and receive a shared, writeable mapping. This can be used > to obtain write access to any readable character device. > > This problem is particularly serious when a hostile process has read > access to kernel memory devices. The system status utilities "ps", > "netstat", "systat", and others operate setgid "kmem", allowing them to > use the KVM library to directly access kernel memory. A bug in any of > these programs can allow an attacker to trivially obtain root access, by > mmap()'ing a read-only descriptor to "/dev/mem" and altering process > credential structures. > > This issue also directly subverts the system securelevel. 4.4BSD has a > facility called "securelevels" which adds restrictions to the kernel that > take effect only when a flag in the kernel (the "securelevel") is set. > These restrictions include "immutable" files, which cannot be altered > (even by root), and "append-only" files, which can only have data appended > to. The former is useful for system binaries (to prevent attackers from > backdooring libraries and executables), and the latter is useful for logs > (to prevent attackers from covering their tracks by deleting log data). > > The 4.4BSD securelevel features are active when the securelevel is > nonzero. The securelevel is set using the "sysctl" facility. The system > does not allow the securelevel to be lowered once it is nonzero; if > an attacker can lower the securelevel, she can evade securelevels > protections by turning them off. > > The 4.4BSD kernel does not allow processes to write directly to kernel > memory when the securelevel is nonzero; this prevents "root" from > bypassing the securelevel simply by writing to "/dev/kmem". This is > controlled by an access check in "sys/miscfs/specfs/spec_vnops.c", which > provides vnode operations (open, read, write, etc) for special files (like > character devices). > > The access check is performed in the "spec_open()" function, which handles > the "open" system call for special files. When the securelevel is nonzero, > the system explicitly checks for attempts to open devices in read-write > mode, and prevents read-write opens for disk and kernel memory devices. > > Unfortunately, the mmap() bug allows a process to write to a descriptor > even if it is open read-only; the assumption made in spec_open() thus > fails to catch attempts to reset the securelevel using mmap(). > > ------------------------------------------------------------------------- > > RESOLUTION > > This is a kernel problem that can only be fixed by patching or upgrading > the problematic system code. Patches for the OpenBSD operating system are > provided in this advisory. The problem is fixed in OpenBSD-current and > must be patched in versions 2.2 and below. > > The attached OpenBSD patch causes any attempt to create a private mapping > of a character device to fail, and enhances access checking in mmap() to > explicitly verify that the mapping requested is consistant with the open > mode on the file descriptor being mapped. > > Accelerated X from X Inside relies on this bug to operate correctly; this > patch thus breaks the Accelerated X server. Contact your Accelerated X > vendor for more information about this. XFree86 is not believed to be > affected by the problem. > > More information about the OpenBSD resolution to the problem is available > at "http://www.openbsd.org/errata.html". > > ------------------------------------------------------------------------- > > CREDITS > > Documentation and testing of this problem was conducted by Theo de Raadt > and Chuck Cranor. Theo de Raadt, Chuck Cranor, and Niklas Hallqvist of the > OpenBSD project provided the OpenBSD patch for the problem. > > The developers at OpenBSD would like to extend their gratitude to Perry > "Scare Bear" Metzger for his continued support of their efforts. > > ------------------------------------------------------------------------- > > OPENBSD PATCH > > Index: vm_mmap.c > =================================================================== > RCS file: /cvs/src/sys/vm/vm_mmap.c,v > retrieving revision 1.10 > retrieving revision 1.13 > diff -u -9 -u -r1.10 -r1.13 > --- vm_mmap.c 1997/11/14 20:56:08 1.10 > +++ vm_mmap.c 1998/02/25 22:13:46 1.13 > @@ -1,10 +1,10 @@ > -/* $OpenBSD: vm_mmap.c,v 1.10 1997/11/14 20:56:08 deraadt Exp $ */ > +/* $OpenBSD: vm_mmap.c,v 1.13 1998/02/25 22:13:46 deraadt Exp $ */ > /* $NetBSD: vm_mmap.c,v 1.47 1996/03/16 23:15:23 christos Exp $ */ > > /* > * Copyright (c) 1988 University of Utah. > * Copyright (c) 1991, 1993 > * The Regents of the University of California. All rights reserved. > * > * This code is derived from software contributed to Berkeley by > * the Systems Programming Group of the University of Utah Computer > @@ -207,48 +207,60 @@ > * Mapping file, get fp for validation. > * Obtain vnode and make sure it is of appropriate type. > */ > if (((unsigned)fd) >= fdp->fd_nfiles || > (fp = fdp->fd_ofiles[fd]) == NULL) > return (EBADF); > if (fp->f_type != DTYPE_VNODE) > return (EINVAL); > vp = (struct vnode *)fp->f_data; > - if (vp->v_type != VREG && vp->v_type != VCHR) > - return (EINVAL); > + > /* > * XXX hack to handle use of /dev/zero to map anon > * memory (ala SunOS). > */ > if (vp->v_type == VCHR && iszerodev(vp->v_rdev)) { > flags |= MAP_ANON; > goto is_anon; > } > + > + /* > + * Only files and cdevs are mappable, and cdevs does not > + * provide private mappings of any kind. > + */ > + if (vp->v_type != VREG && > + (vp->v_type != VCHR || (flags & (MAP_PRIVATE|MAP_COPY)))) > + return (EINVAL); > /* > * Ensure that file and memory protections are > * compatible. Note that we only worry about > * writability if mapping is shared; in this case, > * current and max prot are dictated by the open file. > * XXX use the vnode instead? Problem is: what > * credentials do we use for determination? > * What if proc does a setuid? > */ > maxprot = VM_PROT_EXECUTE; /* ??? */ > if (fp->f_flag & FREAD) > maxprot |= VM_PROT_READ; > else if (prot & PROT_READ) > + return (EACCES); > + > + /* > + * If we are sharing potential changes (either via MAP_SHARED > + * or via the implicit sharing of character device mappings), > + * and we are trying to get write permission although we > + * opened it without asking for it, bail out. > + */ > + if (((flags & MAP_SHARED) != 0 || vp->v_type == VCHR) && > + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) > return (EACCES); > - if (flags & MAP_SHARED) { > - if (fp->f_flag & FWRITE) > - maxprot |= VM_PROT_WRITE; > - else if (prot & PROT_WRITE) > - return (EACCES); > - } else > + else > maxprot |= VM_PROT_WRITE; > handle = (caddr_t)vp; > } else { > /* > * (flags & MAP_ANON) == TRUE > * Mapping blank space is trivial. > */ > if (fd != -1) > return (EINVAL); > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 12:19:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16662 for freebsd-security-outgoing; Thu, 26 Feb 1998 12:19:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from joshua.enteract.com (joshua.enteract.com [207.229.129.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA16600 for ; Thu, 26 Feb 1998 12:19:08 -0800 (PST) (envelope-from tqbf@secnet.com) From: tqbf@secnet.com Received: (qmail 6492 invoked by uid 1004); 26 Feb 1998 20:19:07 -0000 Message-ID: <19980226201907.6491.qmail@joshua.enteract.com> Subject: OpenBSD Security Advisory: Source Routing To: freebsd-security@FreeBSD.ORG Date: Thu, 26 Feb 1998 14:19:07 -0600 (CST) Reply-To: tqbf@secnet.com 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 ---------------------------------------------------------------------------- NOTICE Due to confusion over the meaning of our "CREDITS" section in our advisories, we would like to clarify the matter of Perry Metzger and his support for OpenBSD. At this time we would like to make it clear that these comments were meant in jest, as a reaction to a large body of public commentary by Mr. Metzger regarding OpenBSD. As far as we know, Mr. Metzger in no way supports the OpenBSD project. ---------------------------------------------------------------------------- OpenBSD Security Advisory February 15, 1998 IP Source Routing Problem ---------------------------------------------------------------------------- SYNOPSIS Due to implementation problems, the system configuration control for "do source route" does not prevent source routed packets from being accepted by 4.4BSD kernels. Additionally, if source routing is enabled, the "forward IP packets" control does not prevent source routed packets from being forwarded. This allows remote attackers to trivially spoof TCP connections against BSD hosts on networks that do not filter source routed packets via router packet filters. ---------------------------------------------------------------------------- AFFECTED SYSTEMS This vulnerability has been confirmed against OpenBSD 2.2 (and below), and FreeBSD 2.2.5 (and below). Also FreeBSD 2.2-current (before 1998/02/16) and FreeBSD-stable (before 1998/02/23) are vulnerable. ---------------------------------------------------------------------------- DETAILS 4.4BSD allows "kernel state" variables, which control certain configuration options inside the kernel, to be changed via the "sysctl" facility. "sysctl" is used to define whether a 4.4BSD system accepts source routed packets, via the variable "net.inet.ip.dosourceroute". This variable is set to "0" by default, meaning "do not perform IP source routing". Additionally, the sysctl variable "net.inet.ip.forwarding" dictates whether the system will act as an IP router, forwarding any received packets that are not destined to the host. This variable is also turned off by default. Due to the manner in which the check against the "dosourceroute" variable is implemented in the kernel, it is possible to send source routed packets to a 4.4BSD host, even when the flag is set to "0". The "dosourceroute" flag only prevents forwarding of source routed packets, not delivery to the local system. Source routed packets can be used to spoof TCP connections that appear to come from arbitrary hosts. A host receiving a source-routed packet sends replies to that packet using the reverse of the specified route; an attacker can route TCP message responses (such as the server SYN+ACK of the TCP three-way-handshake) back to her machine, to obtain the server's initial sequence number and complete a TCP active open. Additionally, the "forwarding" variable does not apply to the forwarding of source routed packets. If source routing is enabled, source routed packets will be forwarded regardless of whether the "forwarding" variable is set. ---------------------------------------------------------------------------- TECHNICAL DETAILS These problems exist due to the manner in which the kernel state variables "dosourceroute" and "forwarding" are checked inside the kernel IP input processing code. Both problems are the result of code within the kernel function "ip_dooptions()", which processes IP options in incoming datagrams. The IP source routing check in 4.4BSD is performed only after a packet is checked to see if it is at the end of it's source route, in which case the packet is delivered if it is destined to the processing host. The destination of a source routed packet will usually be the end of a source route; hence, this check will almost always result in the delivery of the source routed packet. IP packets can be "forwarded", via the "ip_forward()" function, in two places in the IP input processing code. The first place IP packets are forwarded at is the initial IP input processing function "ip_input()", which handles the general case of forwarding arbitrary packets. This code checks the variable "forwarding" to verify that the system is configured to forward IP packets. IP packets can also be forwarded in the "ip_dooptions()" function, in the case of source routed packets. This can only occur if the "dosourceroute" variable is enabled; however, the "forwarding" variable is not checked from within "ip_dooptions()", meaning that a system configured to allow source routing will forward source routed packets even with IP forwarding disabled. Additionally, if IP forwarding is enabled, and IP source routing is disabled, source routed packets can be forwarded as long as the recipient isn't listed in the source route. ---------------------------------------------------------------------------- RESOLUTION This is a kernel problem that can only be fixed by patching or upgrading the problematic system code. Patches for the OpenBSD and FreeBSD operating systems are provided in this advisory. This problem is fixed in OpenBSD-current and must be patched in versions 2.2 and below. The attached FreeBSD patch is against version 2.2.5. The attached OpenBSD patch modifies the kernel to check the "dosourceroute" variable immediately upon detecting a source-route option in a recieved IP packet. If source routing is disabled, the packet will be logged and dropped before any further processing is performed. Additionally, the variable "forwarding" is now checked from within the "ip_dooptions()" function, meaning that source routed packets can only be forwarded when IP forwarding is enabled. The attached FreeBSD patch adds a new sysctl kernel variable, "accept_sourceroute", which determines whether the OS will deliver source routed packets locally if they have the source route option set. Additionally, source routed packets are dropped automatically if "dosourceroute" is set to zero, and the "ip_forwarding" variable is checked before packets are forwarded from ip_dooptions(), preventing source routed packets from being forwarded when IP forwarding is disabled. More information about the OpenBSD resolution to the problem is available at "http://www.openbsd.org/errata.html#sourceroute". Sites that cannot patch their kernels (or run operating systems without available patches) can address this problem by packet filtering source routed packets at routers or via kernel packet filters such as IP-filter. ---------------------------------------------------------------------------- CREDITS Documentation and testing of this problem was conducted by Theo de Raadt and the OpenBSD development team with the assistance of Secure Networks Inc. Helpful information and FreeBSD's response to this problem were provided by Guido van Rooij. The developers of OpenBSD and the author of this advisory would like to again confirm the fact that Perry Metzger does not in any way support their project. ---------------------------------------------------------------------------- OPENBSD PATCH Index: ip_input.c =================================================================== RCS file: /cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- ip_input.c 1998/02/01 21:46:02 1.28 +++ ip_input.c 1998/02/03 21:11:08 1.29 @@ -1,4 +1,4 @@ -/* $OpenBSD: ip_input.c,v 1.28 1998/02/01 21:46:02 deraadt Exp $ */ +/* $OpenBSD: ip_input.c,v 1.29 1998/02/03 21:11:08 deraadt Exp $ */ /* $NetBSD: ip_input.c,v 1.30 1996/03/16 23:53:58 christos Exp $ */ /* @@ -744,6 +744,17 @@ */ case IPOPT_LSRR: case IPOPT_SSRR: + if (!ip_dosourceroute) { + char buf[4*sizeof "123"]; + + strcpy(buf, inet_ntoa(ip->ip_dst)); + log(LOG_WARNING, + "attempted source route from %s to %s\n", + inet_ntoa(ip->ip_src), buf); + type = ICMP_UNREACH; + code = ICMP_UNREACH_SRCFAIL; + goto bad; + } if ((off = cp[IPOPT_OFFSET]) < IPOPT_MINOFF) { code = &cp[IPOPT_OFFSET] - (u_char *)ip; goto bad; @@ -771,18 +782,6 @@ break; } - if (!ip_dosourceroute) { - char buf[4*sizeof "123"]; - - strcpy(buf, inet_ntoa(ip->ip_dst)); - log(LOG_WARNING, - "attempted source route from %s to %s\n", - inet_ntoa(ip->ip_src), buf); - type = ICMP_UNREACH; - code = ICMP_UNREACH_SRCFAIL; - goto bad; - } - /* * locate outgoing interface */ @@ -889,7 +888,7 @@ ipt->ipt_ptr += sizeof(n_time); } } - if (forward) { + if (forward && ipforwarding) { ip_forward(m, 1); return (1); } ---------------------------------------------------------------------------- FREEBSD PATCH Index: in.h =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/netinet/in.h,v retrieving revision 1.22.2.1 diff -u -r1.22.2.1 in.h --- in.h 1996/11/11 23:40:37 1.22.2.1 +++ in.h 1998/02/24 18:31:44 @@ -301,7 +301,8 @@ #define IPCTL_DIRECTEDBROADCAST 9 /* may re-broadcast received packets */ #define IPCTL_INTRQMAXLEN 10 /* max length of netisr queue */ #define IPCTL_INTRQDROPS 11 /* number of netisr q drops */ -#define IPCTL_MAXID 12 +#define IPCTL_ACCEPTSOURCEROUTE 13 /* may accept source routed packets */ +#define IPCTL_MAXID 13 #define IPCTL_NAMES { \ { 0, 0 }, \ @@ -316,6 +317,7 @@ { "directed-broadcast", CTLTYPE_INT }, \ { "intr-queue-maxlen", CTLTYPE_INT }, \ { "intr-queue-drops", CTLTYPE_INT }, \ + { "accept_sourceroute", CTLTYPE_INT }, \ } Index: ip_input.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/netinet/ip_input.c,v retrieving revision 1.50.2.8 diff -u -r1.50.2.8 ip_input.c --- ip_input.c 1997/09/15 23:10:55 1.50.2.8 +++ ip_input.c 1998/02/24 18:30:43 @@ -94,6 +94,10 @@ static int ip_dosourceroute = 0; SYSCTL_INT(_net_inet_ip, IPCTL_SOURCEROUTE, sourceroute, CTLFLAG_RW, &ip_dosourceroute, 0, ""); + +static int ip_acceptsourceroute = 0; +SYSCTL_INT(_net_inet_ip, IPCTL_ACCEPTSOURCEROUTE, accept_sourceroute, + CTLFLAG_RW, &ip_acceptsourceroute, 0, ""); #ifdef DIAGNOSTIC static int ipprintfs = 0; #endif @@ -923,6 +927,8 @@ code = ICMP_UNREACH_SRCFAIL; goto bad; } + if (!ip_dosourceroute) + goto nosourcerouting; /* * Loose routing, and not at next destination * yet; nothing to do except forward. @@ -934,14 +940,17 @@ /* * End of source route. Should be for us. */ + if (!ip_acceptsourceroute) + goto nosourcerouting; save_rte(cp, ip->ip_src); break; } if (!ip_dosourceroute) { char buf[4*sizeof "123"]; - strcpy(buf, inet_ntoa(ip->ip_dst)); +nosourcerouting: + strcpy(buf, inet_ntoa(ip->ip_dst)); log(LOG_WARNING, "attempted source route from %s to %s\n", inet_ntoa(ip->ip_src), buf); @@ -1056,7 +1065,7 @@ ipt->ipt_ptr += sizeof(n_time); } } - if (forward) { + if (forward && ipforwarding) { ip_forward(m, 1); return (1); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 12:50:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21362 for freebsd-security-outgoing; Thu, 26 Feb 1998 12:50:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21348 for ; Thu, 26 Feb 1998 12:50:07 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id MAA26454; Thu, 26 Feb 1998 12:49:50 -0800 (PST) To: tqbf@secnet.com cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: Source Routing In-reply-to: Your message of "Thu, 26 Feb 1998 14:19:07 CST." <19980226201907.6491.qmail@joshua.enteract.com> Date: Thu, 26 Feb 1998 12:49:49 -0800 Message-ID: <26450.888526189@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > advisories, we would like to clarify the matter of Perry Metzger and > his support for OpenBSD. At this time we would like to make it clear > that these comments were meant in jest, as a reaction to a large body > of public commentary by Mr. Metzger regarding OpenBSD. As far as we > know, Mr. Metzger in no way supports the OpenBSD project. I note that this has also been the case for some time, just based on a quick scan of some of the previous advisories - perhaps the jest in question has run its course and can be removed now? It seems to me that it needlessly politicizes what should be (IMHO) a more neutral analysis of security issues. But that's just MHO. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 20:24:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12713 for freebsd-security-outgoing; Thu, 26 Feb 1998 20:24:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12660; Thu, 26 Feb 1998 20:23:56 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id UAA14003; Thu, 26 Feb 1998 20:23:53 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaolaa; Thu Feb 26 20:23:39 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id UAA01955; Thu, 26 Feb 1998 20:23:34 -0800 (PST) Message-Id: <199802270423.UAA01955@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd001893; Fri Feb 27 04:23:09 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: tqbf@secnet.com cc: freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Thu, 26 Feb 1998 11:43:59 CST." <19980226174359.3210.qmail@joshua.enteract.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Feb 1998 20:23:06 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk I've ported this patch to FreeBSD 2.2.5R. XIG's Accelerated X server crashes trying to access the VT. To get the XIG Accelerated X server to work I've modified the patch to allow superuser to access to character devices. I'm not sure what other applications could break because of the originally posted patch or my modified patch, so additional study needs to be done. Here's my modified patch. --- sys/vm/vm_mmap.c.orig Mon Mar 24 20:54:29 1997 +++ sys/vm/vm_mmap.c Thu Feb 26 20:02:38 1998 @@ -230,6 +230,15 @@ flags |= MAP_ANON; } else { /* + * cdevs does not provide private mappings of any kind, + * except for superuser. (This may still be insecure + * and requires more investigation). + */ + error = suser(p->p_ucred, &p->p_acflag); + if (vp->v_type == VCHR && error && + (flags & (MAP_PRIVATE|MAP_COPY))) + return (EINVAL); + /* * Ensure that file and memory protections are * compatible. Note that we only worry about * writability if mapping is shared; in this case, @@ -243,12 +252,18 @@ maxprot |= VM_PROT_READ; else if (prot & PROT_READ) return (EACCES); - if (flags & MAP_SHARED) { - if (fp->f_flag & FWRITE) - maxprot |= VM_PROT_WRITE; - else if (prot & PROT_WRITE) - return (EACCES); - } else + /* + * If we are sharing potential changes (either via MAP_SHARED + * or via the implicit sharing of character device mappings), + * and we are trying to get write permission although we + * opened it without asking for it, bail out. (Once again + * superuser can map character devices, though further + * investigation is required to see if this is insecure). + */ + if (((flags & MAP_SHARED) != 0 || (vp->v_type == VCHR && error)) && + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) + return (EACCES); + else maxprot |= VM_PROT_WRITE; handle = (caddr_t) vp; } Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca > > ------------------------------------------------------------------------- > > OpenBSD Security Advisory > > February 20, 1998 > > 4.4BSD mmap() Vulnerability > > ------------------------------------------------------------------------- > > SYNOPSIS > > Due to a 4.4BSD VM system problem, it is possible to memory-map a > read-only descriptor to a character device in read-write mode. This > allows group "kmem" programs to become root, and root to lower the > system securelevel, both by writing to the kernel memory device. > > ------------------------------------------------------------------------- > > AFFECTED SYSTEMS > > This vulnerability has been confirmed against OpenBSD 2.2 (and below), > FreeBSD 2.2.5 (and below), and BSDI 3.0. NetBSD-current (without UVM) > and below is also affected. > > ------------------------------------------------------------------------- > > DETAILS > > The 4.4BSD VM system allows files to be "memory mapped", which causes > the specified contents of a file to be made available to a process via > its address space. Manipulations of that file can then be performed > simply by manipulating memory, rather than using filesystem I/O calls. > This technique is used to simplify code, speed up access to files, and > provide interprocess communication. > > Memory mappings can be "private" or "shared". In a private memory mapping, > changes to the mapped memory are not committed back to the original file. > Multiple processes with private mappings of the same file will not see > each other's changes. In a shared mapping, changes to the mapped memory > are reflected in the original file, and all processes mapping the same > file see each others's changes. > > In order to create a writeable mapping for a file descriptor, that file > descriptor must be open in read-write mode. This prevents users from using > read-only access to system files to change the system configuration (by > taking the read-only descriptors and mapping them read-write). The 4.4BSD > VM system verifies that an open file descriptor is read-write before > allowing a shared read-write mapping. > > 4.4BSD does not perform this access check when the mapping is not shared; > a process with a private mapping cannot modify the original file, so the > potential for danger is minimized. Unfortunately, the 4.4BSD VM system > automatically changes any private mapping of a character device to > "shared", regardless of the flags passed to mmap(), after the access check > is performed. > > This allows a user with read-only access to a character device to create a > read-write mapping to that device, and thus write to the device. This can > be used against the raw memory device ("/dev/mem") to write arbitrary > bytes directly to physical memory; if a process has read-only access to > "/dev/mem" (processes in group "kmem" have this access), it can become > "root" by altering kernel data structures. > > Furthermore, a process with a read-write mapping on "/dev/mem" can rewrite > the system securelevel back to zero after it has been raised. This allows > an attacker to bypass the "immutable" and "append-only" filesystem flags, > along with any other securelevel protections. > > ------------------------------------------------------------------------- > > TECHNICAL DETAILS > > The code exhibiting this problem is located in "sys/vm/vm_mmap.c", in the > functions "mmap()" (the mmap system call handler), and "vm_mmap()", the VM > function that actually performs memory mapping. The problem is due to a > faulty access check in mmap(), combined with a side-effect of character > device mapping in vm_mmap(). > > The mmap() system call handler performs a read-write access check by > examining the file descriptor passed in as an argument to the system call. > Before allowing a shared read-write mapping, the system verifies that the > file being mapped is open in write mode: > > if (flags & MAP_SHARED) { > if (fp->f_flag & FWRITE) > maxprot |= VM_PROT_WRITE; > else if (prot & PROT_WRITE) > return (EACCES); > } > > If the requested mapping is not shared, the access check against the > file (the check for FWRITE in fp->f_flag, which is the file structure > for the descriptor passed to mmap) is not performed. For regular files, > this check is sufficient; a non-shared mapping will not allow a process > to write to the actual file, only to a private copy in memory. > > The vm_mmap() kernel VM function handles memory mapping for all of the > kernel facilities that require this capability, including execve(), > System V shared memory, and the mmap() system call. vm_mmap() checks > to see if a mapping is requested is associated with a character device, > and, if so, automatically creates a shared mapping (comments from original > source code): > > if (vp->v_type == VCHR) { > type = OBJT_DEVICE; > handle = (caddr_t) vp->v_rdev; > } > > ... > > /* > * Force device mappings to be shared. > */ > if (type == OBJT_DEVICE) { > flags &= ~(MAP_PRIVATE|MAP_COPY); > flags |= MAP_SHARED; > } > > As a result of this code, it is possible to request a non-shared mapping > of a character device (which will appear innocuous to the mmap() access > checking code), and receive a shared, writeable mapping. This can be used > to obtain write access to any readable character device. > > This problem is particularly serious when a hostile process has read > access to kernel memory devices. The system status utilities "ps", > "netstat", "systat", and others operate setgid "kmem", allowing them to > use the KVM library to directly access kernel memory. A bug in any of > these programs can allow an attacker to trivially obtain root access, by > mmap()'ing a read-only descriptor to "/dev/mem" and altering process > credential structures. > > This issue also directly subverts the system securelevel. 4.4BSD has a > facility called "securelevels" which adds restrictions to the kernel that > take effect only when a flag in the kernel (the "securelevel") is set. > These restrictions include "immutable" files, which cannot be altered > (even by root), and "append-only" files, which can only have data appended > to. The former is useful for system binaries (to prevent attackers from > backdooring libraries and executables), and the latter is useful for logs > (to prevent attackers from covering their tracks by deleting log data). > > The 4.4BSD securelevel features are active when the securelevel is > nonzero. The securelevel is set using the "sysctl" facility. The system > does not allow the securelevel to be lowered once it is nonzero; if > an attacker can lower the securelevel, she can evade securelevels > protections by turning them off. > > The 4.4BSD kernel does not allow processes to write directly to kernel > memory when the securelevel is nonzero; this prevents "root" from > bypassing the securelevel simply by writing to "/dev/kmem". This is > controlled by an access check in "sys/miscfs/specfs/spec_vnops.c", which > provides vnode operations (open, read, write, etc) for special files (like > character devices). > > The access check is performed in the "spec_open()" function, which handles > the "open" system call for special files. When the securelevel is nonzero, > the system explicitly checks for attempts to open devices in read-write > mode, and prevents read-write opens for disk and kernel memory devices. > > Unfortunately, the mmap() bug allows a process to write to a descriptor > even if it is open read-only; the assumption made in spec_open() thus > fails to catch attempts to reset the securelevel using mmap(). > > ------------------------------------------------------------------------- > > RESOLUTION > > This is a kernel problem that can only be fixed by patching or upgrading > the problematic system code. Patches for the OpenBSD operating system are > provided in this advisory. The problem is fixed in OpenBSD-current and > must be patched in versions 2.2 and below. > > The attached OpenBSD patch causes any attempt to create a private mapping > of a character device to fail, and enhances access checking in mmap() to > explicitly verify that the mapping requested is consistant with the open > mode on the file descriptor being mapped. > > Accelerated X from X Inside relies on this bug to operate correctly; this > patch thus breaks the Accelerated X server. Contact your Accelerated X > vendor for more information about this. XFree86 is not believed to be > affected by the problem. > > More information about the OpenBSD resolution to the problem is available > at "http://www.openbsd.org/errata.html". > > ------------------------------------------------------------------------- > > CREDITS > > Documentation and testing of this problem was conducted by Theo de Raadt > and Chuck Cranor. Theo de Raadt, Chuck Cranor, and Niklas Hallqvist of the > OpenBSD project provided the OpenBSD patch for the problem. > > The developers at OpenBSD would like to extend their gratitude to Perry > "Scare Bear" Metzger for his continued support of their efforts. > > ------------------------------------------------------------------------- > > OPENBSD PATCH > > Index: vm_mmap.c > =================================================================== > RCS file: /cvs/src/sys/vm/vm_mmap.c,v > retrieving revision 1.10 > retrieving revision 1.13 > diff -u -9 -u -r1.10 -r1.13 > --- vm_mmap.c 1997/11/14 20:56:08 1.10 > +++ vm_mmap.c 1998/02/25 22:13:46 1.13 > @@ -1,10 +1,10 @@ > -/* $OpenBSD: vm_mmap.c,v 1.10 1997/11/14 20:56:08 deraadt Exp $ */ > +/* $OpenBSD: vm_mmap.c,v 1.13 1998/02/25 22:13:46 deraadt Exp $ */ > /* $NetBSD: vm_mmap.c,v 1.47 1996/03/16 23:15:23 christos Exp $ */ > > /* > * Copyright (c) 1988 University of Utah. > * Copyright (c) 1991, 1993 > * The Regents of the University of California. All rights reserved. > * > * This code is derived from software contributed to Berkeley by > * the Systems Programming Group of the University of Utah Computer > @@ -207,48 +207,60 @@ > * Mapping file, get fp for validation. > * Obtain vnode and make sure it is of appropriate type. > */ > if (((unsigned)fd) >= fdp->fd_nfiles || > (fp = fdp->fd_ofiles[fd]) == NULL) > return (EBADF); > if (fp->f_type != DTYPE_VNODE) > return (EINVAL); > vp = (struct vnode *)fp->f_data; > - if (vp->v_type != VREG && vp->v_type != VCHR) > - return (EINVAL); > + > /* > * XXX hack to handle use of /dev/zero to map anon > * memory (ala SunOS). > */ > if (vp->v_type == VCHR && iszerodev(vp->v_rdev)) { > flags |= MAP_ANON; > goto is_anon; > } > + > + /* > + * Only files and cdevs are mappable, and cdevs does not > + * provide private mappings of any kind. > + */ > + if (vp->v_type != VREG && > + (vp->v_type != VCHR || (flags & (MAP_PRIVATE|MAP_COPY)))) > + return (EINVAL); > /* > * Ensure that file and memory protections are > * compatible. Note that we only worry about > * writability if mapping is shared; in this case, > * current and max prot are dictated by the open file. > * XXX use the vnode instead? Problem is: what > * credentials do we use for determination? > * What if proc does a setuid? > */ > maxprot = VM_PROT_EXECUTE; /* ??? */ > if (fp->f_flag & FREAD) > maxprot |= VM_PROT_READ; > else if (prot & PROT_READ) > + return (EACCES); > + > + /* > + * If we are sharing potential changes (either via MAP_SHARED > + * or via the implicit sharing of character device mappings), > + * and we are trying to get write permission although we > + * opened it without asking for it, bail out. > + */ > + if (((flags & MAP_SHARED) != 0 || vp->v_type == VCHR) && > + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) > return (EACCES); > - if (flags & MAP_SHARED) { > - if (fp->f_flag & FWRITE) > - maxprot |= VM_PROT_WRITE; > - else if (prot & PROT_WRITE) > - return (EACCES); > - } else > + else > maxprot |= VM_PROT_WRITE; > handle = (caddr_t)vp; > } else { > /* > * (flags & MAP_ANON) == TRUE > * Mapping blank space is trivial. > */ > if (fd != -1) > return (EINVAL); > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 21:46:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA24094 for freebsd-security-outgoing; Thu, 26 Feb 1998 21:46:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA24048; Thu, 26 Feb 1998 21:45:48 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id VAA26437; Thu, 26 Feb 1998 21:43:51 -0800 (PST) Message-Id: <199802270543.VAA26437@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Cy Schubert - ITSD Open Systems Group cc: tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Thu, 26 Feb 1998 20:23:06 PST." <199802270423.UAA01955@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Feb 1998 21:43:49 -0800 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > I've ported this patch to FreeBSD 2.2.5R. XIG's Accelerated X server > crashes trying to access the VT. To get the XIG Accelerated X server > to work I've modified the patch to allow superuser to access to > character devices. I'm not sure what other applications could break > because of the originally posted patch or my modified patch, so > additional study needs to be done. This modification effectively defeats much of the actual usefulness of the patch. The bug is a second-order security risk in that an attacker must already have obtained at least group kmem before she can take advantage of it. I don't (at this point) think that we want to go ahead with this until we hear from XIG. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 21:46:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA24198 for freebsd-security-outgoing; Thu, 26 Feb 1998 21:46:47 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA24107; Thu, 26 Feb 1998 21:46:15 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id VAA12005; (8.8.8/RDY) Thu, 26 Feb 1998 21:46:03 -0800 (PST) Message-Id: <199802270546.VAA12005@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802270423.UAA01955@cwsys.cwsent.com> from Cy Schubert - ITSD Open Systems Group at "Feb 26, 98 08:23:06 pm" To: cschuber@uumail.gov.bc.ca Date: Thu, 26 Feb 1998 21:46:03 -0800 (PST) Cc: tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Cy Schubert - ITSD Open Systems Group writes: > I've ported this patch to FreeBSD 2.2.5R. XIG's Accelerated X server > crashes trying to access the VT. To get the XIG Accelerated X server > to work I've modified the patch to allow superuser to access to > character devices. I'm not sure what other applications could break > because of the originally posted patch or my modified patch, so > additional study needs to be done. I've already requested John Dyson's review on my port of the patch (almost if not exactly the same as this one) Also, it does indeed breaks Xaccel. Holwever, it's really easy to fix it using gdb. (it's will violate it's license, though :-) > > Here's my modified patch. > > --- sys/vm/vm_mmap.c.orig Mon Mar 24 20:54:29 1997 > +++ sys/vm/vm_mmap.c Thu Feb 26 20:02:38 1998 > @@ -230,6 +230,15 @@ > flags |= MAP_ANON; > } else { > /* > + * cdevs does not provide private mappings of any kind, > + * except for superuser. (This may still be insecure > + * and requires more investigation). > + */ > + error = suser(p->p_ucred, &p->p_acflag); > + if (vp->v_type == VCHR && error && > + (flags & (MAP_PRIVATE|MAP_COPY))) > + return (EINVAL); > + /* > * Ensure that file and memory protections are > * compatible. Note that we only worry about > * writability if mapping is shared; in this case, > @@ -243,12 +252,18 @@ > maxprot |= VM_PROT_READ; > else if (prot & PROT_READ) > return (EACCES); > - if (flags & MAP_SHARED) { > - if (fp->f_flag & FWRITE) > - maxprot |= VM_PROT_WRITE; > - else if (prot & PROT_WRITE) > - return (EACCES); > - } else > + /* > + * If we are sharing potential changes (either via MAP_SHARED > + * or via the implicit sharing of character device mappings), > + * and we are trying to get write permission although we > + * opened it without asking for it, bail out. (Once again > + * superuser can map character devices, though further > + * investigation is required to see if this is insecure). > + */ > + if (((flags & MAP_SHARED) != 0 || (vp->v_type == VCHR && error)) && > + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) > + return (EACCES); > + else > maxprot |= VM_PROT_WRITE; > handle = (caddr_t) vp; > } > > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > UNIX Support OV/VM: BCSC02(CSCHUBER) > ITSD BITNET: CSCHUBER@BCSC02.BITNET > Government of BC Internet: cschuber@uumail.gov.bc.ca > Cy.Schubert@gems8.gov.bc.ca > > > > > ------------------------------------------------------------------------- > > > > OpenBSD Security Advisory > > > > February 20, 1998 > > > > 4.4BSD mmap() Vulnerability > > > > ------------------------------------------------------------------------- > > > > SYNOPSIS > > > > Due to a 4.4BSD VM system problem, it is possible to memory-map a > > read-only descriptor to a character device in read-write mode. This > > allows group "kmem" programs to become root, and root to lower the > > system securelevel, both by writing to the kernel memory device. > > > > ------------------------------------------------------------------------- > > > > AFFECTED SYSTEMS > > > > This vulnerability has been confirmed against OpenBSD 2.2 (and below), > > FreeBSD 2.2.5 (and below), and BSDI 3.0. NetBSD-current (without UVM) > > and below is also affected. > > > > ------------------------------------------------------------------------- > > > > DETAILS > > > > The 4.4BSD VM system allows files to be "memory mapped", which causes > > the specified contents of a file to be made available to a process via > > its address space. Manipulations of that file can then be performed > > simply by manipulating memory, rather than using filesystem I/O calls. > > This technique is used to simplify code, speed up access to files, and > > provide interprocess communication. > > > > Memory mappings can be "private" or "shared". In a private memory mapping, > > changes to the mapped memory are not committed back to the original file. > > Multiple processes with private mappings of the same file will not see > > each other's changes. In a shared mapping, changes to the mapped memory > > are reflected in the original file, and all processes mapping the same > > file see each others's changes. > > > > In order to create a writeable mapping for a file descriptor, that file > > descriptor must be open in read-write mode. This prevents users from using > > read-only access to system files to change the system configuration (by > > taking the read-only descriptors and mapping them read-write). The 4.4BSD > > VM system verifies that an open file descriptor is read-write before > > allowing a shared read-write mapping. > > > > 4.4BSD does not perform this access check when the mapping is not shared; > > a process with a private mapping cannot modify the original file, so the > > potential for danger is minimized. Unfortunately, the 4.4BSD VM system > > automatically changes any private mapping of a character device to > > "shared", regardless of the flags passed to mmap(), after the access check > > is performed. > > > > This allows a user with read-only access to a character device to create a > > read-write mapping to that device, and thus write to the device. This can > > be used against the raw memory device ("/dev/mem") to write arbitrary > > bytes directly to physical memory; if a process has read-only access to > > "/dev/mem" (processes in group "kmem" have this access), it can become > > "root" by altering kernel data structures. > > > > Furthermore, a process with a read-write mapping on "/dev/mem" can rewrite > > the system securelevel back to zero after it has been raised. This allows > > an attacker to bypass the "immutable" and "append-only" filesystem flags, > > along with any other securelevel protections. > > > > ------------------------------------------------------------------------- > > > > TECHNICAL DETAILS > > > > The code exhibiting this problem is located in "sys/vm/vm_mmap.c", in the > > functions "mmap()" (the mmap system call handler), and "vm_mmap()", the VM > > function that actually performs memory mapping. The problem is due to a > > faulty access check in mmap(), combined with a side-effect of character > > device mapping in vm_mmap(). > > > > The mmap() system call handler performs a read-write access check by > > examining the file descriptor passed in as an argument to the system call. > > Before allowing a shared read-write mapping, the system verifies that the > > file being mapped is open in write mode: > > > > if (flags & MAP_SHARED) { > > if (fp->f_flag & FWRITE) > > maxprot |= VM_PROT_WRITE; > > else if (prot & PROT_WRITE) > > return (EACCES); > > } > > > > If the requested mapping is not shared, the access check against the > > file (the check for FWRITE in fp->f_flag, which is the file structure > > for the descriptor passed to mmap) is not performed. For regular files, > > this check is sufficient; a non-shared mapping will not allow a process > > to write to the actual file, only to a private copy in memory. > > > > The vm_mmap() kernel VM function handles memory mapping for all of the > > kernel facilities that require this capability, including execve(), > > System V shared memory, and the mmap() system call. vm_mmap() checks > > to see if a mapping is requested is associated with a character device, > > and, if so, automatically creates a shared mapping (comments from original > > source code): > > > > if (vp->v_type == VCHR) { > > type = OBJT_DEVICE; > > handle = (caddr_t) vp->v_rdev; > > } > > > > ... > > > > /* > > * Force device mappings to be shared. > > */ > > if (type == OBJT_DEVICE) { > > flags &= ~(MAP_PRIVATE|MAP_COPY); > > flags |= MAP_SHARED; > > } > > > > As a result of this code, it is possible to request a non-shared mapping > > of a character device (which will appear innocuous to the mmap() access > > checking code), and receive a shared, writeable mapping. This can be used > > to obtain write access to any readable character device. > > > > This problem is particularly serious when a hostile process has read > > access to kernel memory devices. The system status utilities "ps", > > "netstat", "systat", and others operate setgid "kmem", allowing them to > > use the KVM library to directly access kernel memory. A bug in any of > > these programs can allow an attacker to trivially obtain root access, by > > mmap()'ing a read-only descriptor to "/dev/mem" and altering process > > credential structures. > > > > This issue also directly subverts the system securelevel. 4.4BSD has a > > facility called "securelevels" which adds restrictions to the kernel that > > take effect only when a flag in the kernel (the "securelevel") is set. > > These restrictions include "immutable" files, which cannot be altered > > (even by root), and "append-only" files, which can only have data appended > > to. The former is useful for system binaries (to prevent attackers from > > backdooring libraries and executables), and the latter is useful for logs > > (to prevent attackers from covering their tracks by deleting log data). > > > > The 4.4BSD securelevel features are active when the securelevel is > > nonzero. The securelevel is set using the "sysctl" facility. The system > > does not allow the securelevel to be lowered once it is nonzero; if > > an attacker can lower the securelevel, she can evade securelevels > > protections by turning them off. > > > > The 4.4BSD kernel does not allow processes to write directly to kernel > > memory when the securelevel is nonzero; this prevents "root" from > > bypassing the securelevel simply by writing to "/dev/kmem". This is > > controlled by an access check in "sys/miscfs/specfs/spec_vnops.c", which > > provides vnode operations (open, read, write, etc) for special files (like > > character devices). > > > > The access check is performed in the "spec_open()" function, which handles > > the "open" system call for special files. When the securelevel is nonzero, > > the system explicitly checks for attempts to open devices in read-write > > mode, and prevents read-write opens for disk and kernel memory devices. > > > > Unfortunately, the mmap() bug allows a process to write to a descriptor > > even if it is open read-only; the assumption made in spec_open() thus > > fails to catch attempts to reset the securelevel using mmap(). > > > > ------------------------------------------------------------------------- > > > > RESOLUTION > > > > This is a kernel problem that can only be fixed by patching or upgrading > > the problematic system code. Patches for the OpenBSD operating system are > > provided in this advisory. The problem is fixed in OpenBSD-current and > > must be patched in versions 2.2 and below. > > > > The attached OpenBSD patch causes any attempt to create a private mapping > > of a character device to fail, and enhances access checking in mmap() to > > explicitly verify that the mapping requested is consistant with the open > > mode on the file descriptor being mapped. > > > > Accelerated X from X Inside relies on this bug to operate correctly; this > > patch thus breaks the Accelerated X server. Contact your Accelerated X > > vendor for more information about this. XFree86 is not believed to be > > affected by the problem. > > > > More information about the OpenBSD resolution to the problem is available > > at "http://www.openbsd.org/errata.html". > > > > ------------------------------------------------------------------------- > > > > CREDITS > > > > Documentation and testing of this problem was conducted by Theo de Raadt > > and Chuck Cranor. Theo de Raadt, Chuck Cranor, and Niklas Hallqvist of the > > OpenBSD project provided the OpenBSD patch for the problem. > > > > The developers at OpenBSD would like to extend their gratitude to Perry > > "Scare Bear" Metzger for his continued support of their efforts. > > > > ------------------------------------------------------------------------- > > > > OPENBSD PATCH > > > > Index: vm_mmap.c > > =================================================================== > > RCS file: /cvs/src/sys/vm/vm_mmap.c,v > > retrieving revision 1.10 > > retrieving revision 1.13 > > diff -u -9 -u -r1.10 -r1.13 > > --- vm_mmap.c 1997/11/14 20:56:08 1.10 > > +++ vm_mmap.c 1998/02/25 22:13:46 1.13 > > @@ -1,10 +1,10 @@ > > -/* $OpenBSD: vm_mmap.c,v 1.10 1997/11/14 20:56:08 deraadt Exp $ */ > > +/* $OpenBSD: vm_mmap.c,v 1.13 1998/02/25 22:13:46 deraadt Exp $ */ > > /* $NetBSD: vm_mmap.c,v 1.47 1996/03/16 23:15:23 christos Exp $ */ > > > > /* > > * Copyright (c) 1988 University of Utah. > > * Copyright (c) 1991, 1993 > > * The Regents of the University of California. All rights reserved. > > * > > * This code is derived from software contributed to Berkeley by > > * the Systems Programming Group of the University of Utah Computer > > @@ -207,48 +207,60 @@ > > * Mapping file, get fp for validation. > > * Obtain vnode and make sure it is of appropriate type. > > */ > > if (((unsigned)fd) >= fdp->fd_nfiles || > > (fp = fdp->fd_ofiles[fd]) == NULL) > > return (EBADF); > > if (fp->f_type != DTYPE_VNODE) > > return (EINVAL); > > vp = (struct vnode *)fp->f_data; > > - if (vp->v_type != VREG && vp->v_type != VCHR) > > - return (EINVAL); > > + > > /* > > * XXX hack to handle use of /dev/zero to map anon > > * memory (ala SunOS). > > */ > > if (vp->v_type == VCHR && iszerodev(vp->v_rdev)) { > > flags |= MAP_ANON; > > goto is_anon; > > } > > + > > + /* > > + * Only files and cdevs are mappable, and cdevs does not > > + * provide private mappings of any kind. > > + */ > > + if (vp->v_type != VREG && > > + (vp->v_type != VCHR || (flags & (MAP_PRIVATE|MAP_COPY)))) > > + return (EINVAL); > > /* > > * Ensure that file and memory protections are > > * compatible. Note that we only worry about > > * writability if mapping is shared; in this case, > > * current and max prot are dictated by the open file. > > * XXX use the vnode instead? Problem is: what > > * credentials do we use for determination? > > * What if proc does a setuid? > > */ > > maxprot = VM_PROT_EXECUTE; /* ??? */ > > if (fp->f_flag & FREAD) > > maxprot |= VM_PROT_READ; > > else if (prot & PROT_READ) > > + return (EACCES); > > + > > + /* > > + * If we are sharing potential changes (either via MAP_SHARED > > + * or via the implicit sharing of character device mappings), > > + * and we are trying to get write permission although we > > + * opened it without asking for it, bail out. > > + */ > > + if (((flags & MAP_SHARED) != 0 || vp->v_type == VCHR) && > > + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) > > return (EACCES); > > - if (flags & MAP_SHARED) { > > - if (fp->f_flag & FWRITE) > > - maxprot |= VM_PROT_WRITE; > > - else if (prot & PROT_WRITE) > > - return (EACCES); > > - } else > > + else > > maxprot |= VM_PROT_WRITE; > > handle = (caddr_t)vp; > > } else { > > /* > > * (flags & MAP_ANON) == TRUE > > * Mapping blank space is trivial. > > */ > > if (fd != -1) > > return (EINVAL); > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe security" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 21:58:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA26641 for freebsd-security-outgoing; Thu, 26 Feb 1998 21:58:46 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA26604; Thu, 26 Feb 1998 21:58:02 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id QAA09092; Fri, 27 Feb 1998 16:57:30 +1100 (EST) Message-ID: <19980227165729.27270@rf900.physics.usyd.edu.au> Date: Fri, 27 Feb 1998 16:57:29 +1100 From: David Dawes To: Mike Smith Cc: Cy Schubert - ITSD Open Systems Group , tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem References: <199802270423.UAA01955@cwsys.cwsent.com> <199802270543.VAA26437@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199802270543.VAA26437@dingo.cdrom.com>; from Mike Smith on Thu, Feb 26, 1998 at 09:43:49PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, Feb 26, 1998 at 09:43:49PM -0800, Mike Smith wrote: >> I've ported this patch to FreeBSD 2.2.5R. XIG's Accelerated X server >> crashes trying to access the VT. To get the XIG Accelerated X server >> to work I've modified the patch to allow superuser to access to >> character devices. I'm not sure what other applications could break >> because of the originally posted patch or my modified patch, so >> additional study needs to be done. > >This modification effectively defeats much of the actual usefulness of >the patch. The bug is a second-order security risk in that an attacker >must already have obtained at least group kmem before she can take >advantage of it. I don't (at this point) think that we want to go >ahead with this until we hear from XIG. Does anyone know if it crashes an XFree86 server. XFree86 has a new release about to come out, and if there might be a problem here it would be good for us to know about it now. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 23:11:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09722 for freebsd-security-outgoing; Thu, 26 Feb 1998 23:11:46 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09679; Thu, 26 Feb 1998 23:11:32 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id XAA29612; Thu, 26 Feb 1998 23:11:05 -0800 (PST) To: dima@best.net cc: cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Thu, 26 Feb 1998 21:46:03 PST." <199802270546.VAA12005@burka.rdy.com> Date: Thu, 26 Feb 1998 23:11:05 -0800 Message-ID: <29607.888563465@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Also, it does indeed breaks Xaccel. Holwever, it's really easy to fix it > using gdb. (it's will violate it's license, though :-) Yeesh! I can only imagine the tech support that would generate. :-( Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu Feb 26 23:28:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12150 for freebsd-security-outgoing; Thu, 26 Feb 1998 23:28:42 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12099; Thu, 26 Feb 1998 23:28:27 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id XAA18263; Thu, 26 Feb 1998 23:28:25 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaatCqa; Thu Feb 26 23:28:15 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id XAA01171; Thu, 26 Feb 1998 23:28:09 -0800 (PST) Message-Id: <199802270728.XAA01171@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd001160; Fri Feb 27 07:27:47 1998 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Mailer: MH X-Sender: cy To: David Dawes cc: Mike Smith , Cy Schubert - ITSD Open Systems Group , tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 16:57:29 +1100." <19980227165729.27270@rf900.physics.usyd.edu.au> Date: Thu, 26 Feb 1998 23:27:46 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On Thu, Feb 26, 1998 at 09:43:49PM -0800, Mike Smith wrote: > >> I've ported this patch to FreeBSD 2.2.5R. XIG's Accelerated X server > >> crashes trying to access the VT. To get the XIG Accelerated X server > >> to work I've modified the patch to allow superuser to access to > >> character devices. I'm not sure what other applications could break > >> because of the originally posted patch or my modified patch, so > >> additional study needs to be done. > > > >This modification effectively defeats much of the actual usefulness of > >the patch. The bug is a second-order security risk in that an attacker > >must already have obtained at least group kmem before she can take > >advantage of it. I don't (at this point) think that we want to go > >ahead with this until we hear from XIG. > > Does anyone know if it crashes an XFree86 server. XFree86 has a new > release about to come out, and if there might be a problem here it > would be good for us to know about it now. It doesn't. XF86 doesn't open /dev/mem read-only, then write to it like the XIG X server does. > > David Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 00:34:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18516 for freebsd-security-outgoing; Fri, 27 Feb 1998 00:34:05 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18443; Fri, 27 Feb 1998 00:33:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id IAA24141; Fri, 27 Feb 1998 08:33:22 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id JAA03388; Fri, 27 Feb 1998 09:32:58 +0100 (MET) Message-ID: <19980227093258.00824@follo.net> Date: Fri, 27 Feb 1998 09:32:58 +0100 From: Eivind Eklund To: "Jordan K. Hubbard" , dima@best.net Cc: cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem References: <199802270546.VAA12005@burka.rdy.com> <29607.888563465@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <29607.888563465@time.cdrom.com>; from Jordan K. Hubbard on Thu, Feb 26, 1998 at 11:11:05PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, Feb 26, 1998 at 11:11:05PM -0800, Jordan K. Hubbard wrote: > > Also, it does indeed breaks Xaccel. Holwever, it's really easy to fix it > > using gdb. (it's will violate it's license, though :-) > > Yeesh! I can only imagine the tech support that would generate. :-( It's a major bug on their part. I can't see much we can do about it, beyond notifying them that the change will take place, and helping them distribute announcements. We _can't_ let this bug stay in, IMO. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 07:01:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29502 for freebsd-security-outgoing; Fri, 27 Feb 1998 07:01:58 -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 HAA29497 for ; Fri, 27 Feb 1998 07:01:54 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id KAA04815; Fri, 27 Feb 1998 10:01:50 -0500 (EST) (envelope-from wollman) Date: Fri, 27 Feb 1998 10:01:50 -0500 (EST) From: Garrett Wollman Message-Id: <199802271501.KAA04815@khavrinen.lcs.mit.edu> To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802270423.UAA01955@cwsys.cwsent.com> References: <19980226174359.3210.qmail@joshua.enteract.com> <199802270423.UAA01955@cwsys.cwsent.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > crashes trying to access the VT. To get the XIG Accelerated X server > to work I've modified the patch to allow superuser to access to > character devices. The would be pointless. The whole purpose of the securelevel facility is to make it impossible for even the superuser to do certain things, so that when someone cracks root on your box, the amount of damage they can do is limited. -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 security" in the body of the message From owner-freebsd-security Fri Feb 27 08:10:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10072 for freebsd-security-outgoing; Fri, 27 Feb 1998 08:10:21 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10058 for ; Fri, 27 Feb 1998 08:10:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id QAA01903; Fri, 27 Feb 1998 16:10:15 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id RAA00504; Fri, 27 Feb 1998 17:09:54 +0100 (MET) Message-ID: <19980227170953.30435@follo.net> Date: Fri, 27 Feb 1998 17:09:54 +0100 From: Eivind Eklund To: Garrett Wollman , Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem References: <19980226174359.3210.qmail@joshua.enteract.com> <199802270423.UAA01955@cwsys.cwsent.com> <199802271501.KAA04815@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199802271501.KAA04815@khavrinen.lcs.mit.edu>; from Garrett Wollman on Fri, Feb 27, 1998 at 10:01:50AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, Feb 27, 1998 at 10:01:50AM -0500, Garrett Wollman wrote: > < said: > > > crashes trying to access the VT. To get the XIG Accelerated X server > > to work I've modified the patch to allow superuser to access to > > character devices. > > The would be pointless. It'd kill the securelevel facility, but it would still remove the kmem => root exploits. But it isn't good enough, I agree. Perhaps denying the transition only when !(root || securelevel > -1) would be a potential solution? It'd allow AccelX to keep working (AFAIK, it won't work with securelevel > 0 anyway) and it would stop all real violations I can think of 1. root can't lower the securelevel 2. kmem can't get privileges it shouldn't have 3. root will get some privileges it could get some privileges it would have anyway if it had opened in another mode. This will make us vulnerable to the unlikely exploit of somebody getting hold of a root mmap() pointing at a character device, but _not_ being able to execute arbitary code. Sounds unlikely to me. Have I covered everything? (Perhaps there are some special /dev/mem interactions I don't know of...) Eivind, who don't really like this solution, either, but if the alternative is leaving the bug wide open... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 08:45:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16669 for freebsd-security-outgoing; Fri, 27 Feb 1998 08:45:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [194.93.177.113]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA16424 for ; Fri, 27 Feb 1998 08:44:57 -0800 (PST) (envelope-from ru@relay.ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.8.8/8.8.8) id SAA01330 for freebsd-security@freebsd.org; Fri, 27 Feb 1998 18:44:26 +0200 (EET) (envelope-from ru) From: Ruslan Ermilov Message-Id: <199802271644.SAA01330@relay.ucb.crimea.ua> Subject: Another sendmail spam? To: freebsd-security@FreeBSD.ORG Date: Fri, 27 Feb 1998 18:44:26 +0200 (EET) X-My-Interests: Unix,Oracle,Networking 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 Hi! Does your antispam rules work right on the following sequence? ehlo somewhere.domain mail from: <> rcpt to: you data From: To: Subject: spam mail data . -- Ruslan Ermilov System Administrator ru@ucb.crimea.ua United Commercial Bank +380-652-247647 Simferopol, Crimea 2426679 ICQ Network, UIN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 09:20:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA22894 for freebsd-security-outgoing; Fri, 27 Feb 1998 09:20:36 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA22875; Fri, 27 Feb 1998 09:20:05 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id JAA14823; (8.8.8/RDY) Fri, 27 Feb 1998 09:19:30 -0800 (PST) Message-Id: <199802271719.JAA14823@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <19980227093258.00824@follo.net> from Eivind Eklund at "Feb 27, 98 09:32:58 am" To: eivind@yes.no (Eivind Eklund) Date: Fri, 27 Feb 1998 09:19:29 -0800 (PST) Cc: jkh@time.cdrom.com, dima@best.net, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Eivind Eklund writes: > On Thu, Feb 26, 1998 at 11:11:05PM -0800, Jordan K. Hubbard wrote: > > > Also, it does indeed breaks Xaccel. Holwever, it's really easy to fix it > > > using gdb. (it's will violate it's license, though :-) > > > > Yeesh! I can only imagine the tech support that would generate. :-( > > It's a major bug on their part. I can't see much we can do about it, > beyond notifying them that the change will take place, and helping > them distribute announcements. I already did that. > > We _can't_ let this bug stay in, IMO. I completely agree. > > Eivind. > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:07:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18675 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:07:21 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18625; Fri, 27 Feb 1998 12:06:18 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id MAA15942; (8.8.8/RDY) Fri, 27 Feb 1998 12:05:33 -0800 (PST) Message-Id: <199802272005.MAA15942@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <19980227165729.27270@rf900.physics.usyd.edu.au> from David Dawes at "Feb 27, 98 04:57:29 pm" To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Fri, 27 Feb 1998 12:05:33 -0800 (PST) Cc: mike@smith.net.au, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 David Dawes writes: > > Does anyone know if it crashes an XFree86 server. XFree86 has a new > release about to come out, and if there might be a problem here it > would be good for us to know about it now. No, it does not crash XFree86 servers. > > David > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:28:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21544 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:28:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21424; Fri, 27 Feb 1998 12:26:24 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id MAA16117; (8.8.8/RDY) Fri, 27 Feb 1998 12:25:27 -0800 (PST) Message-Id: <199802272025.MAA16117@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802272019.VAA06101@gvr.gvr.org> from Guido van Rooij at "Feb 27, 98 09:19:13 pm" To: guido@gvr.org (Guido van Rooij) Date: Fri, 27 Feb 1998 12:25:27 -0800 (PST) Cc: dima@best.net, eivind@yes.no, jkh@time.cdrom.com, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Guido van Rooij writes: > > > It's a major bug on their part. I can't see much we can do about it, > > > beyond notifying them that the change will take place, and helping > > > them distribute announcements. > > > > I already did that. > > > > And what was their reaction? They said, that new release is gonna be in a few months. However, I've suggested them to release a binary patch that will patch server binaries. I even sent them a program that patches v4.1/v3.1 AX servers. I haven't heard from them ever since. This was about 2 hours ago. I certainly hope that they actually will release a patch before the next release. At least it sounded like they will. > > -Guido > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:29:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21768 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:29:25 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21476; Fri, 27 Feb 1998 12:27:36 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id VAA06092; Fri, 27 Feb 1998 21:18:23 +0100 (MET) From: Guido van Rooij Message-Id: <199802272018.VAA06092@gvr.gvr.org> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <19980227093258.00824@follo.net> from Eivind Eklund at "Feb 27, 98 09:32:58 am" To: eivind@yes.no (Eivind Eklund) Date: Fri, 27 Feb 1998 21:18:23 +0100 (MET) Cc: jkh@time.cdrom.com, dima@best.net, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@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 Eivind Eklund wrote: > On Thu, Feb 26, 1998 at 11:11:05PM -0800, Jordan K. Hubbard wrote: > > > Also, it does indeed breaks Xaccel. Holwever, it's really easy to fix it > > > using gdb. (it's will violate it's license, though :-) > > > > Yeesh! I can only imagine the tech support that would generate. :-( > > It's a major bug on their part. I can't see much we can do about it, > beyond notifying them that the change will take place, and helping > them distribute announcements. > > We _can't_ let this bug stay in, IMO. I agree completely here. Did anyone already contact XIG? -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:32:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22500 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:32:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21482; Fri, 27 Feb 1998 12:27:40 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id VAA06101; Fri, 27 Feb 1998 21:19:13 +0100 (MET) From: Guido van Rooij Message-Id: <199802272019.VAA06101@gvr.gvr.org> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802271719.JAA14823@burka.rdy.com> from Dima Ruban at "Feb 27, 98 09:19:29 am" To: dima@best.net Date: Fri, 27 Feb 1998 21:19:13 +0100 (MET) Cc: eivind@yes.no, jkh@time.cdrom.com, dima@best.net, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@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 > > It's a major bug on their part. I can't see much we can do about it, > > beyond notifying them that the change will take place, and helping > > them distribute announcements. > > I already did that. > And what was their reaction? -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:43:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25897 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:43:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25738; Fri, 27 Feb 1998 12:43:16 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id MAA16246; (8.8.8/RDY) Fri, 27 Feb 1998 12:42:36 -0800 (PST) Message-Id: <199802272042.MAA16246@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802272036.VAA06582@gvr.gvr.org> from Guido van Rooij at "Feb 27, 98 09:36:55 pm" To: guido@gvr.org (Guido van Rooij) Date: Fri, 27 Feb 1998 12:42:36 -0800 (PST) Cc: dima@best.net, eivind@yes.no, jkh@time.cdrom.com, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) 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 Guido van Rooij writes: > > Perhaps it would be a good thing if we send a pointer to a possible > binary patch when sending out our advisory. Now that would be tricky. In this case we'll need to wait untill XiG will actually release the patch. > > -Guido > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 12:45:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26275 for freebsd-security-outgoing; Fri, 27 Feb 1998 12:45:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26241; Fri, 27 Feb 1998 12:45:10 -0800 (PST) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.6/8.8.5) id VAA06582; Fri, 27 Feb 1998 21:36:55 +0100 (MET) From: Guido van Rooij Message-Id: <199802272036.VAA06582@gvr.gvr.org> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802272025.MAA16117@burka.rdy.com> from Dima Ruban at "Feb 27, 98 12:25:27 pm" To: dima@best.net Date: Fri, 27 Feb 1998 21:36:55 +0100 (MET) Cc: dima@best.net, eivind@yes.no, jkh@time.cdrom.com, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@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 Dima Ruban wrote: > Guido van Rooij writes: > > > > It's a major bug on their part. I can't see much we can do about it, > > > > beyond notifying them that the change will take place, and helping > > > > them distribute announcements. > > > > > > I already did that. > > > > > > > And what was their reaction? > > They said, that new release is gonna be in a few months. However, I've > suggested them to release a binary patch that will patch server binaries. > I even sent them a program that patches v4.1/v3.1 AX servers. > I haven't heard from them ever since. This was about 2 hours ago. > > I certainly hope that they actually will release a patch before the next > release. At least it sounded like they will. Perhaps it would be a good thing if we send a pointer to a possible binary patch when sending out our advisory. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 14:34:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13644 for freebsd-security-outgoing; Fri, 27 Feb 1998 14:34:48 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13601 for ; Fri, 27 Feb 1998 14:34:29 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA29161; Fri, 27 Feb 1998 14:31:27 -0800 (PST) Message-Id: <199802272231.OAA29161@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Eivind Eklund cc: Garrett Wollman , Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 17:09:54 +0100." <19980227170953.30435@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Feb 1998 14:31:26 -0800 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On Fri, Feb 27, 1998 at 10:01:50AM -0500, Garrett Wollman wrote: > > < said: > > > > > crashes trying to access the VT. To get the XIG Accelerated X server > > > to work I've modified the patch to allow superuser to access to > > > character devices. > > > > The would be pointless. > > It'd kill the securelevel facility, but it would still remove the kmem > => root exploits. But it isn't good enough, I agree. Perhaps denying > the transition only when !(root || securelevel > -1) would be a > potential solution? It'd allow AccelX to keep working (AFAIK, it > won't work with securelevel > 0 anyway) and it would stop all real > violations I can think of The fundamental question still hasn't been answered; as Bruce asked, why are mmap operations on readonly character devices promoted to readwrite in the first place? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 17:33:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16347 for freebsd-security-outgoing; Fri, 27 Feb 1998 17:33:18 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16283 for ; Fri, 27 Feb 1998 17:33:10 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id RAA32086; Fri, 27 Feb 1998 17:33:03 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaAkxa; Fri Feb 27 17:32:51 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id RAA00955; Fri, 27 Feb 1998 17:32:45 -0800 (PST) Message-Id: <199802280132.RAA00955@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd000944; Sat Feb 28 01:32:09 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Eivind Eklund cc: Garrett Wollman , Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 17:09:54 +0100." <19980227170953.30435@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Feb 1998 17:32:08 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk I've managed to solve the problem while waiting in the doctor's office this afternoon. According to the 4.4BSD Bible, at securelevel > 0 /dev/mem and /dev/kmem are read only, which would break XIG's X server anyway. Securelevel 0 is used only in single user mode, so the XIG X server could only be used in securelevel -1. Here's a new copy of my hack of the OpenBSD patch. It only allows the insecure mmap access to character devices at securelevel -1. This seems like a good compromise because the XIG X server should be broken at securelevels 1 and 2 anyhow and to allow superuser to write to a read-only /dev/mem device at securelevel -1 doesn't add any new security exposures. --- sys/vm/vm_mmap.c.orig Mon Mar 24 20:54:29 1997 +++ sys/vm/vm_mmap.c Fri Feb 27 17:27:34 1998 @@ -230,6 +230,22 @@ flags |= MAP_ANON; } else { /* + * cdevs does not provide private mappings of any kind, + * except for superuser. Check for superuser to allow + * XIG X server to continue to work -- this is not a + * security hole because we only allow it to run at + * securelevel -1. Because the XIG X server writes + * directly to video memory via /dev/mem, it would + * never work at any other securelevel. + */ + if (securelevel == -1) + error = suser(p->p_ucred, &p->p_acflag); + else + error = 1; + if (vp->v_type == VCHR && error && + (flags & (MAP_PRIVATE|MAP_COPY))) + return (EINVAL); + /* * Ensure that file and memory protections are * compatible. Note that we only worry about * writability if mapping is shared; in this case, @@ -243,12 +259,19 @@ maxprot |= VM_PROT_READ; else if (prot & PROT_READ) return (EACCES); - if (flags & MAP_SHARED) { - if (fp->f_flag & FWRITE) - maxprot |= VM_PROT_WRITE; - else if (prot & PROT_WRITE) - return (EACCES); - } else + /* + * If we are sharing potential changes (either via MAP_SHARED + * or via the implicit sharing of character device mappings), + * and we are trying to get write permission although we + * opened it without asking for it, bail out. Check for + * superuser, only if we're at securelevel -1, to allow + * the XIG X server to continue to work. + */ + if (((flags & MAP_SHARED) != 0 || + (vp->v_type == VCHR && error)) && + (fp->f_flag & FWRITE) == 0 && (prot & PROT_WRITE) != 0) + return (EACCES); + else maxprot |= VM_PROT_WRITE; handle = (caddr_t) vp; } Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca > On Fri, Feb 27, 1998 at 10:01:50AM -0500, Garrett Wollman wrote: > > < said: > > > > > crashes trying to access the VT. To get the XIG Accelerated X server > > > to work I've modified the patch to allow superuser to access to > > > character devices. > > > > The would be pointless. > > It'd kill the securelevel facility, but it would still remove the kmem > => root exploits. But it isn't good enough, I agree. Perhaps denying > the transition only when !(root || securelevel > -1) would be a > potential solution? It'd allow AccelX to keep working (AFAIK, it > won't work with securelevel > 0 anyway) and it would stop all real > violations I can think of > > 1. root can't lower the securelevel > 2. kmem can't get privileges it shouldn't have > 3. root will get some privileges it could get some privileges it would > have anyway if it had opened in another mode. This will make us > vulnerable to the unlikely exploit of somebody getting hold of a > root mmap() pointing at a character device, but _not_ being able to > execute arbitary code. Sounds unlikely to me. > > Have I covered everything? (Perhaps there are some special /dev/mem > interactions I don't know of...) > > Eivind, who don't really like this solution, either, but if the > alternative is leaving the bug wide open... > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 17:38:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17271 for freebsd-security-outgoing; Fri, 27 Feb 1998 17:38:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17202; Fri, 27 Feb 1998 17:38:07 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id RAA32214; Fri, 27 Feb 1998 17:38:03 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaysoa; Fri Feb 27 17:37:52 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id RAA00985; Fri, 27 Feb 1998 17:37:44 -0800 (PST) Message-Id: <199802280137.RAA00985@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd000972; Sat Feb 28 01:37:01 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: dima@best.net cc: guido@gvr.org (Guido van Rooij), eivind@yes.no, jkh@time.cdrom.com, cschuber@uumail.gov.bc.ca, tqbf@secnet.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 12:42:36 PST." <199802272042.MAA16246@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Feb 1998 17:37:00 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Guido van Rooij writes: > > > > Perhaps it would be a good thing if we send a pointer to a possible > > binary patch when sending out our advisory. > > Now that would be tricky. In this case we'll need to wait untill XiG will > actually release the patch. > > > > > -Guido > > > > -- dima I've just posted a patch to FreeBSD-Security that makes this a moot point. The XIG X server shouldn't work at securelevel > 0 anyway so the new patch allows their X server to write to /dev/mem while at securelevel -1. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 18:35:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24946 for freebsd-security-outgoing; Fri, 27 Feb 1998 18:35:12 -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 SAA24936 for ; Fri, 27 Feb 1998 18:35:06 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id VAA07394; Fri, 27 Feb 1998 21:35:03 -0500 (EST) (envelope-from wollman) Date: Fri, 27 Feb 1998 21:35:03 -0500 (EST) From: Garrett Wollman Message-Id: <199802280235.VAA07394@khavrinen.lcs.mit.edu> To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802280137.RAA00985@cwsys.cwsent.com> References: <199802272042.MAA16246@burka.rdy.com> <199802280137.RAA00985@cwsys.cwsent.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < said: > I've just posted a patch to FreeBSD-Security that makes this a moot > point. The XIG X server shouldn't work at securelevel > 0 anyway so > the new patch allows their X server to write to /dev/mem while at > securelevel -1. Thereby perpetuating the original bug. I'd rather ask Xi to fix their server; if we ask nicely, they'll probably comply (since the behavior in question is clearly bogus). If not, then the behavior should be optional on ``COMPAT_XACCEL_BUG'' and not enabled by default. -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 security" in the body of the message From owner-freebsd-security Fri Feb 27 19:00:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA28999 for freebsd-security-outgoing; Fri, 27 Feb 1998 19:00:42 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.actrix.gen.nz (root@mail.actrix.gen.nz [203.96.16.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA28876 for ; Fri, 27 Feb 1998 19:00:26 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from [192.168.1.1] (a.mcn.actrix.gen.nz [203.96.56.128]) by mail.actrix.gen.nz (8.8.8/8.8.5) with SMTP id QAA05675 for ; Sat, 28 Feb 1998 16:00:19 +1300 (NZDT) X-Sender: squiz1@mail.actrix.gen.nz Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Feb 1998 16:01:55 +1300 To: freebsd-security@FreeBSD.ORG From: andrew@squiz.co.nz (Andrew McNaughton) Subject: crypto tunnel - international Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Has anyone ported any transport layer crypto tunneling software to FreeBSD that can be downloaded and then linked with code unfettered by US export regulations? Any pointers to setting up such a thing much appreciated. SKIP is listed in the ports collections, but http://skip.incog.com/ wants assurances of being an american citizen etc etc before downloading. Is there a downloadable version of this available with the crypto libs replaced with stubs, or with international versions? Andrew McNaughton The effort to understand the universe is Andrew McNaughton one of the very few things that lifts ++64 4 389 6891 human life above the level of farce, andrew@squiz.co.nz and gives it some of the grace http://www.squiz.co.nz of tragedy - Steven Weinberg http://www.newsroom.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 20:28:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17405 for freebsd-security-outgoing; Fri, 27 Feb 1998 20:28:40 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17389 for ; Fri, 27 Feb 1998 20:28:29 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id UAA19048; (8.8.8/RDY) Fri, 27 Feb 1998 20:28:18 -0800 (PST) Message-Id: <199802280428.UAA19048@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802280132.RAA00955@cwsys.cwsent.com> from Cy Schubert - ITSD Open Systems Group at "Feb 27, 98 05:32:08 pm" To: cschuber@uumail.gov.bc.ca Date: Fri, 27 Feb 1998 20:28:18 -0800 (PST) Cc: eivind@yes.no, wollman@khavrinen.lcs.mit.edu, cschuber@uumail.gov.bc.ca, 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+ 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 Cy Schubert - ITSD Open Systems Group writes: > I've managed to solve the problem while waiting in the doctor's office > this afternoon. According to the 4.4BSD Bible, at securelevel > 0 > /dev/mem and /dev/kmem are read only, which would break XIG's X server > anyway. Securelevel 0 is used only in single user mode, so the XIG X This is not entirely correct. Take a look at OpenBSD's /etc/rc.securelevel. Everything that shoudl have write access to /dev/*mem should be started before securelevel is bumbed. I think, we should not make such a modifications to the patch. > server could only be used in securelevel -1. Here's a new copy of my > hack of the OpenBSD patch. It only allows the insecure mmap access to > character devices at securelevel -1. This seems like a good compromise > because the XIG X server should be broken at securelevels 1 and 2 > anyhow and to allow superuser to write to a read-only /dev/mem device > at securelevel -1 doesn't add any new security exposures. > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 22:36:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29695 for freebsd-security-outgoing; Fri, 27 Feb 1998 22:36:01 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29683 for ; Fri, 27 Feb 1998 22:35:58 -0800 (PST) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id WAA02579; Fri, 27 Feb 1998 22:35:56 -0800 (PST) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaBega; Fri Feb 27 22:35:54 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id WAA02412; Fri, 27 Feb 1998 22:35:49 -0800 (PST) Message-Id: <199802280635.WAA02412@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd002404; Sat Feb 28 06:35:38 1998 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Mailer: MH X-Sender: cy To: Garrett Wollman cc: Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 21:35:03 EST." <199802280235.VAA07394@khavrinen.lcs.mit.edu> Date: Fri, 27 Feb 1998 22:35:36 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > < said: > > > I've just posted a patch to FreeBSD-Security that makes this a moot > > point. The XIG X server shouldn't work at securelevel > 0 anyway so > > the new patch allows their X server to write to /dev/mem while at > > securelevel -1. > > Thereby perpetuating the original bug. I'd rather ask Xi to fix their > server; if we ask nicely, they'll probably comply (since the behavior > in question is clearly bogus). If not, then the behavior should be > optional on ``COMPAT_XACCEL_BUG'' and not enabled by default. I've already talked to them about the upcoming release of their new products. They've told me that they're dropping support for FreeBSD and focusing on Linux because FreeBSD doesn't sell X servers. It will be unlikely that they'll make any changes. Let's go ahead and put out the Advisory, as unsupported products should die anyhow. If Xi no longer supports FreeBSD, FreeBSD should not support Xi!!! A COMPAT_XACCEL_BUG would probably not be a good idea because it could be the cause of compromises of poorly configured systems. It was worth a try to keep it running while I could, though. I'll consider removing Xi's server instead. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the sa me > 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 security" in the body of the message > Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 22:50:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA01764 for freebsd-security-outgoing; Fri, 27 Feb 1998 22:50:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA01723 for ; Fri, 27 Feb 1998 22:50:00 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id WAA19798; (8.8.8/RDY) Fri, 27 Feb 1998 22:49:57 -0800 (PST) Message-Id: <199802280649.WAA19798@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802280635.WAA02412@cwsys.cwsent.com> from Cy Schubert - ITSD Open Systems Group at "Feb 27, 98 10:35:36 pm" To: cschuber@uumail.gov.bc.ca Date: Fri, 27 Feb 1998 22:49:57 -0800 (PST) Cc: wollman@khavrinen.lcs.mit.edu, cschuber@uumail.gov.bc.ca, 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+ 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 Cy Schubert - ITSD Open Systems Group writes: > I've already talked to them about the upcoming release of their new products. > They've told me that they're dropping support for FreeBSD and focusing on > Linux because FreeBSD doesn't sell X servers. It will be unlikely that > they'll make any changes. Let's go ahead and put out the Advisory, as > unsupported products should die anyhow. If Xi no longer supports FreeBSD, > FreeBSD should not support Xi!!! If this is true, then it really does suck. I happen to like their servers before the v4.1 release ... > A COMPAT_XACCEL_BUG would probably not be a good idea because it could > be the cause of compromises of poorly configured systems. Right. > It was worth a try to keep it running while I could, though. I'll consider > removing Xi's server instead. > > > > > -GAWollman > > > > -- > > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the sa > me > > 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 security" in the body of the message > > > > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > UNIX Support OV/VM: BCSC02(CSCHUBER) > ITSD BITNET: CSCHUBER@BCSC02.BITNET > Government of BC Internet: cschuber@uumail.gov.bc.ca > Cy.Schubert@gems8.gov.bc.ca > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri Feb 27 23:19:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA04474 for freebsd-security-outgoing; Fri, 27 Feb 1998 23:19:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA04465 for ; Fri, 27 Feb 1998 23:19:39 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id XAA06822; Fri, 27 Feb 1998 23:19:21 -0800 (PST) To: Cy Schubert - ITSD Open Systems Group cc: Garrett Wollman , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Fri, 27 Feb 1998 22:35:36 PST." <199802280635.WAA02412@cwsys.cwsent.com> Date: Fri, 27 Feb 1998 23:19:21 -0800 Message-ID: <6819.888650361@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > I've already talked to them about the upcoming release of their new products. > They've told me that they're dropping support for FreeBSD and focusing on > Linux because FreeBSD doesn't sell X servers. It will be unlikely that Hmmm. That's interesting news. I guess I'll have to phone XiG tomorrow and ask them whether or not they'd be interested in outsourcing this product to us. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 04:11:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01921 for freebsd-security-outgoing; Sat, 28 Feb 1998 04:11:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01907 for ; Sat, 28 Feb 1998 04:11:49 -0800 (PST) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id PAA05676; Sat, 28 Feb 1998 15:00:48 +0100 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id NAA22546; Sat, 28 Feb 1998 13:19:48 +0100 (CET) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id NAA24493; Sat, 28 Feb 1998 13:10:40 +0100 (CET) Message-ID: <19980228131040.01412@deepo.prosa.dk> Date: Sat, 28 Feb 1998 13:10:40 +0100 From: Philippe Regnauld To: Andrew McNaughton Cc: freebsd-security@FreeBSD.ORG Subject: Re: crypto tunnel - international References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: ; from Andrew McNaughton on Sat, Feb 28, 1998 at 04:01:55PM +1300 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Andrew McNaughton writes: > SKIP is listed in the ports collections, but http://skip.incog.com/ wants > assurances of being an american citizen etc etc before downloading. > > Is there a downloadable version of this available with the crypto libs > replaced with stubs, or with international versions? http://ftpsearch.unit.no/ Look for: skipsrc-1.0 and skipsrc-1.0-binary-freebsd -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 07:03:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14842 for freebsd-security-outgoing; Sat, 28 Feb 1998 07:03:02 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14829 for ; Sat, 28 Feb 1998 07:02:55 -0800 (PST) (envelope-from bs@devnull.ruhr.de) Received: (from admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id PAA06517; Sat, 28 Feb 1998 15:37:30 +0100 (MET) Received: from rm.devnull.ruhr.de [192.168.22.75] by devnull.ruhr.de with smtp (Exim 1.73 #1) id 0y8mZ2-0000JG-00; Sat, 28 Feb 1998 14:44:28 +0100 Received: from bs by rm.devnull.ruhr.de with local (Exim 1.73 #1) id 0y8mgS-0000L6-00; Sat, 28 Feb 1998 14:52:08 +0100 To: Philippe Regnauld Cc: Nicolas Pondemer , freebsd-security@FreeBSD.ORG Subject: Re: Thanks, but... References: <34F5623C.3E6@isty-info.uvsq.fr> <19980226140934.31437@deepo.prosa.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Benedikt Stockebrand Date: 28 Feb 1998 14:52:07 +0100 In-Reply-To: Philippe Regnauld's message of "Thu, 26 Feb 1998 14:09:34 +0100" Message-ID: <8790qvrg54.fsf@devnull.ruhr.de> Lines: 25 X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Philippe Regnauld writes: > I don't see how user B can force user A to have a Bcc:=20 > automatically added to his headers. If B managed to add something like alias mail="/usr/bin/mail -bB@localhost" or whatever your preferred shell uses as syntax to ~A/.profile this could be done. Yes, it depends on your shell and your preferred MUA and requires some sort of security hole (like A not logging out before taking a break). Another option would be to add a trojanized MUA binary in ~A/bin or such. IOW, if you suspect some other user of this, check ~/.* for such beasts (as well as unsolicited ~/.rhosts entries). Ben -- Ben(edikt)? Stockebrand --- Un*x system administrator looking for a job To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 07:07:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15652 for freebsd-security-outgoing; Sat, 28 Feb 1998 07:07:49 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA15644 for ; Sat, 28 Feb 1998 07:07:44 -0800 (PST) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id RAA06076; Sat, 28 Feb 1998 17:56:54 +0100 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id QAA22705; Sat, 28 Feb 1998 16:15:55 +0100 (CET) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id QAA27349; Sat, 28 Feb 1998 16:06:45 +0100 (CET) Message-ID: <19980228160645.62766@deepo.prosa.dk> Date: Sat, 28 Feb 1998 16:06:45 +0100 From: Philippe Regnauld To: Benedikt Stockebrand Cc: Nicolas Pondemer , freebsd-security@FreeBSD.ORG Subject: Re: Thanks, but... References: <34F5623C.3E6@isty-info.uvsq.fr> <19980226140934.31437@deepo.prosa.dk> <8790qvrg54.fsf@devnull.ruhr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: <8790qvrg54.fsf@devnull.ruhr.de>; from Benedikt Stockebrand on Sat, Feb 28, 1998 at 02:52:07PM +0100 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Benedikt Stockebrand writes: > > alias mail="/usr/bin/mail -bB@localhost" > > or whatever your preferred shell uses as syntax to ~A/.profile this > could be done. This is out of the scope of an external attack on an environment assumed to minimally secure. > Yes, it depends on your shell and your preferred MUA and requires some > sort of security hole (like A not logging out before taking a break). > Another option would be to add a trojanized MUA binary in ~A/bin or > such. And once again, this implies a compromised environment: either the sysadmin is evil/corrupt, or someone broke root on the box. In that scenario, the methods are infinite. What'd be more interesting is to mangle the headers or confuse sendmail/some MTA from the *outside* into adding Bcc: headers. Now that's art :-) -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 09:32:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27934 for freebsd-security-outgoing; Sat, 28 Feb 1998 09:32:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from onyx.atipa.com (user4330@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA27868 for ; Sat, 28 Feb 1998 09:31:34 -0800 (PST) (envelope-from freebsd@atipa.com) Received: (qmail-queue invoked by uid 1018); 28 Feb 1998 17:39:55 -0000 Date: Sat, 28 Feb 1998 10:39:55 -0700 (MST) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Andrew McNaughton cc: freebsd-security@FreeBSD.ORG Subject: Re: crypto tunnel - international In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Some of our customers faced this problem as well, and the simplest thing to use was OpenBSD. Since OpenBSD has cryptography built in to the OS, it is very easy to set up secure tunneling. OpenBSD is a product of Canada, so they can use full-strength cryptography. Once it is installed in the US, it is non-exportable, but the international sites can download directly from Canada :) So far, I do not recommend OpenBSD for anything except ultra-secure servers. FreeBSD is much easier to use and has a better user base. Kevin On Sat, 28 Feb 1998, Andrew McNaughton wrote: > Has anyone ported any transport layer crypto tunneling software to FreeBSD > that can be downloaded and then linked with code unfettered by US export > regulations? > > Any pointers to setting up such a thing much appreciated. > > SKIP is listed in the ports collections, but http://skip.incog.com/ wants > assurances of being an american citizen etc etc before downloading. > > Is there a downloadable version of this available with the crypto libs > replaced with stubs, or with international versions? > > Andrew McNaughton > > > > The effort to understand the universe is Andrew McNaughton > one of the very few things that lifts ++64 4 389 6891 > human life above the level of farce, andrew@squiz.co.nz > and gives it some of the grace http://www.squiz.co.nz > of tragedy - Steven Weinberg http://www.newsroom.co.nz > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 10:07:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00861 for freebsd-security-outgoing; Sat, 28 Feb 1998 10:07:26 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00846 for ; Sat, 28 Feb 1998 10:07:19 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id KAA13619; Sat, 28 Feb 1998 10:06:58 -0800 (PST) To: Atipa cc: Andrew McNaughton , freebsd-security@FreeBSD.ORG Subject: Re: crypto tunnel - international In-reply-to: Your message of "Sat, 28 Feb 1998 10:39:55 MST." Date: Sat, 28 Feb 1998 10:06:58 -0800 Message-ID: <13614.888689218@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Some of our customers faced this problem as well, and the simplest thing > to use was OpenBSD. Since OpenBSD has cryptography built in to the OS, it > is very easy to set up secure tunneling. Can you explain *precisely* what you mean by "cryptography built in to the OS?" > OpenBSD is a product of Canada, so they can use full-strength > cryptography. Once it is installed in the US, it is non-exportable, but > the international sites can download directly from Canada :) And we've been exporting said crypto from ftp.freebsd.org as well, which is in a region of the U.S. which falls under Judge Patel's decision. I really don't see what OpenBSD can export which we cannot and it would be really nifty if you could give us details on what is missing from FreeBSD. Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 10:33:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05023 for freebsd-security-outgoing; Sat, 28 Feb 1998 10:33:31 -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 KAA05017 for ; Sat, 28 Feb 1998 10:33:26 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id NAA13156; Sat, 28 Feb 1998 13:33:18 -0500 (EST) (envelope-from wollman) Date: Sat, 28 Feb 1998 13:33:18 -0500 (EST) From: Garrett Wollman Message-Id: <199802281833.NAA13156@khavrinen.lcs.mit.edu> To: dima@best.net Cc: freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802280428.UAA19048@burka.rdy.com> References: <199802280132.RAA00955@cwsys.cwsent.com> <199802280428.UAA19048@burka.rdy.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk < This is not entirely correct. Take a look at OpenBSD's /etc/rc.securelevel. > Everything that shoudl have write access to /dev/*mem should be started > before securelevel is bumbed. And then all you have to do is compromise one of those programs... There is a legitimate purpose for starting programs that early, but I don't think running an insecure X server is one of them. -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 security" in the body of the message From owner-freebsd-security Sat Feb 28 11:02:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07088 for freebsd-security-outgoing; Sat, 28 Feb 1998 11:02:10 -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 LAA07074 for ; Sat, 28 Feb 1998 11:02:03 -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 MAA08223; Sat, 28 Feb 1998 12:02:00 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA10911; Sat, 28 Feb 1998 12:01:58 -0700 Date: Sat, 28 Feb 1998 12:01:58 -0700 Message-Id: <199802281901.MAA10911@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Cy Schubert - ITSD Open Systems Group Cc: Garrett Wollman , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802280635.WAA02412@cwsys.cwsent.com> References: <199802280235.VAA07394@khavrinen.lcs.mit.edu> <199802280635.WAA02412@cwsys.cwsent.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > Thereby perpetuating the original bug. I'd rather ask Xi to fix their > > server; if we ask nicely, they'll probably comply (since the behavior > > in question is clearly bogus). If not, then the behavior should be > > optional on ``COMPAT_XACCEL_BUG'' and not enabled by default. > > I've already talked to them about the upcoming release of their new products. > They've told me that they're dropping support for FreeBSD and focusing on > Linux because FreeBSD doesn't sell X servers. *sigh* I've bought every version of their software they've made, and paid full price. But, as of late, it appears that they aren't doing so well per the inability to get through to tech-support, so that may be why things are being 'cut-back'. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 11:34:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09735 for freebsd-security-outgoing; Sat, 28 Feb 1998 11:34:03 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA09702 for ; Sat, 28 Feb 1998 11:33:57 -0800 (PST) (envelope-from handy@sag.space.lockheed.com) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA28771; Sat, 28 Feb 1998 11:33:15 -0800 Date: Sat, 28 Feb 1998 11:33:15 -0800 (PST) From: Brian Handy To: Nate Williams Cc: Cy Schubert - ITSD Open Systems Group , Garrett Wollman , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802281901.MAA10911@mt.sri.com> Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk >> [Xig] >> I've already talked to them about the upcoming release of their new products. >> They've told me that they're dropping support for FreeBSD and focusing on >> Linux because FreeBSD doesn't sell X servers. > >*sigh* I've bought every version of their software they've made, and >paid full price. But, as of late, it appears that they aren't doing so >well per the inability to get through to tech-support, so that may be >why things are being 'cut-back'. Hrmph. I'm almost to a point where it's not so important to me. The one thing I've wanted (and didn't get until 4.1) was "overlay visuals" so that I could have a 24-bit display and still have my 8-bit-only applications work. The other thing that distresses me is are they also ditching Motif support for FreeBSD? Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 11:44:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10931 for freebsd-security-outgoing; Sat, 28 Feb 1998 11:44:28 -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 LAA10926 for ; Sat, 28 Feb 1998 11:44:23 -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 MAA08453; Sat, 28 Feb 1998 12:44:15 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA11031; Sat, 28 Feb 1998 12:44:13 -0700 Date: Sat, 28 Feb 1998 12:44:13 -0700 Message-Id: <199802281944.MAA11031@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Handy Cc: Nate Williams , Cy Schubert - ITSD Open Systems Group , Garrett Wollman , freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: References: <199802281901.MAA10911@mt.sri.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > >> [Xig] > >> I've already talked to them about the upcoming release of their new products. > >> They've told me that they're dropping support for FreeBSD and focusing on > >> Linux because FreeBSD doesn't sell X servers. > > > >*sigh* I've bought every version of their software they've made, and > >paid full price. But, as of late, it appears that they aren't doing so > >well per the inability to get through to tech-support, so that may be > >why things are being 'cut-back'. > > Hrmph. I'm almost to a point where it's not so important to me. The one > thing I've wanted (and didn't get until 4.1) was "overlay visuals" so that > I could have a 24-bit display and still have my 8-bit-only applications > work. BTW, visuals are known to be buggy in 4.1 on our cards (MM-II). I just got them admit that after a month of whining. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 11:53:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12175 for freebsd-security-outgoing; Sat, 28 Feb 1998 11:53:57 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12153 for ; Sat, 28 Feb 1998 11:53:52 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id LAA25341; (8.8.8/RDY) Sat, 28 Feb 1998 11:53:49 -0800 (PST) Message-Id: <199802281953.LAA25341@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802281833.NAA13156@khavrinen.lcs.mit.edu> from Garrett Wollman at "Feb 28, 98 01:33:18 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sat, 28 Feb 1998 11:53:49 -0800 (PST) Cc: dima@best.net, 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+ 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 Garrett Wollman writes: > < > > This is not entirely correct. Take a look at OpenBSD's /etc/rc.securelevel. > > Everything that shoudl have write access to /dev/*mem should be started > > before securelevel is bumbed. > > And then all you have to do is compromise one of those programs... > > There is a legitimate purpose for starting programs that early, but I > don't think running an insecure X server is one of them. Well, please define "insecure X server". Personaly, I don't know about any security bugs in it. > > -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 > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 11:56:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12621 for freebsd-security-outgoing; Sat, 28 Feb 1998 11:56:43 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12605 for ; Sat, 28 Feb 1998 11:56:36 -0800 (PST) (envelope-from dima@burka.rdy.com) Received: by burka.rdy.com id LAA25370; (8.8.8/RDY) Sat, 28 Feb 1998 11:56:26 -0800 (PST) Message-Id: <199802281956.LAA25370@burka.rdy.com> Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199802281944.MAA11031@mt.sri.com> from Nate Williams at "Feb 28, 98 12:44:13 pm" To: nate@mt.sri.com (Nate Williams) Date: Sat, 28 Feb 1998 11:56:26 -0800 (PST) Cc: handy@sag.space.lockheed.com, nate@mt.sri.com, cschuber@uumail.gov.bc.ca, wollman@khavrinen.lcs.mit.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+ 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 Nate Williams writes: > > >> [Xig] > > > >> I've already talked to them about the upcoming release of their new products. > > >> They've told me that they're dropping support for FreeBSD and focusing on > > >> Linux because FreeBSD doesn't sell X servers. > > > > > >*sigh* I've bought every version of their software they've made, and > > >paid full price. But, as of late, it appears that they aren't doing so > > >well per the inability to get through to tech-support, so that may be > > >why things are being 'cut-back'. > > > > Hrmph. I'm almost to a point where it's not so important to me. The one > > thing I've wanted (and didn't get until 4.1) was "overlay visuals" so that > > I could have a 24-bit display and still have my 8-bit-only applications > > work. > > BTW, visuals are known to be buggy in 4.1 on our cards (MM-II). I just > got them admit that after a month of whining. This is not the only problem with v4.1. It incorrectly displays some of the bold fonts when using with CDE. > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 12:22:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15727 for freebsd-security-outgoing; Sat, 28 Feb 1998 12:22:27 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gw.wmich.edu (gw.wmich.edu [141.218.1.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15716 for ; Sat, 28 Feb 1998 12:22:24 -0800 (PST) (envelope-from x96matteson@wmich.edu) Received: from eeyore.cc.wmich.edu (PMDF_BATCH@eeyore.cc.wmich.edu [141.218.20.103]) by gw.wmich.edu (8.8.8/8.8.8) with ESMTP id PAA09342; Sat, 28 Feb 1998 15:22:06 -0500 (EST) Received: from wmich.edu ("port 1043"@pm135-07.dialip.mich.net) by wmich.edu (PMDF V5.1-10 #17195) with ESMTP id <01IU4994Q4GK8WVYUT@wmich.edu>; Sat, 28 Feb 1998 15:22:04 EST Date: Sat, 28 Feb 1998 15:26:56 -0500 From: Ryan Matteson Subject: (no subject) To: "Jordan K. Hubbard" Cc: Cy Schubert - ITSD Open Systems Group , freebsd-security@FreeBSD.ORG Message-id: <34F87310.3F5DC01D@wmich.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.04 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <6819.888650361@time.cdrom.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 16:16:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09764 for freebsd-security-outgoing; Sat, 28 Feb 1998 16:16:01 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09740 for ; Sat, 28 Feb 1998 16:15:52 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id QAA06455; Sat, 28 Feb 1998 16:12:19 -0800 (PST) Message-Id: <199803010012.QAA06455@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dima@best.net cc: nate@mt.sri.com (Nate Williams), handy@sag.space.lockheed.com, cschuber@uumail.gov.bc.ca, wollman@khavrinen.lcs.mit.edu, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-reply-to: Your message of "Sat, 28 Feb 1998 11:56:26 PST." <199802281956.LAA25370@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Feb 1998 16:12:19 -0800 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > BTW, visuals are known to be buggy in 4.1 on our cards (MM-II). I just > > got them admit that after a month of whining. > > This is not the only problem with v4.1. It incorrectly displays some of the > bold fonts when using with CDE. It appears to have a number of font rendering problems; I get random font garbage (mispositioned characters, noise data in characters, etc.) again on an MM-II. They also decided to start shipping more than just the server with 4.1; installing it "out of the box" onto a 3.0 machine is a Really Bad Idea. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 16:36:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11395 for freebsd-security-outgoing; Sat, 28 Feb 1998 16:36:22 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA11376 for ; Sat, 28 Feb 1998 16:36:17 -0800 (PST) (envelope-from handy@sag.space.lockheed.com) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA02121; Sat, 28 Feb 1998 16:34:00 -0800 Date: Sat, 28 Feb 1998 16:34:00 -0800 (PST) From: Brian Handy To: Mike Smith Cc: dima@best.net, Nate Williams , cschuber@uumail.gov.bc.ca, wollman@khavrinen.lcs.mit.edu, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD Security Advisory: mmap() Problem In-Reply-To: <199803010012.QAA06455@dingo.cdrom.com> Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 28 Feb 1998, Mike Smith wrote: >>> [Xig's MM-II] > >It appears to have a number of font rendering problems; I get random >font garbage (mispositioned characters, noise data in characters, etc.) >again on an MM-II. Interestingly...I mentioned this to Nate offline. IDL has a "graphics_times" benchmark you can run, I'm sure Mike is familiar with it. I ran it to compare the Xig server to the XSuSe server to an SGI O/2. Without going into the details, the final results were the XSuSE server ran in 22 seconds, the Xig in 13.5 and the O/2 in around 7.5. The greatest difference was in this test called "Hardware Fonts". Both the XSuSE and Xig servers spent around 7 seconds in this section alone. What it does is print random sequences of characters all over the display window. The O/2 kicked it out in 0.15 seconds. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 19:09:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29512 for freebsd-security-outgoing; Sat, 28 Feb 1998 19:09:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29441 for ; Sat, 28 Feb 1998 19:08:44 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id EAA28051 for freebsd-security@FreeBSD.ORG; Sun, 1 Mar 1998 04:08:35 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id CAA25516; Sun, 1 Mar 1998 02:51:12 +0100 (CET) (envelope-from roberto) Message-ID: <19980301025112.A25490@keltia.freenix.fr> Date: Sun, 1 Mar 1998 02:51:12 +0100 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: crypto tunnel - international Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <13614.888689218@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.4i In-Reply-To: <13614.888689218@time.cdrom.com>; from Jordan K. Hubbard on Sat, Feb 28, 1998 at 10:06:58AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4088 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk According to Jordan K. Hubbard: > I really don't see what OpenBSD can export which we cannot and it would > be really nifty if you could give us details on what is missing from > FreeBSD. They have IPsec in /usr/src along with Photuris (key management). 445 [2:48] roberto@keltia:openbsd/src> ls sbin/ip ipf/ ipfstat/ ipnat/ ipsec/ 445 [2:48] roberto@keltia:openbsd/src> ls sbin/ipsec/ Makefile,v pfr/ sah/ sespmd5/ startkey/ Makefile.inc,v photurisd/ sahhmac/ sgrp/ delspi/ rt/ sesp/ shahmac/ ipsecadm/ rtdelete/ sesp3md5/ si4/ I don't know how usable is it though :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #1: Sun Feb 22 00:44:29 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 21:05:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA10688 for freebsd-security-outgoing; Sat, 28 Feb 1998 21:05:14 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA10674 for ; Sat, 28 Feb 1998 21:05:07 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id AAA14534; Sun, 1 Mar 1998 00:04:24 -0500 (EST) Date: Sun, 1 Mar 1998 00:01:55 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Ollivier Robert cc: freebsd-security@FreeBSD.ORG Subject: Re: crypto tunnel - international In-Reply-To: <19980301025112.A25490@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 1 Mar 1998, Ollivier Robert wrote: > According to Jordan K. Hubbard: > > I really don't see what OpenBSD can export which we cannot and it would > > be really nifty if you could give us details on what is missing from > > FreeBSD. > > They have IPsec in /usr/src along with Photuris (key management). IPsec sounds great, but I was under the impression that Photuris was largely not happening, and that ISA-KMP was being used. I'm a little behind in the IPsec world, but the impression I last had was "ISA-KMP/Oakley: feature-poor, here today, and well-presented; Photuris: does everything, not here today, and with a very split design base because of disagreements in the working group" or something. I was also under the impression that the FreeBSD reason for holding out in having an IPsec implementation shipped with the system was that the plethora of implementations out there had largely not matured, and we would wait for a clear winner. Again, I haven't followed IPsec closely at all -- DNSsec and distributed file system security (Coda, etc) are really my areas of interest :). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message From owner-freebsd-security Sat Feb 28 21:31:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14685 for freebsd-security-outgoing; Sat, 28 Feb 1998 21:31:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from u2.todiefor.com (chris@u2.todiefor.com [209.57.203.231]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14673 for ; Sat, 28 Feb 1998 21:30:50 -0800 (PST) (envelope-from chris@u2.todiefor.com) Received: from localhost (chris@localhost) by u2.todiefor.com (8.8.8/8.8.8) with SMTP id HAA02907 for ; Sat, 28 Feb 1998 07:30:51 -0500 (EST) (envelope-from chris@u2.todiefor.com) Date: Sat, 28 Feb 1998 07:30:51 -0500 (EST) From: Christopher J Ceska To: freebsd-security@FreeBSD.ORG Subject: Question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk What would be a good method to have two servers run the same passwd file? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 21:51:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20279 for freebsd-security-outgoing; Sat, 28 Feb 1998 21:51:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kjsl.com (Limpia.KJSL.COM [198.137.202.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20240 for ; Sat, 28 Feb 1998 21:51:48 -0800 (PST) (envelope-from javier@kjsl.com) Received: (from javier@localhost) by kjsl.com (8.8.5/8.8.5) id VAA18342; Sat, 28 Feb 1998 21:51:46 -0800 (PST) Date: Sat, 28 Feb 1998 21:51:46 -0800 (PST) Message-Id: <199803010551.VAA18342@kjsl.com> From: Javier Henderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Christopher J Ceska Cc: freebsd-security@FreeBSD.ORG Subject: Question In-Reply-To: References: X-Mailer: VM 6.33 under Emacs 19.34.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Christopher J Ceska writes: > What would be a good method to have two servers run the same passwd file? Run VMS? Oh, sorry, wrong crowd. Seriously, has anyone thought about writing something equivalent to VMS clusters? This is not a veiled attempt at starting a my-os-is-better-than-yours war. Maybe something useful could come of an educated discussion of the advantages of VMS clusters. -jav, VMS geek, FreeBSD apprentice To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 22:22:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA25810 for freebsd-security-outgoing; Sat, 28 Feb 1998 22:22:03 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA25767 for ; Sat, 28 Feb 1998 22:21:44 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id BAA15412; Sun, 1 Mar 1998 01:21:34 -0500 (EST) Date: Sun, 1 Mar 1998 01:19:05 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Javier Henderson cc: Christopher J Ceska , freebsd-security@FreeBSD.ORG Subject: Re: Question In-Reply-To: <199803010551.VAA18342@kjsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 28 Feb 1998, Javier Henderson wrote: > > What would be a good method to have two servers run the same passwd file? > > Run VMS? > > Oh, sorry, wrong crowd. > > Seriously, has anyone thought about writing something > equivalent to VMS clusters? This is not a veiled attempt at starting a > my-os-is-better-than-yours war. Maybe something useful could come of > an educated discussion of the advantages of VMS clusters. Jav, I'm not familiar with the VMS clustering behavior -- what services does it provide? NIS can certainly provide an (insecure) password/etc sharing option under FreeBSD, although personally I make use of Kerberos and use a distributed file system for moving password files/etc around. I have always found the concept of Hesiod appealing -- especially now that DNSsec seems to be working out. The Athena secure DNS (via kerberos) concept never did much for me, though. None of these solutions are particularly transparent, though -- perhaps having a shared /etc/usefulfiles and working NFS locking (and a few other snippets) would be a reasonable answer for small-scale clustering. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message From owner-freebsd-security Sat Feb 28 22:44:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA29829 for freebsd-security-outgoing; Sat, 28 Feb 1998 22:44:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kjsl.com (Limpia.KJSL.COM [198.137.202.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA29816 for ; Sat, 28 Feb 1998 22:44:32 -0800 (PST) (envelope-from javier@kjsl.com) Received: (from javier@localhost) by kjsl.com (8.8.5/8.8.5) id WAA18503; Sat, 28 Feb 1998 22:44:25 -0800 (PST) Date: Sat, 28 Feb 1998 22:44:25 -0800 (PST) Message-Id: <199803010644.WAA18503@kjsl.com> From: Javier Henderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Javier Henderson , Christopher J Ceska , freebsd-security@FreeBSD.ORG Subject: Re: Question In-Reply-To: References: <199803010551.VAA18342@kjsl.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Robert Watson writes: > I'm not familiar with the VMS clustering behavior -- what services does it > provide? You can mount disk drives across the clusters. There's a distributed lock manager, which is what allows the transparent sharing of resources across the cluster members. Most clusters have a shared authorization file, though you can have node-specific files as well. You can have multiple hosts and disk drives on the same SCSI bus, and even if one node crashes, the remaining nodes' access to the disk drives remains undisturbed in most cases. Any node can also serve disk drives to the cluster, though of course those drives would go away if the node crashes. That's in a very small nutshell. There's lots more. -jav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 23:03:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA02321 for freebsd-security-outgoing; Sat, 28 Feb 1998 23:03:27 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA02316 for ; Sat, 28 Feb 1998 23:03:20 -0800 (PST) (envelope-from brian@shell.firehouse.net) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id CAA29666; Sun, 1 Mar 1998 02:03:10 -0500 (EST) Date: Sun, 1 Mar 1998 02:03:08 -0500 (EST) From: Brian Mitchell To: Javier Henderson cc: Christopher J Ceska , freebsd-security@FreeBSD.ORG Subject: Re: Question In-Reply-To: <199803010551.VAA18342@kjsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 28 Feb 1998, Javier Henderson wrote: > Christopher J Ceska writes: > > > What would be a good method to have two servers run the same passwd file? > > Run VMS? > > Oh, sorry, wrong crowd. > > Seriously, has anyone thought about writing something > equivalent to VMS clusters? This is not a veiled attempt at starting a > my-os-is-better-than-yours war. Maybe something useful could come of > an educated discussion of the advantages of VMS clusters. well, kinda overkill when all the original posted needed is nis. To each his own, I suppose -- even delusional vms freaks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 23:18:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05620 for freebsd-security-outgoing; Sat, 28 Feb 1998 23:18:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05614 for ; Sat, 28 Feb 1998 23:18:49 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id CAA16116; Sun, 1 Mar 1998 02:18:41 -0500 (EST) Date: Sun, 1 Mar 1998 02:16:09 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Javier Henderson cc: Christopher J Ceska , freebsd-security@FreeBSD.ORG Subject: Re: Question In-Reply-To: <199803010644.WAA18503@kjsl.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sat, 28 Feb 1998, Javier Henderson wrote: > Robert Watson writes: > > > I'm not familiar with the VMS clustering behavior -- what services does it > > provide? > > You can mount disk drives across the clusters. There's a > distributed lock manager, which is what allows the transparent sharing > of resources across the cluster members. What resources? This sounds like it would go beyond just distributed file sharing/management, but given my lack of experience, I hesitate to assume that. When Terry's NFS locking patches are in place, and the client/server side rpc.lockd/statd stuff works, NFS will be able to provide at least some subset of the file-system locking behavior. > Most clusters have a shared authorization file, though you can > have node-specific files as well. Authorization or Authentication (or both? :). I.e., is this more a concept of a distributed master.passwd/group as in NIS or a distributed file system arrangement, or something a little more broad? > You can have multiple hosts and disk drives on the same SCSI > bus, and even if one node crashes, the remaining nodes' access to the > disk drives remains undisturbed in most cases. Any node can also serve > disk drives to the cluster, though of course those drives would go > away if the node crashes. > > That's in a very small nutshell. There's lots more. There has been discussion of this SCSI behavior on FreeBSD-SCSI and elsewhere recently. I believe the conclusion reached was that most easy solutions to the problem are definitely hacks, etc. The shared SCSI bus sounds like an interestin arrangement that would be very nice in a fault-tolerant/highly-available system, but sounds like there would be quite complicated arbitration issues for buses/devices. Are there distributed process facilities to allow farming of processes? A nice LPC/RPC transparency system is always fun. :) I seem to recall a group in Israel was doing some work on something like that on BSD/OS a year or two ago, but I can't remember the specifics. A cool clustering system for a BSD would be very nice to have -- on any of these levels. They tend to involve a lot of expensive research, though, I understand. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message From owner-freebsd-security Sat Feb 28 23:21:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA06495 for freebsd-security-outgoing; Sat, 28 Feb 1998 23:21:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kjsl.com (Limpia.KJSL.COM [198.137.202.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06376 for ; Sat, 28 Feb 1998 23:21:15 -0800 (PST) (envelope-from javier@kjsl.com) Received: (from javier@localhost) by kjsl.com (8.8.5/8.8.5) id XAA18606; Sat, 28 Feb 1998 23:21:06 -0800 (PST) Date: Sat, 28 Feb 1998 23:21:06 -0800 (PST) Message-Id: <199803010721.XAA18606@kjsl.com> From: Javier Henderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Mitchell Cc: Javier Henderson , Christopher J Ceska , freebsd-security@FreeBSD.ORG Subject: Re: Question In-Reply-To: References: <199803010551.VAA18342@kjsl.com> X-Mailer: VM 6.33 under Emacs 19.34.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Brian Mitchell writes: > well, kinda overkill when all the original posted needed is nis. To each > his own, I suppose -- even delusional vms freaks. I know what the original question was, and as I said on my posting, I was trying to get a discussion started, not an OS war, as you're implying. -jav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat Feb 28 23:23:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA06924 for freebsd-security-outgoing; Sat, 28 Feb 1998 23:23:59 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA06917 for ; Sat, 28 Feb 1998 23:23:54 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id CAA16221; Sun, 1 Mar 1998 02:23:44 -0500 (EST) Date: Sun, 1 Mar 1998 02:21:12 -0500 (EST) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Christopher J Ceska cc: Javier Henderson , freebsd-security@FreeBSD.ORG, Brian Mitchell Subject: Re: Question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 1 Mar 1998, Brian Mitchell wrote: > > Christopher J Ceska writes: > > > > > What would be a good method to have two servers run the same passwd file? > > > > Run VMS? > > well, kinda overkill when all the original posted needed is nis. To each > his own, I suppose -- even delusional vms freaks. So Chris, leaving aside this stuff, you really want to take a look at the yp(4) manpage for one possible way to do what you desire. This is the Yellowpages/NIS service as thought of (I believe) by Sun -- it provides distributed password, group files, as well as local modifications of them specified in a wild-cardy kind of way. Programs like passwd and chfn know how to deal with it, so it doesn't have the implementation mess from the point of view of users that a distributed file system solution can have. On the other hand, there are some security issues involved (such as a lack of cryptography support -- run this on trusted lans only). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ 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 security" in the body of the message