Hi,
I''ve been thinking about group membership and the corresponding (weak)
restrictions to system resources. Consider the following:
% cat > gsh.c
main()
{
system("/bin/sh");
}
% cc -o gsh gsh.c
% id
uid=100(joe) gid=500(users) groups=14(floppy),15(sound)
% chgrp sound gsh
% chmod g+s gsh
% mail abuser
Subject: You owe me $5...
Hi ab!
So the sysadmin stopped you using the sound card did he? Well
if you will give me the money you promised, I''ll solve that!
.
The beauty of this is that once ''joe'' has made this program he
will always
have access to the sound card.. Even if the administrator tries to remove
him from the group too...
My problem with this is that the sys-admin is powerless to control the
allocation of groups on his system since the individual users have freedom
to share membership in this way. Is there a legitimate reason why users can
set programs to be setgid?
I''d like to hear people''s comments.. Thanks.
[REW: There is NOTHING you can do to prevent people giving away the
access they have themselves. They can give their password away, and
for example the above trick can be used to give just their group access
away....]
Andrew
--
Linux-PAM: http://parc.power.net/morgan/Linux-PAM/index.html
libpwdb: http://parc.power.net/morgan/libpwdb/index.html
From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by
(8.6.10/1.34JP)
Received: (qmail 11199 invoked from network); 29 Nov 1996 06:56:12 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 29 Nov 1996 06:56:11 -0000
Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id BAA08844 for
<linux-security@redhat.com>; Fri, 29 Nov 1996 01:03:49 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id BAA22439
for linux-security@redhat.com; Fri, 29 Nov 1996 01:04:00 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id PAA22794; Thu, 28 Nov 1996 15:25:30 +0100
Received: (qmail 27627 invoked by uid 501); 28 Nov 1996 14:14:49 -0000
Received: (qmail 27594 invoked from network); 28 Nov 1996 14:14:45 -0000
Received: from medusa.uplex.net (204.157.226.2)
by mail2.redhat.com with SMTP; 28 Nov 1996 14:14:45 -0000
Received: from nihl.accessone.com (mike@nihl.uplex.net [204.157.226.13]) by
medusa.uplex.net (8.7.5/8.7.3) with SMTP id GAA12548 for
<linux-security@redhat.com>; Thu, 28 Nov 1996 06:04:43 -0800 (PST)
Sender: mike@uplex.net
Message-ID: <329D2D7E.24CA51FC@uplex.net>
Date: Thu, 28 Nov 1996 06:13:18 +0000
From: Abraham Bodizapha Ozzda Igy Asok Marfund Garduchey Soco Swanawehak Fenway
Buisquali Montecarlo Neuman Smith <mike@uplex.net>
Approved: R.E.Wolff@BitWizard.nl
Organization: UltraPLEX
X-Mailer: Mozilla 3.0 (X11; I; Linux 2.1.0 i586)
MIME-Version: 1.0
To: linux-security@redhat.com
Subject: Re: [linux-security] denial of service attack on login
References: <Pine.GSO.3.95.961128114119.12757S-100000@melkor>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[I presume I''ll just get flamed or a terse answer in response to this,
attributed to ignorance (in some form or other)]
On Tue, 26 Nov 1996, Andrew G. Morgan wrote:> The following denial of service attack seems to work quite nicely on my
> ancient Red Hat 3.0.3 system with the standard login application. Perhaps
> this is not a problem with 4.0? Does anyone know about other distributions?
>
> joe$ nvi /var/log/wtmp
>
> [ Now no-one else can log in ]
Now that we''ve determined that this problem exists in just about every
popular, current distribution, what can I do or where do I go for my
best bet at a (temporary, at least) solution? Any additional
information on what is/isn''t fixed would be appricated. ... eg
regarding
wheather said fix addresses the problem of needing a lock on wtmp and
the ability of others to prevent that or a specific program like login
which has been told it doesnt need to lock the file.
[mod: I''d suggest that you grab your closest login sources. Easiest
would be to grab those that are for your system. Recompile them, and
verify that they are the same as what you already have. Then find the
part that locks the wtmp file and delete it. -- REW]
Thanks in advace...
mike
From mail@mail.redhat.com
Received: (qmail 15713 invoked from network); 29 Nov 1996 12:20:40 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 29 Nov 1996 12:20:32 -0000
Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id NAA10842 for
<linux-security@redhat.com>; Fri, 29 Nov 1996 13:11:42 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id NAA26407
for linux-security@redhat.com; Fri, 29 Nov 1996 13:12:09 +0100
Message-Id: <199611291212.NAA26407@cave.et.tudelft.nl>
Subject: Denial of service.
To: linux-security@redhat.com
Date: Fri, 29 Nov 1996 13:12:09 +0100 (MET)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Approved: R.E.Wolff@BitWizard.nl
Content-Type: text
There are conflicting reports about wether or not Red Hat 4.0 is
vulnerable to the login-lockout described earlier. I have the
impression that if you install the updates it will have been fixed.
Approval of messages about this subject is now restricted to
"here is a patch", and a vendors "We have made a patch
available".
Roger.
From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by
(8.6.10/1.34JP)
Received: (qmail 25236 invoked from network); 30 Nov 1996 11:43:11 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 30 Nov 1996 11:43:10 -0000
Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id LAA14185 for
<linux-security@redhat.com>; Sat, 30 Nov 1996 11:33:49 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id LAA00033
for linux-security@redhat.com; Sat, 30 Nov 1996 11:34:48 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id BAA00498; Sat, 30 Nov 1996 01:17:56 +0100
Received: (qmail 29181 invoked by uid 501); 30 Nov 1996 00:17:57 -0000
Received: (qmail 29169 invoked from network); 30 Nov 1996 00:17:55 -0000
Received: from xemacs.miranova.com (HELO altair.xemacs.org)
(steve@206.190.83.19)
by mail2.redhat.com with SMTP; 30 Nov 1996 00:17:55 -0000
Received: (from steve@localhost) by altair.xemacs.org (8.8.3/8.8.3) id QAA23498;
Fri, 29 Nov 1996 16:27:14 -0800
Sender: steve@altair.xemacs.org
To: linux-security@redhat.com
Subject: Re: Denial of service.
References: <199611291212.NAA26407@cave.et.tudelft.nl>
X-Url: http://www.miranova.com/%7Esteve/
Mail-Copies-To: never
X-Face:
#!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^''[`^sr5"
f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
OSS''2{-)-4wBnVeg0S\O4Al@)uC[pD|+
From: Steven L Baur <steve@miranova.com>
Approved: R.E.Wolff@BitWizard.nl
In-Reply-To: R.E.Wolff@BitWizard.nl''s message of Fri, 29 Nov 1996
13:12:09 +0100 (MET)
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII
Date: 29 Nov 1996 16:27:14 -0800
Message-ID: <m2g21s2zrx.fsf@altair.xemacs.org>
Lines: 25
X-Mailer: Red Gnus v0.71/XEmacs 19.15
The bug exists through the recently released util-linux-2.6. Here is
a patch which removes the locking.
--- util-linux-2.6/login-utils/login.c.orig Thu Nov 7 06:26:15 1996
+++ util-linux-2.6/login-utils/login.c Fri Nov 29 16:12:24 1996
@@ -628,9 +628,10 @@
endutent();
if((wtmp = open(_PATH_WTMP, O_APPEND|O_WRONLY)) >= 0) {
- flock(wtmp, LOCK_EX);
+/* Locking wtmp allows for trivial denial of service attack by nvi */
+/* flock(wtmp, LOCK_EX); */
write(wtmp, (char *)&ut, sizeof(ut));
- flock(wtmp, LOCK_UN);
+/* flock(wtmp, LOCK_UN); */
close(wtmp);
}
}
[mod: WARNING: UNTESTED CODE, MANUALLY FABRICATED PATCH AHEAD.
Anybody dare to test the following?:
--- util-linux-2.6/login-utils/login.c.orig Thu Nov 7 06:26:15 1996
+++ util-linux-2.6/login-utils/login.c Sat Nov 30 11:22:15 1996
@@ -628,6 +628,8 @@
endutent();
if((wtmp = open(_PATH_WTMP, O_APPEND|O_WRONLY)) >= 0) {
+/* Locking wtmp allows for trivial denial of service attack by nvi */
+ alarm (3);
flock(wtmp, LOCK_EX);
write(wtmp, (char *)&ut, sizeof(ut));
flock(wtmp, LOCK_UN);
This is the simple "force the lock if we can''t get it"
solution. If
your wtmp is on an ext2fs, it is pretty unlikely that the solution
"without locking" will corrupt anything. However there are race
conditions in the ext2fs_write_file code that would allow an entry
to get overwritten in special circumstances. -- REW]
--
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.
"Bill Clinton is a bore. He doesn''t have a creative bone in his
body." -- David Brinkley
From mail@mail.redhat.com Fri Nov 15 11:49:12 1996
