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.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,URIBL_CSS_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31386 invoked from network); 30 Jan 2023 00:47:40 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 00:47:40 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 246AA425AC; Mon, 30 Jan 2023 10:47:02 +1000 (AEST) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by minnie.tuhs.org (Postfix) with ESMTPS id 3BC82425AB for ; Mon, 30 Jan 2023 10:46:56 +1000 (AEST) Received: by mail-ej1-f52.google.com with SMTP id gr7so2952750ejb.5 for ; Sun, 29 Jan 2023 16:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R8hCjlKI5UdfvFTYcimlJ/ybrWJaSdD7tpd1CS/r6UU=; b=ESbPx60cVAfKTr0cVkBg5i3JMxOJLe1FgOt1QuS3lYuPkXRF6eVhZOuocrmt84HI+V aeGmL3vBQ6UcjacdJndyQfWr3IfXHvF/6Pt37q2HXEog+Jr/6l5paC5XPPLZXc8vcLzm DAnZCCP648WNkiCkIdiQFmJp0t7b/H6WS6w1Qz7ccShAYu5AH8HvU0LizKg9Q+AiyzOm cvVWYBnGRlmkBvftpERG2on5vhuQtVwZQQVRcEuJj2oqzUdA1e+rzLmFQcGAnsdzkpSM SezVFDqtoBJwTHl1uyRnY1Qpzug++bmTsQL+/aoRJVN0MBih36Y9cyOQHTSD1Ji0LF0R 5xeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R8hCjlKI5UdfvFTYcimlJ/ybrWJaSdD7tpd1CS/r6UU=; b=N9sQxnGbK6ooKS0kKEEprL+C7uxaciNLKQtZvKC0RjXkR50Swpo3XLSOJTO+oS364W xTt6KMgAZeRInRTlYvGcBHOMcpOPd5qOPVrPuPNLBZh7LucICcWKQQUBEdM0C7g8Wncx UJOhhKMl5VlKdBI0PfZ8KPxkRcm4LMCAZ5kHppUWHTe9A/O0BmkWWzadjqjcF35Ui+Bz blXMgAwBijTC4p+WS2yU2P3woW2306HyxIpzRxGJPRqu/fS4Bmg3K8XbQRGakrbr4WT+ 7mUxeC20lCJR6VPUw+9j9iU4uqpbubLZzldpgtImz3DTGN8zYNLLvba6fAfsHaRVecII 9sQw== X-Gm-Message-State: AFqh2kqKC2tt3hu6axIwHM6XWZnvmYPrN71W/qDa0SUH0fjwhRDW5ro7 zlH1F8vGdjkJWYE9E3Q2NRhrWuelA7F7Pp4JZq4TvMA+a+wlEw== X-Google-Smtp-Source: AMrXdXv2c+FaYzoNZ0p6D5ZqKZkIhKWpe482O0K+h7dGbkYaSVUXfWmG+JueLkXZz9SjaioHwipM8To4Gj3WvWrB+gM= X-Received: by 2002:a17:906:7754:b0:86f:2cc2:7028 with SMTP id o20-20020a170906775400b0086f2cc27028mr6881713ejn.133.1675039554496; Sun, 29 Jan 2023 16:45:54 -0800 (PST) MIME-Version: 1.0 References: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> In-Reply-To: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> From: Warner Losh Date: Sun, 29 Jan 2023 17:45:43 -0700 Message-ID: To: Bakul Shah Content-Type: multipart/alternative; boundary="000000000000a17f2d05f37089a5" Message-ID-Hash: Y23UHKFVUWUMJPG2V4YUED4QQRT44H6K X-Message-ID-Hash: Y23UHKFVUWUMJPG2V4YUED4QQRT44H6K X-MailFrom: wlosh@bsdimp.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 CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: 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: --000000000000a17f2d05f37089a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 29, 2023, 3:59 PM Bakul Shah wrote: > Sorry for nitpicking but I don't understand why closing fd 1 *before* > calling mount result in this behavior? Shouldn't a write(1, ...) just fai= l? > Because if it is closed the first open will return 1. And that's also where the printf will go... Warner Anyway, this sounds like a classic case of "the confused deputy". > http://www.cap-lore.com/CapTheory/ConfusedDeputy.html > > Of course, a tighter security design might've made it much more difficult > to apply useful hacks like the one Mike Muus did! > > On Jan 29, 2023, at 11:39 AM, Ron Natalie wrote: > > 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 > setuid programs, but this was pretty loose back in the early days. I wa= s > a budding system programmer back in 1979 at Johns Hopkins. Back then > hacking the UNIX system was generally considered as sport by the students= . > The few of us who were on the admin side spent a lot of time figuring o= ut > 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 de= cided that if it > couldn=E2=80=99t open /etc/passwd for some reason, things must be really = bad and > the invoker should be given a root shell anyhow. The common exploit wou= ld > be to open all the available file descriptors (16 I think back then) and > thus there wasn=E2=80=99t one available. That was fixed before 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 > MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 > file system corrupted. I found that the superblock was corrupted. Wit= h > some painstaking comparison to another RK05 superblock, I reconstituded i= t > enough to run icheck -s etc.. and get the thing back. What I had found > was that the output of the =E2=80=9Cmount=E2=80=9D command had been writt= en on the > superblock. WTF? I said, how did this happen. Interrogating the user > yielded the fact that he decided he didn=E2=80=99t want to see the mount = output so > he closed file descriptor one prior to invoking mount. Still it seemed > odd. > > At JHU we had lots of people with removable packs, so someone had modifie= d > mount to run setuid (with the provision of only allowing certain devices = to > be mounted certain places). At his point we had started with the idea o= f > putting volume labels in the superblock to identify the pack being mounte= d. > Rather than put the stuff in the kernel right away, Mike Muuss just > hacked reading it from the super block in the usermode mount program so > that he could put the volume label in /etc/mtab. Now you can probably s= ee > where this is headed. It opens up the disk, seeks to the pack label in > the superblock and reads it (for somereason things were opened RW). Then > the output goes 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 there > were probably other setuid programs around that had the problem and asked > if it was OK if I hacked on things (at the time I yet was not trusted wit= h > the root password). He told me to go ahead, knock yourself out. > > Well I spent the evening closing various combinations of file descriptors > and invoking setuid programs. I found a few more and noted them. Aft= er > a while I got tired and went home. > > The next day I came in and looked through our paper logbook that we fille= d > out anytime the machine was shutdown (or crashed). There was a note fro= m > two of the other system admins saying they had shut the system down to > rebuild the accounting file (this was essentially the shadow password fil= e > and some additional per-user information not stored in /etc/passwd). Th= e > first 8 bytes were corrupted. Oh, I say, I think I might know how that > happened. Yeah, we thought you might. Your user name was what was > written over the root entry in the file. The passwd changing program w= as > one of the ones I tested, but I hadn=E2=80=99t noticed any ill-effects fo= r it at > the time. > > > --000000000000a17f2d05f37089a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 29, 2023, 3:59 PM Bakul Shah <bakul@iitbombay.org> wrote:
Sorry for nitpicking but I don't understand why closing fd 1 *bef= ore* calling mount result in this behavior? Shouldn't a write(1, ...) j= ust fail?

