Subject: Academ version of wu-ftpd 2.4 Release 2 Beta 12 available for testing

From: [email-masked] (Stan Barber)
Date: Sun, 19 Jan 1997 21:25:58 -0600 (CST)

BETA 12 is now available. It has been tested on the following systems:

Solaris 2.4 Sparc and x86, SunOS 4.1.4, FreeBSD 2.1.5-RELEASE, BSD/OS 1.1, 
BSD/OS 2.1, Unixware 2.1, SCO Open Server 5, Linux 

I would like to hear from folks with access to HP-UX, Digital Unix, IRIX
and AIX in particular. Please send mail to the [email-masked]
address.

If hardware companies wish to donate equipment running their proprietary
UNIX derivatives to me for doing maintenance work on this and the other
packages I maintain (NNTP, RN, etc), please contact me directly to discuss.

If software companies that sell UNIX derivatives I don't to which I don't
have access wish to donain copies of their UNIX derivative to me for the
purposes of doing maintenace work on this and the other packages I maintain,
please contact me directly to discuss.

I wish to offer my thanks to SCO for making available their OS software
for my testing of this release. Additionally, their support in documenting
problems in the software has been very helpful. Additionally, I received 
some bug reports from the FreeBSD project for which I am grateful.

Finally, both The AUS-CERT and the CERT/CC have continued to provide me
with feedback on the security issues with this software. 

This is another release candidate.

The location is: 
	ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-12.tar.Z

NOTE: This directory is protected. Attempts to use a directory listing 
command will fail.

                   -0-FIXES IN THIS RELEASE-0-

Ticket Numbers 18, 20, 29, 31, 43, 46, 47, 50, 52, 59, 77, 92, 102, 107, 115, 
118, 119, 124, 132, 134, and 137: Linix 2.0 (actually libc 5.3.12) changed
the way that directory manupulation was done. This was reported by many folks:
[email-masked],[email-masked],[email-masked],
[email-masked],[email-masked],[email-masked],[email-masked],
[email-masked],[email-masked],[email-masked],[email-masked],
[email-masked],[email-masked],[email-masked],
[email-masked],[email-masked],[email-masked],
[email-masked],[email-masked],[email-masked],[email-masked]

The problem was that glob.c would not compline on Linux 2.X systems.

