From owner-freebsd-security Sun Apr 27 18:11:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA09945 for security-outgoing; Sun, 27 Apr 1997 18:11:26 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA09940 for ; Sun, 27 Apr 1997 18:11:21 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wLexe-0006zz-00; Sun, 27 Apr 1997 19:10:34 -0600 To: The Code Warrior Subject: Re: SNI-12: BIND Vulnerabilities and Solutions (fwd) Cc: Dmitry Valdov , freebsd-security@freebsd.org In-reply-to: Your message of "Wed, 23 Apr 1997 10:15:30 -0000." References: Date: Sun, 27 Apr 1997 19:10:33 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message The Code Warrior writes: I haven't checked the gethostby* libs, so I'm not sure if the : resolver does internal bounds checking, rather than just letting you overflow : the stack with a spoofed DNS name. I have. There are some, but not a lot. I've been trying to plug them as I find them. Most of them have long ago been plugged. And the name doesn't need to be spoofed either. You just need control over the in-addr.arpa domain for the IP numbers that you claim to be coming from for this attack to work. Warner From owner-freebsd-security Sun Apr 27 18:15:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA10146 for security-outgoing; Sun, 27 Apr 1997 18:15:15 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA10138 for ; Sun, 27 Apr 1997 18:15:12 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wLf1v-00070G-00; Sun, 27 Apr 1997 19:15:00 -0600 To: Dmitry Valdov Subject: Re: SNI-12: BIND Vulnerabilities and Solutions (fwd) Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Tue, 22 Apr 1997 23:13:57 +0400." References: Date: Sun, 27 Apr 1997 19:14:59 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Dmitry Valdov writes: : Is fbsd 2.2.1 vulnerable? If yes are there any patches available specially : for FreeBSD? Generally, FreeBSD is vulnerable to the predictable sequence numbers, but not to the buffer overflow. I'm relatively sure that all the setuid programs have been fixed. I'm less certain that all of the places in the tree have been fixed, however. Warner From owner-freebsd-security Sun Apr 27 19:36:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA14035 for security-outgoing; Sun, 27 Apr 1997 19:36:30 -0700 (PDT) Received: from utopia.nh.ultranet.com (jbowie@this.wanker.is.a.teensysop.org [207.41.158.32]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA14030 for ; Sun, 27 Apr 1997 19:36:23 -0700 (PDT) Received: from localhost (jbowie@localhost) by utopia.nh.ultranet.com (8.8.5/8.8.5) with SMTP id WAA00427; Sun, 27 Apr 1997 22:35:49 GMT X-Authentication-Warning: utopia.nh.ultranet.com: jbowie owned process doing -bs Date: Sun, 27 Apr 1997 22:35:48 +0000 (GMT) From: The Code Warrior X-Sender: jbowie@utopia.nh.ultranet.com To: Warner Losh cc: Dmitry Valdov , freebsd-security@freebsd.org Subject: Re: SNI-12: BIND Vulnerabilities and Solutions (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 27 Apr 1997, Warner Losh wrote: > I have. There are some, but not a lot. I've been trying to plug them > as I find them. Most of them have long ago been plugged. As have I. > > And the name doesn't need to be spoofed either. You just need control > over the in-addr.arpa domain for the IP numbers that you claim to be > coming from for this attack to work. I'm well aware of this just commented on it due to the nature of the thread, wouldn't want to give any "impressionable" young children any ideas. :) As always I thank you for your imput. Maybe coming up with a kernel mod, using a new transport medium might be the answer. I mean if you reinvent the packet medium I suppose you could eliminate this sort of problem with better packet handling on the localhosts and / or routers. Regardless though, It seems to me that you could just come up with a version of named in which the server that the request is going to makes a secondary request to an undisclosed ns verifying the authenticity of the incoming packet. Any thoughts? -Jon Bowie SysAdmin / Consulting / TeenSysop 603-436-5698 jobe@insomnia.org jbowie@taco.net jbowie@teensysop.org jbowie@eliteness.org jbowie@bsdnet.org From owner-freebsd-security Mon Apr 28 05:24:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA11400 for security-outgoing; Mon, 28 Apr 1997 05:24:20 -0700 (PDT) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA11392 for ; Mon, 28 Apr 1997 05:24:13 -0700 (PDT) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id OAA22722; Mon, 28 Apr 1997 14:21:50 +0200 (MET DST) Received: from oo7 (pc136.dimaga.com [192.0.0.136]) by dimaga.com (8.7.5/8.7.2) with SMTP id MAA14994; Mon, 28 Apr 1997 12:02:33 +0200 (MET DST) Message-Id: <3.0.32.19970428110452.00f97100@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Apr 1997 11:04:53 +0200 To: Brian Buchanan From: Eivind Eklund Subject: Re: Lowering securelevel from userland Cc: security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 11:17 AM 4/26/97 -0700, Brian Buchanan wrote: >Description: > >On my 2.2.1 system, I was able to lower the securelevel by taking over >init with gdb. I compiled a copy of init with debug symbols by using >-ggdb in the compile flags, then ran gdb using that for the symbol table >and attached to process 1. I was able to execute setsecuritylevel(0) from >gdb, although this caused the process to hang. Sending a signal woke it >up long enough to let the securelevel get changed from 2 to 0 before init >died with a segmentation fault. Even though the system was in an unstable >state, I was able to remove the schg flags from /kernel and /sbin/init >before rebooting the machine from the command line. > >Impact: > >An attacker who has gained superuser privilages can replace the kernel, >delete append-only logs, or thrash the disks, even on a system that >normally runs in highly secure mode. > >Exploit: > >One can do the following as the superuser to gain total control of a >machine running at securelevel 1 or 2. > >gdb /usr/src/sbin/init/init.debug 1 (Attach to process 1, loading > symbols from init compiled w/ -ggdb) >signal SIGHUP (Process will get SIGHUP when it resumes) >call setsecuritylevel(0) (Make init lower the security level) > > flags from files, reboot the machine> Here is a patch that _should_ fix it (2.1.7 sourcebase, as I'm not in the vicinity of the -current sources right now.) --- init.c.orig Mon Apr 28 11:52:04 1997 +++ init.c Mon Apr 28 11:57:58 1997 @@ -235,7 +235,7 @@ */ handle(badsys, SIGSYS, 0); handle(disaster, SIGABRT, SIGFPE, SIGILL, SIGSEGV, - SIGBUS, SIGXCPU, SIGXFSZ, 0); + SIGBUS, SIGXCPU, SIGXFSZ, SIGEMT, SIGQUIT, SIGTRAP, 0); handle(transition_handler, SIGHUP, SIGINT, SIGTERM, SIGTSTP, 0); handle(alrm_handler, SIGALRM, 0); sigfillset(&mask); I can't test this patch, as I can't reboot the local server right now, and doing remote experiments with init isn't my idea of 'safe'. Please tell whether it seem to fix the problem, and I'll commit it if it does. (After having done my own tests, too - init is critical...) Eivind. From owner-freebsd-security Mon Apr 28 09:51:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24025 for security-outgoing; Mon, 28 Apr 1997 09:51:10 -0700 (PDT) Received: from silence.secnet.com ([199.185.231.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24019 for ; Mon, 28 Apr 1997 09:51:07 -0700 (PDT) Received: from localhost (davids@localhost) by silence.secnet.com (8.8.5/secnet) with SMTP id KAA02331 for ; Mon, 28 Apr 1997 10:55:17 -0600 (MDT) Date: Mon, 28 Apr 1997 10:55:16 -0600 (MDT) From: David Sacerdote To: freebsd-security@freebsd.org Subject: Re: Attaching to init with a debugger Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yes, attaching to init with a debugger is a serious issue. OpenBSD fixed this several months ago by forbidding debuggers to attach to pid 1 when the securelevel > 0. If you choose to take this tack in dealing with the problem, make sure you fix not only the system call based interface, but procfs as well. Also, don't forget that you can read symbol tables for a program from a seperate file; so the copy of init on the system need not have been compiled with -ggdb; the attacker needs merely to have source code for it. David Sacerdote From owner-freebsd-security Tue Apr 29 16:51:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA18675 for security-outgoing; Tue, 29 Apr 1997 16:51:35 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18670 for ; Tue, 29 Apr 1997 16:51:32 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.7.3) with SMTP id TAA18574 for ; Tue, 29 Apr 1997 19:51:29 -0400 Date: Tue, 29 Apr 1997 19:51:29 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: security@freebsd.org Subject: vulnerabilities in kerberos (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Most of the stuff in this bulletin is not relevant to FreeBSD's eBones distribution, as it's Kerberos IV, but near the bottom they start talking about some Kerberos IV stuff that was vulnerable in OpenBSD's KerbIV stuff until recently. BTW, is anyone actively maintaining the Kerberos code in FreeBSD? Have we given any thought to bringing in the Kth code instead, as it's more modern, etc? I've noticed, also, that the Krb distribution for FreeBSD doesn't include the kerberos-authenticated FTPd, so one has to make that independantly and set flags appropriately. That should probably be corrected. ---- Robert Watson ---------- Forwarded message ---------- Date: Tue, 29 Apr 1997 13:09:02 -0600 From: David Sacerdote To: BUGTRAQ@NETSPACE.ORG Subject: vulnerabilities in kerberos -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. Security Advisory April 29, 1997 Vulnerabilities in Kerberos V This advisory details two serious vulnerabilities in Kerberos V, which allow attackers to obtain root access to kerberos clients and servers. Problem Descriptions: ~~~~~~~~~~~~~~~~~~~~~ Problem 1 : Kerberos V sites which are running Kerberos IV programs and using the Kerberos IV compatibility libraries, including certain bones derived kerberos IV implementations are vulnerable to a localhost buffer overflow. The problem is exploitable if there are setuid or setgid programs (such as a Kerberized rlogin) which use kerberos IV functions. The problem occurs when certain kerberos programs permit the specification of the kerberos configuration file via an environment variable, and do not perform proper checking on this environment variable. Problem 2 : Systems running the Kerberos V telnet daemon are vulnerable to a buffer overflow in the Kerberized telnet daemon. This buffer overflow can allow remote root access to unauthorized users. Technical Details ~~~~~~~~~~~~~~~~~ Problem 1 : This problem stems from a feature in the Kerberos IV compatibility library under Kerberos V. The problem occurs when incorrect bounds checking is applied to reading in configuration files which may be stipulated via an enviroment variable. If a malicous user stipulates a hand crafted config file they can successfully overflow a buffer and sieze root privileges if any setuid programs call the problem functions in the library. The following code in src/lib/krb4/g_krbhst.c illustrates the problem: int INTERFACE krb_get_krbhst(h,r,n) char *h; char *r; int n; { FILE *cnffile, *krb__get_cnffile(); char tr[REALM_SZ]; char linebuf[BUFSIZ]; register int i; cnffile = krb__get_cnffile(); if (!cnffile) return get_krbhst_default(h, r, n) if (fscanf(cnffile,"%s",tr) == EOF) return get_krbhst_default(h, r, n); Where the krb__get_cnffile() function returns a descriptor to the file pointed to by the environment variable KRB_CONF, or a descriptor to the config file in the default location. The same set of problems, with a different environment variable name, exist in the KTH 0.9.3, OpenBSD 2.0, and Cygnus R3 bones derived kerberos IV distributions. Problem 2: The second problem lies in the kerberized telnet daemon which due to improper bounds checking of the TERM variable is vulnerable to a remote buffer overflow. The following function start_login() in sys_term.c illustrates the problem : ... char speed[128]; .... sprintf(speed, "%s/%d", (cp = getenv("TERM")) ? cp : "", (def_rspeed > 0) ? def_rspeed : 9600); ... Impact ~~~~~~ Problem 1 : Setuid programs using kerberos can allow shell users to gain unauthorized root access to vulnerable systems. Problem 2 : Remote individuals can gain root access to hosts running the Kerberos V telnet daemon. Vulnerable Systems ~~~~~~~~~~~~~~~~~~ Problem 1 : Sites running setuid or setgid Kerberos IV programs and using the Kerberos IV compatibility libraries in Kerberos V 1.0 are vulnerable to the environment variable config file buffer overflow. In addition, a number of bones derived kerberos IV implementations have had environment variable based config file override feature added. The KTH (version 0.9.3) distribution, the one in OpenBSD 2.0 as well as OpenBSD-current prior to 27 March 1997, and the Cygnus R3 distribution all appear to have this problem. The standard vanilla MIT Kerberos IV code is NOT vulnerable to this problem. Problem 2 : Any system running the Kerberos V 1.0 telnet daemon is vulnerable to the buffer overflow in it. Fix information ~~~~~~~~~~~~~~~ The problems described in Kerberos V are fixed by updating your Kerberos installation to Kerberos V 1.0 patch level 1. Information about obtaining the update to Kerberos V can be found at http://web.mit.edu/kerberos/www/krb5-1.0/announce.html OpenBSD users should update to OpenBSD-current via anoncvs, and recompile their kerberos libraries. Cygnus plans to release patches for the Cygnus Kerberos distributions shortly. Additional Information ~~~~~~~~~~~~~~~~~~~~~~ If you have any questions about this advisory, feel free to mail me at davids@secnet.com. Past Secure Networks advisories can be found at ftp://ftp.secnet.com/pub/advisories, and Secure Networks papers can be found at ftp://ftp.secnet.com/pub/papers. This advisory was written by David Sacerdote. Kerberos is a trademark of the Massachusetts Institute of Technology (MIT). Information on obtaining the MIT Kerberos IV and V distributions can be found at ftp://athena-dist.mit.edu/pub/kerberos Many thanks to AusCERT , Mark Eichin , Theodore Y. Ts'o and Thorstern Lockert for the invaluable assistance and feedback they provided during the preparation of this advisory. Feel free to send responses and commments to sni@secnet.com. If you should wish to encrypt such traffic, please use the Secure Networks Inc. key: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM03n 27Tl3s+VYMi5AQHdGwP+N3hhILzzhSvhx1gj6ZElgsLa7Q1P3cTlc/Xqx50/wkcX qIwiPudH+9UHvpL8fUNaHc9iZf3y8YZz0HWz56Vm5SG7uBfB/ksq4x04pQ65dQ1m v51DYCvLG9u0jL4hC3Mz9WvIMANXqOUlAhuU1iy0wM41joE8aHdh2jsLHlB5qlSJ AJUDBRAzTlbK/3eiMPDVSG0BAcTNA/9eF0X4Ei8LM4CXFW7JTB5vwXxerR6FmKI8 0JXt6KTrjGBzTfBrDGUZHNakPELjQPQI+fqg6hKJ7Ro1eSL4QbtX2BTO+wIWoLJG hQmccKleuEK5N9vFgzvPTRknfkbqL1Ta7g3Z9tE8TQhFbj0x4yNFAPB/hOhVvY3s YOkUx4T12A== =ljNl - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc, and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. Kerberos sources distributed in this advisory fall under some or all of the following license(s): Copyright (C) 1996 by the Massachusetts Institute of Technology. All rights reserved. Export of this software from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. Individual source code files are copyright MIT, Cygnus Support, OpenVision, Oracle, Sun Soft, and others. Project Athena, Athena, Athena MUSE, Discuss, Hesiod, Kerberos, Moira, and Zephyr are trademarks of the Massachusetts Institute of Technology (MIT). No commercial use of these trademarks may be made without prior written permission of MIT. "Commercial use" means use of a name in a product or other for-profit manner. It does NOT prevent a commercial firm from referring to the MIT trademarks in order to convey information (although in doing so, recognition of their trademark status should be given). The following copyright and permission notice applies to the OpenVision Kerberos Administration system located in kadmin/create, kadmin/dbutil, kadmin/passwd, kadmin/server, lib/kadm5, and portions of lib/rpc: Copyright, OpenVision Technologies, Inc., 1996, All Rights Reserved WARNING: Retrieving the OpenVision Kerberos Administration system source code, as described below, indicates your acceptance of the following terms. If you do not agree to the following terms, do not retrieve the OpenVision Kerberos administration system. You may freely use and distribute the Source Code and Object Code compiled from it, with or without modification, but this Source Code is provided to you "AS IS" EXCLUSIVE OF ANY WARRANTY, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR ANY OTHER WARRANTY, WHETHER EXPRESS OR IMPLIED. IN NO EVENT WILL OPENVISION HAVE ANY LIABILITY FOR ANY LOST PROFITS, LOSS OF DATA OR COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, INCLUDING, WITHOUT LIMITATION, THOSE RESULTING FROM THE USE OF THE SOURCE CODE, OR THE FAILURE OF THE SOURCE CODE TO PERFORM, OR FOR ANY OTHER REASON. OpenVision retains all copyrights in the donated Source Code. OpenVision also retains copyright to derivative works of the Source Code, whether created by OpenVision or by a third party. The OpenVision copyright notice must be preserved if derivative works are made based on the donated Source Code. OpenVision Technologies, Inc. has donated this Kerberos Administration system to MIT for inclusion in the standard Kerberos 5 distribution. This donation underscores our commitment to continuing Kerberos technology development and our gratitude for the valuable work which has been performed by MIT and the Kerberos community. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM2YB5LgIhFKeVQANAQGJgQQAqePoUOiUJ4R2TnVKMORGKs9KQNDKFh3z xr0XEP2pJKTQPzJEnP4t/V7a65ZJp6O2AYW7vpVC3iZcdgeanQgl6qA0HVbt+7XR PX3YNNMCEANxdHriJu+g0/pgSQBSDTZb+DCpURYibWuN4ngPUNXFqSGklXREUfO2 eFyRZPgKQzc= =vYmT -----END PGP SIGNATURE----- From owner-freebsd-security Tue Apr 29 23:39:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09583 for security-outgoing; Tue, 29 Apr 1997 23:39:21 -0700 (PDT) Received: from grackle.grondar.za (grackle.grondar.za [196.7.18.131]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09577 for ; Tue, 29 Apr 1997 23:39:15 -0700 (PDT) Received: from grackle.grondar.za (localhost [127.0.0.1]) by grackle.grondar.za (8.8.5/8.8.4) with ESMTP id IAA03856; Wed, 30 Apr 1997 08:38:55 +0200 (SAT) Message-Id: <199704300638.IAA03856@grackle.grondar.za> To: Robert N Watson cc: security@freebsd.org Subject: Re: vulnerabilities in kerberos (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 1997 08:38:52 +0200 From: Mark Murray Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 29 Apr 1997 19:51:29 -0400 (EDT) , Robert N Watson wrote: > Most of the stuff in this bulletin is not relevant to FreeBSD's eBones > distribution, as it's Kerberos IV, but near the bottom they start talking > about some Kerberos IV stuff that was vulnerable in OpenBSD's KerbIV stuff > until recently. OK... > BTW, is anyone actively maintaining the Kerberos code in FreeBSD? Have we Yes. Me. (But I have been kinda slack). > given any thought to bringing in the Kth code instead, as it's more > modern, etc? I've noticed, also, that the Krb distribution for FreeBSD > doesn't include the kerberos-authenticated FTPd, so one has to make that > independantly and set flags appropriately. That should probably be > corrected. I am going to commit KTH eBones one of these days (RSN). I have been INCREDIBLY busy at work, and owe them a lot of time for sick leave last year. KTH has a lot of nice toys, and they fix very many problems, like multi- homed hosts, some buffer overruns, etc. I have a license to bring in Kerberos5 as well. That code _really_ sucks, though. It is all over the place, and getting it "bmaked" is a much longer term project. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-security Wed Apr 30 06:15:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA25457 for security-outgoing; Wed, 30 Apr 1997 06:15:25 -0700 (PDT) Received: from tgsoft.com (squirrel.tgsoft.com [207.167.64.183]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA25448 for ; Wed, 30 Apr 1997 06:15:19 -0700 (PDT) Received: (qmail 11351 invoked by uid 128); 30 Apr 1997 13:15:17 -0000 Date: 30 Apr 1997 13:15:17 -0000 Message-ID: <19970430131517.11350.qmail@tgsoft.com> From: mark thompson To: jmg@hydrogen.nike.efn.org CC: security@freefall.FreeBSD.ORG In-reply-to: message from John-Mark Gurney on Fri, 25 Apr 1997 00:55:33 -0700 Subject: Re: What's on Port 1024? Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: John-Mark Gurney Date: Fri, 25 Apr 1997 00:55:33 -0700 joed@ksu.edu scribbled this message on Apr 24: > Greetings, > > I'm currently in the proccess of trying to lock down a FreeBSD workstation > as a firewall, and noticed that my FreeBSD machine is listening to port > 1024. I'm fairly stumped as to what this might be.. According to the > port number database (http://www.sockets.com/services.htm) 1024 is > reserved. > > Any thought as to what's listening to this port? try: lsof | grep 1024 on my machine it returns a line like: xdm 214 root 5u inet 0xf17bbc00 0t0 TCP *:1024 so it looks like the process is xdm.... ttyl.. Interesting. On my machine (2.2.1) I have the following bits: bash$ sudo lsof | grep UDP [skip...] inetd 139 root 18u inet 0xf1a77b00 0t0 UDP *:1024 inetd 139 root 19u inet 0xf1a77a80 0t0 UDP *:blackjack [skip...] blackjack is 1025. Since neither of these is in inetd.conf, i wonder whazzup? -mark From owner-freebsd-security Wed Apr 30 07:18:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA28279 for security-outgoing; Wed, 30 Apr 1997 07:18:30 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA28273 for ; Wed, 30 Apr 1997 07:18:27 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id HAA28777; Wed, 30 Apr 1997 07:17:01 -0700 (PDT) Message-ID: <19970430071701.18377@hydrogen.nike.efn.org> Date: Wed, 30 Apr 1997 07:17:01 -0700 From: John-Mark Gurney To: mark thompson Cc: security@freefall.FreeBSD.ORG Subject: Re: What's on Port 1024? References: <19970430131517.11350.qmail@tgsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970430131517.11350.qmail@tgsoft.com>; from mark thompson on Wed, Apr 30, 1997 at 01:15:17PM -0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk try to use my Reply-To instead of From... mark thompson scribbled this message on Apr 30: > From: John-Mark Gurney > Date: Fri, 25 Apr 1997 00:55:33 -0700 > > joed@ksu.edu scribbled this message on Apr 24: > > I'm currently in the proccess of trying to lock down a FreeBSD workstation > > as a firewall, and noticed that my FreeBSD machine is listening to port > > 1024. I'm fairly stumped as to what this might be.. According to the > > port number database (http://www.sockets.com/services.htm) 1024 is > > reserved. > try: lsof | grep 1024 > on my machine it returns a line like: > xdm 214 root 5u inet 0xf17bbc00 0t0 TCP *:1024 > > so it looks like the process is xdm.... > Interesting. On my machine (2.2.1) I have the following bits: > > bash$ sudo lsof | grep UDP > [skip...] > inetd 139 root 18u inet 0xf1a77b00 0t0 UDP *:1024 > inetd 139 root 19u inet 0xf1a77a80 0t0 UDP *:blackjack > [skip...] > > blackjack is 1025. Since neither of these is in inetd.conf, i wonder > whazzup? hmm. run rpcinfo and see if they are bounded to anything... they would probably be responsible for it... of course mine starts at 1040 though... now for a couple puzzlers... Apache 1.2b3, bash 1.14.7(1)... httpd 4431 nobody 7u inet 0xf17dfd80 0t0 UDP *:2027 bash 28573 jmg 4u inet 0xf1ad0e80 0t0 UDP *:3745 I've verified that these ports are listening (via netstat) so it isn't lsof miss reading kernel structs... -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-security Thu May 1 08:21:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA29133 for security-outgoing; Thu, 1 May 1997 08:21:40 -0700 (PDT) Received: from gateway.oaks.com.au (gateway.oaks.com.au [203.29.75.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA29125 for ; Thu, 1 May 1997 08:21:36 -0700 (PDT) Received: (from maillist@localhost) by gateway.oaks.com.au (8.7.6/8.6.12) id BAA21766 for freebsd-security@freebsd.org; Fri, 2 May 1997 01:21:23 +1000 (EST) From: Chris Cason Message-Id: <199705011521.BAA21766@gateway.oaks.com.au> Subject: MS Exchange mail server and port 137 To: freebsd-security@freebsd.org Date: Fri, 2 May 1997 01:21:22 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently noticed that, a few seconds after I sent an email to a a recipient who was using Microsoft Exchange server internet mail connector version 4.0.994.63, my IPFW setup logged to the console that several probes came to UDP port 137 (Netbios name service.) I've only recently firewalled these ports out so this may be a common occurrance ... has anyone seen this before, or know why they do it ? Is the ME server looking for host information automatically ? -- Chris From owner-freebsd-security Thu May 1 13:02:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12709 for security-outgoing; Thu, 1 May 1997 13:02:13 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12698 for ; Thu, 1 May 1997 13:02:08 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA29546; Thu, 1 May 1997 14:01:53 -0600 (MDT) Date: Thu, 1 May 1997 14:01:53 -0600 (MDT) Message-Id: <199705012001.OAA29546@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chris Cason Cc: freebsd-security@freebsd.org Subject: Re: MS Exchange mail server and port 137 In-Reply-To: <199705011521.BAA21766@gateway.oaks.com.au> References: <199705011521.BAA21766@gateway.oaks.com.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I recently noticed that, a few seconds after I sent an email to a > a recipient who was using Microsoft Exchange server internet mail > connector version 4.0.994.63, my IPFW setup logged to the console > that several probes came to UDP port 137 (Netbios name service.) > > I've only recently firewalled these ports out so this may be a > common occurrance ... has anyone seen this before, or know why > they do it ? Is the ME server looking for host information > automatically ? I see them all the time when I hit certain WWW sites. I'm not sure what is going on, but I've learned to ignore them. Nate From owner-freebsd-security Thu May 1 13:54:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA15995 for security-outgoing; Thu, 1 May 1997 13:54:44 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA15986 for ; Thu, 1 May 1997 13:54:41 -0700 (PDT) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.5/8.8.5) with SMTP id QAA11131 for ; Thu, 1 May 1997 16:54:39 -0400 (EDT) Date: Thu, 1 May 1997 16:54:39 -0400 (EDT) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net Reply-To: Bradley Dunn To: freebsd-security@freebsd.org Subject: Telnetd problem? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From src/libexec/telnetd/sys_term.c: char speed[128]; ... sprintf(speed, "%s/%d", (cp = getenv("TERM")) ? cp : "", (def_rspeed > 0) ? def_rspeed : 9600); This code is identical to the problematic kerberos code that was in the SNI advisory. Also, it appears that the eBones in FreeBSD is vulnerable to both problems in the SNI advisory. Just do a grep for 'strcpy' in src/eBones/lib/libkrb. pbd -- Why can't you be a non-conformist like everyone else? From owner-freebsd-security Thu May 1 14:08:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17019 for security-outgoing; Thu, 1 May 1997 14:08:36 -0700 (PDT) Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [130.237.225.158]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA17011 for ; Thu, 1 May 1997 14:08:29 -0700 (PDT) Received: from joda by blubb.pdc.kth.se with local (Exim 1.60 #3) id 0wN35D-0007C2-00; Thu, 1 May 1997 23:08:07 +0200 To: Bradley Dunn Cc: freebsd-security@freebsd.org Subject: Re: Telnetd problem? References: Mime-Version: 1.0 (generated by tm-edit 7.103) Content-Type: text/plain; charset=US-ASCII From: joda@pdc.kth.se (Johan Danielsson) Date: 01 May 1997 23:08:07 +0200 In-Reply-To: Bradley Dunn's message of Thu, 1 May 1997 16:54:39 -0400 (EDT) Message-ID: Lines: 14 X-Mailer: Gnus v5.4.24/Emacs 19.34 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bradley Dunn writes: > char speed[128]; > ... > sprintf(speed, "%s/%d", (cp = getenv("TERM")) ? cp : "", > (def_rspeed > 0) ? def_rspeed : 9600); > > This code is identical to the problematic kerberos code that was in > the SNI advisory. Yes, but this piece of code (at least in my telnetd source) is only used if your login doesn't grok `-f'. /Johan From owner-freebsd-security Thu May 1 15:53:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA23071 for security-outgoing; Thu, 1 May 1997 15:53:56 -0700 (PDT) Received: from charon.MIT.EDU (brnstndkramden.acf.nyu.edu@CHARON.MIT.EDU [18.70.0.224]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA23066 for ; Thu, 1 May 1997 15:53:53 -0700 (PDT) From: mhpower@mit.edu Received: (from mhpower@localhost) by charon.MIT.EDU (8.7.6/2.3JIK) id SAA06953; Thu, 1 May 1997 18:53:59 -0400 Date: Thu, 1 May 1997 18:53:59 -0400 Message-Id: <199705012253.SAA06953@charon.MIT.EDU> To: bradley@dunn.org Cc: freebsd-security@FreeBSD.ORG Subject: Re: Telnetd problem? In-Reply-To: Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From src/libexec/telnetd/sys_term.c: ... >sprintf(speed, "%s/%d", (cp = getenv("TERM")) ? cp : "", ... >This code is identical to the problematic kerberos code ... The code is also inside "#if defined(LOGIN_R)" "#endif", as it is in many other variants of this telnetd. I haven't personally seen any environments in which LOGIN_R is defined at build time, and I suspect it's not normally defined on FreeBSD systems. There may be some systems where LOGIN_R is defined, but I think typically the code is not actually problematic as a consequence of it not actually being compiled. Matt Power mhpower@mit.edu From owner-freebsd-security Thu May 1 21:34:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA11401 for security-outgoing; Thu, 1 May 1997 21:34:38 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA11392 for ; Thu, 1 May 1997 21:34:34 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wNA2D-0005Wp-00; Thu, 1 May 1997 22:33:29 -0600 To: Nate Williams Subject: Re: MS Exchange mail server and port 137 Cc: Chris Cason , freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 01 May 1997 14:01:53 MDT." <199705012001.OAA29546@rocky.mt.sri.com> References: <199705012001.OAA29546@rocky.mt.sri.com> <199705011521.BAA21766@gateway.oaks.com.au> Date: Thu, 01 May 1997 22:33:29 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199705012001.OAA29546@rocky.mt.sri.com> Nate Williams writes: : I see them all the time when I hit certain WWW sites. I'm not sure what : is going on, but I've learned to ignore them. The Village Security Officer treats these as "door bells" If we get too many from a site, we sent out a request to have them stop. So far all sites have complied and made them stop somehow. Warner From owner-freebsd-security Thu May 1 21:40:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA11703 for security-outgoing; Thu, 1 May 1997 21:40:30 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA11698 for ; Thu, 1 May 1997 21:40:27 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wNA8o-0005XU-00; Thu, 1 May 1997 22:40:18 -0600 To: mhpower@mit.edu Subject: Re: Telnetd problem? Cc: bradley@dunn.org, freebsd-security@freebsd.org In-reply-to: Your message of "Thu, 01 May 1997 18:53:59 EDT." <199705012253.SAA06953@charon.MIT.EDU> References: <199705012253.SAA06953@charon.MIT.EDU> Date: Thu, 01 May 1997 22:40:18 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199705012253.SAA06953@charon.MIT.EDU> mhpower@mit.edu writes: : The code is also inside "#if defined(LOGIN_R)" "#endif", as it is in : many other variants of this telnetd. I haven't personally seen any : environments in which LOGIN_R is defined at build time, and I suspect : it's not normally defined on FreeBSD systems. There may be some systems : where LOGIN_R is defined, but I think typically the code is not : actually problematic as a consequence of it not actually being compiled. I can't find any either. However, my paranoia is such that I've gone ahead and fixed it locally which means it will eventually make it into the tree. Since I get identical .o files before and after, I don't think that it is a big deal. Warner