<= div dir=3D"auto">Because if it is closed the first open will return 1. And = that's also where the printf will go...

Warner=C2=A0

Anyway, this sounds like a classic cas= e of "the confused deputy".

Of course, a tighter security design might've made it much more diff= icult to apply useful hacks like the one Mike Muus did!

=
On Jan 29, 2023, at 11:39 AM, Ron Natalie &l= t;ron@ronnatalie.com> wrote:

Another of Ron=E2=80=99s historical diversion= s that came to mind.

Mo= st of you probably know of various exploits that can happen now with setuid= 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 students. = =C2=A0 The few of us who were on the admin side spent a lot of time figurin= g 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 reason, 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 descriptors (16 I think back then) and thus there wasn= =E2=80=99t one available. =C2=A0 That was fixed before 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= MiniUnix on a PDP-11/40 and our main 11/45 UNIX came to me with his RK05 f= ile system corrupted. =C2=A0 I found that the superblock was corrupted. =C2= =A0 With some painstaking comparison to another RK05 superblock, I reconsti= tuded 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=A0 I said, how did this happ= en. =C2=A0 Interrogating the user yielded the fact that he decided he didn= =E2=80=99t want to see the mount output so he closed file descriptor one pr= ior to invoking mount. =C2=A0 Still it seemed odd.
<= br>
At JHU we had lots of people with removable pack= s, so someone had modified mount to run setuid (with the provision of only = allowing certain devices to be mounted certain places). =C2=A0 At his point= we had started with the idea of putting volume labels in the superblock to= identify the pack being mounted. =C2=A0 =C2=A0Rather than put the stuff in= the kernel right away, Mike Muuss just hacked reading it from the super bl= ock in the usermode mount program so that he could put the volume label 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 reads it (= for somereason things were opened RW).=C2=A0 Then the output goes to file d= escriptor 1 which just happens to be further in the superblock.

I figured this out. =C2=A0 Fixed it= and told Mike about 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 time I yet was not trusted with the root password). =C2=A0 = He told me to go ahead, knock yourself out.

Well I spent the evening closing various combinations o= f file descriptors and invoking setuid programs. =C2=A0 I found a few more = and noted them. =C2=A0 =C2=A0After a while I got tired and went home.
=

The next day I came in and lo= oked through our paper logbook that we filled out anytime the machine was s= hutdown (or crashed). =C2=A0 There was a note from two of the other system = admins saying they had shut the system down to rebuild the accounting file = (this was essentially the shadow password file and some additional per-user= information not stored in /etc/passwd). =C2=A0 The first 8 bytes were corr= upted. =C2=A0 =C2=A0Oh, I say, I think I might know how that happened. =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 w= as one of the ones I tested, but I hadn=E2=80=99t noticed any ill-effects f= or it at the time.

--000000000000a17f2d05f37089a5--