[601] in linux-security and linux-alert archive
Re: dump RedHat security hole
daemon@ATHENA.MIT.EDU (Remy Card)
Fri Feb 2 20:04:19 1996
From: card@excalibur.ibp.fr (Remy Card)
To: davem@cmu.edu (David J Meltzer)
Date: Sat, 3 Feb 1996 00:14:57 +0100 (MET)
Cc: linux-security@tarsier.cv.nrao.edu, linux-alert@tarsier.cv.nrao.edu,
marc@redhat.com
In-Reply-To: <El13r1W00YUv8llIgV@andrew.cmu.edu> from "David J Meltzer" at "Jan 22, 96 08:45:37 pm"
> [mod: Marc Ewing has already made available an RPM for this; the URL is
> ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/dump-0.2e-4.i386.rpm
> --okir]
>
> There is a security hole in RedHat 2.1, which installs /sbin/dump suid
> root. The dump program makes no provisions for checking file permissions,
> allowing any user on the system to read arbitrary files on the system.
> Dump checks permissions only on the directory you specify to backup, and
> not on files or subdirectories.
> The process to exploit this is to backup the files via dump as if it was
> a normal backup to a temporary file, and then restore the temporary file
> with /sbin/restore to your own directory. The solution is simple, don't
> run dump suid root on your system.
Firstly, people who think that they have found a security hole in a
program should contact the author/porter/maintainer/... I have ported 4.4BSD
dump to Linux and I maintain it and I never got any mail about this problem.
Secondly, this security hole does not even exist! I have just checked
and the problem, if any, is not in dump. Dump gives up its priviledges after
establishing a connection to a remote host and *before* opening the filesystem:
(void)setuid(getuid()); /* rmthost() is the only reason to be setuid */
If the calling user has read access on the special device, the open
succeeds and the user can backup the filesystem, but if the calling user does
not have read access on the device, the open fails:
bbj>id
uid=1001(card) gid=50(users) groups=50(users),0(wheel),19(disk)
bbj>ls -l /dev/hda2
brw-r----- 1 root disk 3, 2 Oct 3 1993 /dev/hda2
bbj>/sbin/dump 0f woot.dump /dev/hda2
DUMP: Date of this level 0 dump: Sat Feb 3 00:00:28 1996
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda2 (/) to woot.dump
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 92218 tape blocks on 2.37 tape(s).
DUMP: dumping (Pass III) [directories]
...
bbj>id
uid=2001(q1) gid=50(users) groups=50(users)
bbj>/sbin/dump 0f woot.dump /dev/hda2
DUMP: Date of this level 0 dump: Sat Feb 3 00:01:15 1996
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda2 (/) to woot.dump
/dev/hda2: Permission denied while opening filesystem
This happens when trying to backup a subtree as well.
So, I suspect that the problem is with the permissions on special files
and not in dump itself. BTW, if special files are readable by users, one can
use the ``debugfs'', ``dd'', ``strings'', and ``cat'' commands to view the
contents of files, and these commands are not even setuid! The right solution
to this problem is to fix the permissions on /dev entries.
Next time, please be more prudent before telling that a program
contains a security hole! At least, contact its maintainer to check with
him...
> Program: /sbin/dump incorrectly installed
> Affected Operating Systems: RedHat 2.1 linux distribution
> Requirements: account on system
> Patch: chmod -s /sbin/dump
> Security Compromise: read arbitrary files on system
> Author: Dave M. (davem@cmu.edu)
> Synopsis: dump fails to check file permissions against
> user running dump, or to give up suid when
> backing up a filesystem.
>
> Exploit:
> $ /sbin/dump 0uf woot.dump DIRECTORY_FILE_TO_READ_IS_IN
>
> /-------------\
> |David Meltzer|
> |davem@cmu.edu|
> /--------------------------\
> |School of Computer Science|
> |Carnegie Mellon University|
> \--------------------------/
Remy
[Mod: This is not the first time that this issue has come up. If you
are tempted to publicly announce a bug in something, please do not let
your zeal to get the word out overcome your general sensibilities;
contact the maintainer(s) of the package, if possible, prior to posting
a message to bugtraq, linux-{security,alert}, etc. Doing so can save
much in the way of embarrassment and/or hard feelings for *all* involved
parties. --Jeff.]