The fix was one suggested by [email-masked] along with some work by me to
insure that Linux 1.X users would still be able to use this on their systems.
-------------------------------------------------------------------------------
Ticket Numbers 19 from [email-masked] pointed out a bug in processing
"SITE CHMOD 0". The command didn't work and the server didn't give a reply.
His fix is incorporated in this release.
-------------------------------------------------------------------------------
Ticket 28 from [email-masked] and Ticket 105 from [email-masked]
noted that there were some instances in ftpcmd.y where values could be
NULL. This would cause segmentation violations on may flavors of Unix.
Ian's bug fixes were incorporated into this release.
-------------------------------------------------------------------------------
Ticket 49 from [email-masked] provided configuration files
for Digital Unix 3.2 with C2 Security. This is now integrated into this
release.
-------------------------------------------------------------------------------
Ticket 55 from [email-masked] pointed out that Solaris 2.X does support
getrlimit. He suggested that a change be made to config.sol to make use
of that. This release does make that change.
-------------------------------------------------------------------------------
Ticket 57 from [email-masked] offered some adjustments for making better use of
available library routines in Unixware 2.1. This release has made some of
the adjustments he suggested.
-------------------------------------------------------------------------------
Ticket 60 from [email-masked] pointed out errors in the ftpd.8 manual page.
The suggested changes have been made in this release.
-------------------------------------------------------------------------------
Ticket 61 from [email-masked] pointed out that when a null is sent
to the server, it should ignore it and it is treating it like EOF. Now it
ignores it. Fix from [email-masked] was used.
-------------------------------------------------------------------------------
Ticket 62 from [email-masked] noted a type on one of the URLs in the NOTES file.
This is fixed in this release. He also suggested that having the debug mode
log passwords is not good. He provided a fix for this and it is also in
this release.
-------------------------------------------------------------------------------
Ticket 65 from [email-masked] noted that subsequent files upload requests can't
be restarted correctly. He provided a fix for this and it is in this release.
-------------------------------------------------------------------------------
Ticket 67 from [email-masked] noted RFC 1127's suggestions are not being followed
by this server and that STAT is using a 211 response when a 213 is probably
better. Those changed are in this release.
-------------------------------------------------------------------------------
Ticket 70 from [email-masked] pointed out a possible overflow problem when
processing the SITE CHMOD and SITE UMASK commands. The server did not check 
for overflow conditions. His fix is incorporated in this release.
-------------------------------------------------------------------------------
Ticket 72 from [email-masked] noted that subsequent files requests can't
be aborted correctly. He provided a fix for this and it is in this release.
-------------------------------------------------------------------------------
Ticket 75 from the AUSCERT brought to my attention a need to check to be sure
the 100 element argv array in the popen subroutine is not overflowed. This is
now done. The other problem reported had been fixed in previous releases.
-------------------------------------------------------------------------------
Ticket 76 from [email-masked] noted stderr output from ftpd when being started
by inetd were problematical. Theses error messages now go to syslog.
-------------------------------------------------------------------------------
Ticket 79 from [email-masked] noted that Unixware 2.1 supports getrlimit.
So, this is now added to config.uxw in the src/config directory.
-------------------------------------------------------------------------------
Ticket 80 from [email-masked] noted that fnmatch.c did not have the right
flags defined correctly. This is now fixed in this release
-------------------------------------------------------------------------------
Ticket 81 from [email-masked] noted some typos in the manual pages. The suggested
changes have been made for this release.
-------------------------------------------------------------------------------
Ticket 83 from [email-masked] noted some macro inconsistency in the manual pages.
The suggested changes have been made for this release.
-------------------------------------------------------------------------------
Ticket 85 from [email-masked] pointed out places where files could or should be
closed. The suggested changes have been made for this release.
-------------------------------------------------------------------------------
Ticket 86 from [email-masked] suggests that the ftpgroups and ftpconversions file
checks in conversions.c and acl.c should be done using an fstat after an open
succeeds. The suggested changes have been made for this release.
-------------------------------------------------------------------------------
Ticket 87 from [email-masked] offers fixes the basic problems introduced in 
beta-11 with the virtual host code. There have been no changes in how the
configuration files are configured. 
-------------------------------------------------------------------------------
Ticket 97 from [email-masked] pointed out a problem in the old virtual
code where an illegal strcpy was being done. This was fixed with the patches
in ticket 87.
-------------------------------------------------------------------------------
Ticket 98 from [email-masked] points out a bug introduced in the academ betas
with the T_ASCII flag in ftpconversions. Its meaning had become reverse from
what it used to be. This is now fixed.
-------------------------------------------------------------------------------
Ticket 100 from [email-masked] points out a mispelling in the notes file and 
suggests a fix so that "anonymous" and "ftp" are made to be the same as far
as the server is concerned. This is included in this release.
-------------------------------------------------------------------------------
Ticket 103 from [email-masked] offered some support files to make
it possible to build wu-ftpd on AU/X 3.0 and later. This is included in
this release
-------------------------------------------------------------------------------
Ticket 106 from [email-masked] offers changes to ftpcmd.y to insure that 
free() is called when the arguments are non-null. These fixes are included
in this release.
-------------------------------------------------------------------------------
Ticket 108 from [email-masked] reports a bug in how the ftw.h file in the 
support directory gets included when it shouldn't be for Unixware 2.1. This
fix is included in this release.
-------------------------------------------------------------------------------
Ticket 109 from [email-masked] reports a bug in how the shutdown feature
works. The bug is that new connections may continue to be accepted after
shutdown is in force. The suggested fixes have been included in this release.
-------------------------------------------------------------------------------
Ticket 110 from [email-masked] suggests that all filename checking should be
case sensitive. I agree. Fixes to make that so are now included in this
release.
-------------------------------------------------------------------------------
Ticket 111 from [email-masked] reports a bug in how ftpcount reports classes
that can have an unlimited number of users. The suggested fixes have been
included in this release.
-------------------------------------------------------------------------------
Ticket 113 from [email-masked] suggests that ftpd should use getopt and I agree.
The suggested fixes are included in this release.
-------------------------------------------------------------------------------
Ticket 117 from [email-masked] pointed out two bugs in the build program which
are now fixed. It also pointed out an inconsistent use of #if verus #ifdef
in authenticate.c. This is also fixed.
-------------------------------------------------------------------------------
Ticket 120 from [email-masked] pointed an inconsistency between the documentation
and how the server logs information. The server has been fixed to document
guest users in the xferlog with a "g" and real users with a "r". 
-------------------------------------------------------------------------------
Ticket 130 from [email-masked] pointed a number of problems with upload and 
offered fixes for these problems. They have been included in this release.
-------------------------------------------------------------------------------
Ticket 131 from [email-masked] suggested that the readme directive should really
only apply to regular files. Suggested fixes included in this release.
-------------------------------------------------------------------------------
Ticket 133 from [email-masked] provides a fix to permit bad autogroup entries
in the ftpaccess file to be ignored. Suggested fixes included in this release.
-------------------------------------------------------------------------------
Ticket 139 from [email-masked] provides a significant security fix without which
regular and anonymous users could access files as the root user. This fix is
included in this release.
-------------------------------------------------------------------------------
Ticket 146 from [email-masked] offers a fix to the virtual host
code that permits guest groups to continue to work. This fix is included in
this release.
-------------------------------------------------------------------------------
Ticket 152 from [email-masked] provided additional protection for
some operating system over the protection provided in ticket 139. This is
included in this release, but has only been tested on the operating systems
listed in the ANNOUNCE-12 file.
-------------------------------------------------------------------------------
Ticket 152 from [email-masked] suggested the the FreeBSD configuration
not install the sample configuration files over previously existing ones.
This release does not install them at all. A new approach will be used in
release 2.5 of this software that will address this for all OSes supported.
-------------------------------------------------------------------------------
A message on the mailing list from May 2, 1996 by [email-masked] 
suggested a mechanism to permit AIX hosts to make effective use of the virtual
host feature in wu-ftpd. This mechanism has been included in this release.
-------------------------------------------------------------------------------
A message to the mailing list from August 12, 1996 by [email-masked]
suggested some changes to ftpcount.c to make it return more useful information
when used with Solaris2 and AIX. Those changes are includedi in this release.
-------------------------------------------------------------------------------
A message to the mailting list send January 13, 1997 by 
[email-masked] suggested that the use of putchar in ftpd.c and
ftpcmd.y might have side effects on arguement lists when putchar is a macro.
The use of putchar has been changed to putc in these files for this release.

