From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26531 invoked from network); 29 Jan 2023 19:40:06 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 29 Jan 2023 19:40:06 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 0AACA42591; Mon, 30 Jan 2023 05:39:59 +1000 (AEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by minnie.tuhs.org (Postfix) with ESMTPS id 22BDD42590 for ; Mon, 30 Jan 2023 05:39:56 +1000 (AEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 896735C00DC for ; Sun, 29 Jan 2023 14:39:55 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 29 Jan 2023 14:39:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ronnatalie.com; h=cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:reply-to:sender:subject:subject:to:to; s= fm2; t=1675021195; x=1675107595; bh=/sAqXuhVbkaDwIK4wYgLMGiy/qGP 1Dc2OM628SikbdY=; b=g0gIWxwe1VZemwYSM9y2/mYrlAIw3BavTLcPEhFkCWwm TxnXvto5RG9zGuekCB0c1RMm0P3LmSqspkQELFSrPwZXZYyNxzfKXXFxuS/ky5gz OHrlm4SnGJDBVQjgBsvVadiRyY1TUuK+EHSpwIjqJmsVTKRlgKo0g6F/dC2Btfnm uS+r5qkwtYHTRSLAqEbTz0vFLCe0gOw+cwmOu9obrJpsCZi92+x2+WvBejk8N/ha KD6H+sOt8gVTFl3WBBG/laz1CV7/Pj2eyWG1x6+Sj+FHXr3JrfI/s9/PNi3478ps KbglNE0Dpbh2Erlzrwp+WRKUxc9u8o45Ckw8X6L5Gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1675021195; x=1675107595; bh=/sAqXuhVbkaDwIK4wYgLMGiy/qGP1Dc2OM6 28SikbdY=; b=nof6MVYmsKe6Li3z7jcQCfxaFg/k9czIjYfVX/AuI4r4Lvqtdu2 xAN0kVnBC2IevFYZeiZkVlqK48kCGQTI69oSk6Kxf7suBk+JAXm5BV98KIxkyjQL adC7UTCPaCRp6Ulr9GGdbJKXV2DRXOZqieXB0zOiJLcZiSNwnOaWO7QXGcBD+rlw qF/KnGzgQp7P3DoGb67Pww0GWu+gsFvSa0In/yLbsBBB79CzB61x4HCw95cRgFnG jZqisLE2CHaSQctdsbs1UDl031dIPhHj80kEY4/Ao8TdDcnBkt41JrPZQ9IanMVg indRSwkt+yrSfF+9/8xFgTq9G27j+YCDNkA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeftddguddvlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfhrfgggtgesrgdtre ertderjeenucfhrhhomhepfdftohhnucfprghtrghlihgvfdcuoehrohhnsehrohhnnhgr thgrlhhivgdrtghomheqnecuggftrfgrthhtvghrnhepfedvudeikefgjeefheduudefke duueefveffvdeiiefgfefggedthfehgefhjefgnecuffhomhgrihhnpehsuhhpvghrsghl ohgtkhdrfihtfhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehrohhnsehrohhnnhgrthgrlhhivgdrtghomh X-ME-Proxy: Feedback-ID: iaba146ad:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 29 Jan 2023 14:39:55 -0500 (EST) From: "Ron Natalie" To: "The Eunuchs Hysterical Society" Date: Sun, 29 Jan 2023 19:39:54 +0000 Message-Id: User-Agent: eM_Client/9.2.1222.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB254C0197-BFC3-4002-B0A0-6AE16626C9E0" Message-ID-Hash: YMBLHCDXP3YZ5KZS4FKGVHNFIIWSUKZV X-Message-ID-Hash: YMBLHCDXP3YZ5KZS4FKGVHNFIIWSUKZV X-MailFrom: ron@ronnatalie.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Reply-To: Ron Natalie Subject: [TUHS] File descriptor fun and games (setuid) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --------=_MB254C0197-BFC3-4002-B0A0-6AE16626C9E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Another of Ron=E2=80=99s historical diversions that came to mind. Most of you probably know of various exploits that can happen now with=20 setuid programs, but this was pretty loose back in the early days. I=20 was a budding system programmer back in 1979 at Johns Hopkins. Back=20 then hacking the UNIX system was generally considered as sport by the=20 students. The few of us who were on the admin side spent a lot of time=20 figuring out how it had happened and running around fixing it. The first one found was the fact that the =E2=80=9Csu=E2=80=9D program deci= ded that if=20 it couldn=E2=80=99t open /etc/passwd for some reason, things must be really = bad=20 and the invoker should be given a root shell anyhow. The common=20 exploit would be to open all the available file descriptors (16 I think=20 back then) and thus there wasn=E2=80=99t one available. That was fixed be= fore=20 my time at JHU (but I used it on other systems). One day one of the guys who was shuffling stuff back and forth between=20 MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05=20 file system corrupted. I found that the superblock was corrupted. =20 With some painstaking comparison to another RK05 superblock, I=20 reconstituded it enough to run icheck -s etc.. and get the thing back. =20 What I had found was that the output of the =E2=80=9Cmount=E2=80=9D command = had been=20 written on the superblock. WTF? I said, how did this happen. =20 Interrogating the user yielded the fact that he decided he didn=E2=80=99t w= ant=20 to see the mount output so he closed file descriptor one prior to=20 invoking mount. Still it seemed odd. At JHU we had lots of people with removable packs, so someone had=20 modified mount to run setuid (with the provision of only allowing=20 certain devices to be mounted certain places). At his point we had=20 started with the idea of putting volume labels in the superblock to=20 identify the pack being mounted. Rather than put the stuff in the=20 kernel right away, Mike Muuss just hacked reading it from the super=20 block in the usermode mount program so that he could put the volume=20 label in /etc/mtab. Now you can probably see where this is headed. =20 It opens up the disk, seeks to the pack label in the superblock and=20 reads it (for somereason things were opened RW). Then the output goes=20 to file descriptor 1 which just happens to be further in the superblock. I figured this out. Fixed it and told Mike about it. I told him=20 there were probably other setuid programs around that had the problem=20 and asked if it was OK if I hacked on things (at the time I yet was not=20 trusted with the root password). He told me to go ahead, knock=20 yourself out. Well I spent the evening closing various combinations of file=20 descriptors and invoking setuid programs. I found a few more and noted=20 them. After a while I got tired and went home. The next day I came in and looked through our paper logbook that we=20 filled out anytime the machine was shutdown (or crashed). There was a=20 note from two of the other system admins saying they had shut the system=20 down to rebuild the accounting file (this was essentially the shadow=20 password file and some additional per-user information not stored in=20 /etc/passwd). The first 8 bytes were corrupted. Oh, I say, I think=20 I might know how that happened. Yeah, we thought you might. Your=20 user name was what was written over the root entry in the file. The=20 passwd changing program was one of the ones I tested, but I hadn=E2=80=99t= =20 noticed any ill-effects for it at the time. --------=_MB254C0197-BFC3-4002-B0A0-6AE16626C9E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0AAnother o= f Ron=E2=80=99s historical diversions that came to mind.

Most of you probably know of various exploits that can happen now with s= etuid programs, but this was pretty loose back in the early days. =C2=A0 I= was a budding system programmer back in 1979 at Johns Hopkins. =C2=A0 Back= then hacking the UNIX system was generally considered as sport by the stude= nts. =C2=A0 The few of us who were on the admin side spent a lot of time fi= guring out how it had happened and running around fixing it.
The first one found was the fact that the =E2=80=9Csu=E2=80=9D = program decided that if it couldn=E2=80=99t open /etc/passwd for some reas= on, things must be really bad and the invoker should be given a root shell= anyhow. =C2=A0 The common exploit would be to open all the available file d= escriptors (16 I think back then) and thus there wasn=E2=80=99t one availab= le. =C2=A0 That was fixed before my time at JHU (but I used it on other sys= tems).

One day one of the guys who was shuffling = stuff back and forth between MiniUnix on a PDP-11/40 and our main 11/45 UN= IX came to me with his RK05 file system corrupted. =C2=A0 I found that the= superblock was corrupted. =C2=A0 With some painstaking comparison to anothe= r RK05 superblock, I reconstituded it enough to run icheck -s etc.. and get = the thing back. =C2=A0 What I had found was that the output of the =E2=80= =9Cmount=E2=80=9D command had been written on the superblock. =C2=A0 WTF? = =C2=A0I said, how did this happen. =C2=A0 Interrogating the user yielded t= he fact that he decided he didn=E2=80=99t want to see the mount output so h= e closed file descriptor one prior to invoking mount. =C2=A0 Still it seeme= d odd.

At JHU we had lots of people with removab= le packs, so someone had modified mount to run setuid (with the provision o= f only allowing certain devices to be mounted certain places). =C2=A0 At hi= s point we had started with the idea of putting volume labels in the superb= lock to identify the pack being mounted. =C2=A0 =C2=A0Rather than put the s= tuff in the kernel right away, Mike Muuss just hacked reading it from the s= uper block in the usermode mount program so that he could put the volume la= bel in /etc/mtab. =C2=A0 Now you can probably see where this is headed. =C2= =A0 It opens up the disk, seeks to the pack label in the superblock and rea= ds it (for somereason things were opened RW). =C2=A0Then the output goes to = file descriptor 1 which just happens to be further in the superblock.

I figured this out. =C2=A0 Fixed it and told Mike ab= out it. =C2=A0 I told him there were probably other setuid programs around= that had the problem and asked if it was OK if I hacked on things (at the t= ime I yet was not trusted with the root password). =C2=A0 He told me to go= ahead, knock yourself out.

Well I spent the even= ing closing various combinations of file descriptors and invoking setuid pr= ograms. =C2=A0 I found a few more and noted them. =C2=A0 =C2=A0After a whil= e I got tired and went home.

The next day I came = in and looked through our paper logbook that we filled out anytime the mac= hine was shutdown (or crashed). =C2=A0 There was a note from two of the oth= er system admins saying they had shut the system down to rebuild the accoun= ting file (this was essentially the shadow password file and some additiona= l per-user information not stored in /etc/passwd). =C2=A0 The first 8 bytes = were corrupted. =C2=A0 =C2=A0Oh, I say, I think I might know how that happ= ened. =C2=A0 Yeah, we thought you might. =C2=A0 Your user name was what was = written over the root entry in the file. =C2=A0 =C2=A0The passwd changing= program was one of the ones I tested, but I hadn=E2=80=99t noticed any ill-= effects for it at the time.

--------=_MB254C0197-BFC3-4002-B0A0-6AE16626C9E0--