Your message dated Sun, 06 Mar 2005 18:47:03 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#298114: fixed in nvi 1.79-22
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 4 Mar 2005 19:36:24 +0000
>From [EMAIL PROTECTED] Fri Mar 04 11:36:24 2005
Return-path: <[EMAIL PROTECTED]>
Received: from tornado.dat.etsit.upm.es (dat.etsit.upm.es) [138.100.17.73]
by spohr.debian.org with smtp (Exim 3.35 1 (Debian))
id 1D7Ib1-0005V4-00; Fri, 04 Mar 2005 11:36:23 -0800
Received: (qmail 24334 invoked by uid 1013); 4 Mar 2005 19:36:21 -0000
Date: Fri, 4 Mar 2005 20:36:21 +0100
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Nvi: Improved init.d recover file that fixes security bugs
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o"
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
--Fba/0zbH8Xs+Fj9o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Package: nvi
Version: 1.79-21
Priority: grave
Tags: security patch woody sid
Justification: local DoS
(Note: The bugs I talk about in this report have been present in Debian's
nvi for ages. Actually, OpenBSD provides an alternate 'recover'
implementation (attached) written in Perl that fixes most of this stuff in
probably a better way since it includes additional cheks than my patch to
the init.d file (also attached).)
Doing a security audit review of /tmp usage I've found that the
/etc/init.d/nviboot (it is also provided with other names in woody in the
nvi-m17n source package) is not coded in order to prevent some situations
that could be forced by local users to generate unexpected events. The fact
that this script runs as root on startup makes the bugs serious even if a
direct attack is not self evident.
The script has the following issues:
- Will run even if the binary and directory it uses are not available
- Will interpret any file even if it has been created by non-interactive=20
users that do not normally create vi.recover files
- Will follow symlinks
- Will work with directories, even if this generates errors later on (when=
=20
trying to read from them)
- PATH is unset
All of these are fixed in the attached patch.
If you think that the patch is not worth it, consider the following=20
hypotheses:
- A local user symlinks "recover.test" to /dev/zero: will cause a DoS when
the system whenever the system starts up. This is a local attack.
- A remote user compromises a service server in which mail use is
restricted to a given group (this is non-standard configuration, can be=20
implemented through capabitities or just chmoding 660 /usr/sbin/sendmail=20
or whatever it points to) and creates a "recover.test" file with:
=2E................................................
To: hacker
=46rom: root
X-vi-recover-path: /etc/passwd
System rebooted!
=2E
=2E................................................
He will get a mail whenever the system is rebooted. This can also be used=
=20
by local users to play tricks on other users ("I just got a mail from=20
root saying I should change my password to '111111'" :-)
- A bug is found in exim's implementation of sendmail -t (buffer overflow
when parsing headers?). When 'sendmail -t' is run with a rogue
'recover.hackme' file a local user can attempt a privilege escalation when
the server is rebooted since 'sendmail -t' will be run on whatever is in=20
/var/tmp/vi.recover as root.
- A local user creates a "recover.test" directory: error on startup
The patch:
- will delete any symlink files found in /var/tmp/vi.recover
- will refuse to work with directories that resemble recover files
- will call the sendmail binary with lower (nobody) privileges to prevent a=
=20
bug in sendmail from becoming a privilege escalation possibility.
- will delete any files found if they don't below to a "Joe user". It has=
=20
the cavea that root nvi recover sessions will also be removed (probably=20
one of the few admin user which will use nvi often). This behaviour can be=
=20
switched on or off.
- will set a proper PATH
Please include this patch or a similar one in the next release.
BTW, an alternative for the "won't send mails of admin users" it to not=20
honor the content of the recover file and mail to the owner of the file=20
(instead of to whomever the file says to in its 'To:' 'Resent-To', 'Bcc:',=
=20
'Cc:', 'Resent-Cc:' and 'Resent-Bcc:'
Thanks
Javier
--------------------------------------------------------------------------
--- init.orig 2005-03-01 00:18:16.000000000 +0100
+++ init 2005-03-01 00:49:38.000000000 +0100
@@ -3,8 +3,20 @@
#
# Script to recover nvi edit sessions.
#
+PATH=3D/sbin:/usr/sbin:/bin:/usr/bin
RECDIR=3D/var/tmp/vi.recover
SENDMAIL=3D/usr/sbin/sendmail
+SYSTEMUIDS=3D"no"
+
+[ ! -x "$SENDMAIL" ] && exit 0
+[ ! -d "$RECDIR" ] && exit 0
+
+FIRST_UID=3D""
+if [ -r /etc/adduser.conf ] ; then
+ FIRST_UID=3D`grep ^FIRST_UID /etc/adduser.conf | awk -F =3D '{print
$2}'`
+fi
+# Sane default
+[ -z "$FIRST_UID" ] && FIRST_UID=3D1000
=20
case "$1" in
start)
@@ -18,8 +30,15 @@
# would only happen if some loser is playing games with
# embedded spaces in vi recovery file names
i=3D$RECDIR/${i#$RECDIR/}
+ # Nvi editor backup files should not be symlinks.
+ # Delete them
+ if test -L $i ; then
+ rm $i
+ continue
+ fi
+
# Only test files that are readable.
- if test ! -r $i; then
+ if test ! -r $i -o test ! -f $i; then
continue
fi
=20
@@ -27,7 +46,17 @@
# execute bit set or are zero length. Delete them.
if test -x $i -o ! -s $i; then
rm $i
+ continue
fi
+
+
+ # Files that belong to administrative users are
+ # discarded
+ if [ "$SYSTEMUIDS" =3D "no" ] && \
+ [ "`/usr/bin/stat -c %u $i`" -lt "$FIRST_UID" ]; then
+ rm $i
+ fi
+
done
fi
=20
@@ -40,17 +69,30 @@
# would only happen if some loser is playing games with
# embedded spaces in vi recovery file names
i=3D$RECDIR/${i#$RECDIR/}
+ # Discard symlinks
+ if test -L $i ; then
+ rm $i
+ continue
+ fi
# Only test files that are readable.
- if test ! -r $i; then
+ if test ! -r $i -o ! -f $i; then
continue
fi
=20
+ # Files that belong to administrative users are
+ # discarded
+ if [ "$SYSTEMUIDS" =3D "no" ] && \
+ [ "`/usr/bin/stat -c %u $i`" -lt "$FIRST_UID" ]; then
+ rm $i
+ continue
+ fi
+
# Delete any recovery files that are zero length, corrupted,
# or that have no corresponding backup file. Else send mail
# to the user.
recfile=3D`awk '/^X-vi-recover-path:/{print $2}' < $i`
if test -n "$recfile" -a -s "$recfile"; then
- ($SENDMAIL -t < $i &) </dev/null >/dev/null 2>&0
+ (su - nobody -c $SENDMAIL -t < $i &) </dev/null
>/dev/null 2>&0
else
rm $i
fi
--------------------------------------------------------------------------
#!/usr/bin/perl -w
#
# $OpenBSD: recover,v 1.9 2001/11/06 23:31:08 millert Exp $
#
# Script to (safely) recover nvi edit sessions.
#
use Fcntl;
require 'sys/syscall.ph';
$recoverdir =3D $ARGV[0] || "/var/tmp/vi.recover";
$sendmail =3D "/usr/sbin/sendmail";
die "Sorry, $0 must be run as root\n" if $>;
# Make the recovery dir if it does not already exist.
if (!sysopen(DIR, $recoverdir, O_RDONLY|O_NOFOLLOW) || !stat(DIR)) {
die "Warning! $recoverdir is a symbolic link! (ignoring)\n"
if -l $recoverdir;
mkdir($recoverdir, 01777) || die "Unable to create $recoverdir: $!\n";
chmod(01777, $recoverdir);
exit(0);
}
#
# Sanity check the vi recovery dir
# Perl doesn't support fchdir, fchmod, or fchown so we call
# fchdir(2) via the syscall interface and then just modify ".".
#
die "Warning! $recoverdir is not a directory! (ignoring)\n"
unless -d _;
die "$0: can't chdir to $recoverdir: $!\n"
unless syscall(&SYS_fchdir, fileno(DIR)) =3D=3D 0;
if (! -O _) {
warn "Warning! $recoverdir is not owned by root! (fixing)\n";
chown(0, 0, ".");
}
if (((stat(_))[2] & 07777) !=3D 01777) {
warn "Warning! $recoverdir is not mode 01777! (fixing)\n";
chmod(01777, ".");
}
# Check editor backup files.
opendir(RECDIR, ".") || die "$0: can't open $recoverdir: $!\n";
foreach $file (readdir(RECDIR)) {
next unless $file =3D~ /^vi\./;
#
# Unmodified vi editor backup files either have the
# execute bit set or are zero length. Delete them.
# Anything that is not a normal file gets deleted too.
#
lstat($file) || die "$0: can't stat $file: $!\n";
if (-x _ || ! -s _ || ! -f _) {
unlink($file) unless -d _;
}
}
#
# It is possible to get incomplete recovery files if the editor crashes
# at the right time.
#
rewinddir(RECDIR);
foreach $file (readdir(RECDIR)) {
next unless $file =3D~ /^recover\./;
if (!sysopen(RECFILE, $file, O_RDONLY|O_NOFOLLOW)) {
warn "$0: can't open $file: $!\n";
next;
}
#
# Delete anything that is not a regular file as that is either
# filesystem corruption from fsck or an exploit attempt.
#
if (!stat(RECFILE)) {
warn "$0: can't stat $file: $!\n";
close(RECFILE);
next;
}
$owner =3D (stat(_))[4];
if (! -f _ || ! -s _) {
unlink($file) unless -d _;
close(RECFILE);
next;
}
#
# Slurp in the recover.* file and search for X-vi-recover-path
# (which should point to an existing vi.* file).
#
@recfile =3D <RECFILE>;
close(RECFILE);
#
# Delete any recovery files that have no (or more than one)
# corresponding backup file.
#
@backups =3D grep(m#^X-vi-recover-path:\s*\Q$recoverdir\E/+#, @recfile);
if (@backups !=3D 1) {
unlink($file);
next;
}
#
# Make a copy of the backup file path.
# We must not modify @backups directly since it contains
# references to data in @recfile which we pipe to sendmail.
#
$backups[0] =3D~ m#^X-vi-recover-path:\s*\Q$recoverdir\E/+(.*)[\r\n]*$#;
$backup =3D $1;
#
# If backup file is not rooted in the recover dir, ignore it.
# If backup file owner doesn't match recovery file owner, ignore it.
# If backup file is zero length or not a regular file, remove it.
# Else send mail to the user.
#
if ($backup =3D~ m#/# || !lstat($backup)) {
unlink($file);
} elsif ($owner !=3D 0 && (stat(_))[4] !=3D $owner) {
unlink($file);
} elsif (! -f _ || ! -s _) {
unlink($file, $backup);
} else {
open(SENDMAIL, "|$sendmail -t") ||
die "$0: can't run $sendmail -t: $!\n";
print SENDMAIL @recfile;
close(SENDMAIL);
}
}
closedir(RECDIR);
close(DIR);
exit(0);
----- End forwarded message -----
--=20
--Fba/0zbH8Xs+Fj9o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCKLi1i4sehJTrj0oRArI6AKCBlbNJgw5j1zszmPhYqlDUSWwl0QCfevin
bOLx+K+Dkg6mKI/R1Kyv3HQ=
=abli
-----END PGP SIGNATURE-----
--Fba/0zbH8Xs+Fj9o--
---------------------------------------
Received: (at 298114-close) by bugs.debian.org; 6 Mar 2005 23:53:02 +0000
>From [EMAIL PROTECTED] Sun Mar 06 15:53:02 2005
Return-path: <[EMAIL PROTECTED]>
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D85YU-0003zU-00; Sun, 06 Mar 2005 15:53:02 -0800
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1D85Sh-0001Ts-00; Sun, 06 Mar 2005 18:47:03 -0500
From: Steve Greenland <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.55 $
Subject: Bug#298114: fixed in nvi 1.79-22
Message-Id: <[EMAIL PROTECTED]>
Sender: Archive Administrator <[EMAIL PROTECTED]>
Date: Sun, 06 Mar 2005 18:47:03 -0500
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
X-CrossAssassin-Score: 2
Source: nvi
Source-Version: 1.79-22
We believe that the bug you reported is fixed in the latest version of
nvi, which is due to be installed in the Debian FTP archive:
nvi_1.79-22.diff.gz
to pool/main/n/nvi/nvi_1.79-22.diff.gz
nvi_1.79-22.dsc
to pool/main/n/nvi/nvi_1.79-22.dsc
nvi_1.79-22_i386.deb
to pool/main/n/nvi/nvi_1.79-22_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Steve Greenland <[EMAIL PROTECTED]> (supplier of updated nvi package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 6 Mar 2005 17:21:34 -0600
Source: nvi
Binary: nvi
Architecture: source i386
Version: 1.79-22
Distribution: unstable
Urgency: low
Maintainer: Steve Greenland <[EMAIL PROTECTED]>
Changed-By: Steve Greenland <[EMAIL PROTECTED]>
Description:
nvi - 4.4BSD re-implementation of vi
Closes: 207720 298114
Changes:
nvi (1.79-22) unstable; urgency=low
.
* Create/fix /var/tmp/vi.recover in postinst (closes: #207720)
* Take more care in handling of recovery files in nviboot. The nviboot
script now ignores entries that are not regular files, calls sendmail
as user "nobody", and send mail to the owner of the recover file, not
the "To:" header in the recovery file. (closes: #298114)
Files:
a29fd62c5d98f2476556fd5802f1dd57 555 editors important nvi_1.79-22.dsc
f6adb1779c78ddc6b07df8b13f37e324 13374 editors important nvi_1.79-22.diff.gz
0dd7f7fb47fc92b6f5813a2874dc64fb 288166 editors important nvi_1.79-22_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCK5NddiZsUPux21MRAjXdAJ9tyaoLN+xjjy4XWPdaqOd7KReUGQCeNpF8
klzPMHSYokQ7UOZkNG5sAtU=
=4B4y
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
