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 2473 invoked from network); 30 Jan 2023 01:18:55 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 01:18:55 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C6E57425B0; Mon, 30 Jan 2023 11:18:41 +1000 (AEST) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by minnie.tuhs.org (Postfix) with ESMTPS id 473FD425AE for ; Mon, 30 Jan 2023 11:18:37 +1000 (AEST) Received: by mail-il1-f181.google.com with SMTP id i6so741227ilq.8 for ; Sun, 29 Jan 2023 17:18:37 -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=plDubkpMRe006JNY0lq+se0PoBY5WTOYFi97KQTEZIo=; b=0bvZwq5jYz7DOcNdxCqnUPz3pTzKQYs/LUCsXbo8PZfB6ZRc9TiYuV7dFFrOlFOKHy k25SXSddju/pgUBv62P0uqhvr+0VUmUsTu2ql/GipRzWqOBC9hpo9XXx0p184B7Nc6KW qkLkuxCxnMGtm3Vko6PmwxOaDF/NILSCNUWZHpbJTkuzQxeG/BKBt3xSPMcjRvArwm0H SsmYJ3u/2fiCvr0cnAm4pfhANc+kniZ7STrHqQTinwhqXoELh8JUUOZsLzy7J/Ro6tPB tLGNNQ+IAJRN280vV2rTGzt5UQPSZqwlZ8yEthRu1tOkxCJsfwDQBctucyGc6cHOqiCi Np5Q== 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=plDubkpMRe006JNY0lq+se0PoBY5WTOYFi97KQTEZIo=; b=KS2QudYcGmHNbxCpIBK3ExiTRqaSbDY+68jk8JekpIVaEUUUYoBN01evgUUo7NOFya 06WadL4F9RRfITqiiQvUB+QHXre5hv30CD2exXVwqIB/VbkQtRD7wqLoJ28CCv7NWVZp W6kyitudcgn7LNMsDumbsKRyF+Ih7xKw0BWuORgezbnYWojZeHCxxGQI4EEWimHh4guG I2oNZ61iqhqaZv7ebYVnxl9T/jkAflLCj2HEagx0zcmWvyWrNYclrOV0dgk8hihpI4Mt ipb5PMc/qpZcWKexGs26wGPiWn1WMMMubkm6UVovpc0WaJCz9cFEnSJ90qv27RxBrGSt 6Jug== X-Gm-Message-State: AFqh2kpV4M//EYpspvFI+Ck26fdxZkShxjH96G1HNHPOb1SRncn/N2w4 u0lH83aUu+/+h6xMXfTTuAaEe/+J4tZUUZc/ X-Google-Smtp-Source: AMrXdXshCBBt/tNujpBDYLGqNHJFyO8TIvPvU0PJ6hKfHAPj4bycuGAmokoiLhn9XC92ue/JEuayig== X-Received: by 2002:a05:6e02:1a2b:b0:30f:5d64:cc3 with SMTP id g11-20020a056e021a2b00b0030f5d640cc3mr29694875ile.9.1675041456453; Sun, 29 Jan 2023 17:17:36 -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 u23-20020a02aa97000000b0039d71c46577sm4278601jai.21.2023.01.29.17.17.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2023 17:17:36 -0800 (PST) From: Bakul Shah Message-Id: <29FC4361-59FF-4F1B-843E-CF88D65E416C@iitbombay.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_0E56686B-C548-4D32-84BC-C47CA90C5362" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Date: Sun, 29 Jan 2023 17:17:24 -0800 In-Reply-To: To: Warner Losh References: <2D760346-E44F-4248-9122-19A5E4EDA42D@iitbombay.org> X-Mailer: Apple Mail (2.3731.400.51.1.1) Message-ID-Hash: Q3IAREEXEXYKPJJJQWJDVYDZRQ5Y7JU5 X-Message-ID-Hash: Q3IAREEXEXYKPJJJQWJDVYDZRQ5Y7JU5 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=_0E56686B-C548-4D32-84BC-C47CA90C5362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 29, 2023, at 4:45 PM, Warner Losh wrote: >=20 >=20 >=20 > 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 = fail? >=20 >=20 > Because if it is closed the first open will return 1. And that's also = where the printf will go... I got that far but didn't think further (open to read the superblock = will be now on fd 1). Thanks! Definitely a confused deputy problem!=20 > Warner=20 >=20 >> Anyway, this sounds like a classic case of "the confused deputy". >> http://www.cap-lore.com/CapTheory/ConfusedDeputy.html >>=20 >> Of course, a tighter security design might've made it much more = difficult to apply useful hacks like the one Mike Muus did! >>=20 >>> 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. >>=20 --Apple-Mail=_0E56686B-C548-4D32-84BC-C47CA90C5362 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan = 29, 2023, at 4:45 PM, Warner Losh <imp@bsdimp.com> wrote:



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 *before* calling mount result in this = behavior? Shouldn't a write(1, ...) just = fail?

Because if it is closed the first open will return 1. And = that's also where the printf will = go...

I got that far but = didn't think further (open to read the superblock will be now on fd = 1).
Thanks! Definitely a confused deputy = problem! 

Warner 

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



Another of Ron=E2=80=99= s 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=_0E56686B-C548-4D32-84BC-C47CA90C5362--