From owner-freebsd-security Wed May 28 14:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05306 for security-outgoing; Wed, 28 May 1997 14:50:59 -0700 (PDT) Received: from mx1.cso.uiuc.edu (mx1.cso.uiuc.edu [128.174.5.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05301 for ; Wed, 28 May 1997 14:50:52 -0700 (PDT) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by mx1.cso.uiuc.edu (8.8.5/8.8.5) with SMTP id QAA28509 for <@mailhost.uiuc.edu:freebsd-security@freebsd.org>; Wed, 28 May 1997 16:50:49 -0500 (CDT) Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) for freebsd-security@freebsd.org id QAA09204; Wed, 28 May 1997 16:48:08 -0500 Date: Wed, 28 May 1997 16:48:08 -0500 From: igor@alecto.physics.uiuc.edu (Igor Roshchin) Message-Id: <199705282148.QAA09204@alecto.physics.uiuc.edu> To: freebsd-security@freebsd.org Subject: sshd: input bufer overflow Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, computer gurus! I am not sure if this might be a reason to worry about, but probably somebody might clear this up. I am running 2.1.7-RELEASE FreeBSD 2.1.7-RELEASE #0: Sun Feb 23 01:01:32 EST 1997 on P5 computer. I have 1.2.17 sshd running. Today I found the following strings in my log: May 28 10:42:28 kurort /kernel: ep0: Status: 2002 (input buffer overflow) May 28 10:42:28 kurort sshd[3334]: fatal: Local: Bad packet length 761285176. I know, that this was not an attempt of a break in, but I am just thinking if this can be a source for the DOS-attack, or something like that. Sorry, if this is known already and was fixed in the recent version of sshd. Best regards, IgoR From owner-freebsd-security Thu May 29 10:53:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28232 for security-outgoing; Thu, 29 May 1997 10:53:17 -0700 (PDT) Received: from tangelo.lal.ufl.edu ([204.199.163.200]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28223 for ; Thu, 29 May 1997 10:53:07 -0700 (PDT) Received: from bates.lal.ufl.edu (204.199.163.70) by tangelo.lal.ufl.edu (EMWAC SMTPRS 0.81) with SMTP id ; Thu, 29 May 1997 13:56:18 -0400 Message-ID: From: "Brad Bates" To: Subject: Fw: Inquiries? Date: Thu, 29 May 1997 13:54:14 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is this correct? If so, please let me know. Mine are fairly straightforward questions, and very limited. Thank you, Brad Bates ---------- > From: Paul Traina > To: Brad Bates > Cc: security-officer@freebsd.org > Subject: Re: Inquiries? > Date: Tuesday, May 27, 1997 1:30 PM > > I'm afraid we really don't do that. security@freebsd.org is a group > of FreeBSD folks who can most likely help you out. > > Good luck & best regards, > > Paul > Security Officer Emeritus > > From: "Brad Bates" > Subject: Inquiries? > Could you take two or three direct inquiries about a few > practical security issues? I am preparing to set up a > single host site, and would like to plan its security in > advance. A bit of planning based on your experience > may be very helpful. > > Thanks in advance, > > Brad Bates > University of Florida Citrus Research and Education Center > bab@icon.lal.ufl.edu > > From owner-freebsd-security Thu May 29 12:34:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04349 for security-outgoing; Thu, 29 May 1997 12:34:38 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04336 for ; Thu, 29 May 1997 12:34:34 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA29222 for ; Thu, 29 May 1997 12:26:56 -0700 (PDT) To: security@freebsd.org Subject: Just FYI.. Date: Thu, 29 May 1997 12:26:56 -0700 Message-ID: <29218.864934016@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subject: Sun Crypto Skirts Feds Forwarded-by: Keith Bostic Forwarded-by: Jeff Reed Sun Crypto Skirts Feds By John Fontana, Communications Week Menlo Park, Calif. -- Sun Microsystems is prepared to take on the federal government this week when it discloses plans to offer a product from Russia that provides 128-bit and triple DES encryption over the Internet. The software, which Sun will offer worldwide, could help ignite electronic commerce over the Internet. It could also lead to an all-out brawl between Sun and the Feds. It is now illegal for a U.S. company to export encryption software that exceeds 56-bit encoding. But it is legal to import such technology from abroad, presuming the domestic vendor had no role in its development. "The government will try to link Sun to the development of this product and go after them, or this will open the floodgates on strong encryption," said John O'Leary, the director of education at the Computer Security Institute in San Francisco. "The government will find that we are in full compliance with the letter of the law," maintained Humphrey Polanen, general manager of Sun's security and electronic-commerce group. "We took great pains to stay within the legal requirements." Polanen said a key factor was that Sun offered no technical assistance in the development of the software, although it is based on a protocol the company published publicly nearly two years ago. The product Sun will OEM is Secure Virtual Private Network for Windows. Developed by Moscow-based ElvisPlus Co., the product will be sold through Sun channels under the name PC SunScreen SKIP E+. The software is based on Sun's Simple Key Management for IP (SKIP) encryption and key management technology. It will ship with algorithms for 56- and 64-bit DES, two- and three-key triple DES and 128-bit ciphers for both traffic and key encryption. SKIP, a published specification, had been submitted to the Internet Engineering Task Force for standardization, but the draft proposals have expired, a source said. The software manages keys for exchanging encrypted data and can sit on any machine, including desktops, servers and routers. Because it operates at the network level, it can work with any IP transmission and does not require any modification to existing applications. Sun's plan to import the Russian technology neatly sidesteps current U.S. restrictions. To export encryption software using a key code in excess of 40 bits, a U.S. business must first get government approval. Furthermore, the would-be exporter must have a plan in place to supply a key recovery model within a two-year time frame before receiving approval. SKIP E+ does not include a model for key recovery, and Sun did not seek government approval for the product, but the computer maker expects to provide the software to the global offices of its U.S.-based customers and others through third-party distributors. Sun's newly formed Security Group--and before that its Internet Commerce Group--has worked for two years with the company's legal and export-compliant government regulatory departments laying the groundwork that led to the OEM deal, and this will be the first time a major U.S. computer company has offered U.S.-based corporations 128-bit and triple DES encryption for global use. Given President Clinton's lack of support for current efforts to lift encryption export restrictions, Sun is anticipating a major backlash from the Clinton administration. A White House spokesperson declined comment. But a source familiar with the administration's handling of encryption policy was doubtful that the White House would wage a full-scale attack on Sun. "What Sun had to go through to release a product like this points up the folly of the current policy," commented Rep. Bob Goodlatte (R-Va.), who authored a bill that would prohibit mandatory key recovery. Last week, Goodlatte's bill, the Security and Freedom through Encryption (SAFE) Act, was approved by the House Judiciary Committee, marking the first time any encryption legislation had made it out of committee. It could take another eight to 12 months, however, before it moves through the full House and Senate and on to the president. The computer industry and retail and banking groups are vehemently opposed to the export restrictions and have been trying to find ways around them. Hewlett-Packard, IBM, Trusted Information Systems and others have formed a Key Recovery Alliance as a way to work within the current law pending relaxation of the restrictions. And RSA Data Security Inc. has bought a Japanese software vendor, now called Nihon-RSA. But Sun believes it will be some time before other software companies can match its efforts. Several products incorporate the SKIP protocol, including Sun's own line of SunScreen security products, Firewall-1 from Check Point Software Technologies Ltd. and SmartGate from VOne Corp. Sun says it is also negotiating with two leading router vendors. SKIP E+ provides encryption and authentication of any IP-based communication, including Telnet, HTTP, SQL requests and SMTP, while it manages encryption keys, negotiates data transfers and controls access to data through a three-tiered approval process. Sun says work still remains to create a management model for the access lists network administrators would need to create for a global system. "You'll see some announcements in a month or two that take care of the overall management headache for this," said Chris Tolles, product manager for the network security products group. "We're moving forward with solutions that get to the large-scale access control list distribution problem. It's a key issue for wide-scale deployment." SKIP E+ will be available Aug. 15 and will run on Windows 3.11, Windows 95 and Windows NT. It is compatible with most commercial TCP/IP stacks for Windows 3.x, Windows 95, NT 3.5 and NT 4.0. ElvisPlus plans to make evaluation copies available on its Web site. Related articles from: Search TechWire & CMP Archives Copyright (c) CMP Media, 1996. From owner-freebsd-security Thu May 29 13:11:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06321 for security-outgoing; Thu, 29 May 1997 13:11:59 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06316 for ; Thu, 29 May 1997 13:11:56 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id XAA25219; Thu, 29 May 1997 23:11:40 +0300 (EEST) Date: Thu, 29 May 1997 23:11:40 +0300 (EEST) Message-Id: <199705292011.XAA25219@silver.sms.fi> From: Petri Helenius To: "Jordan K. Hubbard" Cc: security@FreeBSD.ORG Subject: Just FYI.. In-Reply-To: <29218.864934016@time.cdrom.com> References: <29218.864934016@time.cdrom.com> Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > > The software, which Sun will offer worldwide, could help ignite electronic > commerce over the Internet. It could also lead to an all-out brawl between > Sun and the Feds. > > It is now illegal for a U.S. company to export encryption software that > exceeds 56-bit encoding. But it is legal to import such technology from > abroad, presuming the domestic vendor had no role in its development. > > "The government will try to link Sun to the development of this product > and go after them, or this will open the floodgates on strong encryption," > said John O'Leary, the director of education at the Computer Security > Institute in San Francisco. > I wonder why the press makes so much of an issue about this since SSH has been available across the globe with 128 bit triple-des for years... Pete From owner-freebsd-security Thu May 29 14:11:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09644 for security-outgoing; Thu, 29 May 1997 14:11:48 -0700 (PDT) Received: from dfw.dfw.net (aleph1@dfw.dfw.net [198.175.15.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA09638 for ; Thu, 29 May 1997 14:11:45 -0700 (PDT) Received: from localhost by dfw.dfw.net (4.1/SMI-4.1) id AA24424; Thu, 29 May 97 16:12:30 CDT Date: Thu, 29 May 1997 16:12:30 -0500 (CDT) From: Aleph One To: Petri Helenius Cc: "Jordan K. Hubbard" , security@FreeBSD.ORG Subject: Re: Just FYI.. In-Reply-To: <199705292011.XAA25219@silver.sms.fi> 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 Thu, 29 May 1997, Petri Helenius wrote: > I wonder why the press makes so much of an issue about this since SSH > has been available across the globe with 128 bit triple-des for > years... Because this is a large US based corporation trying to tell the goverment that the ITAR regulations are hurting it's business and therefore must attempt to bypass them by buying its crypto from a company from a country that not long ago was their mortal enemy? > Pete > Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-security Fri May 30 08:38:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21146 for security-outgoing; Fri, 30 May 1997 08:38:37 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21131; Fri, 30 May 1997 08:38:22 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.7.6/8.7.3) id RAA08714; Fri, 30 May 1997 17:38:02 +0200 (MET DST) Date: Fri, 30 May 1997 17:38:02 +0200 (MET DST) Message-Id: <199705301538.RAA08714@bitbox.follo.net> From: Eivind Eklund To: security@freebsd.org Subject: X libraries Cc: rich@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is presently at least one hole in the X11 libraries (a buffer overflow) being passed around in hacker circles. This buffer overrun makes it possible to exploit any setuid program for X11 (e.g. xterm) user set to; xterm (and others) give root. A temporary fix is to remove the setuid bit on all X11 executables; the following statement will find them > find /usr/X11R6 -perm -4000 -print unless somebody has installed them in /usr/local/bin - hopefully not. The following statement will remove the bits (untested) - and you _will_ loose functionality on it: > find /usr/X11R6 -perm -4000 -exec chmod u-s \{\} \; This will _not_ remove group vulnerabilities. Remember that running an X-server locally is not required to be vulnerable; all non-patched servers able to run xterm are vulnerable. Hopefully XFree will provide replacement libraries soon; if not, I'll try to do it, but I'm not presently equipped to compile new libraries for all FreeBSD versions. (The XFree liason is Cc:'ed - can you comment on this, Rich?) Eivind. From owner-freebsd-security Fri May 30 16:41:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA15961 for security-outgoing; Fri, 30 May 1997 16:41:48 -0700 (PDT) Received: from rich.isdn.bcm.tmc.edu (RICH.ISDN.BCM.TMC.EDU [128.249.250.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15946 for ; Fri, 30 May 1997 16:41:44 -0700 (PDT) Received: (from rich@localhost) by rich.isdn.bcm.tmc.edu (8.8.5/8.8.2) id SAA08966; Fri, 30 May 1997 18:41:27 -0500 (CDT) Date: Fri, 30 May 1997 18:41:27 -0500 (CDT) Message-Id: <199705302341.SAA08966@rich.isdn.bcm.tmc.edu> From: Rich Murphey To: perhaps@yes.no CC: security@freebsd.org In-reply-to: <199705301538.RAA08714@bitbox.follo.net> (message from Eivind Eklund on Fri, 30 May 1997 17:38:02 +0200 (MET DST)) Subject: Re: X libraries Reply-to: rich@rich.isdn.bcm.tmc.edu Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk |Hopefully XFree will provide replacement libraries soon; if not, I'll |try to do it, but I'm not presently equipped to compile new libraries |for all FreeBSD versions. (The XFree liason is Cc:'ed - can you |comment on this, Rich?) I guess I've missed other discussions about the bug. We can include the patch for freebsd untill XFree86 picks it up if that's the consensus. Have you talked to anyone else with XFree86 about it? Rich From owner-freebsd-security Fri May 30 17:01:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17257 for security-outgoing; Fri, 30 May 1997 17:01:41 -0700 (PDT) Received: from mx1.cso.uiuc.edu (mx1.cso.uiuc.edu [128.174.5.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17249 for ; Fri, 30 May 1997 17:01:39 -0700 (PDT) Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [128.174.83.167]) by mx1.cso.uiuc.edu (8.8.5/8.8.5) with SMTP id TAA26962 for <@mailhost.uiuc.edu:security@FreeBSD.ORG>; Fri, 30 May 1997 19:01:38 -0500 (CDT) Received: by alecto.physics.uiuc.edu (940816.SGI.8.6.9/940406.SGI) id SAA15102; Fri, 30 May 1997 18:59:46 -0500 Date: Fri, 30 May 1997 18:59:45 -0500 (CDT) From: Vlad Roubtsov To: security@FreeBSD.ORG Subject: Re: X libraries In-Reply-To: <199705301538.RAA08714@bitbox.follo.net> 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 Fri, 30 May 1997, Eivind Eklund wrote: > > There is presently at least one hole in the X11 libraries (a buffer >overflow) being passed around in hacker circles. This buffer overrun >makes it possible to exploit any setuid program for X11 (e.g. xterm) >user set to; xterm (and others) give root. > Somebody made a semi-systematic analysis of many X11 applications and identified several vulnerable programs (xterm included) about a year ago. The fact didn't draw much attention at the time... Vlad. From owner-freebsd-security Fri May 30 18:33:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20659 for security-outgoing; Fri, 30 May 1997 18:33:28 -0700 (PDT) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20635; Fri, 30 May 1997 18:33:22 -0700 (PDT) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id LAA26863; Sat, 31 May 1997 11:33:02 +1000 (EST) Message-ID: <19970531113302.04820@rf900.physics.usyd.edu.au> Date: Sat, 31 May 1997 11:33:02 +1000 From: David Dawes To: Eivind Eklund Cc: security@FreeBSD.ORG, rich@FreeBSD.ORG Subject: Re: X libraries References: <199705301538.RAA08714@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705301538.RAA08714@bitbox.follo.net>; from Eivind Eklund on Fri, May 30, 1997 at 05:38:02PM +0200 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, May 30, 1997 at 05:38:02PM +0200, Eivind Eklund wrote: > >There is presently at least one hole in the X11 libraries (a buffer >overflow) being passed around in hacker circles. This buffer overrun >makes it possible to exploit any setuid program for X11 (e.g. xterm) >user set to; xterm (and others) give root. >Hopefully XFree will provide replacement libraries soon; if not, I'll >try to do it, but I'm not presently equipped to compile new libraries >for all FreeBSD versions. (The XFree liason is Cc:'ed - can you >comment on this, Rich?) XFree86 is aware of two Xlib buffer overflows which are present in the base X11R6.3 code. One is related to the -xrm command line flag, and the other is related to the locale-related environment variables. Xterm built from XFree86 3.1.2 and later source happens to be immune from the first problem because it runs the vulnerable code with the euid == ruid. It may be open to the second problem however, although the impact of the second problem on OSs with a working setlocale(3) isn't so clear (to me). It is definitely a problem on Linux where Xlib doesn't use the OSs setlocale(3). We have fixes for both of these problems, and they will be included in our 3.3 release, which should be available some time in the next week. We'll be providing binary distributions for FreeBSD 2.1.7, 2.2.x, and 3.0-CURRENT (using the 970520-SNAP). If you know of any other Xlib (or other) vulnerabilities, please let me know *now* (send details to XFree86@XFree86.org) so that we can attempt to have them fixed in 3.3. We close off 3.3 completely in a day or two. David From owner-freebsd-security Sat May 31 11:21:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02383 for security-outgoing; Sat, 31 May 1997 11:21:58 -0700 (PDT) Received: from eyelab.psy.msu.edu (eyelab.psy.msu.edu [35.8.64.179]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA02374 for ; Sat, 31 May 1997 11:21:56 -0700 (PDT) Received: from psy219.psy.msu.edu (psy219.psy.msu.edu [35.8.64.167]) by eyelab.psy.msu.edu (8.8.5/8.8.5) with SMTP id OAA21343 for ; Sat, 31 May 1997 14:19:08 -0400 (EDT) X-Authentication-Warning: eyelab.psy.msu.edu: psy219.psy.msu.edu [35.8.64.167] didn't use HELO protocol Message-Id: <3.0.2.32.19970531142155.006dec74@eyelab.msu.edu> X-Sender: root@eyelab.msu.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 31 May 1997 14:21:55 -0400 To: freebsd-security@freebsd.org From: Gary Schrock Subject: ftpd signal handler race? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Regarding the CERT announcement just recently about a problem with ftpd, according to the information there it was implied that only 2.2+ was fixed, and that the changes weren't in the 2.1 line. When looking through the cvs logs on the freebsd web site, I ran across a checkin on the RELENG_2_1_0 line that seemed to imply that this problem was fixed. So is it true that if one's tracking the 2.1-STABLE line then this problem has been fixed regardless of what the cert announcement says? Thanks Gary Schrock root@eyelab.msu.edu From owner-freebsd-security Sat May 31 16:19:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA22015 for security-outgoing; Sat, 31 May 1997 16:19:28 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA22010 for ; Sat, 31 May 1997 16:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id QAA14848; Sat, 31 May 1997 16:21:17 -0700 (PDT) Message-Id: <199705312321.QAA14848@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Gary Schrock cc: freebsd-security@FreeBSD.ORG Subject: Re: ftpd signal handler race? In-reply-to: Your message of "Sat, 31 May 1997 14:21:55 EDT." <3.0.2.32.19970531142155.006dec74@eyelab.msu.edu> From: David Greenman Reply-To: dg@root.com Date: Sat, 31 May 1997 16:21:17 -0700 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Regarding the CERT announcement just recently about a problem with ftpd, >according to the information there it was implied that only 2.2+ was fixed, >and that the changes weren't in the 2.1 line. When looking through the cvs >logs on the freebsd web site, I ran across a checkin on the RELENG_2_1_0 >line that seemed to imply that this problem was fixed. So is it true that >if one's tracking the 2.1-STABLE line then this problem has been fixed >regardless of what the cert announcement says? I was the one who originally discovered the security hole and informed CERT. The bug was fixed in the 2.2 tree prior to the 2.2.0 release and was merged (by pst) into the 2.1 branch prior to the 2.1.7 release. So the answer is "yes", the problem is fixed in the 2.1-stable branch and if you're tracking that then you don't need to worry about it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project