In Debian 1.1, the optional DOSEMU package installs /usr/sbin/dos
setuid root. This is a serious security hole which can be exploited
to gain access to any file on the system.
Package: dosemu
Version: 0.64.0.2-9
------- start of cut text --------------
$ cat /etc/debian_version
1.1
$ id
uid=xxxx(quinlan) gid=xxxx(quinlan) groups=xxxx(quinlan),20(dialout),24(cdrom)
[quinlan:~]$ ls -al /usr/bin/dos
-rwsr-xr-x 1 root root 569576 Oct 24 00:05 /usr/bin/dos
$ ls -al /root/foo
-rw------- 1 root root 1117 Nov 13 23:10 /root/foo
$ dos -F /root/foo
[ Prints /root/foo, which is not readable by user `quinlan''. ]
------- end ----------------------------
I expect there may be other holes in dosemu other than this one that
can be exploited if it is installed setuid root. It took about 60
seconds to find this hole once I realized /usr/bin/dos was setuid
root.
Dan
From mail@mail.redhat.com 17277 by invoked 501); uid
Received: (qmail 11024 invoked from network); 27 Nov 1996 05:31:21 -0000
Received: from bach.cis.temple.edu (155.247.71.92)
by mail2.redhat.com with SMTP; 27 Nov 1996 05:31:21 -0000
Received: (from alex@localhost) by bach.cis.temple.edu (8.7.4/8.7.3) id
BAA03514; Wed, 27 Nov 1996 01:29:19 -0500
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by
bach.cis.temple.edu (8.7.4/8.7.3) with SMTP id MAA17262 for
<alex@bach.cis.temple.edu>; Tue, 26 Nov 1996 12:07:55 -0500
Received: (qmail 17277 invoked by uid 501); 26 Nov 1996 16:27:45 -0000
Received: (qmail 17257 invoked from network); 26 Nov 1996 16:27:43 -0000
Received: from parc.power.net (198.186.216.82)
by mail2.redhat.com with SMTP; 26 Nov 1996 16:27:41 -0000
Received: (from morgan@localhost) by parc.power.net (8.7.1/8.7.1) id HAA16832;
Tue, 26 Nov 1996 07:49:33 -0800
From: "Andrew G. Morgan" <morgan@parc.power.net>
Approved: alex@bach.cis.temple.edu
Message-Id: <199611261549.HAA16832@parc.power.net>
Subject: denial of service attack on login
To: linux-security@redhat.com (Linux Security)
Date: Tue, 26 Nov 1996 07:49:33 -0800 (PST)
Cc: johnsonm@redhat.com (Michael K. Johnson)
Content-Type: text
Hi,
I''ve been writing a login application to utilize the features of both
PAM
and libpwdb. Not surprisingly, this has meant looking at some old code..
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 ]
This is a problem with advisory locking. The fact that anyone can create an
exclusive lock on a file they can only read! Is this behavior appropriate?
My copy of the POSIX book (D. Lewin, O''Reilly & Assoc.
''94) is a little
vague as to the "correctness" of this behavior. Perhaps someone can
provide
a better explanation?
Regards
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 3556 by invoked 501); uid
Received: (qmail 7549 invoked from network); 27 Nov 1996 07:15:01 -0000
Received: from bach.cis.temple.edu (155.247.71.92)
by mail2.redhat.com with SMTP; 27 Nov 1996 07:15:00 -0000
Received: (from alex@localhost) by bach.cis.temple.edu (8.7.4/8.7.3) id
DAA04137; Wed, 27 Nov 1996 03:13:00 -0500
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by
bach.cis.temple.edu (8.7.4/8.7.3) with SMTP id TAA01605 for
<alex@bach.cis.temple.edu>; Tue, 26 Nov 1996 19:46:49 -0500
Received: (qmail 3556 invoked by uid 501); 26 Nov 1996 23:48:40 -0000
Received: (qmail 3544 invoked from network); 26 Nov 1996 23:48:37 -0000
Received: from hustle.rahul.net (192.160.13.2)
by mail2.redhat.com with SMTP; 26 Nov 1996 23:48:36 -0000
Received: by hustle.rahul.net with UUCP id AA06611
(5.67b8/IDA-1.5 for linux-security@redhat.com); Tue, 26 Nov 1996 15:48:37
-0800
Received: (from jimd@localhost) by antares.starshine.org (8.8.3/8.8.3) id
QAA22488; Tue, 26 Nov 1996 16:53:20 -0800
From: Jim Dennis <jimd@starshine.org>
Approved: alex@bach.cis.temple.edu
Message-Id: <199611270053.QAA22488@antares.starshine.org>
Subject: Re: [linux-security] chattr +i and securelevel
To: linux-security@redhat.com
Date: Tue, 26 Nov 1996 16:53:19 -0800 (PST)
In-Reply-To: <199611210849.JAA00445@cave.et.tudelft.nl> from "Rogier
Wolff" at Nov 21, 96 09:49:53 am
Content-Type: text
[Mod: Subject changed and a part about modules removed. Also, if people have
comments, please email them directly to Jim and me - we will post a summary.
-- alex]
>>> To be honest, I haven''t gone through the trouble
>>> of coding a module yet, but compiled kernels with securelevel=1
works. :)
>>> It''s a nice lock+key function when you''re looking
to immute or append-
>>> only special files. (Immuting /etc/passwd on production machines
is a
>>> simple security measure that saves hours of time... trust me.)
>>
>> Which will prevent passwd, chfn and chsh work.... So no, I
won''t
>> trust you.
So. I believe he was referring to dedicated servers, like
ftp, web, nfs, db servers, and the like. These boxes -- to
be considered reasonably secure -- should have not user
level accounts on them -- just administrative accounts.
I agree that there are many types of "production" machines
where you don''t want /etc/passwd and /etc/aliases, and
/etc/sendmail.cf (etc). to be immutable. However I do
recommend setting all libs, bins, kernels, man pages
(groff macro trojans), and as many other files to
immutable as you can. Do this *even if you don''t set
sysctl*.
[Mod: Even on dedicated systems one needs to change passwords. The question
becomes more of a policy issue. Using a principle of the least priviledge,
one would expect that becoming superuser in order to just change a password
of one of the www admins is a not a good idea.
Also keep in mind that package manegers do not check for the immutable flags
which prevent easy package upgrades. -- alex]
>>> I did,
>>> however, notice a couple of broken things in the immutable area,
namely,
>>> the execption for root is tested before the immutable kick-out
code.
>>> The main reason I use the immute/append tags are so processes
running
>>> as root CANT alter certain files. (Ie a human has to un-tag the
files
>>> before they can be altered).
I don''t know about the code -- but I''ve chattr''d +i
and was unable to modify files as root. So it has worked
as *I* expected.
[Mod: from chattr(1) manual page:
A file with the ''a'' attribute set can only be open in
append mode for writing.
A file with the ''s'' attribute cannot be modified: it can-
not be deleted or renamed, no link can be created to this
file and no data can be written to the file. Only the
superuser can set or clear this attribute. -- alex]
> > Correct me if I am wrong but is not chattr a wrapper against a system
call?
> > Who will prevent a program running as root to issue such call?
Essentially,
> > I think we can agree that there is no way to prevent a smart attacker
from
> > penetrating a system, you can only make your system harder to
penetrate than
> > a system of your neighbour.
I suspect that you''re wrong -- but I haven''t looked at the
code. Clearly an immutable file can be unprotected by
''chattr -i'' by a root process -- until we have securelevel
working.
> The securelevel code simply isn''t finished. I suspect Remi Card
had the
> feeling he wanted a securelevel variable, stuck it in in his area of the
> code (ext2fs) and put in a little code in the sysctl as an example of how
> this variable might be changed.
>
> When securelevel <> 0, you should
> 1) Disable writing/reading block devices. (i.e. you can no longer use
mtools
> for floppies)
> 2) disable writing/reading char devices, except maybe mouse and serial
> ports. (At least kmem should be disabled, which is a char device.)
I disagree with both of these statements. You could be
able to access the block and char devices according to
their permissions.
I also think that you should be able to create new b and
c nodes according to the filesystem permissions.
However I think that filesystems should not be mountable
or remountable after securelevel is set. At least
there should be some mechanism by which mounting, remounting
and unmounting is only supported according to the settings
in /etc/fstab -- no override via command line parms.
(Otherwise you can mount removable backup devices).
> 3) Disable module loading.
> 4) disable the chattr call for ext2fs.
I agree with this -- securelevel should prevent changes
to the kernel memory space that would render the
system insecure.
> Only (4) is implemented right now.
Jim Dennis,
Starshine Technical Services
From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by
(8.6.10/1.34JP)
Received: (qmail 32342 invoked from network); 27 Nov 1996 09:23:03 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 09:22:59 -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 JAA01947 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 09:40:18 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id JAA07090
for linux-security@redhat.com; Wed, 27 Nov 1996 09:45:34 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id GAA12572; Wed, 27 Nov 1996 06:41:14 +0100
Received: (qmail 18686 invoked by uid 501); 27 Nov 1996 05:40:44 -0000
Received: (qmail 18416 invoked from network); 27 Nov 1996 05:40:33 -0000
Received: from sh1.ro.com (cadams@205.216.92.5)
by mail2.redhat.com with SMTP; 27 Nov 1996 05:40:32 -0000
Received: (from cadams@localhost) by sh1.ro.com (8.7.6/8.6.9) id XAA32687; Tue,
26 Nov 1996 23:40:33 -0600
From: Chris Adams <cadams@sh1.ro.com>
Approved: R.E.Wolff@BitWizard.nl
Message-Id: <199611270540.XAA32687@sh1.ro.com>
Subject: Re: [linux-security] denial of service attack on login
To: linux-security@redhat.com
Date: Tue, 26 Nov 1996 23:40:33 -0600 (CST)
Cc: johnsonm@redhat.com
In-Reply-To: <199611261549.HAA16832@parc.power.net> from "Andrew G.
Morgan" at Nov 26, 96 07:49:33 am
Content-Type: text
Status: RO
Once upon a time, 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 ]
This doesn''t seem to happen on my system - RedHat 3.0.3 + shadow
passwords. My /bin/login comes from shadow-960810-1. Maybe the
shadow passowrd suite doesn''t try to lock wtmp?
--
Chris Adams - cadams@ro.com
System Administrator - Renaissance Internet Services
From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by
(8.6.10/1.34JP)
Received: (qmail 71 invoked from network); 27 Nov 1996 09:23:38 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 09:22:59 -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 JAA01941 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 09:39:56 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id JAA07073
for linux-security@redhat.com; Wed, 27 Nov 1996 09:45:12 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id BAA18972; Wed, 27 Nov 1996 01:51:22 +0100
Received: (qmail 26799 invoked by uid 501); 27 Nov 1996 00:51:09 -0000
Received: (qmail 26692 invoked from network); 27 Nov 1996 00:51:03 -0000
Received: from darkstar.sysinfo.com (root@204.246.65.62)
by mail2.redhat.com with SMTP; 27 Nov 1996 00:51:01 -0000
Received: from localhost (dufresne@localhost [127.0.0.1]) by
darkstar.sysinfo.com (8.8.2/8.8.2) with SMTP id SAA06632 for
<linux-security@redhat.com>; Tue, 26 Nov 1996 18:53:22 -0600
X-Received: from parka.winternet.com (dufresne@parka.winternet.com
[198.174.169.9]) by darkstar.sysinfo.com (8.8.2/8.8.2) with SMTP id SAA06621 for
<dufresne@darkstar.sysinfo.com>; Tue, 26 Nov 1996 18:51:10 -0600
Posted-Date: Tue, 26 Nov 1996 17:31:02 -0600 (CST)
Received-Date: Tue, 26 Nov 1996 17:31:02 -0600 (CST)
Approved-By: ALEPH1@UNDERGROUND.ORG
X-Authentication-Warning: dilbert.kluge.net: felicity owned process doing -bs
MIME-Version: 1.0
Approved-By: Theo Van Dinter <felicity@KLUGE.NET>
Message-ID: <Pine.LNX.3.95.961126161126.13571C-100000@dilbert.kluge.net>
Date: Tue, 26 Nov 1996 16:14:48 -0500
Reply-To: Theo Van Dinter <felicity@kluge.net>
Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Theo Van Dinter <felicity@kluge.net>
Approved: R.E.Wolff@BitWizard.nl
Subject: Re: Security Problems in XMCD 2.1
X-To: "David J. Meltzer" <davem@ISS.NET>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: <Pine.LNX.3.95.961126122846.12271F-100000@phoenix.iss.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-ReSent-Date: Tue, 26 Nov 1996 18:42:46 -0600 (CST)
X-ReSent-From: Ron DuFresne <dufresne@parka.winternet.com>
X-ReSent-To: dufresne <dufresne@darkstar.sysinfo.com>
X-ReSent-Message-ID:
<Pine.SOL.3.91.961126184246.18469E@parka.winternet.com>
ReSent-Date: Tue, 26 Nov 1996 18:53:19 -0600 (CST)
ReSent-From: "R. DuFresne" <dufresne@darkstar.sysinfo.com>
ReSent-To: linux-security@redhat.com
ReSent-Message-ID: <Pine.LNX.3.95.961126185319.6549B@darkstar.sysinfo.com>
Status: RO
On Tue, 26 Nov 1996, David J. Meltzer wrote:
> I have obtained the 2.1 release of XMCD and through a cursory
> examination of the code have uncovered another buffer overflow problem
> that appear to be exploitable to gain root access on the system. I have
> not verified that the hole is exploitable, although it definitely exists.
> As I stated before, if you remove the suid bit from xmcd, then you do not
> have to worry about upgrading other than for the new features that have
> been added, whether you can still function xmcd without the suid bit
> varies depending on your system.
On a side tangent, I grabbed the 2.1 binary (since I don''t have the
motif
libraries under Linux...) and installed it. It''s not setuid by
default...
On a side tangent, the standard rule of thumb is: "If a program
doesn''t
really need SUID/GID, don''t give it SUID/GID." ...
Doesn''t fix the buffer
overrun, but it doesn''t give the user root either...
--
-----------------------------------------------------------------------------
Theo Van Dinter www: http://www.kluge.net/~felicity/
Vice-President WPI Lens and Lights Active Member in SocComm Films
Member of WPI ACM AME for the Masque B-Term Show
Guillotine operators get severance pay.
-----------------------------------------------------------------------------
From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38])
(dutecai.et.tudelft.nl rosie.et.tudelft.nl by
Received: (qmail 218 invoked from network); 27 Nov 1996 09:23:45 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 09:22:59 -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 JAA01910 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 09:31:00 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id JAA07016
for linux-security@redhat.com; Wed, 27 Nov 1996 09:36:17 +0100
Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id HAA01606 for
<rogier@cave.et.tudelft.nl>; Wed, 27 Nov 1996 07:55:47 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id CAA23449; Wed, 27 Nov 1996 02:50:03 +0100
Received: (qmail 8573 invoked by uid 501); 27 Nov 1996 01:49:51 -0000
Received: (qmail 8557 invoked from network); 27 Nov 1996 01:49:50 -0000
Received: from phoenix.iss.net (204.241.60.5)
by mail2.redhat.com with SMTP; 27 Nov 1996 01:49:49 -0000
Received: from localhost (davem@localhost) by phoenix.iss.net (8.8.3/8.6.12)
with SMTP id UAA01671; Tue, 26 Nov 1996 20:47:02 -0500
Date: Tue, 26 Nov 1996 20:47:01 -0500 (EST)
From: "David J. Meltzer" <davem@iss.net>
Approved: R.E.Wolff@BitWizard.nl
To: bugtraq@netspace.org, best-of-security@suburbia.net,
linux-security@redhat.com, cert@cert.org, xmcd@bazooka.amb.org,
firewalls@greatcircle.com
cc: root@camco.celestial.com, root@ultra.sonic.net, root@smurfy.tcimet.net,
root@wildride.schoneal.com, root@crescent.Dartmouth.EDU,
root@sunsite.unc.edu, root@redwood.shu.ac.uk, root@mylly.ton.tut.fi,
root@MX.westel.hu, root@cddb.sai.msu.su, root@nematic.ieo.nctu.edu.tw
Subject: Major Security Vulnerabilities in Remote CD Databases
Message-ID: <Pine.LNX.3.95.961126203741.1613A-100000@phoenix.iss.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
XMCD is a popular unix audio cd-player with a unique feature that it will
query remote databases over the Internet to determine the title, group, and
song list for cds that are being played. The remote database of compact
discs has become quite popular and is now supported by several Windows based
cd players as well, including EasyCD2, DiscPlay, MyCDPLayer, and WinMCD.
XMCD source is available freely under the GNU Public License, and I have
examined it for possible security problems; some or all of the Windows based
cd players do not have source available and so I am unable to directly
determine if they are vulnerable to similar problems; from a security
standpoint I think it is prudent to assume that they are until there is
evidence to the contrary.
When I started examining XMCD I thought the scope of problems it may
result in was limited to it running as an suid root program on the local
host. It seems the extent that it may compromise the vulnerability of your
host may extend far beyond that. The handling of input returned from a remote
cddbd server appears suspect with respect to buffer handling, meaning that
if a cddb server has had its security compromised, it could return false
responses to database queries that could result in a buffer overflow allowing
the cddb server to execute arbitrary code on your machine. Because of the
major threat that this vulnerability would allow, and the history of security
problems in xmcd, I feel it is important that the potential for this problem
be released before a comprehensive analysis of the code can take place to
determine the ease with which this can be exploited.
Since a cddb connection is an outgoing TCP connection, any firewall or
filtering router configured to allow outgoing TCP connections to port 888 or
to any arbitrary TCP port would allow this to be exploited on any machine
inside of the firewall.
Another possible method of exploiting this vulnerability is a man in the
middle attack. In this manner, an attacker could watch the network for
outgoing queries to the cd database server, and hijack the connection,
returning trojaned data back to the client and gaining access to the client
machine remotely.
[mod: Let me tell you that once you can hijack connections, you''re
pretty powerful in subverting any host that has a connection through
your wire. -- REW]
The net result of this is that if you run xmcd with remote database
querying enabled, it may be possible for a remote attacker to gain access
to your machine. This same vulnerability MAY exist with the various Windows
CD players that use the same mechanism. If the authors of these programs
were not specifically aware of the security implications of checking the
input from the database servers for proper length and boundaries, it is
quite likely that this would be the case.
There are even more issues regarding remote cd querying on the server side.
The cd database server, cddbd, has an input buffer of 1024 characters. The
size of the buffer with which log messages are created with is 256 characters.
This results in a buffer overflow which can be used to remotely gain access
to any host running cddbd. An attacker that is able to exploit this problem
could then gain access to every cd database server, replace cddbd with a
trojaned piece of code, and then attempt to gain access to any machine that
queries it by sending replies with trojaned information. In this manner,
an attack of a very small set of known machines on the Internet through this
hole could gain access to literally THOUSANDS of machines on the Internet,
regardless of firewalls, within a very short time span, and with very little
effort once the initial exploit code has been written.
It is not my intention to blow this threat out of proportion, but this
and other kinds of passive attacks are becoming increasingly common, and
it is exactly the type of attack that is able to compromise machines on
a wide-spread scale. Although there are no "reports" of this type of
attack going on currently, it is inevitable that this will occur in the
near future on the Internet.
It is my strong recommendation that users of xmcd, or any of the Windows
cd players that query the cddb remote servers, disable remote querying until
a thorough security evaluation of the source code to each of the programs
can be performed. I would further recommend that firewall administrators
reconfigure their firewall to disable OUTBOUND connections to port 888,
the cddbd server port. I would also strongly recommend that all servers
running cddbd remove it from their machines until a comprehensive examination
of its buffer handling can take place.
I would like to thank Thomas Ptacek for his assistance in examining these
vulnerabilities and for his examination of cddbd for buffer overflows.
--------------------------------+---------------------
David J. Meltzer | Email: davem@iss.net
Systems Engineer | Web: www.iss.net
Internet Security Systems, Inc. | Fax: (770)395-1972
From mail@mail.redhat.com mail2.redhat.com [199.183.24.247]) (mail2.redhat.com
rosie.et.tudelft.nl by
Received: (qmail 29403 invoked from network); 27 Nov 1996 11:03:55 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 11:03:53 -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 LAA02483 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 11:58:29 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id MAA07996
for linux-security@redhat.com; Wed, 27 Nov 1996 12:03:49 +0100
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id LAA02399 for
<rogier@cave.et.tudelft.nl>; Wed, 27 Nov 1996 11:31:22 +0100
Received: (qmail 24795 invoked by uid 501); 27 Nov 1996 10:36:26 -0000
Received: (qmail 24779 invoked from network); 27 Nov 1996 10:36:24 -0000
Received: from kro.amtp.cam.ac.uk (root@131.111.16.190)
by mail2.redhat.com with SMTP; 27 Nov 1996 10:36:15 -0000
Received: by kro.amtp.cam.ac.uk
(Smail-3.1.28.1 #6) id m0vShLQ-00024vC; Wed, 27 Nov 96 10:35 GMT
Message-Id: <m0vShLQ-00024vC%kro.amtp.cam.ac.uk@damtp.cam.ac.uk>
X-Mailer: exmh version 1.5.1 12/2/94
To: linux-security@redhat.com
cc: johnsonm@redhat.com (Michael K. Johnson), jp107@damtp.cam.ac.uk
Subject: Re: [linux-security] denial of service attack on login
In-reply-to: Your message of "Tue, 26 Nov 1996 07:49:33 PST."
<199611261549.HAA16832@parc.power.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 27 Nov 1996 10:35:55 +0000
From: Jon Peatfield <J.S.Peatfield@damtp.cam.ac.uk>
Approved: R.E.Wolff@BitWizard.nl
Hmm, I can imagine utmp being locked this way, but is it worth it for wtmp?
All login does is add an entry to the end...
Linux lacks the updwtmp{,x}() calls which SVR4 provides as a packaged way to
update wtmp. My local login code when on Linux just does (basically):
if ((fd = open(_PATH_WTMP, O_WRONLY|O_APPEND, 0)) >= 0) {
(void)write(fd, (char *)ut, sizeof(struct utmp));
(void)close(fd);
}
and I''ve seen no problems so far (we don''t care about the
order of the writes,
and the worst that can happen is a couple of corrup wtmp entries).
Of course this "denial of service" doesn''t stop someone
connecting by rcmd or
rexec, so it can be detected and fixed.
[mod: You can''t assume that everybody is running rcmd/rexec. There
are good, security related, reasons for not running those.... -- REW]
-- Jon
From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38])
(dutecai.et.tudelft.nl rosie.et.tudelft.nl by
Received: (qmail 18037 invoked from network); 27 Nov 1996 22:38:05 -0000
Received: from softdnserror (HELO rosie.et.tudelft.nl) (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 22:38:03 -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 XAA04802 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 23:30:53 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id XAA10960
for linux-security@redhat.com; Wed, 27 Nov 1996 23:36:29 +0100
Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id RAA03985 for
<rogier@cave.et.tudelft.nl>; Wed, 27 Nov 1996 17:31:02 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id RAA19547; Wed, 27 Nov 1996 17:10:47 +0100
Received: (qmail 11077 invoked by uid 501); 27 Nov 1996 16:06:26 -0000
Received: (qmail 11047 invoked from network); 27 Nov 1996 16:06:22 -0000
Received: from softcon.com (tsiegel@205.216.96.189)
by mail2.redhat.com with SMTP; 27 Nov 1996 16:06:21 -0000
Received: from localhost (tsiegel@localhost) by softcon.com (8.7.5/8.7.5) with
SMTP id MAA09137 for <linux-security@redhat.com>; Wed, 27 Nov 1996
12:15:49 -0500
Date: Wed, 27 Nov 1996 12:15:49 -0500 (EST)
From: Travis Siegel <tsiegel@softcon.com>
Approved: R.E.Wolff@BitWizard.nl
To: linux-security@redhat.com
Subject: Re: [linux-security] Re: denial of service attack on login
In-Reply-To: <199611270540.XAA32687@sh1.ro.com>
Message-ID: <Pine.LNX.3.95.961127121443.9130A-100000@softcon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> > 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 ]
>
It doesn''t work on my (slightly) modified slackware 3.1 installation
either. Just for reference.
Http://softcon.com offers web pages for a reasonable rate, and will even
create pages for you at *very* fair rates. Check us out today if
you''re
looking for a home for your web pages.
From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38])
(dutecai.et.tudelft.nl rosie.et.tudelft.nl by
Received: (qmail 22806 invoked from network); 27 Nov 1996 22:45:17 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 22:45:16 -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 XAA04895 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 23:34:52 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id XAA11029
for linux-security@redhat.com; Wed, 27 Nov 1996 23:40:28 +0100
Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id XAA04844 for
<rogier@cave.et.tudelft.nl>; Wed, 27 Nov 1996 23:32:29 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id VAA28434; Wed, 27 Nov 1996 21:10:58 +0100
Received: (qmail 29194 invoked by uid 501); 27 Nov 1996 20:10:00 -0000
Received: (qmail 29150 invoked from network); 27 Nov 1996 20:09:56 -0000
Received: from i17linuxb.ists.pwr.wroc.pl (root@156.17.35.8)
by mail2.redhat.com with SMTP; 27 Nov 1996 20:09:53 -0000
Received: by i17linuxb.ists.pwr.wroc.pl
id m0vSqI9-0007qSC
(Debian Smail-3.2 1996-Jul-4 #3); Wed, 27 Nov 1996 21:09:09 +0100 (MET)
Message-Id: <m0vSqI9-0007qSC@i17linuxb.ists.pwr.wroc.pl>
From: marekm@i17linuxb.ists.pwr.wroc.pl (Marek Michalkiewicz)
Approved: R.E.Wolff@BitWizard.nl
Subject: Re: [linux-security] Re: denial of service attack on login
To: linux-security@redhat.com
Date: Wed, 27 Nov 1996 21:09:08 +0100 (MET)
Cc: johnsonm@redhat.com
In-Reply-To: <199611270540.XAA32687@sh1.ro.com> from "Chris
Adams" at Nov 26, 96 11:40:33 pm
X-Mailer: ELM [version 2.4 PL25 PGP2]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Chris Adams:> > joe$ nvi /var/log/wtmp
> >
> > [ Now no-one else can log in ]
>
> This doesn''t seem to happen on my system - RedHat 3.0.3 + shadow
> passwords. My /bin/login comes from shadow-960810-1. Maybe the
> shadow passowrd suite doesn''t try to lock wtmp?
Yes. It shouldn''t be necessary - the O_APPEND open() flag should be
enough to guarantee atomic writes at end of file (it''s a kernel bug
if it doesn''t). Original *BSD login sources don''t lock wtmp
either,
but util-linux does. Perhaps O_APPEND didn''t work right on old
kernels? Remember util-linux login was ported to Linux 0.12 :-).
Marek
From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38])
(dutecai.et.tudelft.nl rosie.et.tudelft.nl by
Received: (qmail 22864 invoked from network); 27 Nov 1996 22:45:22 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 27 Nov 1996 22:45:16 -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 XAA04892 for
<linux-security@redhat.com>; Wed, 27 Nov 1996 23:34:45 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id XAA11013
for linux-security@redhat.com; Wed, 27 Nov 1996 23:40:21 +0100
Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by
rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id XAA04855 for
<rogier@cave.et.tudelft.nl>; Wed, 27 Nov 1996 23:32:43 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id RAA21547; Wed, 27 Nov 1996 17:55:06 +0100
Received: (qmail 15243 invoked by uid 501); 27 Nov 1996 16:54:47 -0000
Received: (qmail 15230 invoked from network); 27 Nov 1996 16:54:44 -0000
Received: from tech.cyclades.com (root@208.138.19.34)
by mail2.redhat.com with SMTP; 27 Nov 1996 16:54:44 -0000
Received: from localhost by tech.cyclades.com
with smtp id m0vSnFx-0006NlC
(Debian Smail-3.2 1996-Jul-4 #3); Wed, 27 Nov 1996 08:54:41 -0800 (PST)
Date: Wed, 27 Nov 1996 08:54:41 -0800 (PST)
From: Paul Christenson <paul@tech.cyclades.com>
Approved: R.E.Wolff@BitWizard.nl
To: Linux Security <linux-security@redhat.com>
Subject: Re: [linux-security] denial of service attack on login
In-Reply-To: <199611261549.HAA16832@parc.power.net>
Message-ID: <Pine.LNX.3.95.961127085350.5482C-100000@tech.cyclades.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
It locks people out of Debian 1.2 as well.
+----------------------------------------------------+
| Technical Support Engineer, Cyclades Corporation |
| 800/88-CYCLADES (882-9252) or (510)770-9727, x258 |
| High Performance Multiport Serial Cards & Routers |
| Unsolicited mail ads subject to a $25 handling fee |
+----------------------------------------------------+
From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by
(8.6.10/1.34JP)
Received: (qmail 14221 invoked from network); 28 Nov 1996 12:58:15 -0000
Received: from rosie.et.tudelft.nl (130.161.127.248)
by mail2.redhat.com with SMTP; 28 Nov 1996 12:58:13 -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 NAA07149 for
<linux-security@redhat.com>; Thu, 28 Nov 1996 13:50:30 +0100
Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id NAA15134
for linux-security@redhat.com; Thu, 28 Nov 1996 13:56:27 +0100
Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP)
id LAA18094; Thu, 28 Nov 1996 11:45:26 +0100
Received: (qmail 30022 invoked by uid 501); 28 Nov 1996 10:45:05 -0000
Received: (qmail 30007 invoked from network); 28 Nov 1996 10:44:59 -0000
Received: from ghost.mimuw.edu.pl (148.81.13.1)
by mail2.redhat.com with SMTP; 28 Nov 1996 10:41:50 -0000
Received: from melkor.mimuw.edu.pl (melkor.mimuw.edu.pl [148.81.12.1]) by
ghost.mimuw.edu.pl (8.7.5/8.7.3) with SMTP id LAA04162 for
<linux-security@redhat.com>; Thu, 28 Nov 1996 11:41:12 +0100
Received: from localhost by melkor.mimuw.edu.pl (SMI-8.6/SMI-SVR4)
id LAA13888; Thu, 28 Nov 1996 11:41:47 +0100
Date: Thu, 28 Nov 1996 11:41:47 +0100 (MET)
From: "Andrzej K. Brandt" <andy@mimuw.edu.pl>
Approved: R.E.Wolff@BitWizard.nl
X-Sender: andy@melkor
To: Linux Security <linux-security@redhat.com>
Subject: Re: [linux-security] denial of service attack on login
In-Reply-To: <199611261549.HAA16832@parc.power.net>
Message-ID: <Pine.GSO.3.95.961128114119.12757S-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 ]
Doesn''t work on RedHat 4.0 on sparc.
[mod: Figures. Andrews introduction mentioned that he was looking at
old code for the implementation of the PAM project. So you''d guess
that they wouldn''t make the same mistake there as in the
"old"
code.... (PAM is included in Red Hat 4.0) -- REW]
--
/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I andy@linux.org.pl I
+-------------------+--------+-----+-------------+-------------------------+
| http://melkor.mimuw.edu.pl/~andy | IRC: Emin | PGP key available |
\--------------------------------------------------------------------------/
From mail@mail.redhat.com 7055 from invoked 14 network);
Hynek Med
1996-Nov-15 10:42 UTC
Re: [linux-security] Security hole in Debian 1.1 dosemu package
On 14 Nov 1996, Daniel Quinlan wrote:> In Debian 1.1, the optional DOSEMU package installs /usr/sbin/dos > setuid root. This is a serious security hole which can be exploited > to gain access to any file on the system.Dosemu, especially in older versions, has a lot of security holes (remember the one with unix.com?). I doubt it can be made totally secure, when it gives you direct control of hardware.. Putting someone to dosemu.users is almost the same as giving him root access. Hynek [REW: I wasn''t trivially able to reproduce this under Red Hat 3.0.3 (with patches for 2.0 kernel) and dosemu "0.60.4.5 $Date: 1995/05/06 16:25:30" Joshua Heling reports that Red Hat 4.0, dosemu 0.63.1 IS vulnerable.] -- Hynek Med, xmedh02@manes.vse.cz From mail@mail.redhat.com Sun Nov 17 04:36:35 1996