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 18694 invoked from network); 29 Jan 2023 22:59:43 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 29 Jan 2023 22:59:43 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 18DD342590; Mon, 30 Jan 2023 08:59:18 +1000 (AEST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by minnie.tuhs.org (Postfix) with ESMTPS id 921AF4258F for ; Mon, 30 Jan 2023 08:59:08 +1000 (AEST) Received: by mail-io1-f49.google.com with SMTP id e2so1173959iot.11 for ; Sun, 29 Jan 2023 14:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=eaUGzmt3xycfTKtI6/ROCjXspTLvIjGYDY+g5bc9qVs=; b=gVWLbZ5oyuIcftzFq5ejrL7LnXXbiXAA0v/cBf+u5oI1BsIbfwaLj+Z/O/AZKGdLXo 9Joo3xaS4qS+q0xqEdclTpwDGoQ9aS/7cfmHkqDH3awsuufbrJHgsy6R3cFSFqD2hecC xkVS3FLIpJh8fC9Iac32HIgVm75S+wyfP8Hs1b0RTeUxjK2DXmU+iU0QDQiYYdYRBCZs flxeBDH0aF0IO9vEt3uoPXtWNgRItVybRxPov5qlQHvSPYye8hR/wvIVeZLTHeKet4s+ UPp7hjNQStQu8qnv1FY21YLumWBOIOpfKuItdW8zFDORbmUAVd9BZ2QmC5NKktW+qq6e lXng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eaUGzmt3xycfTKtI6/ROCjXspTLvIjGYDY+g5bc9qVs=; b=gg6J8K07m+IJNOl+jTafdkiY4DMAuKZRgDwHCVXw0KrDdI42dxkfZ6YEX4DHLrVuD6 Fxziumf09gbdpyz4nB2GS1p7SQpqsP28ulmMJmZLJ7OmaPOe7R/8sI4xW5ouA+2UNGnW rJ0Gdg1/ZPfiPUzmjU4K9co9EEifVbahs7Ws+S9k2r/xReHdY/yUIvWJ1eLZ2S3ryv9o CokXVMm3pPyAkUR8wgonoTkOHuXW2/4nJ3jkC+z/lI5PyDys4OXi4Y9/aDKSc5aIHjiA rl4Mt+UBmw6/mC76WqgmxxE5XASqu2rVNyNi7yPXIfGf61q++PfJJj/56WZlB1OQ/Qba bALQ== X-Gm-Message-State: AO0yUKUoozo3A+0ZbYJZxbgYu+Fh1PVOzETkRxMfKBfIchlxF40RoUxG vyRx+GhrnaoSYmLW0yUShUekhRCxS+NMppFH X-Google-Smtp-Source: AK7set+5dccvie+r0uGqOgkHrMjzeCfiu5QnL8zHt6TraKGMNh7j44OOuH+M6Tbjfwk0sPteF5Dy1Q== X-Received: by 2002:a5e:da42:0:b0:718:cf71:b633 with SMTP id o2-20020a5eda42000000b00718cf71b633mr3182508iop.8.1675033087757; Sun, 29 Jan 2023 14:58:07 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id f21-20020a056638169500b0038a06a14b37sm3477396jat.103.2023.01.29.14.58.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2023 14:58:07 -0800 (PST) From: Bakul Shah Message-Id: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_79D4F7E7-6E0B-4E8B-A1F9-301C7C9C6B01" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Date: Sun, 29 Jan 2023 14:57:56 -0800 In-Reply-To: To: Ron Natalie References: X-Mailer: Apple Mail (2.3731.400.51.1.1) Message-ID-Hash: FXL65J45FFNH4DZ4WBTADPFRA332H2CN X-Message-ID-Hash: FXL65J45FFNH4DZ4WBTADPFRA332H2CN X-MailFrom: bakul@iitbombay.org 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: --Apple-Mail=_79D4F7E7-6E0B-4E8B-A1F9-301C7C9C6B01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = fail? 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: >=20 > Another of Ron=E2=80=99s historical diversions that came to mind. >=20 > 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 = was 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 out how it had happened and running around fixing it. >=20 > 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. 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. That was fixed before my time at JHU (but I used it on = other systems). >=20 > 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. = With some painstaking comparison to another RK05 superblock, I = reconstituded it 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 written 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. >=20 > At JHU we had lots of people with removable packs, so someone had = modified 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 of putting volume labels in the superblock to = identify the pack being mounted. 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 see 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. >=20 > 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 with the root password). He told me to go ahead, knock = yourself out. >=20 > Well I spent the evening closing various combinations of file = descriptors and invoking setuid programs. I found a few more and noted = them. After a while I got tired and went home. >=20 > The next day I came in and looked through our paper logbook that we = filled out anytime the machine was shutdown (or crashed). 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). The 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 was one of the ones I tested, but I hadn=E2=80=99t= noticed any ill-effects for it at the time. --Apple-Mail=_79D4F7E7-6E0B-4E8B-A1F9-301C7C9C6B01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 = fail?

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

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 <ron@ronnatalie.com> 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 was 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 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.   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.   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.   With = some painstaking comparison to another RK05 superblock, I reconstituded = it 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 written 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 = modified 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 of putting volume labels in the superblock to = identify the pack being mounted.    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 see 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 with 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.   =  After a while I got tired and went home.

The next day I = came in and looked through our paper logbook that we filled out anytime = the machine was shutdown (or crashed).   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).   The 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 was one of = the ones I tested, but I hadn=E2=80=99t noticed any ill-effects for it = at the time.

= --Apple-Mail=_79D4F7E7-6E0B-4E8B-A1F9-301C7C9C6B01--