---

From: CERT(sm) Coordination Center <[email-masked]>
Date: Sun, 19 Jan 97 22:26:42 EST

********************************************************************************

		[NOTE -- THIS IS AN AUTOMATED RESPONSE]

On weekends, the CERT(sm) Coordination Center staff are on call for
emergencies only.  Attacks considered to be emergencies are:

	- possible life-threatening activity
        - attacks on the Internet infrastructure (such as root name 
	  servers, domain name servers, major archive sites, and 
	  network access points--NAPs, or widespread automated 
	  attacks against Internet sites)
        - network sniffers 
        - router attacks
        - root compromises 

If you are reporting such an emergency outside our operational hours -
business days between 08:30-17:00 EST/EDT (GMT-5)/(GMT-4) and require
immediate assistance, then, please call the CERT hotline:

        +1 412 268 7090

If you are experiencing another type of incident, please complete and
return the Incident Reporting Form appended below.  Your e-mail is very
important to us, and we will respond to it as soon as possible.

If you are reporting such an emergency outside our operational hours -
business days between 08:30-17:00 EST/EDT (GMT-5)/(GMT-4) and require
immediate assistance, then, please call the CERT hotline:

  Intruder Detection Checklist
    ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist    

  Steps for Recovering from a UNIX Root Compromise
    ftp://info.cert.org/pub/tech_tips/root_compromise

  UNIX Configuration Guidelines
    ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines

  List of Security Tools
    ftp://info.cert.org/pub/tech_tips/security_tools

  Overview of CERT advisories
    ftp://info.cert.org/pub/cert_advisories/01-README

  Overview of CERT vendor initiated bulletins (VIB's)
    ftp://info.cert.org/pub/cert_bulletins/01-README

  Overview of CERT summaries
    ftp://info.cert.org/pub/cert_summaries/01-README

  FIRST contact information
    ftp://info.cert.org/pub/FIRST/first-contacts

  CERT Coordination Center FAQ
    ftp://info.cert.org/pub/cert_faq

Keep us informed about your incident - let us know of any actions you
take, intruder tools you discover, and what other sites may be
affected. If you have not already done so, please complete an incident
reporting form, which you can get from

          ftp://info.cert.org/pub/incident_report_form

If you believe the intruder activity is a threat to people's lives or to
the Internet infrastructure, please contact us immediately.

We appreciate your understanding and cooperation.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA  USA  15213-3890

Internet e-mail:  [email-masked] (monitored during business hours)

Telephone: +1-412-268-7090 24-hour hotline 
CERT Coordination Center personnel answer business days 08:30-17:00
EST/EDT (GMT-5)/(GMT-4), on call for emergencies during other hours.
Fax: +1-412-268-6989

**************************** cut here **************************** 
version 3.0
February 28, 1996

                       CERT(sm) Coordination Center
                       Incident Reporting Form

The CERT Coordination Center (CERT/CC) has developed the following form in
an effort to gather incident information.  We would appreciate your
completing the form below in as much detail as possible.  The information
is optional, but from our experience we have found that having the answers
to all the questions enables us to provide the best assistance.  Completing
the form also helps avoid delays while we get back to you requesting the
information we need in order to help you.  Sites have told us, as well,
that filling out the form has helped them work through the incident.

Note that our policy is to keep any information specific to your site
confidential unless we receive your permission to release that information.

Please feel free to duplicate any section as required.  Please return this
form to [email-masked].  If you are unable to email this form, please send
it by FAX.  The CERT/CC FAX number is

	 +1 412 268 6989

Thank you for your cooperation and help.
............................................................................

1.0. General Information

     1.1. Incident number (to be assigned by the CERT/CC):  CERT#

     1.2. Reporting site information

          1.2.1.  Name (e.g., CERT Coordination Center):  
          1.2.2.  Domain Name (e.g., cert.org):  
          1.2.3.  Brief description of the organization:  
          1.2.4.  Is your site an Internet Service Provider (Yes/No):  

2.0. Contact Information

     2.1. Your contact information

           2.1.1.  Name:  
           2.1.2.  Email address:  
           2.1.3.  Telephone number:  
           2.1.4.  FAX number:
           2.1.5.  Pager number:  
           2.1.6.  Home telephone number (for CERT/CC internal use only):  
           2.1.7.  Secure communication channel (e.g., PGP, PEM, DES, secure
                    telephone/FAX) [NOTE -- we will call to obtain the secure
                    communication channel information] (Yes/No):  

     2.2. Additional contact information (if available)

           2.2.1.  Name:  
           2.2.2.  Email address:  
           2.2.3.  Telephone number:  
           2.2.4.  FAX number:  
           2.2.5.  Pager number:  
           2.2.6.  Home telephone number (for CERT/CC internal use only):  
           2.2.7.  Secure communication channel (Yes/No):  

     2.3. Site security contact information (if applicable)

           2.3.1.  Name:  
           2.3.2.  Email address:  
           2.3.3.  Telephone number:  
           2.3.4.  FAX number:  
           2.3.5.  Pager number:  
           2.3.6.  Home telephone number (for our internal use only):  
           2.3.7.  Secure communication channel (Yes/No):  

     2.4. Contact information for other site(s) involved in this incident (if
           available)

           2.4.1.  Site name:  
           2.4.2.  Contact person name:
           2.4.3.  Email address:  
           2.4.4.  Telephone number:  
           2.4.5.  FAX number:  
           2.4.6.  Pager number:  
           2.4.7.  Home telephone number (for CERT/CC internal use only):  
           2.4.8.  Secure communication channel (Yes/No):  

     2.5. Contact information for any other incident response team(s) (IRTs)
           that has/have been notified (if available)

           2.5.1.  IRT name:  
           2.5.2.  Constituency domain:  
           2.5.3.  Contact person name:
           2.5.4.  Email address:  
           2.5.5.  Telephone number:  
           2.5.6.  FAX number:  
           2.5.7.  Pager number:  
           2.5.8.  Home telephone number (for CERT/CC internal use only):  
           2.5.9.  Secure communication channel (Yes/No): 
           2.5.10. IRT reference number:   

     2.6. Contact information for any law enforcement agency(ies) that
	  has/have been notified (if available) 

          2.6.1.  Law enforcement agency name:  
          2.6.2.  Contact person name:
          2.6.3.  Email address:  
          2.6.4.  Telephone number:  
          2.6.5.  FAX number:  
          2.6.6.  Pager number:  
          2.6.7.  Home telephone number (for CERT/CC internal use only):  
          2.6.8.  Secure communication channel (Yes/No):  
          2.6.9.  Law enforcement agency reference number:  

3.0. Contacting Sites Involved

     3.1. We ask that reporting sites contact other sites involved in
	  incident activity.  Please let us know if you need assistance
	  in obtaining contact information for the site(s) involved.
	    
          When contacting the other sites, we would very much
	  appreciate a cc to the "[email-masked]" alias.  This helps
	  us identify connections between incidents and understand
	  the scope of intruder activity.  We would also appreciate
	  your including our incident number in the subject line of
	  any correspondence relating to this incident if one
	  has been assigned (see item 1.1.).

          If you are unable to contact the involved sites, please get in
	  touch with us to discuss how we can assist you.

     3.2. Disclosure information -- may we give the following types of
          information to 

          3.2.1. the sites involved in this incident

		 3.2.1.1. your domain (Yes/No):
	  	 3.2.1.2. your host(s) involved (Yes/No):
	   	 3.2.1.3. your contact information (Yes/No):

          3.2.2. incident response teams, for sites from their
                 constituencies involved in this incident

		 3.2.2.1. your domain (Yes/No):
		 3.2.2.2. your host(s) involved (Yes/No):
		 3.2.2.3. your contact information (Yes/No):

          3.2.3. law enforcement agency(ies) if there is a legal
                 investigation

		 3.2.3.1. your domain (Yes/No):
		 3.2.3.2. your host(s) involved (Yes/No):
		 3.2.3.3. your contact information (Yes/No):

4.0. Host Information

     4.1. Host(s) involved at your site.  Please provide information on all
          host(s) involved in this incident at the time of the incident (one
          entry per host please) 

          4.1.1.  Hostname:  
          4.1.2.  IP address(es):  
          4.1.3.  Vendor hardware, OS, and version:  
          4.1.4.  Security patches applied/installed as currently
                  recommended by the vendor and the CERT/CC
                  (Yes/No/Unknown):  
          4.1.5.  Function(s) of the involved host 

                  4.1.5.1. Router (Yes/No):  
                  4.1.5.2. Terminal server (Yes/No):  
                  4.1.5.3. Other (e.g. mail hub, information server, DNS
                           [external or internal], etc.):  

          4.1.6.  Where on the network is the involved host (e.g.
	    	  backbone, subnet):  
          4.1.7.  Nature of the information at risk on the involved host
                  (e.g., router configuration, proprietary, personnel,
                  financial, etc.):  
          4.1.8.  Timezone of the involved host (relative to GMT):
          4.1.9.  In the attack, was the host the source, the victim, or
	          both:
          4.1.10. Was this host compromised as a result of this attack
                  (Yes/No):  

     4.2. Host(s) involved at other other sites (one entry per host
          please) 

          4.2.1. Hostname:  
          4.2.2. IP address(es):  
          4.2.3. Vendor hardware, OS, and version:  
          4.2.4. Has the site been notified (Yes/No):  
          4.2.5. In the attack, was the host the source, the victim, or
	  	 both:
          4.2.6. Was this host compromised as a result of this attack
                 (Yes/No):  

5.0. Incident Categories

     5.1. Please mark as many categories as are appropriate to
          this incident

          5.1.1.  Probe(s):  
          5.1.2.  Scan(s):  
          5.1.3.  Prank:  
          5.1.4.  Scam:  
          5.1.5.  Email Spoofing:
          5.1.6.  Email bombardment:  

 	   	  5.1.6.1. was this denial-of-service attack successful
	 	           (Yes/No):

          5.1.7.  Sendmail attack:  

	   	  5.1.7.1. did this attack result in a compromise (Yes/No):  

          5.1.8.  Break-in

                  5.1.8.1. Intruder gained root access (Yes/No):  
                  5.1.8.2. Intruder installed Trojan horse program(s)
	   	           (Yes/No):
                  5.1.8.3. Intruder installed packet sniffer (Yes/No):  

                           5.1.8.3.1. What was the full pathname(s) of the
		        	      sniffer output file(s):
                           5.1.8.3.2. How many sessions did the sniffer log?
                                      (use "grep -c 'DATA' <filename>" to
                                      obtain this information):  

                  5.1.8.4.  NIS (yellow pages) attack (Yes/No):
                  5.1.8.5.  NFS attack (Yes/No):  
                  5.1.8.6.  TFTP attack (Yes/No):  
                  5.1.8.7.  FTP attack (Yes/No):  
                  5.1.8.8.  Telnet attack (Yes/No):  
                  5.1.8.9.  Rlogin or rsh attack (Yes/No):  
                  5.1.8.10. Cracked password (Yes/No):  
                  5.1.8.11. Easily-guessable password (Yes/No):  

          5.1.9.  Anonymous FTP abuse (Yes/No):
          5.1.10. IP spoofing (Yes/No):  
          5.1.11. Product vulnerability (Yes/No):
          
                  5.1.11.1. Vulnerability exploited:  

          5.1.12. Configuration error (Yes/No):  

                  5.1.12.1. Type of configuration error:  

          5.1.13. Misuse of host(s) resources (Yes/No):  
          5.1.14. Worm (Yes/No):
          5.1.15. Virus (Yes/No):
          5.1.16. Other (please specify):

6.0. Security Tools 

     6.1. At the time of the incident, were you any using the following
          security tools (Yes/No; How often) 

          Network Monitoring tools
             6.1.1.  Argus:  
             6.1.2.  netlog (part of the TAMU Security Package): 

          Authentication/Password tools
             6.1.3.  Crack:  
             6.1.4.  One-time passwords:  
             6.1.5.  Proactive password checkers:  
             6.1.6.  Shadow passwords: 
             6.1.7.  Kerberos:

          Service filtering tools
             6.1.8.  Host access control via modified daemons or wrappers:  
             6.1.9.  Drawbridge (part of the TAMU Security Package):  
             6.1.10. Firewall (what product):  
             6.1.11. TCP access control using packet filtering:  

          Tools to scan hosts for known vulnerabilities
             6.1.12. ISS:  
             6.1.13. SATAN:  

          Multi-purpose tools
             6.1.14. C2 security:
             6.1.15. COPS:
             6.1.16. Tiger (part of the TAMU Security Package):  

          File Integrity Checking tools
             6.1.17. MD5:
             6.1.18. Tripwire:

          Other tools
             6.1.19. lsof:  
             6.1.20. cpm:
             6.1.21. smrsh:
             6.1.22. append-only file systems:

          Additional tools (please specify):  

     6.2. At the time of the incident, which of the following logs were you
          using, if any (Yes/No)

          6.2.1. syslog:
          6.2.2. utmp:
          6.2.3. wtmp:
          6.2.4. TCP wrapper:
          6.2.5. process accounting:  

     6.3. What do you believe to be the reliability and integrity of
          these logs (e.g., are the logs stored offline or on a
          different host):  

7.0. Detailed description of the incident

     7.1. Please complete in as much detail as possible

          7.1.1.  Date and duration of incident:
          7.1.2.  How you discovered the incident:
          7.1.3.  Method used to gain access to the affected host(s):
          7.1.4.  Details of vulnerabilities exploited that are
		  not addressed in previous sections:
          7.1.5.  Other aspects of the "attack":
          7.1.6.  Hidden files/directories:  
          7.1.7.  The source of the attack (if known):
          7.1.8.  Steps taken to address the incident (e.g., binaries
                  reinstalled, patches applied):  
          7.1.9.  Planned steps to address the incident (if any):  
          7.1.10. Do you plan to start using any of the tools listed
	          above in question 6.0 (please list tools expected 
		  to use):
          7.1.11. Other:   

     7.2. Please append any log information or directory listings and
          timezone information (relative to GMT).

     7.3. Please indicate if any of the following were left on your
	  system by the intruder (Yes/No):  

          7.3.1. intruder tool output (such as packet sniffer output
		 logs):
          7.3.2. tools/scripts to exploit vulnerabilities:  
          7.3.3. source code programs (such as Trojan horse programs,
	         sniffer programs):  
          7.3.4. binary code programs (such as Trojan horse programs,
                 sniffer programs):  
          7.3.5. other files:  

          If you answered yes to any of the last 5 questions, please call
	  the CERT/CC hotline (+1 412 268 7090) for instructions on
	  uploading files to us by FTP.  Thanks.

     7.4. What assistance would you like from the CERT/CC?

Copyright 1996 Carnegie Mellon University
This form may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the CERT Coordination Center is
acknowledged.

CERT is a service mark of Carnegie Mellon University.

---

From: "Paul Taylor" <[email-masked]>
Date: Wed, 29 Jan 1997 14:14:00 +0000

Hi Everyone

I know that this may sound like a strange question, but is there 
anything that can be done to assist in transfers timeing out giving 
the remote lost connections. I know that the ftpd can not sort out 
Internet reponse times but thought there may be a way of giving it a 
longer wait period or something.

I am using Linux 2.0.24 

Thanks
Paul