From owner-freebsd-hackers Tue Oct 24 17:22:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13059 for hackers-outgoing; Tue, 24 Oct 1995 17:22:18 -0700 Received: from ns1.win.net (ns1.win.net [204.215.209.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13053 for ; Tue, 24 Oct 1995 17:22:16 -0700 Received: (from bugs@localhost) by ns1.win.net (8.6.12/8.6.9) id UAA15337 for hackers@freebsd.org; Tue, 24 Oct 1995 20:26:47 -0400 From: Mark Hittinger Message-Id: <199510250026.UAA15337@ns1.win.net> Subject: Re: ld.so, LD_NOSTD_PATH, and suid/sgid programs (fwd) To: hackers@freebsd.org Date: Tue, 24 Oct 1995 20:26:46 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1340 Sender: owner-hackers@freebsd.org Precedence: bulk On Tops-10 (an olden day DEC OS) there was a hack called the "meddle bit". Programs that ran with "JACCT" (suid root) were allowed to load shareable segements in the default way. When Tops-10 detected an unusual condition during the execution of such a program it set a bit in the process data called "the meddle bit". When loading a shareable image, if this bit was set then changes in path were ignored. When the "meddle bit" was set, a program which would normally be allowed to write in a shared memory segment would be refused. Anyplace where the OS developers felt something weird was going on they would just turn on "meddle". As is usual with these sorts of things I found something that fell through the cracks. Each process could load its own pagefault handler. I discovered that I could load my own page fault handler and gain write access to shared images. It was easy to fix, just turn on meddle if a non-default page fault handler was loaded. No programs broke, no procedures changed. The fix for telnetd seems too concentrated to me, it seems that we are grappling with a much broader problem that may pop up elsewhere. Perhaps we could prevent SUID images from connecting with shared libraries that are not owned by root/bin? Regards, Mark Hittinger Internet Manager WinNET Communications, Inc. bugs@win.net