os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Import FreeBSD Security Advisories and Errata Notices, as well as their

Browse source 
patches for easier mirroring, to eliminate a special copy, to make
www.freebsd.org/security a full copy of security.freebsd.org and be
eventually be the same.

For now files are just sitting there.   The symlinks are missing.

Discussed on:	www (repository location)
Discussed with:	simon (so)
This commit is contained in:
Bjoern A. Zeeb 2012-08-15 06:19:40 +00:00
parent 01c8718f26
commit 3571e53040
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=39381
1185 changed files with 317546 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

254
share/security/advisories/CERT-CA-98-13-tcp-denial-of-service.asc Normal file
View file

@ -0,0 +1,254 @@
-----BEGIN PGP SIGNED MESSAGE-----
CERT Advisory CA-98-13-tcp-denial-of-service
Original Issue Date: December 21, 1998
Last Revised
Topic: Vulnerability in Certain TCP/IP Implementations
Affected Systems
Some systems with BSD-derived TCP/IP stacks. See Appendix A for a
complete list of affected systems.
Overview
Intruders can disrupt service or crash systems with vulnerable TCP/IP
stacks. No special access is required, and intruders can use
source-address spoofing to conceal their true location.
I. Description
By carefully constructing a sequence of packets with certain
characteristics, an intruder can cause vulnerable systems to crash,
hang, or behave in unpredictable ways. This vulnerability is similar
in its effect to other denial-of-service vulnerabilities, including
the ones described in
http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html
Specifically, intruders can use this vulnerability in conjunction with
IP-source-address spoofing to make it difficult or impossible to know
their location. They can also use the vulnerability in conjunction
with broadcast packets to affect a large number of vulnerable machines
with a small number of packets.
II. Impact
Any remote user can crash or hang a vulnerable machine, or cause the
system to behave in unpredictable ways.
III. Solution
A. Install a patch from your vendor.
Appendix A contains input from vendors who have provided information
for this advisory. We will update the appendix as we receive more
information. If you do not see your vendor's name, the CERT/CC did not
hear from that vendor. Please contact your vendor directly.
B. Configure your router or firewall to help prevent source-address spoofing.
We encourage sites to configure their routers or firewalls to reduce
the ability of intruders to use source-address spoofing. Currently,
the best method to reduce the number of IP-spoofed packets exiting
your network is to install filtering on your routers that requires
packets leaving your network to have a source address from your
internal network. This type of filter prevents a source IP-spoofing
attack from your site by filtering all outgoing packets that contain a
source address of a different network.
A detailed description of this type of filtering is available in RFC
2267, "Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing" by Paul Ferguson of Cisco
Systems, Inc. and Daniel Senie of Blazenet, Inc. We recommend it to
both Internet Service Providers and sites that manage their own
routers. The document is currently available at
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2267.txt
Note that this type of filtering does not protect a site from the
attack itself, but it does reduce the ability of intruders to conceal
their location, thereby discouraging attacks.
Appendix A - Vendor Information
Berkeley Software Design, Inc. (BSDI)
BSDI's current release BSD/OS 4.0 is not vulnerable to this problem.
BSD/OS 3.1 is vulnerable and a patch (M310-049) is available from
BSDI's WWW server at http://www.bsdi.com/support/patches or via our
ftp server from the directory
ftp://ftp.bsdi.com/bsdi/patches/patches-3.1.
Cisco Systems
Cisco is not vulnerable.
Compaq Computer Corporation
SOURCE: (c) Copyright 1994, 1995, 1996, 1997, 1998 Compaq Computer
Corporation.
All rights reserved.
SOURCE: Compaq Computer Corporation
Compaq Services
Software Security Response Team USA
This reported problem is not present for the as shipped, Compaq's
Digital ULTRIX or Compaq's Digital UNIX Operating Systems Software.
- Compaq Computer Corporation
Data General Corporation
We are investigating. We will provide an update when our investigation
is complete.
FreeBSD, Inc.
FreeBSD 2.2.8 is not vulnerable.
FreeBSD versions prior to 2.2.8 are vulnerable.
FreeBSD 3.0 is also vulnerable.
FreeBSD 3.0-current as of 1998/11/12 is not vulnerable.
A patch is available at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/CA-98-13/patch
Fujitsu
Regarding this vulnerability, Fujitsu's UXP/V operating system is not
vulnerable.
Hewlett-Packard Company
HP is not vulnerable.
IBM Corporation
AIX is not vulnerable.
IBM and AIX are registered trademarks of International Business
Machines Corporation.
Livingston Enterprises, Inc.
Livingston systems are not vulnerable.
Computer Associates International
CA systems are not vulnerable.
Microsoft Corporation
Microsoft is not vulnerable.
NEC Corporation
NEC Corporation EWS-UX, UP-UX and UX/4800 Unix systems are not
vulnerable to this problem.
OpenBSD
Security fixes for this problem are now available for 2.3 and 2.4.
For 2.3, see
www.openbsd.org/errata23.html#tcpfix
For our 2.4 release which is available on CD on Dec 1, see
www.openbsd.org/errata.html#tcpfix
The bug is fixed in our -current source tree.
Sun Microsystems, Inc.
We have confirmed that SunOS and Solaris are not vulnerable to the DOS
attack.
Wind River Systems, Inc.
We've taken a look at our networking code and have determined that
this is not a problem in the currently shipping version of the VxWorks
RTOS.
_________________________________________________________________
Contributors
The vulnerability was originally discovered by Joel Boutros of the
Enterprise Security Services team of Cambridge Technology Partners.
Guido van Rooij of FreeBSD, Inc., provided an analysis of the
vulnerability and information regarding its scope and extent.
______________________________________________________________________
This document is available from:
http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html.
______________________________________________________________________
CERT/CC Contact Information
Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.
CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
Monday through Friday; they are on call for emergencies during other
hours, on U.S. holidays, and on weekends.
Using encryption
We strongly urge you to encrypt sensitive information sent by email.
Our public PGP key is available from http://www.cert.org/CERT_PGP.key.
If you prefer to use DES, please call the CERT hotline for more
information.
Getting security information
CERT publications and other security information are available from
our web site http://www.cert.org/.
To be added to our mailing list for advisories and bulletins, send
email to cert-advisory-request@cert.org and include SUBSCRIBE
your-email-address in the subject of your message.
Copyright 1998 Carnegie Mellon University.
Conditions for use, disclaimers, and sponsorship information can be
found in http://www.cert.org/legal_stuff.html.
* CERT is registered in the U.S. Patent and Trademark Office
______________________________________________________________________
NO WARRANTY
Any material furnished by Carnegie Mellon University and the Software
Engineering Institute is furnished on an "as is" basis. Carnegie
Mellon University makes no warranties of any kind, either expressed or
implied as to any matter including, but not limited to, warranty of
fitness for a particular purpose or merchantability, exclusivity or
results obtained from use of the material. Carnegie Mellon University
does not make any warranty of any kind with respect to freedom from
patent, trademark, or copyright infringement.
_________________________________________________________________
Revision History
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNn64knVP+x0t4w7BAQHd/wQAv+1cQif/KNdFZ1ObARzlJJUd9T0Za5WM
GjZwrlYR3CIm+eByVbGGizCYTXzuiTjQdenKxfDXAXXwqZRIvFbpjU3qWY6kCicf
BhTbvzOOIT/ROhr9fWRwPqqPMKUyUYaJCbeWYWeV6PFJ6fYhWrBihiE+yml4n1Xp
k2lHvwHl9lE=
=9kEz
-----END PGP SIGNATURE-----

84
share/security/advisories/FreeBSD-EN-04:01.twe.asc Normal file
View file

@ -0,0 +1,84 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-04:01.twe Errata Notice
The FreeBSD Project
Topic: twe(4) driver may hang on heavily loaded systems
Category: core
Module: twe(4) device driver
Announced: 2004-06-28
Credits: Vinod Kashyap
Paul Saab
Affects: FreeBSD 4.10-RELEASE
Corrected: 2004-06-26 02:22:24 UTC (4.10-RELEASE-p1)
I. Background
The twe(4) driver handles the 3ware series of RAID controllers.
II. Problem Description
On 6xxx series controllers the driver may try to repeatedly submit the
same request if the cmd queue gets full, which may happen under extremely
high I/O rates.
III. Impact
Once the driver entered the state it was repeatedly submitting the same
request all normal disk I/O through the controller stops. The computer
would require a hard reset, any pending I/O buffered in memory would be
lost.
IV. Solution
Do one of the following:
1) Upgrade your vulnerable system to the RELENG_4_10 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the preferred
method.
2) To patch your present system:
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ERRATA/patches/EN-04:01/twe.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ERRATA/patches/EN-04:01/twe.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch -p0 < /path/to/patch
Then follow the normal procedures for rebuilding/reinstalling the kernel.
Note that this method will only work with no errors if your system was
installed from scratch using the FreeBSD-4.10 Release CDs or FTP install.
If that is not the case you may see errors while patching the UPDATING
file. Those errors would be harmless. Any other errors while running
patch(1) should be investigated before proceeding with the rebuild/reinstall.
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- --------------------------------------------------------------------------
RELENG_4_10
src/sys/dev/twe/twe.c 1.1.2.8.2.2
src/sys/dev/twe/twe_freebsd.c 1.2.2.8.2.1
src/sys/dev/twe/twevar.h 1.1.2.6.2.2
src/sys/conf/newvers.sh 1.44.2.34.2.3
src/UPDATING 1.73.2.90.2.2
- --------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFA3ZYO/G14VSmup/YRAlOqAJ0cTgJcc83f+aAnHSFejBbUwMp5vQCdGpfB
mHTWM/zA65ZjvrPEq1mrZy8=
=T1Ow
-----END PGP SIGNATURE-----

84
share/security/advisories/FreeBSD-EN-05:01.nfs.asc Normal file
View file

@ -0,0 +1,84 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-05:01.nfs Errata Notice
The FreeBSD Project
Topic: NFS Server may panic under certain load patterns
Category: core
Module: nfsserver
Announced: 2005-01-05
Credits: Robert Watson
Affects: FreeBSD 5.3-RELEASE
Corrected: 2005-01-05 03:35:00 UTC
I. Background
The Network File System (NFS) allows a system to share directories and files
with others over a network. By using this, users and programs can access
files on remote systems almost as if they were local files.
II. Problem Description
Due to a bug in nfsrv_create() a call to nfsrv_access() might be made
while holding the NFS server mutex, which results in kernel panics under
certain load patterns.
III. Impact
NFS servers that encountered the load pattern would crash and reboot.
IV. Solution
Do one of the following to update the source tree:
1) Upgrade your vulnerable system to the RELENG_5_3 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the
preferred method.
2) Obtain the updated files using the cvsweb interface. Cvsweb is a
Web interface to the CVS repository. The URL to the general
interface is "http://www.freebsd.org/cgi/cvsweb.cgi/". You can
obtain any of the source files for the RELENG_5_3 branch by going
to the src directory ("http://www.freebsd.org/cgi/cvsweb.cgi/src")
and then selecting the "RELENG_5_3" branch tag. With the branch
tag set navigate to the files listed below in the "Correction
details" section and download them, making sure you get the correct
revision numbers. Copy the downloaded files into your /usr/src tree.
If using the second procedure you should make sure you have used that
same procedure to download all previous Errata Notices and Security
Advisories. We strongly discourage this procedure due to the problems
that may be caused by not doing that - using the first procedure takes
care of making sure all updates get applied.
Then follow the normal procedures for rebuilding/reinstalling the kernel.
Details about rebuilding/reinstalling are available here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- --------------------------------------------------------------------------
RELENG_5_3
Revision Changes Path
1.342.2.13.2.6 +5 -0 src/UPDATING
1.62.2.15.2.8 +1 -1 src/sys/conf/newvers.sh
1.147.2.1.2.2 +52 -38 src/sys/nfsserver/nfs_serv.c
- --------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFB3HLR/G14VSmup/YRAuOXAJwI4YDlIDgLSkf8gTGSGKV+9CJX0wCgmVik
x/MKtaf+dAelJTDxrUGUfmo=
=ywyb
-----END PGP SIGNATURE-----

85
share/security/advisories/FreeBSD-EN-05:02.sk.asc Normal file
View file

@ -0,0 +1,85 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-05:02.sk Errata Notice
The FreeBSD Project
Topic: sk(4) driver instability on SMP systems
Category: core
Module: sys_pci
Announced: 2005-01-06
Credits: Peter Edwards, John-Mark Gurney, David O'Brien, Bjoern A. Zeeb
Affects: FreeBSD 5.3-RELEASE
Corrected: 2005-01-06 17:54:47 UTC
I. Background
The sk(4) network driver provides support for SysKonnect-based Gigabit
Ethernet adapters.
II. Problem Description
Several programming errors were discovered in the sk(4) network driver,
including an off-by-one error and a missing lock.
III. Impact
FreeBSD symmetric multiprocessing (SMP) systems using the sk(4) network
driver may experience data corruption or system crashes. Symptoms
include panics, page faults, aborted SSH connections, and corrupted file
transfers.
IV. Solution
Do one of the following to update the source tree:
1) Upgrade your vulnerable system to the RELENG_5_3 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the
preferred method.
2) Obtain the updated files using the cvsweb interface. Cvsweb is a
Web interface to the CVS repository. The URL to the general
interface is "http://www.freebsd.org/cgi/cvsweb.cgi/". You can
obtain any of the source files for the RELENG_5_3 branch by going
to the src directory ("http://www.freebsd.org/cgi/cvsweb.cgi/src")
and then selecting the "RELENG_5_3" branch tag. With the branch
tag set navigate to the files listed below in the "Correction
details" section and download them, making sure you get the correct
revision numbers. Copy the downloaded files into your /usr/src tree.
If using the second procedure you should make sure you have used that
same procedure to download all previous Errata Notices and Security
Advisories. We strongly discourage this procedure due to the problems
that may be caused by not doing that - using the first procedure takes
care of making sure all updates get applied.
Then follow the normal procedures for rebuilding/reinstalling the kernel.
Details about rebuilding/reinstalling are available here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
- --------------------------------------------------------------------------
RELENG_5_3
Revision Changes Path
1.342.2.13.2.7 +4 -0 src/UPDATING
1.62.2.15.2.9 +1 -1 src/sys/conf/newvers.sh
1.83.2.2.2.1 +33 -16 src/sys/pci/if_sk.c
1.20.2.2.2.1 +1 -0 src/sys/pci/if_skreg.h
- --------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFB3YWR/G14VSmup/YRAisHAKCZDDsbpJ6QQWtVQaU+lo1N8OKQfACdGOdL
dppEWGvxke7etwmpDK63k98=
=x28D
-----END PGP SIGNATURE-----

89
share/security/advisories/FreeBSD-EN-05:03.ipi.asc Normal file
View file

@ -0,0 +1,89 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-05:03.ipi Errata Notice
The FreeBSD Project
Topic: FreeBSD/i386 may panic under heavy load on SMP machines
Category: core
Module: smp
Announced: 2005-01-16
Credits: Stephan Uphoff, Xin LI
Affects: FreeBSD 5.3-RELEASE
Corrected: 2005-01-16 08:29:14 UTC
I. Background
Inter-processor Interrupt, also known as ``IPI'', is a mechanism on
multiprocessor system (specifically, SMP) to indicate some event that the
other CPUs should be aware of.
II. Problem Description
Under FreeBSD 5.3-RELEASE prior to the correction date, when there are
more than two pending IPI vectors per local APIC it is possible to cause
deadlocks. The deadlock will then result in a kernel panic.
III. Impact
SMP servers that encounted heavy load, e.g. buildworld with md(4) and -jN,
can easily be crashed.
IV. Solution
Do one of the following to update the source tree:
1) Upgrade your affected system to the RELENG_5_3 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the
preferred method. For information on how to use cvsup(1) to update
your source code see:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
2) Obtain the updated files using the cvsweb interface. Cvsweb is a
Web interface to the CVS repository. The URL to the general
interface is "http://www.freebsd.org/cgi/cvsweb.cgi/". You can
obtain any of the source files for the RELENG_5_3 branch by going
to the src directory ("http://www.freebsd.org/cgi/cvsweb.cgi/src")
and then selecting the "RELENG_5_3" branch tag. With the branch
tag set navigate to the files listed below in the "Correction
details" section and download them, making sure you get the correct
revision numbers. Copy the downloaded files into your /usr/src tree.
If using the second procedure you should make sure you have used that
same procedure to download all previous Errata Notices and Security
Advisories. We strongly discourage this procedure due to the problems
that may be caused by not doing that - using the first procedure takes
care of making sure all updates get applied.
Then follow the normal procedures for rebuilding/reinstalling the kernel.
Details about rebuilding/reinstalling are available here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
- ---------------------------------------------------------------------------
RELENG_5_3
Revision Changes Path
1.342.2.13.2.8 +4 -0 src/UPDATING
1.62.2.15.2.10 +1 -1 src/sys/conf/newvers.sh
1.101.4.1 +2 -50 src/sys/i386/i386/apic_vector.s
1.235.2.3.2.1 +65 -37 src/sys/i386/i386/mp_machdep.c
1.8.4.1 +42 -9 src/sys/i386/include/apicvar.h
1.78.4.1 +2 -5 src/sys/i386/include/smp.h
- ---------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFB6yY3/G14VSmup/YRAtq7AJ4nr1MGKyV1kzEhTRN66L7atWbUUgCdHERt
tYcKMOFWc6i7sjGuJBqZvog=
=k5nm
-----END PGP SIGNATURE-----

82
share/security/advisories/FreeBSD-EN-05:04.nfs.asc Normal file
View file

@ -0,0 +1,82 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-05:04.nfs Errata Notice
The FreeBSD Project
Topic: NFS Client may panic when encounted errors
Category: core
Module: nfsclient
Announced: 2005-12-19
Credits: Mohan Srinivasan, Xin LI
Affects: FreeBSD 6.0-RELEASE
Corrected: 2005-12-19 10:58:58 UTC
I. Background
The Network File System (NFS) allows a system to share directories and files
with others over a network. By using this, users and programs can access
files on remote systems almost as if they were local files.
II. Problem Description
Due to a locking issue in nfs_lookup() a call to vrele() might be made
while holding the vnode mutex, which results in kernel panic when doing
VFS operations under certain load patterns.
III. Impact
NFS clients that encountered the load pattern would crash and reboot.
IV. Solution
Do one of the following to update the source tree:
1) Upgrade your affected system to the RELENG_6_0 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the
preferred method.
2) Obtain the updated files using the cvsweb interface. Cvsweb is a
Web interface to the CVS repository. The URL to the general
interface is "http://cvsweb.freebsd.org/". You can obtain any of
the source files for the RELENG_6_0 branch by going to the src
directory ("http://cvsweb.freebsd.org/src") and then selecting
the "RELENG_6_0" branch tag. With the branch tag set navigate
to the files listed below in the "Correction details" section and
download them, making sure you get the correct revision numbers.
Copy the downloaded files into your /usr/src tree.
If using the second procedure you should make sure you have used that
same procedure to download all previous Errata Notices and Security
Advisories. We strongly discourage this procedure due to the problems
that may be caused by not doing that - using the first procedure takes
care of making sure all updates get applied.
Then follow the normal procedures for rebuilding/reinstalling the kernel.
Details about rebuilding/reinstalling are available here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
- ---------------------------------------------------------------------------
RELENG_6_0
Revision Changes Path
1.416.2.3.2.6 +5 -0 src/UPDATING
1.69.2.8.2.2 +1 -1 src/sys/conf/newvers.sh
1.258.4.1 +1 -1 src/sys/nfsclient/nfs_vnops.c
- ---------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQFDujwhFdaIBMps37IRAiPOAKCC9BmZhzFEBm6/kzKMDpZVXk7X/QCfTmsY
kHH+tM9KBV1Vau80d0G3vk4=
=UvNX
-----END PGP SIGNATURE-----

90
share/security/advisories/FreeBSD-EN-06:01.jail.asc Normal file
View file

@ -0,0 +1,90 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
FreeBSD-EN-06:01.jail Errata Notice
The FreeBSD Project
Topic: Jail startup scripts may override some global jail_*
variables.
Category: core
Module: etc_rc.d
Announced: 2006-07-07
Credits: Florent Thoumie, Pawel Dawidek, Cheng-Lung Sung
Affects: FreeBSD 6.1-RELEASE
Corrected: 2006-07-07 07:25:21 UTC
I. Background
System startup scripts, typically in /etc/rc.d, control what happens
as a system boots to multi-user mode. The behavior of those scripts
can be controlled by "global" variables in /etc/rc.conf.
II. Problem Description
The names of several internal variables in the jail startup script
conflicted with those of global variables that could be set by
administrators. In addition, some configuration variables are not
properly validated in the jail startup script.
III. Impact
Jails may not have started up as the administrator intended. If some
configuration variables required by jail configuration in /etc/rc.conf
are not correctly set jail startup may have been attempted by the script
anyway.
IV. Solution
Do one of the following to update the source tree:
1) Upgrade your affected system to the RELENG_6_1 errata branch dated
after the correction date using cvsup(1) or cvs(1). This is the
preferred method. For information on how to use cvsup(1) to update
your source code see:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
2) Obtain the updated files using the cvsweb interface. Cvsweb is a
Web interface to the CVS repository. The URL to the general
interface is "http://www.freebsd.org/cgi/cvsweb.cgi/". You can
obtain any of the source files for the RELENG_6_1 branch by going
to the src directory ("http://www.freebsd.org/cgi/cvsweb.cgi/src")
and then selecting the "RELENG_6_1" branch tag. With the branch
tag set navigate to the files listed below in the "Correction
details" section and download them, making sure you get the correct
revision numbers. Copy the downloaded files into your /usr/src tree.
If using the second procedure you should make sure you have used that
same procedure to download all previous Errata Notices and Security
Advisories. We strongly discourage this procedure due to the problems
that may be caused by not doing that - using the first procedure takes
care of making sure all updates get applied.
Then use mergemaster(8) to install the updated startup script support. Note
that mergemaster(8) will expect to find a normal object file tree having
resulted from doing 'make world' in /usr/src, and will build one if it
does not exist. If you do not have a recent object file tree you may
want to just manually copy the src/etc/rc.d/jail and src/etc/defaults/rc.conf
files into place.
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
- ---------------------------------------------------------------------------
RELENG_6_1
Revision Changes Path
1.416.2.22.2.5 +3 -0 src/UPDATING
1.23.2.3.2.2 +102 -91 src/etc/rc.d/jail
1.69.2.11.2.5 +1 -1 src/sys/conf/newvers.sh
- ---------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFErgzzFdaIBMps37IRAh17AJwLueUv5ZzXrbZG8qtL1lwgpPZCCgCfYGxE
2oAorGMRBTbqVx/YhKJX1lA=
=Lmti
-----END PGP SIGNATURE-----

112
share/security/advisories/FreeBSD-EN-06:02.net.asc Normal file
View file

@ -0,0 +1,112 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-06:02.net Errata Notice
The FreeBSD Project
Topic: Networking Issues
Category: core
Module: sys
Announced: 2006-08-28
Credits: Robert Watson, JINMEI Tatuya
Affects: FreeBSD 6.1-RELEASE
Corrected: 2006-08-28 07:31:11 UTC (RELENG_6_1, 6.1-RELEASE-p5)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The FreeBSD kernel provides basic networking services, supporting the
IPv4 and IPv6 network protocols.
II. Problem Description
Several issues have been discovered in the networking code in the
FreeBSD 6.1 kernel. Specifically:
1. A pointer was not being checked for validity before being
dereferenced.
2. Some statistics-keeping code in the UMA memory allocator
erroneously counted certain types of successful memory allocations
as failures.
3. IPv6 neighbor discovery did not work correctly over point-to-point
links.
III. Impact
The impacts of these bugs are varied.
1. The pointer dereferencing issue could cause a kernel panic.
2. The memory statistics-keeping error could cause the kernel to
report an incorrect number of memory allocations that failed.
One symptom of this problem is a artificially high count of
"requests for mbufs denied" in the output from "netstat -m".
3. The IPv6 neighbor discovery bug could cause spurious warnings to
be generated when running IPv6 over point-to-point links. This
problem was particularly noticeable over gif(4) tunnels.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, or to the RELENG_6_1
security branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 6.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-06:02/net.patch
# fetch http://security.FreeBSD.org/patches/EN-06:02/net.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6_1
src/UPDATING 1.416.2.22.2.7
src/sys/conf/newvers.sh 1.69.2.11.2.7
src/sys/netinet/ip_output.c 1.242.2.8.2.1
src/sys/netinet6/in6.c 1.51.2.8.2.1
src/sys/netinet6/nd6.c 1.48.2.12.2.1
src/sys/vm/uma_core.c 1.119.2.15.2.1
- -------------------------------------------------------------------------
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-06:02.net.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFE8pwjFdaIBMps37IRAtQkAKCd89w0feF8PI4RM5cD90WQX/fPOgCfb/OH
wecGoGYP8sZw8vTx0i5HqQQ=
=Qj8N
-----END PGP SIGNATURE-----

119
share/security/advisories/FreeBSD-EN-07:01.nfs.asc Normal file
View file

@ -0,0 +1,119 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-07:01.nfs Errata Notice
The FreeBSD Project
Topic: NFS server reliability issues
Category: core
Module: sys_nfsserver
Announced: 2007-02-14
Credits: Kostik Belousov,
Pawel Jakub Dawidek,
Padma Bhooma,
Hiroki Sato
Affects: All FreeBSD 6.x releases prior to 6.2-RELEASE
Corrected: 2007-01-07 13:20:24 UTC (RELENG_6, 6.2-STABLE)
2007-02-14 22:30:33 UTC (RELENG_6_1, 6.1-RELEASE-p14)
2007-02-14 22:29:57 UTC (RELENG_6_0, 6.0-RELEASE-p18)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.FreeBSD.org/>.
I. Background
The Network File System (NFS) allows a host to export some or all of
its file systems so that other hosts can access them over the network
and mount them as if they were on local disks. NFS is built on top of
the Sun Remote Procedure Call (RPC) framework. FreeBSD includes
server and client implementations of NFS.
II. Problem Description
The NFS server subsystem had the following three problems:
- Inconsistent locking that leads to performance degradation and can
cause a system panic during certain operations to manipulate symbolic
links.
- A memory leak in pathname lookup operation.
- A bug that prevents a symbolic link with a particular pathname from
being created.
III. Impact
Under some circumstances, the NFS server subsystem can cause a system
panic due to bugs in the FreeBSD kernel. This can be serious and could
lead to a denial of service especially in an NFS server configuration
where the server shares home directories amongst many clients.
This is because several particular operations from a client can trigger
the panic without special privilege on either the server and the client.
IV. Solution
Perform one of the following:
1) Upgrade your affected system to 6-STABLE, or to the RELENG_6_1 or
RELENG_6_0 errata branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.0 and
6.1 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 6.0]
# fetch http://security.FreeBSD.org/patches/EN-07:01/nfs60.patch
# fetch http://security.FreeBSD.org/patches/EN-07:01/nfs60.patch.asc
[FreeBSD 6.1]
# fetch http://security.FreeBSD.org/patches/EN-07:01/nfs61.patch
# fetch http://security.FreeBSD.org/patches/EN-07:01/nfs61.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
V. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6_1
src/UPDATING 1.416.2.22.2.16
src/sys/conf/newvers.sh 1.69.2.11.2.16
src/sys/nfsserver/nfs_serv.c 1.156.2.2.2.1
src/sys/nfsserver/nfs_srvsubs.c 1.136.2.2.2.1
src/sys/nfsserver/nfsm_subs.h 1.37.6.1
RELENG_6_0
src/UPDATING 1.416.2.3.2.23
src/sys/conf/newvers.sh 1.69.2.8.2.19
src/sys/nfsserver/nfs_serv.c 1.156.4.1
src/sys/nfsserver/nfs_srvsubs.c 1.136.4.1
src/sys/nfsserver/nfsm_subs.h 1.37.4.1
- -------------------------------------------------------------------------
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-07:01.nfs.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF047GFdaIBMps37IRAlDuAJ9sjXfjvIl+F9/sqZSXksUeagRIAwCePXsA
cb9f5GWVCblMm/Y90CUjYTE=
=g+wq
-----END PGP SIGNATURE-----

110
share/security/advisories/FreeBSD-EN-07:02.net.asc Normal file
View file

@ -0,0 +1,110 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-07:02.net Errata Notice
The FreeBSD Project
Topic: IPv6 over Point-to-Point gif(4) tunnels
Category: core
Module: sys_netinet6
Announced: 2007-02-28
Credits: Bruce A. Mah
Affects: FreeBSD 6.2-RELEASE
Corrected: 2007-02-08 22:52:56 UTC (RELENG_6, 6.2-STABLE)
2007-02-28 18:24:37 UTC (RELENG_6_2, 6.2-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.FreeBSD.org/>.
I. Background
The FreeBSD kernel provides basic networking services, including
(among other protocols) the IPv6 network protocol stack.
The gif(4) tunnel driver provides a generic tunnelling interface,
which is commonly used to carry IPv6 packets across an IPv4 internetwork.
II. Problem Description
FreeBSD 6.2-RELEASE contains a regression in the behavior of IPv6
over gif(4) tunnels configured as point-to-point interfaces (in
other words, gif(4) interfaces with an explicitly-configured destination
address and a 128-bit prefix length). When such an interface is
configured, a route to the destination address must be added implicitly
by the kernel to allow packets to traverse the tunnel properly.
FreeBSD 6.2-RELEASE does not do this.
III. Impact
In some cases, it may be impossible for a host to send IPv6 traffic over a
gif(4) tunnel interface due to the lack of an appropriate routing table
entry.
IV. Workaround
One workaround is to add a route to the destination address explicitly
using the route(8) command, as in the following example:
# route add -host -inet6 ADDRESS -interface GIF -nostatic -llinfo
In the command line above, ADDRESS and GIF should be replaced by the
destination IPv6 address and the interface name of the gif(4) tunnel,
respectively.
In some cases, the host route to the destination may be added implicitly
as a side-effect of receiving inbound packets over the tunnel.
V. Solution
Perform one of the following:
1) Upgrade your affected system to 6-STABLE or to the RELENG_6_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.2
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-07:02/net.patch
# fetch http://security.FreeBSD.org/patches/EN-07:02/net.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- ----------------------------------------------------------------------------
RELENG_6_2
src/UPDATING 1.416.2.29.2.5
src/sys/conf/newvers.sh 1.69.2.13.2.5
src/sys/netinet6/nd6.c 1.48.2.15.2.1
- ----------------------------------------------------------------------------
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-07:02.net.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF5ct4FdaIBMps37IRAjN0AJ9llRTF/ccXBJDRqJeFDocSkIF5lQCdF2ww
y+4KLUVBRVLLQz0AJuKygfc=
=x04b
-----END PGP SIGNATURE-----

104
share/security/advisories/FreeBSD-EN-07:03.rc.d_jail.asc Normal file
View file

@ -0,0 +1,104 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-07:03.rc.d_jail Errata Notice
The FreeBSD Project
Topic: rc.d jail script interface IP alias removal
Category: core
Module: etc_rc.d
Announced: 2007-02-28
Credits: Philipp Wuensche
Affects: FreeBSD 6.2-RELEASE.
Corrected: 2007-01-02 11:14:07 UTC (RELENG_6, 6.2-STABLE)
2007-02-28 18:24:37 UTC (RELENG_6_2, 6.2-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The jail(2) system call allows a system administrator to lock a process
and all of its descendants inside an environment with a very limited
ability to affect the system outside that environment, even for
processes with superuser privileges. It is an extension of, but
far more powerful than, the traditional UNIX chroot(2) system call.
The host's jail rc.d(8) script can be used to start and stop jails
automatically on system boot/shutdown. The jail_interface rc.conf(5)
variable can be used to automatically add and remove an IP address on
a specific network interface when a jail starts and stops.
II. Problem Description
A cleanup of the rc.d jail script did not rename the variables used by
the jail_interface feature when removing the IP address in the case
where the jail startup fails. This may result in ifconfig(8) being
run with incorrect arguments.
III. Impact
Since the wrong variable is used, in some cases, ifconfig(8) will
remove an arbitrary IP address instead of the IP address of the jail
if startup of a jail fails. It may be possible for a user with root
access in a jail to provoke this situation by intentionally making
jail startup fail.
IV. Workaround
Do not use the jail_interface feature; instead, manually configure IP
addresses for the jails.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE, or to the RELENG_6_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.2
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-07:03/rc.d_jail.patch
# fetch http://security.FreeBSD.org/patches/EN-07:03/rc.d_jail.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# install -o root -g wheel -m 555 etc/rc.d/jail /etc/rc.d
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/etc/rc.d/jail 1.23.2.8
RELENG_6_2
src/UPDATING 1.416.2.29.2.5
src/sys/conf/newvers.sh 1.69.2.13.2.5
src/etc/rc.d/jail 1.23.2.7.2.2
- -------------------------------------------------------------------------
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-07:03.rc.d_jail.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF5ct8FdaIBMps37IRAu3qAKCHNEFb/kqTVyFSllHyG6YOg+qccACfbmfI
CiEeWDDU73GVG+T15VeGH2Q=
=EQyo
-----END PGP SIGNATURE-----

136
share/security/advisories/FreeBSD-EN-07:04.zoneinfo.asc Normal file
View file

@ -0,0 +1,136 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-07:04.zoneinfo Errata Notice
The FreeBSD Project
Topic: Zoneinfo file update
Category: core
Module: share_zoneinfo
Announced: 2007-02-28
Affects: FreeBSD 6.1-RELEASE
Corrected: 2007-02-28 18:23:09 UTC (RELENG_6_1, 6.1-RELEASE-p15)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The tzsetup(8) program allows the user to specify the default local
timezone. Based on the user's choice, tzsetup(8) copies one of the
files from /usr/share/zoneinfo to /etc/localtime. This file actually
controls the conversion.
II. Problem Description
In 2005 several governments, among them the United States of America and
Canada, decided to change when Daylight Savings Time begins and ends.
The change takes effect in 2007. Because of that change the data in
the zoneinfo files needs to be updated, and if the computer's local
time zone is affected tzsetup(8) needs to be run so /etc/localtime
gets updated.
FreeBSD 6.1-RELEASE shipped with the correct zoneinfo files for the United
States time zones affected by the change made in 2005, but the zoneinfo
files for several other countries (e.g. Canada) do not contain current
information.
III. Impact
If the /usr/share/zoneinfo files as well as /etc/localtime are not updated
on a computer that has its time zone set to one of the regions affected by
the change made in 2005 it will display the wrong time between March 15th
and April 1st, then again between October 28th and November 4th. All things
on that computer that rely on the system time (e.g. cron jobs, timestamps
entered in log files, etc) will be affected.
IV. Workaround
At least in theory the system time could be manually adjusted by an hour
on the affected dates. However the system will still incorrectly say whether
or not Daylight Savings Time is in effect (e.g. it will still say the
time is "EST" instead of "EDT" for the Eastern US). Doing this is NOT
recommended because the kernel stores timestamp information in the
filesystem and other places using its internal representation of time
(based on UTC).
Since the following is such a frequently asked question we will mention
the answer here. Using an NTP server as the source of your system's
time will NOT automatically take care of the change in Daylight Savings
Time. This patch should still be applied if you are in a region that
is affected.
V. Solution
Following the instructions in this Errata Notice will update all of
the zoneinfo files to be the same as what was released with FreeBSD
6.2-RELEASE.
Perform one of the following:
1) Upgrade your affected system to 6-STABLE or to the RELENG_6_1
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.1
systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-07:04/zoneinfo.patch
# fetch http://security.FreeBSD.org/patches/EN-07:04/zoneinfo.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/share/misc
# make obj && make depend && make && make install
# cd /usr/src/share/zoneinfo
# make obj && make depend && make && make install
# tzsetup
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6_1
src/UPDATING 1.416.2.22.2.17
src/sys/conf/newvers.sh 1.69.2.11.2.17
src/share/misc/iso3166 1.13.12.1
src/share/zoneinfo/Makefile 1.20.6.1
src/share/zoneinfo/africa 1.14.14.2.2.1
src/share/zoneinfo/antarctica 1.1.2.10.12.2.2.1
src/share/zoneinfo/asia 1.25.2.2.2.1
src/share/zoneinfo/australasia 1.25.10.2.2.1
src/share/zoneinfo/backward 1.1.2.11.2.2.2.1
src/share/zoneinfo/etcetera 1.1.2.5.14.1.2.1
src/share/zoneinfo/europe 1.29.2.2.2.1
src/share/zoneinfo/factory 1.5.38.1
src/share/zoneinfo/leapseconds 1.13.2.1.2.1
src/share/zoneinfo/northamerica 1.25.2.2.2.1
src/share/zoneinfo/southamerica 1.24.2.2.2.1
src/share/zoneinfo/systemv 1.1.2.2.14.1.2.1
src/share/zoneinfo/yearistype.sh 1.1.2.5.14.1.2.1
src/share/zoneinfo/zone.tab 1.17.2.1.2.1
- -------------------------------------------------------------------------
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-07:04.zoneinfo.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF5ct/FdaIBMps37IRAiXgAJ4ldnfI9FL27J9n4/nHM9D0K1Qf6gCghXiL
9VMtdP/Us5QtJ7n4psLVIlg=
=AiEF
-----END PGP SIGNATURE-----

145
share/security/advisories/FreeBSD-EN-07:05.freebsd-update.asc Normal file
View file

@ -0,0 +1,145 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-07:05.freebsd-update Errata Notice
The FreeBSD Project
Topic: FreeBSD Update problems updating SMP kernels
Category: core
Module: usr.sbin
Announced: 2007-03-15
Affects: FreeBSD 6.2
Corrected: 2007-03-08 05:43:12 UTC (RELENG_6, 6.2-STABLE)
2007-03-15 08:06:11 UTC (RELENG_6_2, 6.2-RELEASE-p3)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
FreeBSD Update is a system for building, distributing, and installing
binary security and errata updates to the FreeBSD base system. Starting
with FreeBSD 6.2-RELEASE, the FreeBSD Update client software,
freebsd-update(8), has been included in the FreeBSD base system.
II. Problem Description
Due to a programming error in the FreeBSD Update client, kernels built
from the default SMP kernel configuration (including those distributed
as part of the release) are not correctly identified as such. On the
i386 platform, they are not recognized; on the amd64 platform, they are
mis-identified as GENERIC kernels.
III. Impact
On the i386 platform, if a system is running a kernel built from the
default SMP kernel configuration, and this kernel is installed somewhere
other than /boot/SMP/kernel, the FreeBSD Update client will not download
and install updates for it.
On the amd64 platform, if a system is running a kernel built from the
default SMP kernel configuration, and this kernel is installed somewhere
other than /boot/SMP/kernel, the FreeBSD Update client will replace it
with a kernel built from the GENERIC (single-processor) kernel
configuration.
IV. Workaround
As described in Security Advisories and Errata Notices, it is possible to
update FreeBSD systems by applying source code patches and rebuilding the
affected components.
Note that systems which are not running SMP kernels are not affected.
Note also that this problem applies only to FreeBSD 6.2 systems using the
FreeBSD Update client distributed as part of the FreeBSD base system.
The FreeBSD Update client distributed as security/freebsd-update in the
FreeBSD Ports Collection is not affected.
V. Solution
Perform one of the following:
1) Upgrade your affected system to 6-STABLE or to the RELENG_6_2 errata
branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 6.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-07:05/freebsd-update.patch
# fetch http://security.FreeBSD.org/patches/EN-07:05/freebsd-update.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/freebsd-update/
# make obj && make && make install
V.1. IMPORTANT NOTES to users of FreeBSD Update:
a) i386 systems:
It is possible that past kernel updates have not been downloaded and
installed by FreeBSD Update. To ensure that all available updates have
been installed, run FreeBSD Update twice; first to download and install
an updated FreeBSD Update client, and second to download and install any
updates which were missed earlier.
b) amd64 systems:
It is possible that systems which were initially installed with an SMP
kernel have been "updated" by replacing the kernel with a GENERIC kernel.
To see which kernel is running, run
# sysctl kern.smp.maxcpus
which will report either 1 (GENERIC kernel) or 16 (SMP kernel). (Note
that `uname -i`, the standard mechanism for determining a kernel ident,
returns "GENERIC" on both amd64 GENERIC and SMP kernels.)
If FreeBSD Update has replaced an SMP kernel by a GENERIC kernel,
repeatedly run
# freebsd-update rollback
and reboot until the system is running an SMP kernel.
Once you have verified that the system is running the correct kernel, run
FreeBSD Update twice *without rebooting*. The first time FreeBSD Update
is run it might replace an SMP kernel with a GENERIC kernel; but on the
second run (after an updated FreeBSD Update client is installed, and as
long as the system has not been rebooted into the wrong kernel) it will
download the correct kernel.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/usr.sbin/freebsd-update/freebsd-update.sh 1.2.2.4
RELENG_6_2
src/UPDATING 1.416.2.29.2.6
src/sys/conf/newvers.sh 1.69.2.13.2.6
src/usr.sbin/freebsd-update/freebsd-update.sh 1.2.2.2.2.2
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-07:05.freebsd-update.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFF+pUJFdaIBMps37IRAo+tAKCTwLNoR2C+ACCfQ8LNm7UKJ/K2egCgh2aS
GPNjhwdxwSbjhzNPs4aidwo=
=K+Fo
-----END PGP SIGNATURE-----

99
share/security/advisories/FreeBSD-EN-08:01.libpthread.asc Normal file
View file

@ -0,0 +1,99 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-08:01.libpthread Errata Notice
The FreeBSD Project
Topic: Problems with fork(2) within threaded programs
Category: core
Module: libpthread
Announced: 2008-04-17
Credits: Julian Elischer, Dan Eischen
Affects: FreeBSD 6.3
Corrected: 2008-02-04 20:05:20 UTC (RELENG_6, 6.3-STABLE)
2008-04-16 23:59:48 UTC (RELENG_6_3, 6.3-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
POSIX threads are a set of functions that support applications with
requirements for multiple flows of control, called threads, within a
process. The fork(2) system call is used to create a new process.
II. Problem Description
The libpthread threading library on FreeBSD 6.3 fails to properly
reinitialize mutexes when a threaded process invokes fork(2).
III. Impact
After the fork(2) system returns, the newly created child process may
freeze in user space for no apparent reason. This affects any threaded
application that invokes fork(2), most frequently those that call
fork(2) before execve(2) or system(3) to run external programs.
IV. Workaround
On some systems, using libthr instead of libpthread, via the libmap
configuration file libmap.conf(5), may be an acceptable workaround.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 6-STABLE or the RELENG_6_3
security branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 6.3 systems:
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-08:01/libpthread.patch
# fetch http://security.FreeBSD.org/patches/EN-08:01/libpthread.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libpthread
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/lib/libpthread/sys/lock.c 1.9.2.2
src/lib/libpthread/thread/thr_kern.c 1.116.2.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.6
src/sys/conf/newvers.sh 1.69.2.15.2.5
src/lib/libpthread/sys/lock.c 1.9.2.1.8.1
src/lib/libpthread/thread/thr_kern.c 1.116.2.1.6.1
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-08:01.libpthread.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFIBpWeFdaIBMps37IRAg2wAJ9jwXi2ZTaYXBdsU6CzS8dCzsQ5cwCcD2Fu
NCao693yWJo1bJrCrrbG8Ww=
=7mo1
-----END PGP SIGNATURE-----

111
share/security/advisories/FreeBSD-EN-08:02.tcp.asc Normal file
View file

@ -0,0 +1,111 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-08:02.tcp Errata Notice
The FreeBSD Project
Topic: TCP options padding
Category: core
Module: sys_netinet
Announced: 2008-06-19
Credits: Bjoern A. Zeeb, Mike Silbersack, Andre Oppermann
Affects: 7.0-RELEASE
Corrected: 2008-05-05 20:59:36 UTC (RELENG_7, 7.0-STABLE)
2008-06-19 06:36:10 UTC (RELENG_7_0, 7.0-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The Transmission Control Protocol (TCP) of the TCP/IP protocol suite
provides a connection-oriented, reliable, sequence-preserving data
stream service. TCP packets can contain "TCP options" which allow for
enhancements to basic TCP functionality; depending on the length of
these options, it may be necessary for padding to be added.
II. Problem Description
Under certain conditions, TCP options are not correctly padded.
III. Impact
A small number of firewalls have been reported to block incorrectly
padded TCP SYN and SYN/ACK packets generated by FreeBSD 7.0, with the
result that an attempt to open a TCP connection to or from an affected
host across such a firewall will fail.
IV. Workaround
Disabling RFC 1323 extensions and selective acknowledgments will
eliminate the need for TCP option padding and restore interoperability.
Note that disabling these features may cause a reduction in performance
on high latency networks and networks that experience frequent packet
loss.
To disable these features, add the following lines to /etc/sysctl.conf:
net.inet.tcp.rfc1323=0
net.inet.tcp.sack.enable=0
And then run "/etc/rc.d/sysctl restart" to make the change effective.
V. Solution
Perform one of the following:
1) Upgrade your affected system to 7-STABLE, or the RELENG_7_0 security
branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 7.0 systems:
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-08:02/tcp.patch
# fetch http://security.FreeBSD.org/patches/EN-08:02/tcp.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/sys/netinet/tcp.h 1.40.2.1
src/sys/netinet/tcp_output.c 1.141.2.6
RELENG_7_0
src/UPDATING 1.507.2.3.2.6
src/sys/conf/newvers.sh 1.72.2.5.2.6
src/sys/netinet/tcp.h 1.40.4.1
src/sys/netinet/tcp_output.c 1.141.2.3.2.1
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-08:02.tcp.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkhaAaQACgkQFdaIBMps37KmwgCfdC7qerBUDdmxPLe6yKZEwb7/
TqwAoJGFuowGOY/oeEQr6/AQZm3zgRY3
=UlPD
-----END PGP SIGNATURE-----

113
share/security/advisories/FreeBSD-EN-09:01.kenv.asc Normal file
View file

@ -0,0 +1,113 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-09:01.kenv Errata Notice
The FreeBSD Project
Topic: Kernel panic when dumping environment
Category: core
Module: kern
Announced: 2009-03-23
Affects: FreeBSD 7.x
Corrected: 2009-03-23 00:00:50 UTC (RELENG_7, 7.2-PRERELEASE)
2009-03-23 00:00:50 UTC (RELENG_7_1, 7.1-RELEASE-p4)
2009-03-23 00:00:50 UTC (RELENG_7_0, 7.0-RELEASE-p11)
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
The kenv(2) system call allows userland processes to get, set, and unset
kernel environment variables, as well as to dump all of the entries in
the kernel environment.
II. Problem Description
When dumping all of the entries in the kernel environment, the kernel
does not adequately bounds-check the size of the buffer into which the
environment should be written.
III. Impact
An unprivileged process can cause the FreeBSD kernel to attempt to
allocate a very large amount of memory, thereby causing the FreeBSD
kernel to panic.
IV. Workaround
No workaround is available, but systems without untrusted local users
are not vulnerable.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE, or to the RELENG_7_1
or RELENG_7_0 security branch dated after the correction date.
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 7.0 and 7.1
systems.
a) Download the patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-09:01/kenv.patch
# fetch http://security.FreeBSD.org/patches/EN-09:01/kenv.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/sys/kern/kern_environment.c 1.47.2.1
RELENG_7_1
src/UPDATING 1.507.2.13.2.7
src/sys/conf/newvers.sh 1.72.2.9.2.8
src/sys/kern/kern_environment.c 1.47.6.2
RELENG_7_0
src/UPDATING 1.507.2.3.2.15
src/sys/conf/newvers.sh 1.72.2.5.2.15
src/sys/kern/kern_environment.c 1.47.4.1
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r190301
releng/7.1/ r190301
releng/7.0/ r190301
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-09:01.kenv.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEUEARECAAYFAknG0gwACgkQFdaIBMps37ILlwCfcbVKW5FlPK+GtATY34wfkDWr
5tAAmMteIrkXAeBgp3QNI6pFiHzgunE=
=wJeF
-----END PGP SIGNATURE-----

113
share/security/advisories/FreeBSD-EN-09:02.bce.asc Normal file
View file

@ -0,0 +1,113 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-09:02.bce Errata Notice
The FreeBSD Project
Topic: bce(4) does not work with lagg(4) LACP mode
Category: core
Module: sys/dev
Announced: 2009-06-24
Credits: Pete French <petefrench@ticketswitch.com>
David Christensen
Affects: FreeBSD 7.2
Corrected: 2009-05-20 21:13:49 (RELENG_7, 7.2-STABLE)
2009-06-24 05:28:09 (RELENG_7_2, 7.2-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
bce(4) is a network device driver for Broadcom NetXtreme II
(BCM5706/5708/5709/5716) PCI/PCIe Gigabit Ethernet adapters. The
lagg(4) driver is a pseudo network interface driver which allows
aggregation of multiple network interfaces as one virtual interface
for the purpose of providing fault-tolerance and high-speed links.
II. Problem Description
The bce(4) driver used an incorrect total packet length calculation. This
bug was accidentally added just after 7.1-RELEASE.
III. Impact
When adding a bce(4) interface on the system as a lagg(4) member with
the LACP aggregation protocol enabled network communication via the
bce(4) interface stops completely. Although the bce(4) interface
works if it is not a lagg(4) member, the incoming traffic statistics
which can be found in netstat(1) output will be incorrect because
every packet is recognized as full-sized one.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or to the RELENG_7_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 7.2 system.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-09:02/bce.patch
# fetch http://security.FreeBSD.org/patches/EN-09:02/bce.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot
the system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/sys/dev/bce/if_bce.c 1.34.2.8
src/sys/dev/bce/if_bcereg.c 1.16.2.3
RELENG_7_2
src/UPDATING 1.507.2.23.2.5
src/sys/conf/newvers.sh 1.72.2.11.2.6
src/sys/dev/bce/if_bce.c 1.34.2.7.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r192477
releng/7.2/ r194808
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-09:02.bce.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkpBu9cACgkQFdaIBMps37IyrgCeKorJrpSXubynKzNJ2ld4j1K3
RqoAnAjhR8Fld9c8gJUIP/BuQ0wx2atT
=oSkz
-----END PGP SIGNATURE-----

117
share/security/advisories/FreeBSD-EN-09:03.fxp.asc Normal file
View file

@ -0,0 +1,117 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-09:03.fxp Errata Notice
The FreeBSD Project
Topic: Poor TCP performance of fxp(4)
Category: core
Module: sys/dev
Announced: 2009-06-24
Credits: Bjoern Koenig <bkoenig@alpha-tierchen.de>
Pyun YongHyeon <yongari@FreeBSD.org>
Affects: FreeBSD 7.2
Corrected: 2009-05-07 01:14:59 (RELENG_7, 7.2-STABLE)
2009-06-24 05:28:09 (RELENG_7_2, 7.2-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
fxp(4) is a network device driver which provides support for Ethernet
adapters based on the Intel i82557, i82558, i82559, i82550, and i82562
chips. It supports TCP segmentation offload (TSO) for IPv4 on i82550
and i82551.
II. Problem Description
When a TSO option is enabled, fxp(4) always sets the length of outgoing IP
packets as the interface MTU (Maximum Transmission Unit). This could
could cause the packet to be lost when the TCP receiver advertises a smaller
MSS (Maximum Segment Size) than the interface MTU on the sender side.
III. Impact
TCP connections via fxp(4) can cause significantly poor performance
when the TSO option is enabled due to packet loss. Note that the loss
depends on the receiver side's MSS.
IV. Workaround
Disable TSO of fxp(4) interfaces on your system. There are two ways
to do this:
(disable TSO of a specific interface; "fxp0" in the below example)
# ifconfig fxp0 -tso
(disable TSO of all interfaces on the system)
# sysctl net.inet.tcp.tso=0
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or to the RELENG_7_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 7.2 system.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-09:03/fxp.patch
# fetch http://security.FreeBSD.org/patches/EN-09:03/fxp.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot
the system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/sys/dev/fxp/if_fxp.c 1.266.2.15
RELENG_7_2
src/UPDATING 1.507.2.23.2.5
src/sys/conf/newvers.sh 1.72.2.11.2.6
src/sys/dev/fxp/if_fxp.c 1.266.2.14.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r191867
releng/7.2/ r194808
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-09:03.fxp.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkpB3kwACgkQFdaIBMps37IjxwCgkw+SiBKPWl/VV5dudLRZEi/2
upMAn2CNg1EOpeM4FCuS+C5KaXwIehh2
=sX1l
-----END PGP SIGNATURE-----

109
share/security/advisories/FreeBSD-EN-09:04.fork.asc Normal file
View file

@ -0,0 +1,109 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-09:04.fork Errata Notice
The FreeBSD Project
Topic: Deadlock in a multi-threaded program during fork(2)
Category: core
Module: libc
Announced: 2009-06-24
Credits: Konstantin Belousov <kib@FreeBSD.org>,
Max Brazhnikov <makc@FreeBSD.org>
Affects: FreeBSD 7.2
Corrected: 2009-05-03 17:51:38 (RELENG_7, 7.2-STABLE)
2009-06-24 05:28:09 (RELENG_7_2, 7.2-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
fork(2) is a system call which causes creation of a new process.
FreeBSD supports invoking the malloc(3) function during the fork(2) in
a process running in threaded mode which involves locking of the memory
allocator.
II. Problem Description
A lock order reversal has been found in the interaction between the
malloc(3) implementation and threading library. When a multi-threaded
process calls the fork(2) system call in a thread and the malloc(3)
function in another thread it can cause a deadlock in the child
process.
III. Impact
A multi-threaded program that calls fork(2) in a thread and malloc(3)
in another thread can make the child process stop unintentionally.
There is no direct impact on the other processes or the kernel.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 7-STABLE or to the RELENG_7_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 7.2 system.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-09:04/fork.patch
# fetch http://security.FreeBSD.org/patches/EN-09:04/fork.patch.asc
b) Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/lib/libc
# make obj && make depend && make && make install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/lib/libc/stdlib/malloc.c 1.147.2.7
RELENG_7_2
src/UPDATING 1.507.2.23.2.5
src/sys/conf/newvers.sh 1.72.2.11.2.6
src/lib/libc/stdlib/malloc.c 1.147.2.6.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r191767
releng/7.2/ r194808
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-09:04.fork.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkpBvBsACgkQFdaIBMps37LnLQCeNw8Es9R9X8QySoZni2JQ9Kma
N+8An3Ff/bB4l3dvgfAa0rAA+TjbfQBV
=8YtE
-----END PGP SIGNATURE-----

185
share/security/advisories/FreeBSD-EN-09:05.null.asc Normal file
View file

@ -0,0 +1,185 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-09:05.null Errata Notice
The FreeBSD Project
Topic: No zero mapping feature
Category: core
Module: kern
Announced: 2009-10-02
Credits: John Baldwin, Konstantin Belousov, Alan Cox, and Bjoern Zeeb
Affects: All supported versions of FreeBSD.
Corrected: 2009-10-02 18:09:56 UTC (RELENG_8, 8.0-RC2)
2009-10-02 18:09:56 UTC (RELENG_7, 7.2-STABLE)
2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4)
2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8)
2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE)
2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7)
2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
In the C programming language, address 0 (NULL) is used to represent
unallocated memory. NULL pointer dereferences are a common class of C
programming bug in which pointers are not properly checked for NULL
before being used. Dereferencing a NULL pointer normally terminates
execution, via a segmentation fault for user processes, or a page
fault panic in the kernel.
II. Problem Description
On most architectures, the FreeBSD kernel splits the process virtual
memory address space into two portions: user and kernel. This
improves system call performance by avoiding a full address space
switch when a process enters the kernel, and improves performance for
kernel access to user memory.
However, in this design, address 0 is part of the user-controlled
portion of the virtual address space. If the kernel dereferences a
NULL pointer due to a kernel bug, a malicious process that has mapped
code or data at address 0 may be able to manipulate kernel behavior.
For example, if a malicious user process maps code at address 0 and
then triggers a kernel bug in which a NULL function pointer is
invoked, the kernel may execute that code with kernel privilege rather
than panicking.
III. Impact
This errata patch introduces a mitigation feature in which user
mapping at address 0 is disallowed, limiting the attacker's ability to
convert a kernel NULL pointer dereference into a privilege escalation
attack.
The feature is disabled by default in FreeBSD 7 and lower, and must be
enabled by setting the sysctl(8) variable security.bsd.map_at_zero to
0. In FreeBSD 8 and later feature is enabled by default.
While extremely rare, certain applications may rely on mapping memory
at address 0. Careful testing is advised when enabling this feature
when using virtual machines, emulation technologies, and older a.out
format binaries.
Changing the mentioned sysctl(8) variable only affects processes
started after the sysctl(8) variable was set. Processes started
before the sysctl(8) variable was changed will continue to run with
the setting of the sysctl(8) variable which existed when the processes
was started.
Consequently, to ensure that the sysctl(8) variable affects all
processes, a reboot is required with the sysctl(8) variable configured
as mentioned below.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) Upgrade your system to 6-STABLE, 7-STABLE, or 8-RC, or to the
RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch
dated after the correction date.
Enable feature as mentioned below.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 6.3, 6.4,
7.1, and 7.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 7.x]
# fetch http://security.FreeBSD.org/patches/EN-09:05/null.patch
# fetch http://security.FreeBSD.org/patches/EN-09:05/null.patch.asc
[FreeBSD 6.x]
# fetch http://security.FreeBSD.org/patches/EN-09:05/null6.patch
# fetch http://security.FreeBSD.org/patches/EN-09:05/null6.patch.asc
NOTE WELL: The patch for FreeBSD 7.x can be used on FreeBSD 8, but
does not enable the feature by default!
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
To actually enable the feature in FreeBSD 6.x and 7.x, add the
following to either /boot/loader.conf or /etc/sysctl.conf:
security.bsd.map_at_zero="0"
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/sys/kern/kern_exec.c 1.275.2.9
RELENG_6_4
src/UPDATING 1.416.2.40.2.11
src/sys/conf/newvers.sh 1.69.2.18.2.13
src/sys/kern/kern_exec.c 1.275.2.8.4.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.18
src/sys/conf/newvers.sh 1.69.2.15.2.17
src/sys/kern/kern_exec.c 1.275.2.8.2.1
RELENG_7
src/sys/kern/kern_exec.c 1.308.2.11
RELENG_7_2
src/UPDATING 1.507.2.23.2.7
src/sys/conf/newvers.sh 1.72.2.11.2.8
src/sys/kern/kern_exec.c 1.308.2.8.2.2
RELENG_7_1
src/UPDATING 1.507.2.13.2.11
src/sys/conf/newvers.sh 1.72.2.9.2.12
src/sys/kern/kern_exec.c 1.308.2.6.2.2
RELENG_8
src/sys/kern/kern_exec.c 1.337.2.3
src/sys/kern/init_main.c 1.303.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/6/ r197715
releng/6.4/ r197715
releng/6.3/ r197715
stable/7/ r197715
releng/7.2/ r197715
releng/7.1/ r197715
stable/8/ r197714
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-09:05.null.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iD8DBQFKxltpFdaIBMps37IRAoniAJ9ENWQ431doaje7gXrAfAov5l0FKwCdFRxh
rTmlD1oew/hZTMBuFKM/LSI=
=+ZZf
-----END PGP SIGNATURE-----

156
share/security/advisories/FreeBSD-EN-10:01.freebsd.asc Normal file
View file

@ -0,0 +1,156 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-10:01.freebsd Errata Notice
The FreeBSD Project
Topic: Various FreeBSD 8.0-RELEASE improvements
Category: core
Module: kern
Announced: 2010-01-06
Affects: FreeBSD 8.0-RELEASE.
Corrected: 2010-01-06 21:45:30 UTC (RELENG_8_0, 8.0-RELEASE-p2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.FreeBSD.org/>.
I. Background
Since FreeBSD 8.0 was released, several stability and performance problems
have been identified. This Errata Notice describes several fixes judged to
be of particular importance, but low risk, to users with specific workloads
or using specific features that trigger these problems.
Areas where problems are addressed include NFS, ZFS, Multicast networking,
SCTP as well as the rename(2) syscall.
II. Description
* Slow NFS client reconnects when using TCP
Under certain circumstances the NFS client can queue requests even though
the remote server has initiated a connection shutdown.
The deferred notice of the shutdown can cause slow reconnects against
an NFS server that drops inactive connections.
* Possible panics in ZFS
Due to inadequate checks, attempts to modify a file on a read-only ZFS
snapshot will lead to a 'dirtying snapshot' kernel panic.
The system will also panic if ZFS is combined with a MAC policy supporting
file system labeling (e.g., mac_biba(4) or mac_mls(4)).
* Multicast regression and panic
Multicast filtering may not pass incoming IGMP messages if the group
has not been joined. User space routing daemons will therefore not see
all IGMP control traffic.
Further, the system will panic under certain circumstances in the IPv4
multicast forwarding path.
* Panic when invalid SCTP message received during connection shutdown
Receiving a specially crafted SCTP shutdown message with an invalid
Transmission Sequence Number may cause the system to panic if there
has been a valid association.
* Panic caused by rename(2)
If a path argument to the rename(2) syscall ends in '/.', insufficient
checking will cause the system to panic.
III. Solution
Perform one of the following:
1) Upgrade your system to 8-STABLE, or to the RELENG_8_0 security branch
dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 8.0 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-10:01/nfsreconnect.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/nfsreconnect.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/zfsvaccess.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/zfsvaccess.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/zfsmac.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/zfsmac.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/multicast.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/multicast.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/mcinit.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/mcinit.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/sctp.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/sctp.patch.asc
# fetch http://security.FreeBSD.org/patches/EN-10:01/rename.patch
# fetch http://security.FreeBSD.org/patches/EN-10:01/rename.patch.asc
b) Apply the patches.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
IV. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- - -------------------------------------------------------------------------
RELENG_8_0
src/UPDATING 1.632.2.7.2.5
src/sys/conf/newvers.sh 1.83.2.6.2.5
src/sys/netinet/ip_mroute.c 1.155.2.1.2.2
src/sys/netinet/raw_ip.c 1.220.2.2.2.2
src/sys/netinet6/raw_ip6.c 1.111.2.1.2.2
src/sys/rpc/clnt_vc.c 1.8.2.2.2.2
src/sys/kern/vfs_lookup.c 1.132.2.1.2.2
src/sys/netinet/sctp_input.c 1.82.2.2.2.2
src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c
1.24.2.2.2.1
src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
1.46.2.7.2.1
src/sys/cddl/contrib/opensolaris/uts/common/sys/vnode.h 1.3.4.1.2.1
src/sys/cddl/compat/opensolaris/sys/vnode.h 1.12.2.2.2.2
- - -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- - -------------------------------------------------------------------------
releng/8.0/ r201679
- - -------------------------------------------------------------------------
V. References
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-10:01.freebsd.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iD8DBQFLRRFQFdaIBMps37IRAuq9AJ9fq1708qfDgnyzuNRWnumiQhJD2gCcDqWd
AyQA3ZdKXci6S8d9UauJFw4=
=NwGp
-----END PGP SIGNATURE-----

157
share/security/advisories/FreeBSD-EN-10:02.sched_ule.asc Normal file
View file

@ -0,0 +1,157 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-10:02.sched_ule Errata Notice
The FreeBSD Project
Topic: Deadlock in ULE scheduler
Category: core
Module: kern
Announced: 2010-02-27
Credits: Attilio Rao
Affects: FreeBSD 7.0, 7.1, and 7.2.
Corrected: 2009-09-24 09:08:22 UTC (RELENG_7, 7.2-STABLE)
2010-02-27 10:55:43 UTC (RELENG_7_2, 7.2-RELEASE-p7)
2010-02-27 10:55:43 UTC (RELENG_7_1, 7.1-RELEASE-p11)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
FreeBSD has two schedulers: the classic 4BSD scheduler and a newer,
more SMP-aware scheduler called ULE. The 4BSD scheduler was the
default scheduler until FreeBSD 7.0. Starting with FreeBSD 7.1 the
default scheduler is ULE.
The scheduler is responsible for allocating CPU time to threads and
assigning threads to CPUs. Runnable threads (i.e. threads which are
not waiting for a blocking operation, such as an I/O operation, memory
allocation or lock acquisition, to complete) are assigned to a CPU and
placed in that CPU's run queue. Each thread and each CPU's run queue
is protected by a separate lock.
II. Problem Description
When a thread is reassigned from one CPU to another, the scheduler
first acquires the thread's lock, then releases the source CPU's run
queue lock. The scheduler then acquires the target CPU's run queue
lock and holds the lock while it adds the thread to the queue and signals
the target CPU. Finally it reacquires the source CPU's run queue lock
before unlocking the thread. A thread on the target CPU, having been
notified of the reassigned thread's arrival on the target CPU's run
queue, will then acquire the thread's lock before switching it in.
If, at the same time, a third thread tries to acquire both the source
and target CPUs' run queue locks, a three-way deadlock may occur:
- The second thread has acquired the target CPU's run queue lock, but
has not yet acquired the first thread's lock.
- The third thread has acquired the source CPU's run queue lock, and
is waiting to acquire the target CPU's run queue lock, which is
locked by the second thread.
- The first thread is waiting to acquire the source CPU's run queue
lock, which is held by the third thread, in order to release its
own lock.
As a result both CPUs' run queues are locked, and each of the three
threads is waiting to acquire a lock held by one of the others.
Eventually every CPU in the system ends up in a state where it is
waiting to acquire each other's locks.
It has not been determined whether this also affects single-CPU
systems but it is recommended this Errata Notice be applied to
single-CPU systems as well.
III. Impact
Affected systems may become deadlocked and require power-cycling. The
chance of a deadlock occurring increases with the number of CPUs.
There may be other aggravating factors such as running powerd(8). But
eventually any multi-processor system using the ULE scheduler will
become deadlocked.
IV. Workaround
Replace SCHED_ULE with SCHED_4BSD in your kernel configuration,
recompile your kernel and reboot the system.
Note that systems running the 4BSD scheduler are not affected; to
determine what scheduler a system is using, run
# sysctl kern.sched.name
V. Solution
Perform one of the following:
1) Upgrade your system to 7-STABLE, or to the RELENG_7_2 or RELENG_7_1
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 7.1 and
7.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch
# fetch http://security.FreeBSD.org/patches/EN-10:02/sched_ule.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/sys/kern/sched_ule.c 1.214.2.9
RELENG_7_2
src/UPDATING 1.507.2.23.2.10
src/sys/conf/newvers.sh 1.72.2.11.2.11
src/sys/kern/sched_ule.c 1.214.2.8.2.2
RELENG_7_1
src/UPDATING 1.507.2.13.2.14
src/sys/conf/newvers.sh 1.72.2.9.2.15
src/sys/kern/sched_ule.c 1.214.2.7.2.2
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r197453
releng/7.2/ r204409
releng/7.1/ r204409
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-10:02.sched_ule.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)
iEYEARECAAYFAkuI+1oACgkQFdaIBMps37ItgACghSdnagnmy9Zohrh5IKuhygiy
kVsAn2EXtts/l+IrjuWIzODSSUzLylia
=mj/v
-----END PGP SIGNATURE-----

143
share/security/advisories/FreeBSD-EN-12:01.freebsd-update.asc Normal file
View file

@ -0,0 +1,143 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-12:01.freebsd-update Errata Notice
The FreeBSD Project
Topic: freebsd-update support for FreeBSD 9.0-RELEASE
Category: core
Module: freebsd-update
Announced: 2012-01-04
Affects: All versions of FreeBSD prior to 9.0-RC2.
Corrected: 2011-10-26 20:07:58 UTC (RELENG_7, 7.4-STABLE)
2012-01-04 23:47:20 UTC (RELENG_7_4, 7.4-RELEASE-p6)
2012-01-04 23:47:20 UTC (RELENG_7_3, 7.3-RELEASE-p10)
2011-10-26 20:06:27 UTC (RELENG_8, 8.2-STABLE)
2012-01-04 23:47:20 UTC (RELENG_8_2, 8.2-RELEASE-p6)
2012-01-04 23:47:20 UTC (RELENG_8_1, 8.1-RELEASE-p8)
2011-10-26 20:01:43 UTC (RELENG_9, 9.0-RC2)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
freebsd-update(8) allows system administrators to install binary updates to
the base FreeBSD install, as distributed by the FreeBSD Project.
II. Problem Description
freebsd-update in affected releases is unable to perform an automated upgrade
to FreeBSD 9.0 due to unsupported characters in FreeBSD 9.0 filenames. When
this bug is triggered, updates fail with the following error message:
The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.
III. Impact
Affected systems are unable to update from affected releases to FreeBSD 9.0
using freebsd-update.
IV. Workaround
No workaround is available.
V. Solution
Perform one of the following:
1) For FreeBSD 7.x, upgrade your system to 7-STABLE, or to the RELENG_7_4 or
RELENG_7_3 security branch dated after the correction date. For FreeBSD
8.x, upgrade your system to 8-STABLE, or to the RELENG_8_1 or RELENG_8_2
security branch dated after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 7.3, 7.4, 8.1,
and 8.2 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
# fetch http://security.FreeBSD.org/patches/EN-12:01/freebsd-update.patch
# fetch http://security.FreeBSD.org/patches/EN-12:01/freebsd-update.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/freebsd-update
# make obj && make && make install
3) To update your affected system via a binary patch:
Systems running 7.3-RELEASE, 7.4-RELEASE, 8.1-RELEASE, or 8.2-RELEASE on the
i386 or amd64 platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_7
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.7
RELENG_7_4
src/UPDATING 1.507.2.36.2.8
src/sys/conf/newvers.sh 1.72.2.18.2.11
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.5.4.2
RELENG_7_3
src/UPDATING 1.507.2.34.2.12
src/sys/conf/newvers.sh 1.72.2.16.2.14
src/usr.sbin/freebsd-update/freebsd-update.sh 1.8.2.5.2.2
RELENG_8
src/usr.sbin/freebsd-update/freebsd-update.sh 1.16.2.6
RELENG_8_2
src/UPDATING 1.632.2.19.2.8
src/sys/conf/newvers.sh 1.83.2.12.2.11
src/usr.sbin/freebsd-update/freebsd-update.sh 1.16.2.4.2.2
RELENG_8_1
src/UPDATING 1.632.2.14.2.11
src/sys/conf/newvers.sh 1.83.2.10.2.12
src/usr.sbin/freebsd-update/freebsd-update.sh 1.16.2.3.2.2
RELENG_9
src/usr.sbin/freebsd-update/freebsd-update.sh 1.25.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/7/ r226813
releng/7.4/ r229539
releng/7.3/ r229539
stable/8/ r226812
releng/8.2/ r229539
releng/8.1/ r229539
stable/9/ r226811
- -------------------------------------------------------------------------
VII. References
The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-12:01.freebsd-update.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk8E5YQACgkQFdaIBMps37LeTACeKYRkY5s+Iy+JCf/Zc3yvKSLD
2RsAnRsmN3gCPYglNjwkhJctdkLdGULh
=6LzH
-----END PGP SIGNATURE-----

161
share/security/advisories/FreeBSD-EN-12:02.ipv6refcount.asc Normal file
View file

@ -0,0 +1,161 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-EN-12:02.ipv6refcount Errata Notice
The FreeBSD Project
Topic: Reference count errors in IPv6 code
Category: core
Modules: sys_netinet sys_netinet6
Announced: 2012-06-12
Credits: Scott Long, Rui Paulo, Maksim Yevmenkin
Affects: FreeBSD 8.0 and later
Corrected: 2012-06-09 22:44:49 UTC (RELENG_8, 8.3-STABLE)
2012-06-12 12:10:10 UTC (RELENG_8_3, 8.3-RELEASE-p3)
2012-06-12 12:10:10 UTC (RELENG_8_2, 8.2-RELEASE-p9)
2012-06-12 12:10:10 UTC (RELENG_8_1, 8.1-RELEASE-p11)
2012-06-09 22:44:24 UTC (RELENG_9, 9.0-STABLE)
2012-06-12 12:10:10 UTC (RELENG_9_0, 9.0-RELEASE-p3)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:http://security.freebsd.org/>.
I. Background
The FreeBSD network stack implements Internet Protocol version 6 (IPv6),
the successor to IPv4. IPv6 is now seeing widespread deployment.
Reference counts are a programming technology used by the FreeBSD kernel
to maintain stability of objects while in use.
II. Problem Description
The FreeBSD IPv4 and IPv6 kernel implementations employ reference counts to
protect IP addresses configured on network interfaces. Due to multiple
bugs, IPv6 address references may be improperly acquired or released; IPv4
is unaffected.
III. Impact
Under high IPv6 network load, reference counts may improperly hit zero
due to overflow or underflow, causing an IPv6 address, which is still in
use, to be freed. This will lead to a kernel panic on next access.
IV. Workaround
No workaround is available, but systems not using any IPv6 communication
are not affected.
V. Solution
Perform one of the following:
1) Upgrade your vulnerable system to 8-STABLE, or 9-STABLE, or to the
RELENG_8_3, RELENG_8_2, RELENG_8_1, or RELENG_9_0 security branch dated
after the correction date.
2) To patch your present system:
The following patches have been verified to apply to FreeBSD 8.3, 8.2,
8.1, and 9.0 systems.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 8.1-RELEASE, 8.2-RELEASE, and 9.0-RELEASE]
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount.patch
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount.patch.asc
[FreeBSD 8.3-RELEASE]
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount-83.patch
# fetch http://security.FreeBSD.org/patches/EN-12:02/ipv6refcount-83.patch.asc
b) Apply the patch.
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.
3) To update your vulnerable system via a binary patch:
Systems running 8.3-RELEASE, 8.2-RELEASE, 8.1-RELEASE, or 9.0-RELEASE on
the i386 or amd64 platforms can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
CVS:
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_8
sys/netinet/tcp_input.c 1.411.2.22
sys/netinet6/in6.c 1.121.2.28
sys/netinet6/ip6_input.c 1.132.2.9
RELENG_8_3
src/UPDATING 1.632.2.26.2.5
src/sys/conf/newvers.sh 1.83.2.15.2.7
sys/netinet/tcp_input.c 1.411.2.19.2.2
sys/netinet6/in6.c 1.121.2.23.2.2
sys/netinet6/ip6_input.c 1.132.2.6.4.2
RELENG_8_2
src/UPDATING 1.632.2.19.2.11
src/sys/conf/newvers.sh 1.83.2.12.2.14
sys/netinet/tcp_input.c 1.411.2.9.2.2
sys/netinet6/in6.c 1.121.2.12.2.2
sys/netinet6/ip6_input.c 1.132.2.6.2.2
RELENG_8_1
src/UPDATING 1.632.2.14.2.14
src/sys/conf/newvers.sh 1.83.2.10.2.15
sys/netinet/tcp_input.c 1.411.2.6.2.2
sys/netinet6/in6.c 1.121.2.11.2.2
sys/netinet6/ip6_input.c 1.132.2.4.2.2
RELENG_9
sys/netinet/tcp_input.c 1.437.2.7
sys/netinet6/in6.c 1.139.2.16
sys/netinet6/ip6_input.c 1.147.2.4
RELENG_9_0
src/UPDATING 1.702.2.4.2.5
src/sys/conf/newvers.sh 1.95.2.4.2.7
sys/netinet/tcp_input.c 1.437.2.2.2.2
sys/netinet6/in6.c 1.139.2.4.2.2
sys/netinet6/ip6_input.c 1.147.2.1.2.2
- -------------------------------------------------------------------------
Subversion:
Branch/path Revision
- -------------------------------------------------------------------------
stable/8/ r236827
releng/8.3/ r236953
releng/8.2/ r236953
releng/8.1/ r236953
stable/9/ r236826
releng/9.0/ r236953
- -------------------------------------------------------------------------
VII. References
The latest revision of this Errata Notice is available at
http://security.FreeBSD.org/advisories/FreeBSD-EN-12:02.ipv6refcount.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAk/XQFQACgkQFdaIBMps37LBygCeLi30YsLogAWsemBcX/WdtOqi
35UAoIVvwvGi+fOs/fGm2PoAixAWqhSH
=2X+g
-----END PGP SIGNATURE-----

243
share/security/advisories/FreeBSD-SA-00:01.make.asc Normal file
View file

@ -0,0 +1,243 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:01 Security Advisory
FreeBSD, Inc.
Topic: Insecure temporary file handling in make(1)
Category: core
Module: make
Announced: 2000-01-19
Affects: All versions before the correction date.
Corrected: 2000-01-16
FreeBSD only: NO
Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:01/make.patch
I. Background
The make(1) program is typically used to schedule building of source
code. It has a switch ('-j') to allow parallel building by spawning
multiple child processes.
II. Problem Description
The -j option to make(1) uses temporary files in /tmp to communicate
with its child processes by storing the shell command the child should
execute. This is useful on multi-processor architectures for making
use of all of the available CPUs, and is also widely used on
uniprocessor systems to minimize the scheduling latency of the build
process.
However make(1) uses the temporary file in an insecure way, repeatedly
deleting and reusing the same file name for the entire life of the
program. This makes it vulnerable to a race condition wherein a
malicious user could observe the name of the temporary file being
used, and replace the contents of a later instance of the file with
her desired commands after the legitimate commands have been written.
This vulnerability was discovered as part of the FreeBSD Auditing
Project, an ongoing effort to identify and correct security
vulnerabilities in the FreeBSD operating system.
All versions of NetBSD and OpenBSD are also believed to be vulnerable
to this problem. Other systems using a BSD-derived make(1) binary may
also be vulnerable.
III. Impact
Local users could execute arbitrary shell commands as part of the
build process scheduled by "make -j" by another user.
IV. Workaround
Avoid using the '-j' flag to make(1).
V. Solution
Upgrade your system to one that is listed above as having the problem
resolved, or patch your present system.
To patch your present system: save the patch below into a file, and
execute the following commands as root:
cd /usr/src/usr.bin/make
patch < /path/to/patch/file
make all
make install
Patches for 3.4-STABLE and 4.0-CURRENT systems before the resolution date:
Index: job.c
===================================================================
RCS file: /home/ncvs/src/usr.bin/make/job.c,v
retrieving revision 1.16
diff -u -r1.16 job.c
--- job.c 1999/09/11 13:08:01 1.16
+++ job.c 2000/01/17 01:42:57
@@ -163,14 +163,6 @@
#define JOB_STOPPED 3 /* The job is stopped */
/*
- * tfile is the name of a file into which all shell commands are put. It is
- * used over by removing it before the child shell is executed. The XXXXXXXXXX
- * in the string are replaced by mkstemp(3).
- */
-static char tfile[sizeof(TMPPAT)];
-
-
-/*
* Descriptions for various shells.
*/
static Shell shells[] = {
@@ -993,7 +985,7 @@
/*
* If we are aborting and the job table is now empty, we finish.
*/
- (void) eunlink(tfile);
+ (void) eunlink(job->tfile);
Finish(errors);
}
}
@@ -1668,6 +1660,7 @@
Boolean cmdsOK; /* true if the nodes commands were all right */
Boolean local; /* Set true if the job was run locally */
Boolean noExec; /* Set true if we decide not to run the job */
+ int tfd; /* File descriptor for temp file */
if (previous != NULL) {
previous->flags &= ~(JOB_FIRST|JOB_IGNERR|JOB_SILENT|JOB_REMOTE);
@@ -1697,6 +1690,12 @@
}
job->flags |= flags;
+ (void) strcpy(job->tfile, TMPPAT);
+ if ((tfd = mkstemp(job->tfile)) == -1)
+ Punt("cannot create temp file: %s", strerror(errno));
+ else
+ (void) close(tfd);
+
/*
* Check the commands now so any attributes from .DEFAULT have a chance
* to migrate to the node
@@ -1722,9 +1721,9 @@
DieHorribly();
}
- job->cmdFILE = fopen(tfile, "w+");
+ job->cmdFILE = fopen(job->tfile, "w+");
if (job->cmdFILE == NULL) {
- Punt("Could not open %s", tfile);
+ Punt("Could not open %s", job->tfile);
}
(void) fcntl(FILENO(job->cmdFILE), F_SETFD, 1);
/*
@@ -1830,7 +1829,7 @@
* Unlink and close the command file if we opened one
*/
if (job->cmdFILE != stdout) {
- (void) eunlink(tfile);
+ (void) eunlink(job->tfile);
if (job->cmdFILE != NULL)
(void) fclose(job->cmdFILE);
} else {
@@ -1859,7 +1858,7 @@
}
} else {
(void) fflush(job->cmdFILE);
- (void) eunlink(tfile);
+ (void) eunlink(job->tfile);
}
/*
@@ -2403,13 +2402,6 @@
* be running at once. */
{
GNode *begin; /* node for commands to do at the very start */
- int tfd;
-
- (void) strcpy(tfile, TMPPAT);
- if ((tfd = mkstemp(tfile)) == -1)
- Punt("cannot create temp file: %s", strerror(errno));
- else
- (void) close(tfd);
jobs = Lst_Init(FALSE);
stoppedJobs = Lst_Init(FALSE);
@@ -2914,7 +2906,7 @@
}
}
}
- (void) eunlink(tfile);
+ (void) eunlink(job->tfile);
}
/*
@@ -2948,7 +2940,6 @@
}
}
}
- (void) eunlink(tfile);
return(errors);
}
@@ -3024,6 +3015,7 @@
KILL(job->pid, SIGINT);
KILL(job->pid, SIGKILL);
#endif /* RMT_WANTS_SIGNALS */
+ (void) eunlink(job->tfile);
}
}
@@ -3032,7 +3024,6 @@
*/
while (waitpid((pid_t) -1, &foo, WNOHANG) > 0)
continue;
- (void) eunlink(tfile);
}
#ifdef REMOTE
Index: job.h
===================================================================
RCS file: /home/ncvs/src/usr.bin/make/job.h,v
retrieving revision 1.10
diff -u -r1.10 job.h
--- job.h 1999/08/28 01:03:31 1.10
+++ job.h 2000/01/17 01:42:31
@@ -93,6 +93,8 @@
#define JOB_BUFSIZE 1024
typedef struct Job {
int pid; /* The child's process ID */
+ char tfile[sizeof(TMPPAT)];
+ /* Temporary file to use for job */
GNode *node; /* The target the child is making */
LstNode tailCmds; /* The node of the first command to be
* saved when the job has been run */
=============================================================================
FreeBSD, Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
Security notifications: security-notifications@freebsd.org
Security public discussion: freebsd-security@freebsd.org
PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBOIVvCFUuHi5z0oilAQF7nQP+No1n5Rl2g0ltvu+Vrx2ImMZreOwz04zZ
a6MM+bQQ0q/pXgupzSQ3xcfpzZzHjQx2+ajMg4P+l7+OsBvjBvrVFrc021rRW18W
Ds3A/Vlm8seaWOe4Q4u5qSTdp2PO9HXJrEQWL37xAQtqVyT3J2E37MQyEfENWg4d
FeIUCiTIMuA=
=86yT
-----END PGP SIGNATURE-----

183
share/security/advisories/FreeBSD-SA-00:02.procfs.asc Normal file
View file

@ -0,0 +1,183 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:01 Security Advisory
FreeBSD, Inc.
Topic: Old procfs hole incompletely filled
Category: core
Module: make
Announced: 2000-01-24
Affects: All versions before the correction date.
Corrected: 2000-01-20
FreeBSD only: NO
Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch
I. Background
procfs provides access to other processes memory spaces. This is
intended to be used in debugging and has many safeguards built into it
to prevent abuse.
II. Problem Description
In January 1997 a fatal flaw in *BSD procfs code (leading to a local
root compromise) was discussed on various security forums. The exploit
code dealt with /proc/pid/mem interface. Since then *BSD kernels
contained a simple fix which was meant to close this hole.
Unfortunately, throughout these three years it was still possible to
abuse /proc/pid/mem in a similar, though more complicated fashion,
which could lead to local root compromise.
III. Impact
Local users can gain root access.
IV. Workaround
You can unmount /proc. In both 3.x-stable and 4.0-current this will
break truss and gcore. In 3.x-stable systems only it will reduce the
amount of information ps reports.
V. Solution
Apply the following patch
Index: sys/filedesc.h
===================================================================
RCS file: /base/FreeBSD-CVS/src/sys/sys/filedesc.h,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 filedesc.h
--- filedesc.h 1999/08/29 16:32:22 1.15.2.1
+++ filedesc.h 2000/01/20 21:39:29
@@ -139,6 +139,7 @@
int fsetown __P((pid_t, struct sigio **));
void funsetown __P((struct sigio *));
void funsetownlst __P((struct sigiolst *));
+void setugidsafety __P((struct proc *p));
#endif
#endif
Index: kern/kern_descrip.c
===================================================================
RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_descrip.c,v
retrieving revision 1.58.2.3
diff -u -r1.58.2.3 kern_descrip.c
--- kern_descrip.c 1999/11/18 08:09:08 1.58.2.3
+++ kern_descrip.c 2000/01/20 21:40:00
@@ -984,6 +984,62 @@
}
/*
+ * For setuid/setgid programs we don't want to people to use that setuidness
+ * to generate error messages which write to a file which otherwise would
+ * otherwise be off limits to the proces.
+ *
+ * This is a gross hack to plug the hole. A better solution would involve
+ * a special vop or other form of generalized access control mechanism. We
+ * go ahead and just reject all procfs file systems accesses as dangerous.
+ *
+ * Since setugidsafety calls this only for fd 0, 1 and 2, this check is
+ * sufficient. We also don't for setugidness since we know we are.
+ */
+static int
+is_unsafe(struct file *fp)
+{
+ if (fp->f_type == DTYPE_VNODE &&
+ ((struct vnode *)(fp->f_data))->v_tag == VT_PROCFS)
+ return (1);
+ return (0);
+}
+
+/*
+ * Make this setguid thing safe, if at all possible.
+ */
+void
+setugidsafety(p)
+ struct proc *p;
+{
+ struct filedesc *fdp = p->p_fd;
+ struct file **fpp;
+ char *fdfp;
+ register int i;
+
+ /* Certain daemons might not have file descriptors. */
+ if (fdp == NULL)
+ return;
+
+ fpp = fdp->fd_ofiles;
+ fdfp = fdp->fd_ofileflags;
+ for (i = 0; i <= fdp->fd_lastfile; i++, fpp++, fdfp++) {
+ if (i > 2)
+ break;
+ if (*fpp != NULL && is_unsafe(*fpp)) {
+ if (*fdfp & UF_MAPPED)
+ (void) munmapfd(p, i);
+ (void) closef(*fpp, p);
+ *fpp = NULL;
+ *fdfp = 0;
+ if (i < fdp->fd_freefile)
+ fdp->fd_freefile = i;
+ }
+ }
+ while (fdp->fd_lastfile > 0 && fdp->fd_ofiles[fdp->fd_lastfile] == NULL)
+ fdp->fd_lastfile--;
+}
+
+/*
* Close any files on exec?
*/
void
Index: kern/kern_exec.c
===================================================================
RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_exec.c,v
retrieving revision 1.93.2.3
diff -u -r1.93.2.3 kern_exec.c
--- kern_exec.c 1999/08/29 16:25:58 1.93.2.3
+++ kern_exec.c 2000/01/20 21:39:29
@@ -281,6 +281,7 @@
if (attr.va_mode & VSGID)
p->p_ucred->cr_gid = attr.va_gid;
setsugid(p);
+ setugidsafety(p);
} else {
if (p->p_ucred->cr_uid == p->p_cred->p_ruid &&
p->p_ucred->cr_gid == p->p_cred->p_rgid)
VI. Credits
We are republishing a heavily edited FEAR security advisory (number 1)
entitled "*BSD procfs vulnerability". More information about FEAR can
be found at http://www.fear.pl. We would like to thank
nergal@idea.avet.com.pl for sending a preliminary version of the
advisory to us in time to correct the problem.
=============================================================================
FreeBSD, Inc.
Web Site: http://www.freebsd.org/
Confidential contacts: security-officer@freebsd.org
Security notifications: security-notifications@freebsd.org
Security public discussion: freebsd-security@freebsd.org
PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc
Notice: Any patches in this document may not apply cleanly due to
modifications caused by digital signature or mailer software.
Please reference the URL listed at the top of this document
for original copies of all patches if necessary.
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBOJFWeFUuHi5z0oilAQHo2AP+N4GDREEmjxy6RUvt+G3cRe1Sx4yxr/Jd
q70D5Icp3JlcJgxGfWFqGGvt8yx9xMm6d57mFDltdvPKr0TY0n0bY39BJlRAto9n
gn8BJJvQ0WQ15ctOQKIsGwGJqHvA+p4qAHYFE3sUIZn6oMz5//C5OmaC7mFtrycY
TI64bNR+0F8=
=/F89
-----END PGP SIGNATURE-----

87
share/security/advisories/FreeBSD-SA-00:03.asmon.asc Normal file
View file

@ -0,0 +1,87 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:03 Security Advisory
FreeBSD, Inc.
Topic: Asmon/Ascpu ports fail to drop privileges
Category: ports
Module: asmon/ascpu
Announced: 2000-02-19
Affects: Ports collection before the correction date.
Corrected: 2000-01-29
FreeBSD only: yes
I. Background
Two optional third-party ports distributed with FreeBSD can be used to
execute commands with elevated privileges, specifically setgid kmem
privileges. This may lead to a local root compromise.
II. Problem Description
Asmon and ascpu allow users to execute arbitrary commands as part of a user
configuration file. Both applications are Linux-centric as distributed by
the vendor and require patching to run under FreeBSD (specifically, using
the kvm interface and setgid kmem privileges to obtain system statistics);
this patching was the source of the present security problem. This is a
similar flaw to one found in the wmmon port, which was corrected on
1999/12/31.
Note that neither utility is installed by default, nor are they "part of
FreeBSD" as such: they are part of the FreeBSD ports collection, which
contains over 3100 third-party applications in a ready-to-install format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit of
the most security-critical ports.
III. Impact
If you have not chosen to install the asmon or ascpu ports/packages, then
your system is not vulnerable. If you have, then local users can obtain
setgid kmem rights, which allows them to manipulate kernel memory, and
thereby compromise root.
IV. Workaround
Remove the asmon and ascpu ports/packages, if you have installed them.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the asmon and/or ascpu
ports.
2) Reinstall a new package obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/sysutils/asmon-0.60.tgz
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/sysutils/ascpu-1.8.tgz
after the correction date. At the time of advisory release, the asmon
package was not available - you may need to use one of the other methods
to update the software.
3) download a new port skeleton for the asmon and/or ascpu ports from:
http://www.freebsd.org/ports/
and use it to rebuild one or both ports.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOK+LsFUuHi5z0oilAQHRZAP+MC3e3NhGNTDhiL/GAQjewUS8c16ClPhj
WruCd5Tu1WJA2Em8Q19Ui7vrLRLQ9aXzTocUOBd6x6/zqpM3lS1aJMwvV9BkZ59G
ONh6aiM7FbWPKukW1YThKDn0Vjtc5JaDHsbJ4dVHQh/IMqZD8hqocLG4AjJDxnLj
qlRyhiCr/lA=
=l1gj
-----END PGP SIGNATURE-----

92
share/security/advisories/FreeBSD-SA-00:04.delegate.asc Normal file
View file

@ -0,0 +1,92 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:04 Security Advisory
FreeBSD, Inc.
Topic: Delegate port contains numerous buffer overflows
Category: ports
Module: delegate
Announced: 2000-02-19
Affects: Ports collection before the correction date.
Corrected: 2000-02-02
FreeBSD only: NO
I. Background
An optional third-party port distributed with FreeBSD contains numerous
remotely-exploitable buffer overflows which allow an attacker to execute
arbitrary commands on the local system, typically as the 'nobody' user.
II. Problem Description
Delegate is a versatile application-level proxy. Unfortunately it is
written in a very insecure style, with potentially dozens of different
exploitable buffer overflows (including several demonstrated ones), each of
which could allow an attacker to execute arbitrary code on the delegate
server. This code will run as the user ID of the 'delegated' process,
typically 'nobody' in the recommended configuration, but this still
represents a security risk as the attacker may be able to mount a local
attack to further upgrade his or her access privileges.
Note that the delegate utility is not installed by default, nor is it "part
of FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3100 third-party applications in a ready-to-install format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit of
the most security-critical ports.
III. Impact
If you have not chosen to install the delegate port/package, then your
system is not vulnerable. If you have, then local or remote users who can
connect to the delegate port(s), or malicious servers which a user accesses
using the delegate proxy, can potentially execute arbitrary code on your
system in any number of ways.
IV. Workaround
Remove the delegate port/package, if you have installed it.
V. Solution
Unfortunately no simple fix is available - the problems with the delegate
software are too endemic to be fixed by a simple patch. It is hoped the
software authors will take security to heart and correct the security
problems in a future version, although user caution is advised given the
current state of the code.
Depending on your local setup and your security threat model, using a
firewall/packet filter such as ipfw(8) or ipf(8) to prevent remote users
from connecting to the delegate port(s) may be enough to meet your security
needs. Note that this will not prevent legitimate proxy users from
attacking the delegate server, although this may not be an issue if they
have a shell account on the machine anyway.
Note also that this does not prevent "passive" exploits in which a user is
convinced through other means into visiting a malicious server using the
proxy, which may be able to compromise it by sending back invalid
data. Several flaws of this type have been discovered during a brief
survey of the code.
If you are running FreeBSD 4.0, a possible solution might be to confine the
delegate process inside a "jail" (see the jail(8) manpage). A properly
configured jail will isolate the contents in their own separate "virtual
machine", which can be suitably secured so that an attacker who gains
control of a process running inside the jail cannot escape and gain access
to the rest of the machine. Note that this is different from a traditional
chroot(8), since it does not just attempt to isolate processes inside
portions of the filesystem. This solution is not possible under standard
FreeBSD 3.x or earlier.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOK+NTVUuHi5z0oilAQGGnAP+NOxAOVpEUpyR0iQwNjA1Je7B4M5gOxzc
NwqQKp7WBm/IzzIW23KvyPcbTld83+m2tnhdNW3srh8ESSYDaa/hhmG2AtR0LYEL
H2EWTIBcPBhidquX+ihKGTSaMnMjYpmp6GVGSsBqcNFXAPGHiJ6BbsEg2k6rJSLz
wgL0NJ+qkCI=
=ZhXO
-----END PGP SIGNATURE-----

92
share/security/advisories/FreeBSD-SA-00:05.mysql.asc Normal file
View file

@ -0,0 +1,92 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:05 Security Advisory
FreeBSD, Inc.
Topic: MySQL allows bypassing of password authentication
Category: ports
Module: mysql322-server
Announced: 2000-02-28
Affects: Ports collection before the correction date.
Corrected: 2000-02-15
FreeBSD only: NO
I. Background
MySQL is a popular SQL database client/server distributed as part of the
FreeBSD ports collection.
II. Problem Description
The MySQL database server (versions prior to 3.22.32) has a flaw in the
password authentication mechanism which allows anyone who can connect to
the server to access databases without requiring a password, given a valid
username on the database - in other words, the normal password
authentication mechanism can be completely bypassed.
MySQL is not installed by default, nor is it "part of FreeBSD" as such: it
is part of the FreeBSD ports collection, which contains over 3100
third-party applications in a ready-to-install format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit
of the most security-critical ports.
III. Impact
The successful attacker will have all of the access rights of that
database user and may be able to read, add or modify records.
If you have not chosen to install the mysql322-server port/package, then
your system is not vulnerable.
IV. Workaround
Use appropriate access-control lists to limit which hosts can initiate
connections to MySQL databases - see:
http://www.mysql.com/Manual_chapter/manual_Privilege_system.html
for more information. If unrestricted remote access to the database is not
required, consider using ipfw(8) or ipf(8), or your network perimeter
firewall, to prevent remote access to the database from untrusted machines
(MySQL uses TCP port 3306 for network communication). Note that users who
have access to machines which are allowed to initiate database connections
(e.g. local users) can still exploit the security hole.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the mysql322-server
port.
2) Reinstall a new package obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/databases/mysql-server-3.22.32.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/databases/mysql-server-3.22.32.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/databases/mysql-server-3.22.32.tgz
3) download a new port skeleton for the mysql322-server port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOLtYEVUuHi5z0oilAQHtbwP/TF0hNZwrO/wAuBjYF8Eff5aDU1KtnA9D
u0bcUakDgF/nODVxgOFZ1MfaK95PAhRqdYvtwssTqTXwlRB+PU0vtwjdt3p3l8d3
SixfhxT+Ys/v222jK+o6lJdxfKOC4chNDseboSRoCSLEESNl2NDGkBKezKSzzlng
vzxtva695bI=
=KYqf
-----END PGP SIGNATURE-----

90
share/security/advisories/FreeBSD-SA-00:06.htdig.asc Normal file
View file

@ -0,0 +1,90 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:06 Security Advisory
FreeBSD, Inc.
Topic: htdig port allows remote reading of files
Category: ports
Module: htdig
Announced: 2000-03-01
Affects: Ports collection before the correction date.
Corrected: 2000-02-28
FreeBSD only: NO
I. Background
The ht://Dig system is a complete world wide web indexing and searching
system for a small domain or intranet.
II. Problem Description
There is a security hole in the htsearch cgi-bin program for versions of
htdig prior to 3.1.5, which allows remote users to read any file on the
local system that is accessible to the user ID running htsearch (usually
the user ID running the webserver process, user 'nobody' in the default
installation of apache).
Note that the htdig utility is not installed by default, nor is it "part
of FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3100 third-party applications in a ready-to-install format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit
of the most security-critical ports.
III. Impact
If you have not chosen to install the htdig port/package, then your system
is not vulnerable. If you have, then local or remote users who can connect
to a web server which contains the htsearch cgi-bin executable can read
any file on your system which is accessible to the user running the
htsearch process (typically user nobody). It is not currently believed
that an attacker can exploit this hole to modify or delete files, but they
may be able to use the ability to read files to mount a further attack
based on other security holes they discover.
IV. Workaround
Remove the /usr/local/share/apache/cgi-bin/htsearch file, if you do not
make use of it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the htdig port.
2) Reinstall a new package obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/textproc/htdig-3.1.5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/textproc/htdig-3.1.5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/textproc/htdig-3.1.5.tgz
(Note: it may be several days before the new packages appear on the FTP
site)
3) download a new port skeleton for the htdig port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOL1um1UuHi5z0oilAQGtnwP+JsTP4KCrAO/fEIMG70a79tPsLeqUiuyP
ihPc5Rw/e6wguW8qPLXvLGSsT5zzkXLOeuww+2ViPpYehTkD4cB1zt3UsWeNSGa+
kkWQyYFwK/3BaHbsN8COu4xa5c4B+VdqbFXa3G/cIM+MRRTxlhrDWqaJp58UKpD3
OA7HcbSdSKk=
=A+Nm
-----END PGP SIGNATURE-----

113
share/security/advisories/FreeBSD-SA-00:07.mh.asc Normal file
View file

@ -0,0 +1,113 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:07 Security Advisory
FreeBSD, Inc.
Topic: mh/nmh/exmh/exmh2 ports allow remote execution of binary code
Category: ports
Module: mh/nmh/exmh/exmh2
Announced: 2000-03-15
Revised: 2000-03-19
Affects: Ports collection before the correction date.
Corrected: [See below for a more complete description]
All versions fixed in 4.0-RELEASE.
mh: 2000-03-04
nmh: 2000-02-29
exmh: 2000-03-05
exmh2: 2000-03-05
FreeBSD only: NO
I. Background
MH and its successor NMH are popular Mail User Agents. EXMH and EXMH2 are
TCL/TK-based front-ends to the MH system. There are also Japanese-language
versions of the MH and EXMH2 ports, but these are developed separately and are
not vulnerable to the problem described here.
II. Problem Description
The mhshow command used for viewing MIME attachments contains a buffer
overflow which can be exploited by a specially-crafted email attachment,
which will allow the execution of arbitrary code as the local user when the
attachment is opened.
The *MH ports are not installed by default, nor are they "part of
FreeBSD" as such: they are part of the FreeBSD ports collection, which
contains over 3100 third-party applications in a ready-to-install
format. The FreeBSD 4.0-RELEASE ports collection is not vulnerable to
this problem.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit
of the most security-critical ports.
III. Impact
An attacker who can convince a user to open a hostile MIME attachment sent
as part of an email message can execute arbitrary binary code running with
the privileges of that user.
If you have not chosen to install any of the mh/nmh/exmh/exmh2
ports/packages, then your system is not vulnerable.
The Japanese-language version of MH is being actively developed and is
believed to have fixed this particular problem over a year ago. Consequently
the ja-mh and ja-exmh2 ports are not believed to be vulnerable to this problem.
IV. Workaround
1) Remove the mhshow binary, located in /usr/local/bin/mhshow. This will
prevent the viewing of MIME attachments from within *mh.
2) Remove the mh/nmh/exmh/exmh2 ports, if you you have installed them.
V. Solution
The English language version of the MH software is no longer actively
developed, and no fix is currently available. It is unknown whether a fix
to the problem will be forthcoming - consider upgrading to use NMH instead,
which is the designated successor of the MH software. EXMH and EXMH2 can
both be compiled to use NMH instead (this is now the default behaviour). It
is not necessary to recompile EXMH/EXMH2 after reinstalling NMH.
SOLUTION: Remove any old versions of the mail/mh or mail/nmh ports and
perform one of the following:
1) Upgrade your entire ports collection and rebuild the mail/nmh port.
2) Reinstall a new package obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/nmh-1.0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/mail/nmh-1.0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/mail/nmh-1.0.3.tgz
3) download a new port skeleton for the nmh port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision history
v1.0 2000-03-15 Initial release
v1.1 2000-03-19 Update to note that the japanese-localized ports are not
vulnerable
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBONXFXlUuHi5z0oilAQHQ/QP9FCTFiFlaeSv2ROM46PbDkF6MN39SLTuv
DEW6a6wmMU5+YbSTlFLjvYrqYgpjOmM7NMOMhhceVVpoZVMMPonHuJxHWh7YvF2G
T4bZcRM3kpRcjXAOQnIiUrgh77zoEmfBysAmHZbNucCmOB5y7UqHI3CM31+geiPR
/bsvHCy4U0U=
=Odcg
-----END PGP SIGNATURE-----

111
share/security/advisories/FreeBSD-SA-00:08.lynx.asc Normal file
View file

@ -0,0 +1,111 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:08 Security Advisory
FreeBSD, Inc.
Topic: Lynx ports contain numerous buffer overflows
Category: ports
Module: lynx/lynx-current/lynx-ssl/ja-lynx/ja-lynx-current
Announced: 2000-03-15
Revised: 2000-05-17
Affects: Ports collection before the correction date.
Corrected: 2000-04-16 [lynx-current]
2000-04-21 [lynx]
FreeBSD only: NO
I. Background
Lynx is a popular text-mode WWW browser, available in several versions
including SSL support and Japanese language localization.
II. Problem Description
Versions of the lynx software prior to version 2.8.3pre.5 were written
in a very insecure style and contain numerous potential and several
proven security vulnerabilities (publicized on the BugTraq mailing
list) exploitable by a malicious server.
The lynx ports are not installed by default, nor are they "part of
FreeBSD" as such: they are part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A malicious server which is visited by a user with the lynx browser
can exploit the browser security holes in order to execute arbitrary
code as the local user.
If you have not chosen to install any of the
lynx/lynx-current/lynx-ssl/ja-lynx/ja-lynx-current ports/packages,
then your system is not vulnerable.
IV. Workaround
Remove the lynx/lynx-current/lynx-ssl/ja-lynx/ja-lynx-current ports,
if you you have installed them.
V. Solution
Upgrade to lynx or lynx-current after the correction date.
After the initial release of this advisory, the Lynx development team
conducted an audit of the source code, and have corrected the known
vulnerabilities in lynx as well as increasing the robustness of the
string-handling code. As of lynx-2.8.3pre.5, we consider it safe
enough to use again.
Note that there may be undiscovered vulnerabilities remaining in the
code, as with all software - but should any further vulnerabilities be
discovered a new advisory will be issued.
At this time the lynx-ssl/ja-lynx/ja-lynx-current ports are not yet
updated to a safe version of lynx: this advisory will be reissued
again once they are.
1) Upgrade your entire ports collection and rebuild the lynx or
lynx-current port.
2) Reinstall a lynx new package dated after the correction date,
obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/lynx-2.8.3.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/lynx-2.8.3.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/lynx-2.8.3.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/lynx-2.8.3.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/lynx-2.8.3.1.tgz
Note that the lynx-current port is not automatically built as a package.
3) download a new port skeleton for the lynx/lynx-current port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-03-15 Initial release
v1.1 2000-05-17 Update to note fix of lynx and lynx-current ports.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOSMQT1UuHi5z0oilAQHlgwP9EiLqvf8MM55fvftEXPMfL6PJ6HFQPYMH
+TqX5Q/P9s0mgBFiGfN8wblmtEUyZ1GwF8goPa9fqqJIfNg8Qu2zWqJOYPjc20hW
yo3Rxbi+lEWOYxLpxBKDhvBH7yWxiV8Nm1+w73a76BjaZ20E0b91hgw2lebFiZPi
uzK38WjnFNQ=
=qWEC
-----END PGP SIGNATURE-----

85
share/security/advisories/FreeBSD-SA-00:09.mtr.asc Normal file
View file

@ -0,0 +1,85 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:09 Security Advisory
FreeBSD, Inc.
Topic: mtr port contains a local root exploit.
Category: ports
Module: mtr
Announced: 2000-03-15
Affects: Ports collection before the correction date.
Corrected: 2000-03-07 (included in FreeBSD 4.0-RELEASE)
FreeBSD only: NO
I. Background
mtr ("Multi Traceroute") combines the functionality of the "traceroute" and
"ping" programs into a single network diagnostic tool.
II. Problem Description
The mtr program (versions 0.41 and below) fails to correctly drop setuid
root privileges during operation, allowing a local root compromise.
The mtr port is not installed by default, nor is it "part of FreeBSD" as
such: it is part of the FreeBSD ports collection, which contains over 3100
third-party applications in a ready-to-install format. The FreeBSD
4.0-RELEASE ports collection is not vulnerable to this problem.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit of
the most security-critical ports.
III. Impact
A local user can exploit the security hole to obtain root privileges.
If you have not chosen to install the mtr port/package, then your system is
not vulnerable.
IV. Workaround
1) Remove the mtr port if you have installed it.
2) Disable the setuid bit - run the following command as root:
chmod u-s /usr/local/sbin/mtr
This will mean non-root users cannot make use of the program, since it
requires root privileges to properly run.
V. Solution
1) Upgrade your entire ports collection and rebuild the mtr port.
2) Reinstall a new package obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/mtr-0.42.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/net/mtr-0.42.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/net/mtr-0.42.tgz
Note: it may be several days before the updated packages are available.
3) download a new port skeleton for the mtr port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOM/J3FUuHi5z0oilAQFdjQP+MCxSn1WYvRehaxky8xnOLP8sAOiLvxLf
DG3emT6hgG7IFKTHNQ/KvHE5M9Y4/frk1tJGKVb/RKEbpbDDF3mmN0eq6S2B2Qda
TB4YjbaLVAnFKVhFcbZjVfc4YTtutNgl7xd/4bvXennki77oQiO5T3VRNnIXkjD1
NUk4XQDyTQ4=
=Rrxf
-----END PGP SIGNATURE-----

90
share/security/advisories/FreeBSD-SA-00:10.orville-write.asc Normal file
View file

@ -0,0 +1,90 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:10 Security Advisory
FreeBSD, Inc.
Topic: orville-write port contains local root compromise.
Category: ports
Module: orville-write
Announced: 2000-03-15
Affects: Ports collection before the correction date.
Corrected: 2000-03-09
FreeBSD only: Yes
I. Background
Orville-write is a replacement for the write(1) command, which
provides improved control over message delivery and other features.
II. Problem Description
One of the commands installed by the port is incorrectly installed
with setuid root permissions. The 'huh' command should not have any
special privileges since it is intended to be run by the local user to
view his saved messages.
The orville-write port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3100 third-party applications in a ready-to-install
format. The FreeBSD 4.0-RELEASE ports collection is not vulnerable to
this problem.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security audit of
the most security-critical ports.
III. Impact
A local user can exploit a buffer overflow in the 'huh' utility to
obtain root privileges.
If you have not chosen to install the orville-write port/package, then
your system is not vulnerable.
IV. Workaround
Remove the orville-write port if you have installed it.
V. Solution
Remove the setuid bit from the huh utility, by executing the following
command as root:
chmod u-s /usr/local/bin/huh
It is not necessary to reinstall the orville-write port, although this
can be done in one of the following ways if desired:
1) Upgrade your entire ports collection and rebuild the orville-write port.
2) Reinstall a new package dated after the correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/misc/orville-write-2.41a.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-current/misc/orville-write-2.41a.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-current/misc/orville-write-2.41a.tgz
Note: it may be several days before the updated packages are available.
3) download a new port skeleton for the orville-write port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOM/KWlUuHi5z0oilAQHk3AP+PEWNZ95ou8Oyf0nFzgAvjRCc4T060cJf
8qncBFmbWKvl/VHGJnj+u5HPE2LciZb/SdQxH0Ibuvm45hjt7umRrNcHQABmhtYV
9kG2k2cG+w9QtPnWQUtk7UDAQ2nmbyvQBsUJI+wrILoTHaKU1nLBivzzQbZPX9Nr
YTNtkrInpV0=
=c84W
-----END PGP SIGNATURE-----

93
share/security/advisories/FreeBSD-SA-00:11.ircii.asc Normal file
View file

@ -0,0 +1,93 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:11 Security Advisory
FreeBSD, Inc.
Topic: ircII port contains a remote overflow
Category: ports
Module: ircII
Announced: 2000-04-10
Credits: Derek Callaway <super@UDEL.EDU> via BugTraq
"bladi" <bladi@EUSKALNET.NET> via BugTraq
Affects: Ports collection before the correction date.
Corrected: 2000-03-19
FreeBSD only: NO
I. Background
ircII is a popular text-mode IRC client.
II. Problem Description
ircII version 4.4 contained a remotely-exploitable buffer overflow in
the /DCC CHAT command which allows remote users to execute arbitrary
code as the client user.
The bug was originally reported in 1997 in a much older version of
ircII, but was apparently not corrected at the time, and the problem
was recently rediscovered independently. Development on the version of
ircII previously in ports ceased several years ago, and has been taken
up by a new group who have fixed this problem (and possibly
others). FreeBSD now provides this new version of ircII.
The ircII port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. FreeBSD 4.0 did not ship with the ircII package available
because this vulnerability was reported to us late in the release
cycle and it was not possible to upgrade the port in time.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A remote user can cause arbitrary code to be executed on the local
system as the user running ircII.
If you have not chosen to install the ircII port/package, then your
system is not known to be vulnerable to this problem, although there
are several other IRC clients which are derived from ircII including
Epic and BitchX. At this time it is unknown whether other clients are
vulnerable to this problem.
IV. Workaround
Remove the ircII port, if you you have installed it.
V. Solution
1) Upgrade your entire ports collection and rebuild the ircII port.
2) Reinstall a new package dated after the correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/irc/ircII-4.4S.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/irc/ircII-4.4S.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-3-stable/irc/ircII-4.4S.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/irc/ircII-4.4S.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/irc/ircII-4.4S.tgz
3) download a new port skeleton for the ircII port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOPJAMVUuHi5z0oilAQHKpgQAjdphg+Xaw4J7J5+dowvgrgoggA4YG0P5
a7Nodawpvm2ya8jBStmi0cs3LhYIXZUPQfY3lqiAfEbf4Ndd4r5KUbQ+iAjgz4lZ
XHG0PjUGE98dK3eHZbLszaMIwPbBaCyicCD0gLPCVm40O0VOlqY+WHO9MfITgpec
GFF3l8b8Ym0=
=IU1d
-----END PGP SIGNATURE-----

85
share/security/advisories/FreeBSD-SA-00:12.healthd.asc Normal file
View file

@ -0,0 +1,85 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:12 Security Advisory
FreeBSD, Inc.
Topic: healthd allows a local root compromise
Category: ports
Module: healthd
Announced: 2000-04-10
Credits: Discovered during FreeBSD ports collection auditing.
Affects: Ports collection before the correction date.
Corrected: 2000-03-25
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
healthd is a small utility for monitoring the temperature, fan speed
and voltage levels of certain motherboards.
II. Problem Description
healthd v0.3 installs a utility which is setuid root in order to
monitor the system status. This utility contains a trivial buffer
overflow which allows an unprivileged local user to obtain root
privileges on the system.
The healthd port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A local user can obtain root privileges by exploiting a vulnerability
in the healthd utility.
If you have not chosen to install the healthd port/package, then your
system is not vulnerable.
IV. Workaround
Remove the healthd port, if you you have installed it.
V. Solution
1) Upgrade your entire ports collection and rebuild the healthd port.
2) Reinstall a new package dated after the correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/sysutils/healthd-0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/sysutils/healthd-0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-3-stable/sysutils/healthd-0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/sysutils/healthd-0.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/sysutils/healthd-0.3.tgz
3) download a new port skeleton for the healthd port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOPJABVUuHi5z0oilAQGEjgP/VQi4gknLQTpons+W/D3pT1fsk9F55HjQ
80pdBIfRxWNekFA+ZlfDNESLbG3qPyr+R4UaVxIZMnMVM/ZZRGPc/suYOxoHWZv0
F29AqveqINRewGHJoF+hw+DDGJPrrWy2t25BW9AX8KXPCJ2C1uiyChN+2egdJT5J
EcTA8JgVU8I=
=RtRI
-----END PGP SIGNATURE-----

90
share/security/advisories/FreeBSD-SA-00:13.generic-nqs.asc Normal file
View file

@ -0,0 +1,90 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:13 Security Advisory
FreeBSD, Inc.
Topic: generic-nqs contains a local root compromise
Category: ports
Module: generic-nqs
Announced: 2000-04-19
Credits: Philippe Andersson <philippe_andersson@STE.SCITEX.COM>
via BugTraq
Affects: Ports collection before the correction date.
Corrected: 2000-04-16
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
Generic-NQS is a Network Queuing System for batch-processing jobs across
multiple machines.
II. Problem Description
Generic-NQS versions 3.50.7 and earlier contain a security vulnerability
which allow a local user to easily obtain root privileges. Unfortunately,
further details of the location and nature of the vulnerability were not
provided by the original poster, upon request of the Generic-NQS
developers.
The generic-nqs port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A local user can obtain root privileges by exploiting a vulnerability
in the generic-nqs package.
If you have not chosen to install the generic-nqs port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Remove the generic-nqs port, if you you have installed it.
V. Solution
1) Upgrade your entire ports collection and rebuild the generic-nqs port.
2) Reinstall a new package dated after the correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/generic-nqs-3.50.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/generic-nqs-3.50.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/generic-nqs-3.50.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/generic-nqs-3.50.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/generic-nqs-3.50.9.tgz
Note that it may be a few days before the updated package is available.
3) download a new port skeleton for the generic-nqs port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOP4kUVUuHi5z0oilAQGmYAQAntm5ianpGoWd2dr2Nf294InKoxRK5tt+
61yGHUdZiFIWNUcEEow158vCnmAid1XyBRrYdeZLCs0EU0gaHRL21a1RpKab31T1
oc8pPK5mCyygwrXCf/u4aZES/HQyVbpryEqnvrggSzjlXExhsl6i+4YEBYHUO2Mi
s8xowH91Sy4=
=eXhd
-----END PGP SIGNATURE-----

105
share/security/advisories/FreeBSD-SA-00:14.imap-uw.asc Normal file
View file

@ -0,0 +1,105 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:14 Security Advisory
FreeBSD, Inc.
Topic: imap-uw contains security vulnerabilities for "closed"
mail servers
Category: ports
Module: imap-uw
Announced: 2000-04-24
Credits: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Michal Szymanski <siva9@CLICO.PL> via BugTraq
Affects: Ports collection.
Corrected: See below.
Vendor status: Aware of the problem, no satisfactory solution provided.
FreeBSD only: NO
I. Background
imap-uw is a popular IMAP4/POP2/POP3 mail server from the University
of Washington.
II. Problem Description
There are numerous buffer overflows available to an imap user after
they have successfully logged into their mail account
(i.e. authenticated themselves by giving the correct password,
etc). Once the user logs in, imapd has dropped root privileges and is
running as the user ID of the mail account which has been logged into,
so the buffer overflow can only allow code to be executed as that
user.
Thus, the vulnerability is only relevant on a "closed" mail server,
i.e. one which does not normally allow interactive logins by mail
users. For a system which allows users to log in or execute code on
the system, there is minimal vulnerability.
Note that once a user has successfully exploited the vulnerability to
gain access to their user account they may be able to mount further
attacks against the local (or a remote) machine to upgrade their
privileges.
The imap-uw port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A user with a mail account on the imap server can execute arbitrary
code as themselves on that machine. This is only likely to be a
security issue on "closed" mail servers which do not allow interactive
shell logins.
Only imapd is known to be vulnerable to this time - the other daemons
installed by the imap-uw port (ipop2d/ipop3d) are not known to suffer
from the same vulnerability.
If you have not chosen to install the imap-uw port/package, then your
system is not vulnerable to this problem.
IV. Workaround
1) Deinstall the imap-uw port/package, if you you have installed it.
2) If you do not specifically require imap functionality
(i.e. pop2/pop3 is sufficient) then disable the imap daemon in
/etc/inetd.conf and restart inetd (e.g. with the command 'killall -HUP
inetd')
V. Solution
Unfortunately the vulnerabilities in imapd are quite extensive and no
patch is currently available to address them. There is also no
"drop-in" replacement for imap-uw currently available in ports,
although the mail/cyrus port is another imap server which may be a
suitable replacement. Cyrus has different configuration and
operational requirements than imap-uw however, which may make it
unsuitable for many users.
Until a security audit of the imap-uw source can be completed and the
vulnerabilities patched, it is recommended that operators of "closed"
imapd servers take steps to minimize the impact of users being able to
run code on the server (i.e., by tightening the local security on the
machine to minimize the damage an intruding user can cause).
This advisory will be updated once the known vulnerabilities in
imap-uw have been addressed.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOQTN61UuHi5z0oilAQEe9QQAhoPtcTPFYv4RSvh0x/FYe1x8J4kmvi0x
I5fFL3Am8Yfjra/ETGE/WQpGttIFluyfs7RmOc7aglJHp9Aeii9zgCU0dv+3TIZb
FA0NUpode09tfEOP4ciuL1Diae9utoPc+80mitbGFoNL1uAUj4QKWxNNCJ1K6Jyd
plUnZwIFx64=
=qaIn
-----END PGP SIGNATURE-----

87
share/security/advisories/FreeBSD-SA-00:15.imap-uw.asc Normal file
View file

@ -0,0 +1,87 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:15 Security Advisory
FreeBSD, Inc.
Topic: imap-uw allows local users to deny service to any mailbox
Category: ports
Module: imap-uw
Announced: 2000-04-24
Credits: Alex Mottram <alex@NET-CONNECT.NET> via BugTraq
Affects: Ports collection.
Corrected: See below.
Vendor status: Notified.
FreeBSD only: NO
I. Background
imap-uw is a popular IMAP4/POP2/POP3 mail server from the University
of Washington.
II. Problem Description
The imap-uw port supplies a "libc-client" library which provides
various functionality common to mail servers. The algorithm used for
locking of mailbox files contains a weakness which allows an
unprivileged local user to lock an arbitrary local mailbox.
In the case of POP2/POP3 servers, this means that the mailbox will not
be able to be accessed at all by the owner. In the case of IMAP4
servers, the folder can be opened for reading, but not writing
(i.e. can only be accessed read-only).
Note that this is a different vulnerability than that described in
FreeBSD Security Advisory 00:14, and affects all imap-uw servers which
provide shell-level access to users. However note that by virtue of
advisory 00:14, all users who can access their mail remotely via imap
can acquire such access even without explicit shell login access.
The imap-uw port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
A user who has, or who can obtain (see advisory 00:14) shell access to
the mail server can prevent an arbitrary mailbox from being opened via
pop2/pop3, or can force the mailbox to be only opened read-only via
imap.
If you have not chosen to install the imap-uw port/package, then your
system is not vulnerable to this problem.
IV. Workaround
1) Deinstall the imap-uw port/package, if you you have installed it.
2) Consider using another POP2/POP3 server if you do not require IMAP
functionality. See the notes regarding alternative IMAP servers in
FreeBSD Security Advisory 00:14.
V. Solution
No patch is currently available. It is encumbent on the imap-uw
developers to redesign the mailbox locking scheme to provide a secure
locking mechanism which is not vulnerable to local denial-of-service
attacks.
This advisory will be updated once the known vulnerabilities in
imap-uw have been addressed.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOQTN8FUuHi5z0oilAQH58gP+JtkvDh4EFR13jGKxb6PERkt9x6Cpy+DY
1P56XODBiK4tnbTjdke2JLLNUHpSYtN23h8zt1DtnlxnxunQa8Y6fhptbpgHUWAu
ZIJlLLnl0iQcjj3Lqwz2E2BaFsyZxlVSGQnD/EmI+tyZcY+oTYbomCgi1RW3kbn+
fmNJXmwTXCg=
=TwTN
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:16.golddig.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:16 Security Advisory
FreeBSD, Inc.
Topic: golddig port allows users to overwrite local files
Category: ports
Module: golddig
Announced: 2000-05-09
Credits: Discovered during internal ports collection auditing.
Affects: Ports collection.
Corrected: 2000-04-30
Vendor status: Email bounced.
FreeBSD only: NO
I. Background
Golddig is an X11 game provided as part of the FreeBSD ports collection.
II. Problem Description
The golddig port erroneously installs a level-creation utility setuid
root, which allows users to overwrite the contents of arbitrary local
files. It is not believed that any elevation of privileges is possible
with this vulnerability because the contents of the file are a textual
representation of a golddig game level which is highly constrained.
The golddig port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3200 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
An unprivileged local user can overwrite the contents of any file,
although they are restricted in the possible contents of the new file.
If you have not chosen to install the golddig port/package, then your
system is not vulnerable to this problem.
IV. Workaround
One of the following:
1) Deinstall the golddig port/package, if you you have installed it.
2) Remove the setuid bit from /usr/local/bin/makelev. This will mean
unprivileged users cannot create or modify golddig levels except in
their own directories.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the golddig port.
2) Reinstall a new package dated after the correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/games/golddig-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/games/golddig-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/games/golddig-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/games/golddig-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/games/golddig-2.0.tgz
Note: it may be several days before the updated packages are available.
3) download a new port skeleton for the golddig port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBORhjV1UuHi5z0oilAQHa4AP8D5QZo+zNieNemPMfMW77JIxsHtCHCg+M
MEG6CkJ6QOZlwJ8Mav1ExMyQywWncccgkazBFyK2KG5rAqpxX4KMZ+C3zfysTraS
cHVCVBw73yx0t53/FnvoR3yqtI+GdmhPaw9X3icCtp9st3hiSMF759yPqOUKBbIu
JFgdfAuXaqs=
=Pxca
-----END PGP SIGNATURE-----

157
share/security/advisories/FreeBSD-SA-00:17.libmytinfo.asc Normal file
View file

@ -0,0 +1,157 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:17 Security Advisory
FreeBSD, Inc.
Topic: Buffer overflow in libmytinfo may yield increased
privileges with third-party software.
Category: core
Module: libmytinfo
Announced: 2000-05-09
Affects: FreeBSD 3.x before the correction date.
Corrected: 2000-04-25
FreeBSD only: Yes
Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:17/libmytinfo.patch
I. Background
libmytinfo is part of ncurses, a text-mode display library.
II. Problem Description
libmytinfo allows users to specify an alternate termcap file or entry
via the TERMCAP environment variable, however this is not handled
securely and contains a overflowable buffer inside the library.
This is a security vulnerability for binaries which are linked against
libmytinfo and which are setuid or setgid (i.e. run with elevated
privileges). It may also be a vulnerability in other more obscure
situations where a user can exert control over the environment with
which an ncurses binary is run by another user.
FreeBSD 3.x and earlier versions use a very old, customized version of
ncurses which is difficult to update without breaking
backwards-compatibility. The update was made for FreeBSD 4.0, but it
is unlikely that 3.x will be updated. However, the ncurses source is
currently being audited for further vulnerabilities.
III. Impact
Certain setuid/setgid third-party software (including FreeBSD
ports/packages) may be vulnerable to a local exploit yielding
privileged resources, such as network sockets, privileged filesystem
access, or outright privileged shell access (including root access).
No program in the FreeBSD base system is believed to be vulnerable to
the bug.
FreeBSD 4.0 and above are NOT vulnerable to this problem.
IV. Workaround
Remove any setuid or setgid binary which is linked against libmytinfo
(including statically linked), or remove set[ug]id privileges from the
file as appropriate.
The following instructions will identify the binaries installed on the
system which are candidates for removal or removal of file
permissions. Since there may be other as yet undiscovered
vulnerabilities in libmytinfo it may be wise to perform this audit
regardless of whether or not you upgrade your system as described in
section V below. In particular, see the note regarding static linking
in section V.
Of course, it is possible that some of the identified files may be
required for the correct operation of your local system, in which case
there is no clear workaround except for limiting the set of users who
may run the binaries, by an appropriate use of user groups and
removing the "o+x" file permission bit.
1) Download the 'libfind.sh' script from
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:17/libfind.sh
e.g. with the fetch(1) command:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:17/libfind.sh
Receiving libfind.sh (460 bytes): 100%
460 bytes transferred in 0.0 seconds (394.69 Kbytes/s)
#
2) Verify the md5 checksum and compare to the value below:
# /sbin/md5 libfind.sh
MD5 (libfind.sh) = 59dceaa76d6440c58471354a10a8fb0b
3) Run the libfind script against your system:
# sh libfind.sh /
This will scan your entire system for setuid or setgid binaries which
are linked against libmytinfo. Each returned binary should be examined
(e.g. with 'ls -l' and/or other tools) to determine what security risk
it poses to your local environment, e.g. whether it can be run by
arbitrary local users who may be able to exploit it to gain
privileges.
4) Remove the binaries, or reduce their file permissions, as appropriate.
V. Solution
Upgrade your FreeBSD 3.x system to 3.4-STABLE after the correction
date, or patch your present system source code and rebuild. Then run
the libfind script as instructed in section IV and identify any
statically-linked binaries (those reported as "STATIC" by the
libfind script). These should either be removed, recompiled, or have
privileges restricted to secure them against this vulnerability (since
statically-linked binaries will not be affected by recompiling the
shared libmytinfo library).
To patch your present system: save the patch below into a file, and
execute the following commands as root:
cd /usr/src/lib/libmytinfo
patch < /path/to/patch/file
make all
make install
Patches for 3.x systems before the resolution date:
Index: findterm.c
===================================================================
RCS file: /usr/cvs/src/lib/libmytinfo/Attic/findterm.c,v
retrieving revision 1.3
diff -u -r1.3 findterm.c
--- findterm.c 1997/08/13 01:21:36 1.3
+++ findterm.c 2000/04/25 16:58:19
@@ -242,7 +242,7 @@
} else {
s = path->file;
d = buf;
- while(*s != '\0' && *s != ':')
+ while(*s != '\0' && *s != ':' && d - buf < MAX_LINE - 1)
*d++ = *s++;
*d = '\0';
if (_tmatch(buf, name)) {
@@ -259,7 +259,7 @@
} else {
s = path->file;
d = buf;
- while(*s != '\0' && *s != ',')
+ while(*s != '\0' && *s != ',' && d - buf < MAX_LINE - 1)
*d++ = *s++;
*d = '\0';
if (_tmatch(buf, name)) {
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBORc3NFUuHi5z0oilAQGcaAP6Ar4+mNTHR/qXUJ+MFIVy+AQHFDwpYq5f
KgBpCRzgKVZs/zfsQ+LwC1vCHzusftTK0lEd//2pfGZHt3ln0eD1s6qt+Q6+ZJBE
MYYiXvqoBL1ob2Ahts6uEUs/vbMb4bCbEmMCn4ad2iU+neKH9a81Lk3frIaJjAVK
8/6vW7wH9W4=
=NDsR
-----END PGP SIGNATURE-----

111
share/security/advisories/FreeBSD-SA-00:18.gnapster.knapster.asc Normal file
View file

@ -0,0 +1,111 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:18 Security Advisory
FreeBSD, Inc.
Topic: gnapster/knapster ports allows remote users to view local files
Category: ports
Module: gnapster/knapster
Announced: 2000-05-09
Reissued: 2000-05-16
Credits: Fixed by vendor.
Knapster vulnerability pointed out by:
Tom Daniels <daniels@CERIAS.PURDUE.EDU> via BugTraq
Affects: Ports collection.
Corrected: 2000-04-29 (gnapster)
2000-05-01 (knapster)
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
Gnapster and knapster are clients for the Napster file-sharing network.
II. Problem Description
The gnapster port (version 1.3.8 and earlier), and the knapster port
(version 0.9 and earlier) contain a vulnerability which allows remote
napster users to view any file on the local system which is accessible
to the user running gnapster/knapster. Gnapster and knapster do not
run with elevated privileges, so it is only the user's regular
filesystem access permissions which are involved.
Note that there may be further undiscovered bugs in these and other
napster clients leading to a similar vulnerability. System
administrators and users should exercise discretion in installing a
napster client on their system.
The gnapster/knapster ports are not installed by default, nor are they
"part of FreeBSD" as such: they are part of the FreeBSD ports
collection, which contains over 3200 third-party applications in a
ready-to-install format. The ports collection shipped with FreeBSD 4.0
contains this problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can view files accessible to the user running the
gnapster/knapster client.
If you have not chosen to install a napster client, then your system
is not vulnerable to this problem.
IV. Workaround
Deinstall the gnapster and/or knapster port/package, if you you have
installed them.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the gnapster
and/or knapster port.
2) Reinstall a new package dated after the correction date, obtained from:
[gnapster]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/audio/gnapster-1.3.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/audio/gnapster-1.3.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/audio/gnapster-1.3.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/audio/gnapster-1.3.9.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/audio/gnapster-1.3.9.tgz
[knapster]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/audio/knapster-0.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/audio/knapster-0.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/audio/knapster-0.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/audio/knapster-0.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/audio/knapster-0.10.tgz
3) download a new port skeleton for the gnapster/knapster ports from:
http://www.freebsd.org/ports/
and use it to rebuild the port(s).
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-05-09 Initial release
v1.1 2000-05-16 Update to note that knapster 0.9 is also vulnerable and
broaden warning to include all napster clients.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOSMRPVUuHi5z0oilAQHclAP/X+2Xdki6PUEZ/fCHdwZTLEC0kQNenOJ9
oWxWFuI4z3jpylQ3CweIoo9akx32ZzyIVHTViG3mF2BC+NRQShl1aXu2MYqy6vKc
c4R+oHxx2OeYSQo4Q8rS8Ttxa543ynXg9wLBL0vtGMq07GtVYTXpg1+Ooi+QKe2o
9JMpcxAohAQ=
=2iHQ
-----END PGP SIGNATURE-----

373
share/security/advisories/FreeBSD-SA-00:19.semconfig.asc Normal file
View file

@ -0,0 +1,373 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:19 Security Advisory
FreeBSD, Inc.
Topic: local users can prevent all processes from exiting
Category: core
Module: kernel
Announced: 2000-05-23
Credits: Peter Wemm <peter@FreeBSD.org>
Affects: 386BSD-derived OSes, including all versions of FreeBSD,
NetBSD and OpenBSD.
Corrected: 2000-05-01
FreeBSD only: NO
Patch: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:19/semconfig.patch
I. Background
System V IPC is a set of interfaces for providing inter-process
communication, in the form of shared memory segments, message queues
and semaphores. These are managed in user-space by ipcs(1) and
related utilities.
II. Problem Description
An undocumented system call is incorrectly exported from the kernel
without access-control checks. This operation causes the acquisition
in the kernel of a global semaphore which causes all processes on the
system to block during exit() handling, thereby preventing any process
from exiting until the corresponding "unblock" system call is issued.
This operation was intended for use only by ipcs(1) to atomically
sample the state of System V IPC resources on the system (i.e., to
ensure that resources are not allocated or deallocated during the
process of sampling itself).
In the future, this functionality may be reimplemented as a sysctl()
node.
III. Impact
An unprivileged local user can cause every process on the system to
hang during exiting. In other words, after the system call is issued,
no process on the system will be able to exit completely until another
user issues the "unblock" call or the system is rebooted. This is a
denial-of-service attack.
IV. Workaround
None available.
V. Solution
Upgrade to FreeBSD 2.1.7.1-STABLE, 2.2.8-STABLE, 3.4-STABLE,
4.0-STABLE or 5.0-CURRENT after the correction date.
Alternatively, apply the following patch and rebuild the kernel and
the src/usr.bin/ipcs utility. This patch removes the semconfig()
syscall. It has been tested to apply cleanly against 3.4-RELEASE,
3.4-STABLE, 4.0-RELEASE and 4.0-STABLE systems.
1) Save this advisory as a file, and run the following commands as root:
# cd /usr/src
# patch -p < /path/to/advisory
# cd usr.bin/ipcs
# make all install
2) Rebuild and reinstall the kernel and kernel modules as described in
the FreeBSD handbook (see:
http://www.freebsd.org/handbook/kernelconfig.html for more information)
3) Reboot the system
Patches for FreeBSD systems before the resolution date:
--- sys/kern/syscalls.master 2000/01/19 06:01:07 1.72
+++ sys/kern/syscalls.master 2000/05/01 11:15:10 1.72.2.1
@@ -342,7 +342,7 @@
221 STD BSD { int semget(key_t key, int nsems, int semflg); }
222 STD BSD { int semop(int semid, struct sembuf *sops, \
u_int nsops); }
-223 STD BSD { int semconfig(int flag); }
+223 UNIMPL NOHIDE semconfig
224 STD BSD { int msgctl(int msqid, int cmd, \
struct msqid_ds *buf); }
225 STD BSD { int msgget(key_t key, int msgflg); }
--- sys/kern/init_sysent.c 2000/01/19 06:02:29 1.79
+++ sys/kern/init_sysent.c 2000/05/01 11:15:56 1.79.2.1
@@ -243,7 +243,7 @@
{ 4, (sy_call_t *)__semctl }, /* 220 = __semctl */
{ 3, (sy_call_t *)semget }, /* 221 = semget */
{ 3, (sy_call_t *)semop }, /* 222 = semop */
- { 1, (sy_call_t *)semconfig }, /* 223 = semconfig */
+ { 0, (sy_call_t *)nosys }, /* 223 = semconfig */
{ 3, (sy_call_t *)msgctl }, /* 224 = msgctl */
{ 2, (sy_call_t *)msgget }, /* 225 = msgget */
{ 4, (sy_call_t *)msgsnd }, /* 226 = msgsnd */
--- sys/kern/syscalls.c 2000/01/19 06:02:29 1.71
+++ sys/kern/syscalls.c 2000/05/01 11:15:56 1.71.2.1
@@ -230,7 +230,7 @@
"__semctl", /* 220 = __semctl */
"semget", /* 221 = semget */
"semop", /* 222 = semop */
- "semconfig", /* 223 = semconfig */
+ "#223", /* 223 = semconfig */
"msgctl", /* 224 = msgctl */
"msgget", /* 225 = msgget */
"msgsnd", /* 226 = msgsnd */
--- sys/kern/sysv_ipc.c 2000/02/29 22:58:59 1.13
+++ sys/kern/sysv_ipc.c 2000/05/01 11:15:56 1.13.2.1
@@ -107,15 +107,6 @@
semsys(p, uap)
struct proc *p;
struct semsys_args *uap;
-{
- sysv_nosys(p, "SYSVSEM");
- return nosys(p, (struct nosys_args *)uap);
-};
-
-int
-semconfig(p, uap)
- struct proc *p;
- struct semconfig_args *uap;
{
sysv_nosys(p, "SYSVSEM");
return nosys(p, (struct nosys_args *)uap);
--- sys/kern/sysv_sem.c 2000/04/02 08:47:08 1.24.2.1
+++ sys/kern/sysv_sem.c 2000/05/01 11:15:56 1.24.2.2
@@ -26,8 +26,6 @@
int semget __P((struct proc *p, struct semget_args *uap));
struct semop_args;
int semop __P((struct proc *p, struct semop_args *uap));
-struct semconfig_args;
-int semconfig __P((struct proc *p, struct semconfig_args *uap));
#endif
static struct sem_undo *semu_alloc __P((struct proc *p));
@@ -38,7 +36,7 @@
/* XXX casting to (sy_call_t *) is bogus, as usual. */
static sy_call_t *semcalls[] = {
(sy_call_t *)__semctl, (sy_call_t *)semget,
- (sy_call_t *)semop, (sy_call_t *)semconfig
+ (sy_call_t *)semop
};
static int semtot = 0;
@@ -47,8 +45,6 @@
static struct sem_undo *semu_list; /* list of active undo structures */
int *semu; /* undo structure pool */
-static struct proc *semlock_holder = NULL;
-
void
seminit(dummy)
void *dummy;
@@ -87,64 +83,12 @@
} */ *uap;
{
- while (semlock_holder != NULL && semlock_holder != p)
- (void) tsleep((caddr_t)&semlock_holder, (PZERO - 4), "semsys", 0);
-
if (uap->which >= sizeof(semcalls)/sizeof(semcalls[0]))
return (EINVAL);
return ((*semcalls[uap->which])(p, &uap->a2));
}
/*
- * Lock or unlock the entire semaphore facility.
- *
- * This will probably eventually evolve into a general purpose semaphore
- * facility status enquiry mechanism (I don't like the "read /dev/kmem"
- * approach currently taken by ipcs and the amount of info that we want
- * to be able to extract for ipcs is probably beyond what the capability
- * of the getkerninfo facility.
- *
- * At the time that the current version of semconfig was written, ipcs is
- * the only user of the semconfig facility. It uses it to ensure that the
- * semaphore facility data structures remain static while it fishes around
- * in /dev/kmem.
- */
-
-#ifndef _SYS_SYSPROTO_H_
-struct semconfig_args {
- semconfig_ctl_t flag;
-};
-#endif
-
-int
-semconfig(p, uap)
- struct proc *p;
- struct semconfig_args *uap;
-{
- int eval = 0;
-
- switch (uap->flag) {
- case SEM_CONFIG_FREEZE:
- semlock_holder = p;
- break;
-
- case SEM_CONFIG_THAW:
- semlock_holder = NULL;
- wakeup((caddr_t)&semlock_holder);
- break;
-
- default:
- printf("semconfig: unknown flag parameter value (%d) - ignored\n",
- uap->flag);
- eval = EINVAL;
- break;
- }
-
- p->p_retval[0] = 0;
- return(eval);
-}
-
-/*
* Allocate a new sem_undo structure for a process
* (returns ptr to structure or NULL if no more room)
*/
@@ -873,17 +817,6 @@
register struct sem_undo **supptr;
int did_something;
- /*
- * If somebody else is holding the global semaphore facility lock
- * then sleep until it is released.
- */
- while (semlock_holder != NULL && semlock_holder != p) {
-#ifdef SEM_DEBUG
- printf("semaphore facility locked - sleeping ...\n");
-#endif
- (void) tsleep((caddr_t)&semlock_holder, (PZERO - 4), "semext", 0);
- }
-
did_something = 0;
/*
@@ -898,7 +831,7 @@
}
if (suptr == NULL)
- goto unlock;
+ return;
#ifdef SEM_DEBUG
printf("proc @%08x has undo structure with %d entries\n", p,
@@ -955,14 +888,4 @@
#endif
suptr->un_proc = NULL;
*supptr = suptr->un_next;
-
-unlock:
- /*
- * If the exiting process is holding the global semaphore facility
- * lock then release it.
- */
- if (semlock_holder == p) {
- semlock_holder = NULL;
- wakeup((caddr_t)&semlock_holder);
- }
}
--- sys/sys/sem.h 1999/12/29 04:24:46 1.20
+++ sys/sys/sem.h 2000/05/01 11:15:58 1.20.2.1
@@ -163,13 +163,5 @@
* Process sem_undo vectors at proc exit.
*/
void semexit __P((struct proc *p));
-
-/*
- * Parameters to the semconfig system call
- */
-typedef enum {
- SEM_CONFIG_FREEZE, /* Freeze the semaphore facility. */
- SEM_CONFIG_THAW /* Thaw the semaphore facility. */
-} semconfig_ctl_t;
#endif /* _KERNEL */
--- sys/sys/syscall-hide.h 2000/01/19 06:02:31 1.65
+++ sys/sys/syscall-hide.h 2000/05/01 11:15:58 1.65.2.1
@@ -191,7 +191,6 @@
HIDE_BSD(__semctl)
HIDE_BSD(semget)
HIDE_BSD(semop)
-HIDE_BSD(semconfig)
HIDE_BSD(msgctl)
HIDE_BSD(msgget)
HIDE_BSD(msgsnd)
--- sys/sys/syscall.h 2000/01/19 06:02:31 1.69
+++ sys/sys/syscall.h 2000/05/01 11:15:59 1.69.2.1
@@ -196,7 +196,6 @@
#define SYS___semctl 220
#define SYS_semget 221
#define SYS_semop 222
-#define SYS_semconfig 223
#define SYS_msgctl 224
#define SYS_msgget 225
#define SYS_msgsnd 226
--- sys/sys/syscall.mk 2000/01/19 06:07:34 1.23
+++ sys/sys/syscall.mk 2000/05/01 11:15:59 1.23.2.1
@@ -148,7 +148,6 @@
__semctl.o \
semget.o \
semop.o \
- semconfig.o \
msgctl.o \
msgget.o \
msgsnd.o \
--- sys/sys/sysproto.h 2000/01/19 06:02:31 1.59
+++ sys/sys/sysproto.h 2000/05/01 11:16:00 1.59.2.1
@@ -662,9 +662,6 @@
struct sembuf * sops; char sops_[PAD_(struct sembuf *)];
u_int nsops; char nsops_[PAD_(u_int)];
};
-struct semconfig_args {
- int flag; char flag_[PAD_(int)];
-};
struct msgctl_args {
int msqid; char msqid_[PAD_(int)];
int cmd; char cmd_[PAD_(int)];
@@ -1158,7 +1155,6 @@
int __semctl __P((struct proc *, struct __semctl_args *));
int semget __P((struct proc *, struct semget_args *));
int semop __P((struct proc *, struct semop_args *));
-int semconfig __P((struct proc *, struct semconfig_args *));
int msgctl __P((struct proc *, struct msgctl_args *));
int msgget __P((struct proc *, struct msgget_args *));
int msgsnd __P((struct proc *, struct msgsnd_args *));
--- usr.bin/ipcs/ipcs.c 1999/12/29 05:05:32 1.12
+++ usr.bin/ipcs/ipcs.c 2000/05/01 10:51:37 1.12.2.1
@@ -56,7 +56,6 @@
struct shminfo shminfo;
struct shmid_ds *shmsegs;
-int semconfig __P((int,...));
void usage __P((void));
static struct nlist symbols[] = {
@@ -420,11 +419,6 @@
seminfo.semaem);
}
if (display & SEMINFO) {
- if (semconfig(SEM_CONFIG_FREEZE) != 0) {
- perror("semconfig");
- fprintf(stderr,
- "Can't lock semaphore facility - winging it...\n");
- }
kvm_read(kd, symbols[X_SEMA].n_value, &sema, sizeof(sema));
xsema = malloc(sizeof(struct semid_ds) * seminfo.semmni);
kvm_read(kd, (u_long) sema, xsema, sizeof(struct semid_ds) * seminfo.semmni);
@@ -470,8 +464,6 @@
printf("\n");
}
}
-
- (void) semconfig(SEM_CONFIG_THAW);
printf("\n");
}
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOSpSolUuHi5z0oilAQH+jgP9HxVwbtFPUs9E3CuoeKb6rdDM6GRZUqgt
WpXRSpGkAjQmGNZl/33DN7gt0HnjIvl4lZCHhSVKrl4vg4URU+MQJKEudmdm7/v/
G6nH33ytuXtjC1/tMGquuHLnzhaaaDmYJErPtHgyWPbuN9JTTlvaqQjtJ6IsyBPU
27eN3Py107o=
=bah2
-----END PGP SIGNATURE-----

98
share/security/advisories/FreeBSD-SA-00:20.krb5.asc Normal file
View file

@ -0,0 +1,98 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:20 Security Advisory
FreeBSD, Inc.
Topic: krb5 port contains remote and local root exploits.
Category: ports
Module: krb5
Announced: 2000-05-26
Credits: Jeffrey I. Schiller <jis@MIT.EDU>
Affects: Ports collection prior to the correction date
Corrected: 2000-05-17
Vendor status: Patch released
FreeBSD only: NO
I. Background
MIT Kerberos 5 is an implementation of the Kerberos 5 protocol which
is available in the FreeBSD ports collection as the security/krb5
port. FreeBSD also includes separately-developed Kerberos 4 and 5
implementations from KTH, which are optionally installed as part of
the base system (KTH Heimdal, the Kerberos 5 implementation, is
currently considered "experimental" software).
II. Problem Description
The MIT Kerberos 5 port, versions 1.1.1 and earlier, contains several
remote and local buffer overflows which can lead to root compromise.
Note that the implementations of Kerberos shipped in the FreeBSD base
system are separately-developed software to MIT Kerberos and are
believed not to be vulnerable to these problems.
However, a very old release of FreeBSD dating from 1997 (FreeBSD
2.2.5) did ship with a closely MIT-derived Kerberos implementation
("eBones") and may be vulnerable to attacks of the kind described
here. Any users still using FreeBSD 2.2.5 and who have installed the
optional Kerberos distribution are urged to upgrade to 2.2.8-STABLE or
later. Note however that FreeBSD 2.x is no longer an officially
supported version, nor are security fixes always provided.
The krb5 port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
nearly 3300 third-party applications in a ready-to-install format. The
ports collection shipped with FreeBSD 4.0 contains this problem since
it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local or remote users can obtain root access on the system running krb5.
If you have not chosen to install the krb5 port, then your system is
not vulnerable to this problem.
IV. Workaround
Due to the nature of the vulnerability there are several programs and
network services which are affected. If recompiling the port is not
practical, please see the MIT Kerberos advisory for suggested
workarounds (including the disabling or adjustment of services and
removal of setuid permissions on vulnerable binaries). The advisory
can be found at the following location:
http://web.mit.edu/kerberos/www/advisories/krb4buf.txt
V. Solution
1) Upgrade your entire ports collection and rebuild the krb5 port. A
package is not provided for this port for export control reasons.
2) download a new port skeleton for the krb5 port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
3) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOS626lUuHi5z0oilAQHUWAP+LqSso3fDe+k7/6EJMc5iH9JgbrD2JARh
mQOV6m9qUgZbcaEc9oUrsEJIurFGGukCAbGA82dPHGWpNFzbzL3pXgqcswVvHIqV
qoZuzLyLV5+1NaurwovmXD2hQH56Cgaa+N4byxuxs+cnIbfJNF8DEYjhnPqVHc9l
sP0RelxSDuk=
=yPXe
-----END PGP SIGNATURE-----

109
share/security/advisories/FreeBSD-SA-00:21.ssh.asc Normal file
View file

@ -0,0 +1,109 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:21 Security Advisory
FreeBSD, Inc.
Topic: ssh port listens on extra network port [REVISED]
Category: ports
Module: ssh
Announced: 2000-06-07
Credits: Jan Koum <jkb@best.com>
Affects: Ports collection.
Corrected: 2000-04-21
FreeBSD only: Yes
I. Background
SSH is an implementation of the Secure Shell protocol for providing
encrypted and authenticated communication between networked machines.
II. Problem Description
A patch added to the FreeBSD SSH port on 2000-01-14 incorrectly
configured the SSH daemon to listen on an additional network port,
722, in addition to the usual port 22. This change was made as part of
a patch to allow the SSH server to listen on multiple ports, but the
option was incorrectly enabled by default.
This may cause a violation of security policy if the additional port
is not subjected to the same access-controls (e.g. firewallling) as
the standard SSH port.
Note this is not a vulnerability associated with the SSH software
itself, and it is not likely to be a risk for the majority of
installations, since a remote user must still have valid SSH
credentials in order to access the SSH server on the alternate
port. The risk is that users may be able to access the SSH server from
IP addresses which are prohibited to connect to the standard port.
The ssh port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 3300 third-party applications in a ready-to-install format. The
ports collection shipped with FreeBSD 4.0 contains this problem since
it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
FreeBSD 4.0 ships with OpenSSH, a free implementation of the SSH
protocol, included within the base system. OpenSSH does not suffer
from this misconfiguration.
III. Impact
Remote users with valid SSH credentials may access the ssh server on a
non-standard port, potentially bypassing IP address access controls on
the standard SSH port.
If you have not chosen to install the ssh port/package, or installed
it prior to 2000-01-14 or after 2000-04-21, then your system is not
vulnerable to this problem.
IV. Workaround
One of the following:
1) Comment out the line "Port 722" in /usr/local/etc/sshd_config and
restart sshd
2) Add filtering rules to your perimeter firewall, or on the local
machine (using ipfw or ipf) to limit connections to port 722.
3) Deinstall the ssh port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the ssh port.
2) download a new port skeleton for the ssh port from:
http://www.freebsd.org/ports/
and use it to rebuild the port. Note that packages are not provided
for the ssh port.
3) Use the portcheckout utility to automate option (2) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-06-07 Initial release
v1.1 2000-06-07 Corrected typo in name of sshd config file
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOT7lF1UuHi5z0oilAQHLaQP+LyCyEfrzDh63awRl8swXzHLpYib1upd+
nUbctw+HOc7GfWGCUFfzhTUWvuwjqx43reE1XSX5ETXm4nVKwMDCum35FomlrUB+
3LQeXHgsogeTmGzNoWqaJBhvC7ffMBWZrW4JFokasyWbOgJhhWiklBRVojkale0Y
e+CNOgK3f3U=
=no4A
-----END PGP SIGNATURE-----

89
share/security/advisories/FreeBSD-SA-00:22.apsfilter.asc Normal file
View file

@ -0,0 +1,89 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:22 Security Advisory
FreeBSD, Inc.
Topic: apsfilter allows users to execute arbitrary commands as
user lpd
Category: ports
Module: apsfilter
Announced: 2000-06-07
Credits: Fixed by vendor.
Affects: Ports collection.
Corrected: 2000-04-29
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
apsfilter is a print filter which automatically handles the conversion
of various types of file into a format understood by the printer.
II. Problem Description
The apsfilter port, versions 5.4.1 and below, contain a vulnerability
which allow local users to execute arbitrary commands as the user
running lpd, user root in a default FreeBSD installation. The
apsfilter software allows users to specify their own filter
configurations, which are read in an insecure manner and may be used
to elevate privileges.
The apsfilter port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3300 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users can cause arbitrary commands to be executed as root.
If you have not chosen to install the apsfilter port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the apsfilter port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the apsfilter port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/print/apsfilter-5.4.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/print/apsfilter-5.4.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/print/apsfilter-5.4.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/print/apsfilter-5.4.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/print/apsfilter-5.4.2.tgz
3) download a new port skeleton for the apsfilter port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOT7YnFUuHi5z0oilAQExcgP/T7U8rtKfUE6sn3QiLrhVueX/h06gvUtp
aSwqtd4EVS8FMbnMARs+TAcrLUVQBaHf7RA0LtIHhD441HNUmC0mbtL0GJQr1tI4
3H5tfqav7y3C0PiLe+4yy4HPjhOcZtOneldIf76hU+HiaCwWo6uBvv7ue3z1IIJQ
o6BuABiKzE0=
=S7V8
-----END PGP SIGNATURE-----

172
share/security/advisories/FreeBSD-SA-00:23.ip-options.asc Normal file
View file

@ -0,0 +1,172 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:23 Security Advisory
FreeBSD, Inc.
Topic: Remote denial-of-service in IP stack [REVISED]
Category: core
Module: kernel
Announced: 2000-06-19
Revised: 2000-07-11
Affects: FreeBSD systems prior to the correction date
Credits: NetBSD Security Advisory 2000-002, and
Jun-ichiro itojun Hagino <itojun@kame.net>
Corrected: (Several bugs fixed, the date below is that of the most
recent fix)
2000-06-08 (3.4-STABLE)
2000-06-08 (4.0-STABLE)
2000-06-02 (5.0-CURRENT)
FreeBSD only: NO
I. Background
II. Problem Description
There are several bugs in the processing of IP options in the FreeBSD
IP stack, which fail to correctly bounds-check arguments and contain
other coding errors leading to the possibility of data corruption and
a kernel panic upon reception of certain invalid IP packets.
This set of bugs includes the instance of the vulnerability described
in NetBSD Security Advisory 2000-002 (see
ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/advisories/NetBSD-SA2000-002.txt.asc)
as well as other bugs with similar effect.
III. Impact
Remote users can cause a FreeBSD system to panic and reboot.
IV. Workaround
Incoming packets containing IP Options can be blocked at a perimeter
firewall or on the local system, using ipfw(8) (ipf(8) is also capable
of blocking packets with IP Options, but is not described here).
The following ipfw rules are believed to prevent the denial-of-service
attack (replace the rule numbers '100'-'103' with whichever rule
numbers are appropriate for your local firewall, if you are already
using ipfw):
ipfw add 100 deny log ip from any to any ipopt rr
ipfw add 101 deny log ip from any to any ipopt ts
ipfw add 102 deny log ip from any to any ipopt ssrr
ipfw add 103 deny log ip from any to any ipopt lsrr
Note that there are legitimate uses for IP options, although they are
no believed to be in common use, and blocking them should not cause
any problems. Therefore the log entries generated by these ipfw rules
will not necessarily be evidence of an attempted attack. Furthermore,
the packets may be spoofed and have falsified source addresses.
V. Solution
One of the following:
1) Upgrade your FreeBSD system to 3.4-STABLE, 4.0-STABLE or
5.0-CURRENT after the respective correction dates.
2) Apply the patch below and recompile your kernel.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:23/ip_options.diff
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:23/ip_options.diff.asc
# cd /usr/src/sys/netinet
# patch -p < /path/to/patch_or_advisory
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
VI. Revision History
v1.0 2000-06-19 Initial release
v1.1 2000-07-11 Note workaround using ipfw.
Index: ip_icmp.c
===================================================================
RCS file: /ncvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.39
diff -u -r1.39 ip_icmp.c
--- ip_icmp.c 2000/01/28 06:13:09 1.39
+++ ip_icmp.c 2000/06/08 15:26:39
@@ -662,8 +662,11 @@
if (opt == IPOPT_NOP)
len = 1;
else {
+ if (cnt < IPOPT_OLEN + sizeof(*cp))
+ break;
len = cp[IPOPT_OLEN];
- if (len <= 0 || len > cnt)
+ if (len < IPOPT_OLEN + sizeof(*cp) ||
+ len > cnt)
break;
}
/*
Index: ip_input.c
===================================================================
RCS file: /ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.130
diff -u -r1.130 ip_input.c
--- ip_input.c 2000/02/23 20:11:57 1.130
+++ ip_input.c 2000/06/08 15:25:46
@@ -1067,8 +1067,12 @@
if (opt == IPOPT_NOP)
optlen = 1;
else {
+ if (cnt < IPOPT_OLEN + sizeof(*cp)) {
+ code = &cp[IPOPT_OLEN] - (u_char *)ip;
+ goto bad;
+ }
optlen = cp[IPOPT_OLEN];
- if (optlen <= 0 || optlen > cnt) {
+ if (optlen < IPOPT_OLEN + sizeof(*cp) || optlen > cnt) {
code = &cp[IPOPT_OLEN] - (u_char *)ip;
goto bad;
}
@@ -1174,6 +1178,10 @@
break;
case IPOPT_RR:
+ if (optlen < IPOPT_OFFSET + sizeof(*cp)) {
+ code = &cp[IPOPT_OFFSET] - (u_char *)ip;
+ goto bad;
+ }
if ((off = cp[IPOPT_OFFSET]) < IPOPT_MINOFF) {
code = &cp[IPOPT_OFFSET] - (u_char *)ip;
goto bad;
Index: ip_output.c
===================================================================
RCS file: /ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.99
diff -u -r1.99 ip_output.c
--- ip_output.c 2000/03/09 14:57:15 1.99
+++ ip_output.c 2000/06/08 15:27:08
@@ -1302,8 +1302,10 @@
if (opt == IPOPT_NOP)
optlen = 1;
else {
+ if (cnt < IPOPT_OLEN + sizeof(*cp))
+ goto bad;
optlen = cp[IPOPT_OLEN];
- if (optlen <= IPOPT_OLEN || optlen > cnt)
+ if (optlen < IPOPT_OLEN + sizeof(*cp) || optlen > cnt)
goto bad;
}
switch (opt) {
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWuYHFUuHi5z0oilAQEp+wP/bK5jRQXK/d3sQw9cph/usAbiYUD6Ux3l
MIo1R1ZPWnIE20Hx334hvr3u5AUnbtjkFg+86WZcpv5bgWjKS2VLyV4UjJIMMOQr
sSDXta5X4XRO0aXv1Td/Jlkoh2UcoayhKssYa3LLwgcYq++BBGrwbJM+ShUGmllS
qQ86FwHKdow=
=5Ksz
-----END PGP SIGNATURE-----

142
share/security/advisories/FreeBSD-SA-00:24.libedit.asc Normal file
View file

@ -0,0 +1,142 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:24 Security Advisory
FreeBSD, Inc.
Topic: libedit reads config file from current directory
Category: core
Module: libedit
Announced: 2000-07-05
Affects: All versions of FreeBSD prior to the correction date
Credits: Tim Vanderhoek <hoek@FreeBSD.org>
Vendor status: Notified
Corrected: 2000-05-22
FreeBSD only: NO
I. Background
libedit is a library of routines for providing command editing and
history retrieval for interactive command-oriented programs.
II. Problem Description
libedit incorrectly reads an ".editrc" file in the current directory
if it exists, in order to specify configurable program
behaviour. However it does not check for ownership of the file, so an
attacker can cause a libedit application to execute arbitrary key
rebindings and exercise terminal capabilities by creating an .editrc
file in a directory from which another user executes a libedit binary
(e.g. root running ftp(1) from /tmp). This can be used to fool the
user into unknowingly executing program commands which may compromise
system security. For example, ftp(1) includes the ability to escape to
a shell and execute a command, which can be done under libedit
control.
The supplied patch removes this behaviour and causes libedit to only
search for its configuration file in the home directory of the user,
if it exists and the binary is not running with increased privileges
(i.e. setuid or setgid).
FreeBSD 3.5-RELEASE is not affected by this vulnerability, although
4.0-RELEASE is affected since the problem was discovered after it was
released.
III. Impact
An attacker can cause a user to execute arbitrary commands within a
program which is run from a directory to which the attacker has write
access, potentially leading to system compromise if run as a
privileged user (such as root).
IV. Workaround
Do not interactively run utilities which link against libedit from
directories which can be written to by other users.
To identify utilities which link dynamically against libedit, download
the libfind tool and detached PGP signature as follows:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:24/libfind.sh
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:24/libfind.sh.asc
Verify the detached signature using your PGP utility.
Run the libfind.sh tool as root, as follows:
# sh libfind.sh libedit /
Note that it is not feasible to locate utilities which link statically
against libedit since there are no common strings embedded in such
binaries. However the following is believed to be a complete list of
statically and dynamically linked FreeBSD system utilities which link
against the library:
/bin/sh
/sbin/fsdb
/usr/bin/ftp
/usr/sbin/cdcontrol
/usr/sbin/lpc
/usr/sbin/nslookup
/usr/sbin/pppctl
Because libedit is not a portable library in common use there are
unlikely to be many FreeBSD ports which link statically against it: no
such ports are known at this time.
V. Solution
One of the following:
1) Upgrade your vulnerable system to a version dated after the
correction date.
2) Save the advisory into a file or download the patch and detached
PGP signature:
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:24/libedit.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:24/libedit.patch.asc
Verify the detached PGP signature using your PGP utility.
Apply the patch and rebuild as follows:
# cd /usr/src/lib/libedit
# patch -p < /path/to/patch/or/advisory
and rebuild your system as described in
http://www.freebsd.org/handbook/makeworld.html
--- el.c 1999/08/20 01:17:12 1.6
+++ el.c 2000/05/22 05:55:22 1.7
@@ -290,13 +294,10 @@
char *ptr, path[MAXPATHLEN];
if (fname == NULL) {
- fname = &elpath[1];
- if ((fp = fopen(fname, "r")) == NULL) {
- if (issetugid() != 0 || (ptr = getenv("HOME")) == NULL)
- return -1;
- (void)snprintf(path, sizeof(path), "%s%s", ptr, elpath);
- fname = path;
- }
+ if (issetugid() != 0 || (ptr = getenv("HOME")) == NULL)
+ return -1;
+ (void) snprintf(path, sizeof(path), "%s%s", ptr, elpath);
+ fname = path;
}
if ((fp = fopen(fname, "r")) == NULL)
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWGmz1UuHi5z0oilAQF1rwP/QhuVAAmc1873YHkhTS8kMTPR63HoIlkc
8VRgf0PU6Z3AObVq6fjt3ZikCUXf7d8NhiTqRdL1Cb/Koai56yP+E5Fqbt2U5JCC
cNbWIlI8NYKxAybgOsx+9EJGSnGfrjjjvxG6MguwcyJ+W1DS3M41mDzv8C1hdpqw
/QAi9qToH+Q=
=TlZc
-----END PGP SIGNATURE-----

134
share/security/advisories/FreeBSD-SA-00:25.alpha-random.asc Normal file
View file

@ -0,0 +1,134 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:25 Security Advisory
FreeBSD, Inc.
Topic: FreeBSD/Alpha platform lacks kernel pseudo-random number
generator, some applications fail to detect this.
Category: core
Module: kernel
Announced: 2000-06-12
Affects: FreeBSD/Alpha prior to the correction date.
Corrected: 2000-05-10 (4.0-STABLE)
2000-04-28 (5.0-CURRENT)
FreeBSD only: Yes
I. Background
The FreeBSD kernel provides a cryptographic-strength pseudo-random
number generator via the /dev/random and /dev/urandom interfaces,
which samples hardware measurements to provide a high-quality source
of "entropy" (randomness).
II. Problem Description
The FreeBSD port to the Alpha platform did not provide the /dev/random
or /dev/urandom devices - this was an oversight during the development
process which was not corrected before the Alpha port "became
mainstream". FreeBSD/i386 is not affected.
As a consequence, there is no way for Alpha systems prior to the
correction date to obtain cryptographic-strength random numbers,
unless an application "rolls its own" entropy gathering
mechanism. This in itself is not a vulnerability, although it is an
omission and a departure from the expected behaviour of a FreeBSD
system.
The actual vulnerability is that some applications fail to correctly
check for a working /dev/random and do not exit with an error if it is
not available, so this weakness goes undetected. OpenSSL 0.9.4, and
utilities based on it, including OpenSSH (both of which are included
in the base FreeBSD 4.0 system) are affected in this manner (this bug
was corrected in OpenSSL 0.9.5)
Therefore, cryptographic security systems on vulnerable FreeBSD/Alpha
systems (including OpenSSH in the base FreeBSD 4.0 system) may have
weakened strength, and cryptographic keys generated on such systems
should not be trusted.
III. Impact
Cryptographic secrets (such as OpenSSH public/private keys) generated
on FreeBSD/Alpha systems may be much weaker than their "advertised"
strength, and may lead to data compromise to a dedicated and
knowledgeable attacker.
PGP/GnuPG keys, and keys generated by the SSH or SSH2 ports, are not
believed to be weakened since that software will correctly detect the
lack of a working /dev/random and use alternative sources of
entropy. OpenSSH and OpenSSL are currently the only known vulnerable
applications.
IV. Workaround
None available.
V. Solution
One of the following three options, followed by step 2).
1a) Upgrade your FreeBSD/Alpha system to FreeBSD 4.0-STABLE after the
correction date.
1b) install the patched 4.0-RELEASE GENERIC kernel available from:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:25/kernel.gz
e.g. perform the following steps as root:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:25/kernel.gz
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:25/kernel.gz.asc
[ Verify the detached PGP signature using your PGP utility - consult your
utility's documentation for how to do this ]
# gunzip kernel.gz
# cp /kernel /kernel.old
# chflags noschg /kernel
# cp kernel /kernel
# chflags schg /kernel
1c) Download the kernel source patch and rebuild your FreeBSD/Alpha
kernel, as follows:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:25/kernel.sys.diff
Download the detached PGP signature:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:25/kernel.sys.diff.asc
and verify the signature using your PGP utility.
Apply the patch:
# cd /usr/src
# patch -p < /path/to/kernel.sys.diff
Rebuild your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html
and reboot with the new kernel.
NOTE: Because of the significant improvements to the FreeBSD/Alpha
platform in FreeBSD 4.0, it is not planned at this time to backport
the necessary changes to FreeBSD 3.4-STABLE.
2) Immediately regenerate all OpenSSH-generated SSH keys and
OpenSSL-generated SSL certificates, and any other data relying on
cryptographic random numbers which were generated on FreeBSD/Alpha
systems, whose strength cannot be verified. [Note: for most systems,
the only significant vulnerability is likely to be from OpenSSH and
OpenSSL-generated keys and certificates (e.g. for SSL webservers)]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOUVa6lUuHi5z0oilAQG/VQP/bXSr0YdjwTVuHrc1JOTzKMqSJYyff50d
6Jg7VNL+X2B7hQcWUC8Rn/m+qy6byc9g51v8Wyk70olUs1Fy4bTGh+iEpE0mbQ45
tx75z/Uhq46fYP3ldBx9XvXJQxRHXrPos7gfTOVVdJcchIIgJdtxC7LfvOswbnvY
EK+rxB2I9f8=
=ee12
-----END PGP SIGNATURE-----

105
share/security/advisories/FreeBSD-SA-00:26.popper.asc Normal file
View file

@ -0,0 +1,105 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:26 Security Advisory
FreeBSD, Inc.
Topic: popper port contains remote vulnerability [REVISED]
Category: ports
Module: popper
Announced: 2000-07-05
Revised: 2000-07-11
Credits: Prizm <prizm@RESENTMENT.ORG>
Affects: Ports collection.
Corrected: 2000-05-25
Vendor status: Notified
FreeBSD only: NO
I. Background
QPopper is a popular POP3 mail server.
II. Problem Description
The qpopper port, version 2.53 and earlier, incorrectly parses string
formatting operators included in part of the email message header. A
remote attacker can send a malicious email message to a local user
which can cause arbitrary code to be executed on the server when a POP
client retrieves the message using the UIDL command. The code is
executed as the user who is retrieving mail: thus if root reads email
via POP3 this can lead to a root compromise. This vulnerability is
not present in qpopper-3.0.2, also available in FreeBSD ports.
The qpopper port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3500 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release, but it was fixed in
time for FreeBSD 3.5.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can cause arbitrary code to be executed as the retrieving
user when a POP client retrieves email.
If you have not chosen to install the qpopper-2.53 port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the qpopper-2.53 port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the qpopper port,
or upgrade to qpopper-3.0.2 available in /usr/ports/mail/popper3.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/qpopper-2.53.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/qpopper-2.53.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/qpopper-2.53.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/qpopper-2.53.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/qpopper-2.53.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/qpopper3-3.0.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/qpopper3-3.0.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/qpopper3-3.0.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/qpopper3-3.0.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/qpopper3-3.0.2.tgz
3) download a new port skeleton for the qpopper port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-07-05 Initial release
v1.1 2000-07-11 Correct URL of qpopper-2.53 package and note availability of
qpopper3-3.0.2. Update size of ports collection.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWuXjlUuHi5z0oilAQGviQP/TQqQXqwU0TBkJbvdtuLLXZdcjywbX39p
O5EgHOjsHxnLkfOCYXJ+wQ+2s88OZouFhsR4OcTJDC8UobgVlKicOOEShov6IkrN
rwJfkc7fgxuLVOW8Y3ef3gixqhCkCsgMI5NlvKt88YThr1y0Z8GnK5u9gxz1YUKA
M9iveHnUsSU=
=5bHQ
-----END PGP SIGNATURE-----

110
share/security/advisories/FreeBSD-SA-00:27.XFree86-4.asc Normal file
View file

@ -0,0 +1,110 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:27 Security Advisory
FreeBSD, Inc.
Topic: XFree86-4.0 port contains local root overflow
Category: ports
Module: Xfree86-4
Announced: 2000-07-05
Credits: Michal Zalewski <lcamtuf@TPI.PL>
Affects: Ports collection.
Corrected: 2000-06-09
Vendor status: Vendor eventually released patch
FreeBSD only: NO
I. Background
XFree86 4.0 is a development version of the popular XFree86 X Windows
system.
II. Problem Description
XFree86 4.0 contains a local root vulnerability in the XFree86 server
binary, due to incorrect bounds checking of command-line
arguments.
The server binary is setuid root, in contrast to previous versions
which had a small setuid wrapper which performed (among other things)
argument sanitizing.
The XFree86-4 port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3400 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 4.0 contains this
problem since it was discovered after the release, but it was fixed in
time for FreeBSD 3.5.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged local users can obtain root access.
If you have not chosen to install the XFree86-4 port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the XFree86-4 port/package, if you you have installed it, or
limit the execution file permissions on the /usr/X11R6/bin/XFree86
binary so that only members of a trusted group may run the binary.
V. Solution
At this time, we do not recommend using XFree86 4.0 on multi-user
systems with untrusted users, because of the lack of security in the
server binary. The current "stable" version, XFree86 3.3.6, is also
available in FreeBSD ports.
One of the following:
1) Upgrade your entire ports collection and rebuild the XFree86-4 port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/x11/XFree86-4.0.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/x11/XFree86-4.0.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/x11/XFree86-4.0.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/x11/XFree86-4.0.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/x11/XFree86-4.0.tar.gz
An updated version of XFree86, version 4.0.1, has just been released,
which is believed to also fix the problems detailed in this advisory,
however the X server is still installed setuid root and so the above
warning against installation on multi-user machines still applies. The
packages will be available at the following locations in the next few
days:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/x11/XFree86-4.0.1.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/x11/XFree86-4.0.1.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/x11/XFree86-4.0.1.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/x11/XFree86-4.0.1.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/x11/XFree86-4.0.1.tar.gz
3) download a new port skeleton for the XFree86-4 port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWGrplUuHi5z0oilAQFDjgP9E3l6VG7ic+F0HMDsSDGbsYrIFM3hvBDJ
hu22Vu/F18PyeOVrgZY4ljE/BvdSy4bJMJSDJsrP4jYicse7ArwvSLEJOjoIuPoK
ErUCz34UgNAWs+zszFD0V5xAuWH3Oyii4qamqDnSaurYl6oKp5tPNx2vSrA3UDxM
moK703Mpfak=
=nu3f
-----END PGP SIGNATURE-----

76
share/security/advisories/FreeBSD-SA-00:28.majordomo.asc Normal file
View file

@ -0,0 +1,76 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:28 Security Advisory
FreeBSD, Inc.
Topic: majordomo is not safe to run on multi-user machines
Category: ports
Module: majordomo
Announced: 2000-07-05
Affects: Ports collection.
Corrected: See below
Vendor status: Problem documented
FreeBSD only: NO
I. Background
Majordomo is a popular mailing-list manager.
II. Problem Description
Majordomo contains a number of perl scripts which are executed by a
setuid wrapper for providing mailing-list management
functionality. However there are numerous weaknesses in these scripts
which allow unprivileged users to run arbitrary commands as the
majordomo user, as well as obtaining read and write access to the
mailing list data.
The majordomo port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3400 third-party applications in a ready-to-install
format.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged local users can run commands as the 'majordomo' user,
including accessing and modifying mailing-list subscription data.
If you have not chosen to install the majordomo port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the majordomo port/package, if you you have installed it, or
limit the permissions of the majordomo/ directory and/or its contents
appropriately (see below).
V. Solution
Since the vendor has chosen not to fix the various security holes in
the default installation of majordomo, there is no simple solution. It
may be possible to adequately secure the majordomo installation while
retaining required functionality, by tightening the permissions on the
/usr/local/majordomo directory and/or its contents, but these actions
are not taken by the FreeBSD port and are beyond the scope of this
advisory.
Instead we recommend that majordomo not be used on a system which
contains untrusted users, or an alternative mailing-list manager be
used. There are several such utilities in the FreeBSD ports
collection.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWGsGFUuHi5z0oilAQFUtgP9Gwb/h0AFJB8RH9LkE3zlmaTfePGGnIgk
/SBux8RBiwPnEw4M25mZt26eV6Bd/MIdN8Gnb7q551TD8nrZu0N6//vi5w8uM5/l
itRXtnE4FfqERWOTOt25b8N0kCtqESqGMPMyA1m1x+7wFHpq1B69gsQl8MbohUr5
NlLkkEu6AQI=
=EkWc
-----END PGP SIGNATURE-----

99
share/security/advisories/FreeBSD-SA-00:29.wu-ftpd.asc Normal file
View file

@ -0,0 +1,99 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:29 Security Advisory
FreeBSD, Inc.
Topic: wu-ftpd port contains remote root compromise [REVISED]
Category: ports
Module: wu-ftpd
Announced: 2000-07-05
Revised: 2000-07-11
Credits: tf8 <tf8@ZOLO.FREELSD.NET>
Affects: Ports collection.
Corrected: 2000-06-24
Vendor status: Contacted
FreeBSD only: NO
I. Background
wu-ftpd is a popular FTP server.
II. Problem Description
The wu-ftpd port, versions 2.6.0 and below, contains a vulnerability
which allows FTP users, both anonymous FTP users and those with a
valid account, to execute arbitrary code as root on the local machine,
by inserting string-formatting operators into command input, which are
incorrectly parsed by the FTP server.
The wu-ftpd port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3500 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5 and 4.0
contains this problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
FTP users, including anonymous FTP users, can cause arbitrary commands
to be executed as root on the local machine.
If you have not chosen to install the wu-ftpd port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the wu-ftpd port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the wu-ftpd port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ftp/wu-ftpd-2.6.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ftp/wu-ftpd-2.6.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/ftp/wu-ftpd-2.6.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/ftp/wu-ftpd-2.6.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/ftp/wu-ftpd-2.6.0.tgz
NOTE: It may be several days before updated packages are available. Be
sure to check the file creation date on the package, because the
version number of the software has not changed.
3) download a new port skeleton for the wu-ftpd port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-07-05 Initial release
v1.1 2000-07-11 Clarify that vulnerability affects all FTP users, not
just anonymous FTP. Correct URL of package. Update
size of ports collection.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWuZzVUuHi5z0oilAQH+bgQAhpYzJ0xiU787xQFr/YnOJHe0k/CJiDOU
yrfyvGq4Grl4F/czojsyRTd5DwQzBKqIYm1H/z73gxI6nbEe0KaP+omfpzaAy7iK
pLyQJ5qbjQLuc54ed+gV1+lH84QkuMHzUygj5iqvjn91uAA5nMKEMnGbESZz3J4J
NjYmA1EfXbI=
=T7IG
-----END PGP SIGNATURE-----

141
share/security/advisories/FreeBSD-SA-00:30.openssh.asc Normal file
View file

@ -0,0 +1,141 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:30 Security Advisory
FreeBSD, Inc.
Topic: OpenSSH UseLogin directive permits remote root access
Category: core
Module: openssh
Announced: 2000-07-05
Credits: Markus Friedl <markus@OpenBSD.org>
Affects: FreeBSD 4.0-RELEASE, FreeBSD 4.0-STABLE and 5.0-CURRENT
prior to the correction date
Corrected: 2000-06-11
Vendor status: Disclosed vulnerability.
FreeBSD only: NO
I. Background
OpenSSH is an implementation of the SSH1 (and SSH2 in later versions)
secure shell protocols for providing encrypted and authenticated
network access, which is available free for unrestricted use.
II. Problem Description
The sshd server is typically invoked as root so it can manage general
user logins. OpenSSH has a configuration option, not enabled by
default ("UseLogin") which specifies that user logins should be done
via the /usr/bin/login command instead of handled internally.
OpenSSH also has a facility to enable remote users to execute commands
on the server non-interactively. In this case, the UseLogin directive
fails to correctly drop root privileges before executing the command,
meaning that remote users without root access can execute commands on
the local system as root.
Note that with the default configuration, OpenSSH is not vulnerable to
this problem, and this option is not needed for the vast majority of
systems.
OpenSSH is installed if you chose to install the 'crypto' distribution
at install-time or when compiling from source, and you either have the
international RSA libraries or installed the RSAREF port.
III. Impact
If your sshd configuration was modified to enable the 'UseLogin'
directive then remote users with SSH access to the local machine can
execute arbitrary commands as root.
IV. Workaround
Set 'UseLogin No' in your /etc/ssh/sshd_config file and restart the
SSH server by issuing the following command as root:
# kill -HUP `cat /var/run/sshd.pid`
This will cause the parent process to respawn and reread its
configuration file, and should not interfere with existing SSH sessions.
Note that a bug in sshd (discovered during preparation of this
advisory, fixed in FreeBSD 5.0-CURRENT and 4.0-STABLE as of
2000-07-03) means that it will fail to restart correctly unless it was
originally invoked with an absolute path (i.e. "/usr/sbin/sshd"
instead of "sshd"). Therefore you should verify that the server is
still running after you deliver the HUP signal:
# ps -p `cat /var/run/sshd.pid`
PID TT STAT TIME COMMAND
2110 ?? Ss 0:00.97 /usr/sbin/sshd
If the server is no longer running, restart it by issuing the
following command as root:
# /usr/sbin/sshd
V. Solution
One of the following:
1) Upgrade to FreeBSD 4.0-STABLE or 5.0-CURRENT after the correction
date. Note that these versions of FreeBSD contain a newer version of
OpenSSH than was in 4.0-RELEASE, version 2.1, which provides enhanced
functionality including support for the SSH2 protocol and DSA keys.
2) Save this advisory as a file and extract the relevant patch for
your version of FreeBSD, or download the relevant patch and detached
PGP signature from the following location:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:30/sshd.patch
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:30/sshd.patch.asc
Verify the detached signature using your PGP utility.
Issue the following commands as root:
# cd /usr/src/crypto/openssh
# patch -p < /path/to/patch/or/advisory
# cd /usr/src/secure/lib/libssh
# make all
# cd /usr/src/secure/usr.sbin/sshd
# make all install
# kill -HUP `cat /var/run/sshd.pid`
See the note in the "Workarounds" section about verifying that the
sshd server is still running.
VI. Patch
Index: sshd.c
===================================================================
RCS file: /home/ncvs/src/crypto/openssh/sshd.c,v
retrieving revision 1.6
diff -u -r1.6 sshd.c
--- sshd.c 2000/03/09 14:52:31 1.6
+++ sshd.c 2000/07/04 03:40:46
@@ -2564,7 +2564,13 @@
char *argv[10];
#ifdef LOGIN_CAP
login_cap_t *lc;
+#endif
+ /* login(1) is only called if we execute the login shell */
+ if (options.use_login && command != NULL)
+ options.use_login = 0;
+
+#ifdef LOGIN_CAP
lc = login_getpwclass(pw);
if (lc == NULL)
lc = login_getclassbyname(NULL, pw);
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWPAn1UuHi5z0oilAQEt8QP+KlhsdMVqBjI6mhO/opnpIr+vFo5zxu4R
rhPwSfyXf/ufRPcJbiQFjBlHwQWaOnt2N3w6MJYI4qNySPHmqIa1Cnxv8Em0K/ke
wdFr8sXOZiqgBbu1aJRSsB+5Vc/TQFdHcY/QGwpUIUGYkDvEYcp46iDpQgiS41BW
9hRgZIgcigo=
=nEJ0
-----END PGP SIGNATURE-----

116
share/security/advisories/FreeBSD-SA-00:31.canna.asc Normal file
View file

@ -0,0 +1,116 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:31 Security Advisory
FreeBSD, Inc.
Topic: Canna port contains remote vulnerability [REVISED]
Category: ports
Module: Canna
Announced: 2000-07-05
Revised: 2000-07-11
Affects: Ports collection.
Corrected: 2000-06-29
Credits: Shadow Penguin Security
<http://shadowpenguin.backsection.net/advisories/index.html>
Vendor status: Contacted
FreeBSD only: NO
I. Background
Canna is a Kana-Kanji conversion server.
II. Problem Description
The Canna server contains an overflowable buffer which may be
exploited by a remote user to execute arbitrary code on the local
system as user 'bin'.
The Canna port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3500 third-party applications in a ready-to-install
format. The ports collection shipped with FreeBSD 3.5 contains this
vulnerability since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can run arbitrary code as user 'bin' on the local system.
Depending on the local system configuration, the attacker may be able
to upgrade privileges further by exploiting local vulnerabilities.
If you have not chosen to install the Canna port/package, then your
system is not vulnerable to this problem.
IV. Workaround
One of the following:
1) Deinstall the Canna port/package, if you you have installed it.
2) Consider limiting remote access to the Canna server using ipfw(8)
or ipf(8).
3) Create a /etc/hosts.canna file on the Canna server and list the
hosts which you wish to allow access to the Canna server. For example,
if you want to allow access via localhost only, include the following
in your /etc/hosts.canna file:
localhost
unix
If you want to allow access via localhost and some-other-host.com,
which has IP address x.y.z.w, include the following:
localhost
unix
x.y.z.w
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the Canna port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/japanese/ja-Canna-3.2.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/japanese/ja-Canna-3.2.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/japanese/ja-Canna-3.2.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/japanese/ja-Canna-3.2.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/japanese/ja-Canna-3.2.2.tgz
Note: it may be several days before updated packages are available.
3) download a new port skeleton for the Canna port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
VI. Revision History
v1.0 2000-07-05 Initial release
v1.1 2000-07-11 Add additional access-control method submitted by KOJIMA Hajime <kjm@rins.ryukoku.ac.jp>
Correct package URL. Update size of ports collection.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWuZD1UuHi5z0oilAQEAOgP9FFIPBLNxpRkRC4lQqNHDcBQ/7EOapw1p
YstPyT2sJkykj66QtS4CC5Wd4r7qy4EPQodAqYFgQqMRNyZX3PNzuoRTB+CNzE3f
bV1bQq75FTpWBlDhD1LMxSjywgENeBUkuq214diIzUJMBucOa9caFDZ5K+22WquR
S5O/SGoqI/A=
=dynV
-----END PGP SIGNATURE-----

93
share/security/advisories/FreeBSD-SA-00:32.bitchx.asc Normal file
View file

@ -0,0 +1,93 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:32 Security Advisory
FreeBSD, Inc.
Topic: bitchx port contains client-side vulnerability
Category: ports
Module: bitchx
Announced: 2000-07-05
Affects: Ports collection.
Corrected: 2000-07-03
Vendor status: Patch released
FreeBSD only: NO
I. Background
BitchX is a popular IRC client.
II. Problem Description
The bitchx client incorrectly parses string-formatting operators
included as part of channel invitation messages sent by remote IRC
users. This can cause the local client to crash, and may possibly
present the ability to execute arbitrary code as the local user.
The bitchx port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3400 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.0 and 3.5 contain
this problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote IRC users can cause the local client to crash, and possibly
execute code as the local user.
If you have not chosen to install the bitchx port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Issue the following bitchx command (e.g. as part of a startup script):
/ignore * invites
which will disable processing of channel invitation messages.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the bitchx port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/irc/bitchx-1.0c16.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/irc/bitchx-1.0c16.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/irc/bitchx-1.0c16.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/irc/bitchx-1.0c16.tar.gz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/irc/bitchx-1.0c16.tar.gz
NOTE: It may be several days before updated packages are available. Be
sure to check the file creation date on the package, because the
version number of the software has not changed.
3) download a new port skeleton for the bitchx port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/devel/portcheckout-1.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWGvPlUuHi5z0oilAQGEQAP+MbpDIPmejoZUcpVCpIBFP+2LwmR/ouwu
LMuDVgY5l3kaWNIypTNAbMVPDZFx1l3+LEUJfurBLydpH8PnB17C7tE+uPXpNDzA
ph3jjHXazN8DvvdYCD6EcEXccgGIWREz+OUPsH4VZtqC0g84Lt7tpZwBFZ+Fh2Py
gjxO4c2fPE8=
=B4nR
-----END PGP SIGNATURE-----

153
share/security/advisories/FreeBSD-SA-00:33.kerberosIV.asc Normal file
View file

@ -0,0 +1,153 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:33 Security Advisory
FreeBSD, Inc.
Topic: kerberosIV distribution contains multiple vulnerabilities
under FreeBSD 3.x
Category: core
Module: kerberosIV
Announced: 2000-07-12
Credits: Assar Westerlund <assar@FreeBSD.org>
Affects: FreeBSD 3.x systems prior to the correction date
Corrected: 2000-07-06
FreeBSD only: NO
I. Background
KTH Kerberos is an implementation of the Kerberos 4 protocol which
is distributed as an optional component of the base system.
II. Problem Description
Vulnerabilities in the MIT Kerberos 5 port were the subject of an
earlier FreeBSD Security Advisory (SA-00:20). At the time it was
believed that the implementation of Kerberos distributed with FreeBSD
was not vulnerable to these problems, but it was later discovered that
FreeBSD 3.x contained an older version of KTH Kerberos 4 which is in
fact vulnerable to at least some of these vulnerabilities. FreeBSD
4.0-RELEASE and later are unaffected by this problem, although FreeBSD
3.5-RELEASE is vulnerable.
The exact extent of the vulnerabilities are not known, but are likely
to include local root vulnerabilities on both Kerberos clients and
servers, and remote root vulnerabilities on Kerberos servers. For the
client vulnerabilities, it is not necessary that Kerberos client
functionality be actually configured, merely that the binaries be
present on the system.
III. Impact
Local or remote users can obtain root access on the system running
Kerberos, whether as client or server.
If you have not chosen to install the KerberosIV distribution on your
FreeBSD 3.x system, then your system is not vulnerable to this
problem.
IV. Workaround
Due to the nature of the vulnerability there are several programs and
network services which are affected. The following libraries and
utilities are installed by the KerberosIV distribution and must be
removed or replaced with non-Kerberos versions to disable all
Kerberos-related code.
bin/rcp (*)
sbin/dump (*)
sbin/restore (*)
usr/bin/kadmin
usr/bin/kauth
usr/bin/kdestroy
usr/bin/kinit
usr/bin/klist
usr/bin/ksrvtgt
usr/bin/telnet (*)
usr/bin/cvs (*)
usr/bin/passwd (*)
usr/bin/rlogin (*)
usr/bin/rsh (*)
usr/bin/su (*)
usr/lib/libacl.a
usr/lib/libacl_p.a
usr/lib/libacl.so.3
usr/lib/libacl.so
usr/lib/libkadm.a
usr/lib/libkadm_p.a
usr/lib/libkadm.so.3
usr/lib/libkadm.so
usr/lib/libkafs.a
usr/lib/libkafs_p.a
usr/lib/libkafs.so.3
usr/lib/libkafs.so
usr/lib/libkdb.a
usr/lib/libkdb_p.a
usr/lib/libkdb.so.3
usr/lib/libkdb.so
usr/lib/libkrb.a
usr/lib/libkrb_p.a
usr/lib/libkrb.so.3
usr/lib/libkrb.so
usr/lib/libtelnet.a
usr/lib/libtelnet_p.a
usr/libexec/kauthd
usr/libexec/kipd
usr/libexec/kpropd
usr/libexec/telnetd (*)
usr/libexec/rlogind (*)
usr/libexec/rshd (*)
usr/sbin/ext_srvtab
usr/sbin/kadmind
usr/sbin/kdb_destroy
usr/sbin/kdb_edit
usr/sbin/kdb_init
usr/sbin/kdb_util
usr/sbin/kerberos
usr/sbin/kip
usr/sbin/kprop
usr/sbin/ksrvutil
usr/sbin/kstash
The files marked with a "(*)" are part of the base FreeBSD system when
the Kerberos distribution is not installed, and are replaced when
Kerberos is installed. Therefore you will need to replace them with
non-Kerberos versions from another system, or perform a recompilation
or reinstallation of FreeBSD after removal, if you wish to continue to
use them.
If you have chosen to install any ports with Kerberos support, such as
the security/ssh port, then you should also remove, or recompile these
with support disabled.
As an interim measure, access control measures (either a perimeter
firewall, or a local firewall on the affected machine - see the
ipfw(8) manpage for more information) can be used to prevent remote
systems from connecting to Kerberos services on a vulnerable Kerberos
server.
V. Solution
Upgrade your vulnerable FreeBSD 3.x system to a version of FreeBSD
dated after the correction date (FreeBSD 3.5-STABLE dated after the
correction date, 4.0-RELEASE or 4.0-STABLE). See
http://www.freebsd.org/handbook/makeworld.html for more information
about upgrading FreeBSD from source.
Be sure to install the Kerberos code when performing an upgrade
(whether by source or by a binary upgrade) to ensure that the old
binaries are no longer present on the system.
See the note in section IV. above about recompiling ports which were
compiled with Kerberos support.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOWzyeVUuHi5z0oilAQFJEwP/ZaecQhuSYfdR4ckwsDtGF86AvmRuqkTo
8A55zz2DeBUPKAVrvJAEuzM15zEL4+w+dofCep9gMAPWlgpNoNHRs4H3BLUjMiXc
UpFgKDYtY/gwYXZKOLVbe4as++G2Polk+oQXrRItV1LGKbjrtjuozPRGmkwCYwOk
/rUWX1tCNLI=
=ysen
-----END PGP SIGNATURE-----

125
share/security/advisories/FreeBSD-SA-00:34.dhclient.asc Normal file
View file

@ -0,0 +1,125 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:34 Security Advisory
FreeBSD, Inc.
Topic: dhclient vulnerable to malicious dhcp server
Category: core, ports
Module: dhclient, isc-dhcp2 (ports), isc-dhcp3 (ports)
Announced: 2000-08-14
Affects: All releases of FreeBSD after FreeBSD 3.2-RELEASE and
prior to the correction date (including FreeBSD 4.0
and 3.5, but not 4.1)
Ports collection prior to the correction date.
Credits: OpenBSD
Vendor status: Updated version released
Corrected: 2000-07-20 [FreeBSD 4.0 base system]
2000-08-01 [isc-dhcp2 port]
2000-07-21 [isc-dhcp3 port]
FreeBSD only: NO
I. Background
ISC-DHCP is an implementation of the DHCP protocol containing client
and server. FreeBSD 3.2 and above includes the version 2 client by
default in the base system, and the version 2 and version 3 clients
and servers in the Ports Collection.
II. Problem Description
The dhclient utility (DHCP client), versions 2.0pl2 and before (for
the version 2.x series), and versions 3.0b1pl16 and before (for the
version 3.x series) does not correctly validate input from the server,
allowing a malicious DHCP server to execute arbitrary commands as root
on the client. DHCP may be enabled if your system was initially
configured from a DHCP server at install-time, or if you have
specifically enabled it after installation.
FreeBSD 4.1 is not affected by this problem since it contains the
2.0pl3 client.
III. Impact
An attacker who has or gains control of a DHCP server may gain
additional root access to DHCP clients running vulnerable versions of
ISC-DHCP.
If you are not using dhclient to configure client machines via DHCP,
or your DHCP server is "trusted" according to your local security
policy, then this vulnerability does not apply to you.
IV. Workaround
Disable the use of DHCP for configuring client machines: remove the
case-insensitive string "dhcp" from the "ifconfig_<foo>" directives in
/etc/rc.conf and replace it with appropriate static interface
configuration according to the rc.conf(5) manpage.
An example of a DHCP-enabled interface is the following line in
/etc/rc.conf:
ifconfig_xl0="DHCP"
V. Solution
NOTE: At this time the FreeBSD 3.x branch has not yet been patched,
due to logistical difficulties. Users running a vulnerable 3.x system
are advised to either upgrade to FreeBSD 4.1, disable the use of
DHCP as described above, or use the dhclient binary from the isc-dhcp2
port dated after the correction date.
1) Upgrade your vulnerable FreeBSD 4.0 system to a version dated after the
correction date. See
http://www.freebsd.org/handbook/makeworld.html
for instructions on how to upgrade and recompile your FreeBSD system
from source, or perform a binary upgrade, e.g. to FreeBSD 4.1-RELEASE,
described here:
http://www.freebsd.org/releases/4.1R/notes.html
2) (If using the isc-dhcp2 or isc-dhcp3 ports) One of the following:
2a) Upgrade your entire ports collection and rebuild the isc-dhcp2 or isc-dhcp3 port.
2b) Deinstall the old package and install a new package dated after the
correction date, obtained from:
[isc-dhcp3]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/isc-dhcp3-3.0.b1.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/isc-dhcp3-3.0.b1.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/isc-dhcp3-3.0.b1.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/isc-dhcp3-3.0.b1.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/isc-dhcp3-3.0.b1.17.tgz
NOTE: The isc-dhcp2 port is not available as a package.
2c) download a new port skeleton for the isc-dhcp2 or isc-dhcp3 port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
2d) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOZh3J1UuHi5z0oilAQHXBQQAmCLlTUfikHbgBelFd22agjTo/AVwR933
El0AMRHakiBJAHTMseZ4Nj+HyGUgVzD3oRMgmjx1u+HUCQM2/akuXXZdSHlur5Jc
OyEGxcwxyzYXnNzWAL1vh6MYrpkGDfh74bHircLdO16d6uC1d+0VFmkxUOOFN4zb
g7yK3m2ZOxo=
=qTwd
-----END PGP SIGNATURE-----

99
share/security/advisories/FreeBSD-SA-00:35.proftpd.asc Normal file
View file

@ -0,0 +1,99 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:35 Security Advisory
FreeBSD, Inc.
Topic: proftpd port contains remote root compromise
Category: ports
Module: proftpd
Announced: 2000-08-14
Credits: lamagra <lamagra@DIGIBEL.ORG>
Affects: Ports collection prior to the correction date.
Corrected: 2000/07/28
Vendor status: Updated version released
FreeBSD only: NO
I. Background
proftpd is a popular FTP server.
II. Problem Description
The proftpd port, versions prior to 1.2.0rc2, contains a vulnerability
which allows FTP users, both anonymous FTP users and those with a
valid account, to execute arbitrary code as root on the local machine,
by inserting string-formatting operators into command input, which are
incorrectly parsed by the FTP server.
This is the same class of vulnerability as the one described in
FreeBSD Security Advisory 00:29, which pertained to the wu-ftpd port.
The proftpd port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains nearly 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5 contains this
problem since it was discovered after the release, but FreeBSD 4.1 did
not ship with the proftpd package (and the port was disabled to
prevent building) because the vulnerability was known but not yet
fixed.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
FTP users, including anonymous FTP users, can cause arbitrary commands
to be executed as root on the local machine.
If you have not chosen to install the proftpd port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the proftpd port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the proftpd port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/ftp/proftpd-1.2.0rc2.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the proftpd port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOZh1u1UuHi5z0oilAQFYQQP/UH7MbeD/cm3aPGrPdb8NXUo9giAajayX
uWazNh+kfJGUrpVg3DaYo7jY2ZG5yrBBo5kZRFUUSy5OpDvD20I3QBhtNV0gWItD
n2mkSDP90BG4scmVuwx+GexCz5gZ+frpM2hKXlhtFqJRMA2Sk0R4vzapIvc16EFN
6nraHfzVSCk=
=7ifu
-----END PGP SIGNATURE-----

145
share/security/advisories/FreeBSD-SA-00:36.ntop.asc Normal file
View file

@ -0,0 +1,145 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:36 Security Advisory
FreeBSD, Inc.
Topic: ntop port allows remote and minor local compromise
Category: ports
Module: ntop
Announced: 2000-08-14
Credits: Discovered during internal auditing
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-12 (However see below)
Vendor status: Contacted
FreeBSD only: NO
I. Background
ntop is a utility for monitoring and summarizing network usage, from
the command-line or remotely via HTTP.
II. Problem Description
The ntop software is written in a very insecure style, with many
potentially exploitable buffer overflows (including several
demonstrated ones) which could in certain conditions allow the local
or remote user to execute arbitrary code on the local system with
increased privileges.
By default the ntop port is installed setuid root and only executable
by root and members of the 'wheel' group. The 'wheel' group is
normally only populated by users who also have root access, but this
is not necessarily the case (the user must know the root password to
increase his or her privileges). ntop allows a member of the wheel
group to obtain root privileges directly through a local exploit.
If invoked in 'web' mode (ntop -w) then any remote user who can
connect to the ntop server port (which is determined by local
configuration) can execute arbitrary code on the server as the user
running the ntop process, regardless of whether or not they can
authenticate to the ntop server by providing a valid username and
password.
This will not necessarily yield root privileges unless ntop -w is
executed as root since by the time it services network connections the
program has dropped privileges, although it retains the ability to
view all network traffic on the sampled network interface (instead of
just the connection summaries which ntop normally presents). However,
since ntop is not executable by unprivileged users, it is likely that
the majority of installations using 'ntop -w' are doing so as root, in
which case full system compromise is directly possible.
The ntop port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains nearly 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5 and 4.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users who are members of the wheel group can obtain root
privileges without having to pass through the normal system security
mechanisms (i.e. entering the root password). If ntop is run in "web"
mode (ntop -w) then remote users who can connect to the ntop server
port can also execute arbitrary code on the server as the user running
ntop -w (usually root).
If you have not chosen to install the ntop port/package, then your
system is not vulnerable to this problem.
IV. Workaround
1) Remove the setuid bit from the ntop binary so that only the
superuser may execute it. Depending on local policy this vulnerability
may not present significant risk.
2) Avoid using ntop -w. If ntop -w is required, consider imposing
access controls to limit access to the ntop server port (e.g. using a
perimeter firewall, or ipfw(8) or ipf(8) on the local machine). Note
that specifying a username/password access list within the ntop
configuration file is insufficient, as noted above. Users who pass the
access restrictions can still gain privileges as described above.
V. Solution
Due to the lack of attention to security in the ntop port no simple
fix is possible: for example, the local root overflow can easily be
fixed, but since ntop holds a privileged network socket a member of
the wheel group could still obtain direct read access to all network
traffic by exploiting other vulnerabilities in the program, which
remains a technical security violation.
The FreeBSD port has been changed to disable '-w' mode and remove the
setuid bit, so that the command is only available locally to the
superuser. Full functionality will be restored once the ntop
developers have addressed these security concerns and provided an
adequate fix - this advisory will be reissued at that time.
To upgrade your ntop port/package, perform one of the following:
1) Upgrade your entire ports collection and rebuild the ntop port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/ntop-1.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/ntop-1.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/ntop-1.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/ntop-1.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/ntop-1.1.tgz
NOTE: It may be several days before updated packages are available. Be
sure to check the file creation date on the package, because the
version number of the software has not changed.
3) download a new port skeleton for the ntop port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOZh1m1UuHi5z0oilAQFcIgQArlP0hzT+scsGxjI7wTWXh5fgm5E+CFh0
EfeIvYgGCzsCCCAS0nm3vo+a1IUxloJdk27K2oO4aCjTLy+gLe/vnW28gWn9dzle
nIyUDFudMpsx/WpO4F4UkMPTX+w0fiWpNvY2KddjwOeBn2xhRJik9ZVTMpc7zTe6
+2DGgV9jAnM=
=9UuJ
-----END PGP SIGNATURE-----

106
share/security/advisories/FreeBSD-SA-00:37.cvsweb.asc Normal file
View file

@ -0,0 +1,106 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:37 Security Advisory
FreeBSD, Inc.
Topic: cvsweb allows increased access to CVS committers
Category: ports
Module: cvsweb
Announced: 2000-08-14
Credits: Joey Hess <joey@kitenet.net>
Affects: Ports collection prior to the correction date.
Corrected: 2000-07-11
Vendor status: Patch released
FreeBSD only: NO
I. Background
cvsweb is a CGI script which provides a read-only interface to a CVS
repository for browsing via a web interface.
II. Problem Description
The cvsweb port, versions prior to 1.86, contains a vulnerability
which allows users with commit access to a CVS repository monitored by
cvsweb to execute arbitrary code as the user running the cvsweb.cgi
script, which may be located on another machine where the committer
has no direct access. The vulnerability is that cvsweb does not
correctly process input obtained from the repository and is vulnerable
to embedding of commands in committed filenames. Such an action is
however usually highly visible in the CVS repository and provides an
audit trail of sorts for such abuses unless the committer has access
to modify the repository files directly to cover his or her tracks.
This vulnerability may or may not be a security issue depending on the
local security policy (for example, CVS itself is known to easily
allow committers to execute commands on the CVS server even without a
login account, so this presents little additional exposure if cvsweb
is run on the CVS server itself).
The cvsweb port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains nearly 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5 contains this
problem since it was discovered after the release, but it was fixed
prior to the release of FreeBSD 4.1.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
CVS committers can execute code as the user running the cvsweb.cgi
script, which may present a violation of local security policy.
If you have not chosen to install the cvsweb port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the cvsweb port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the cvsweb port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/cvsweb-1.93.1.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/cvsweb-1.93.1.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/cvsweb-1.93.1.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/cvsweb-1.93.1.10.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/cvsweb-1.93.1.10.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOZh1qlUuHi5z0oilAQEAjAP7B+Kss7dLQ3upyq8HLwVMr5fhOPgW6TWK
BtkZ71mBapFQleZi9vWbpd/R2Cow7i42nsZQi8d7kERiXJRW6EGXr125aIA5NopV
1NoR4BKa9KYOP0CI9jqYUWiMj5PfNy03HlLbrDzHbGOIbqMqcsERXEFNGvt0Qvb4
qkjHlQ9faRE=
=VajH
-----END PGP SIGNATURE-----

96
share/security/advisories/FreeBSD-SA-00:38.zope.asc Normal file
View file

@ -0,0 +1,96 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:38 Security Advisory
FreeBSD, Inc.
Topic: zope port allows remote modification of DTML documents
Category: ports
Module: zope
Announced: 2000-08-14
Credits: Unknown
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-05
Vendor status: Patch released
FreeBSD only: NO
I. Background
zope is an object-based dynamic web application platform.
II. Problem Description
To quote the vendor advisory about this problem:
> The issue involves an inadequately protected method in one of
> the base classes in the DocumentTemplate package that could allow
> the contents of DTMLDocuments or DTMLMethods to be changed
> remotely or through DTML code without forcing proper user
> authorization.
The zope port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
nearly 3700 third-party applications in a ready-to-install format. The
ports collections shipped with FreeBSD 3.5 contains this problem, but
FreeBSD 4.1 did not ship with the proftpd package (and the port was
disabled to prevent building) because the vulnerability was known but
not yet fixed.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can modify DTML documents without authorization.
If you have not chosen to install the zope port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the zope port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the zope port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/zope-2.2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/zope-2.2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/zope-2.2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/zope-2.2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/zope-2.2.0.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the zope port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOZh1lFUuHi5z0oilAQFsowP+JE+R5hHUpY0pDfNl9Dd/ai354XJh8PYG
X5DlmdMTMiByXkR0KMZBMB9SuRljuqBsknc8L3KB8UIyMUccnN0IhsFqZ2WEYiY4
EAgS7I5EPTf/4y6g81Vt4g+s3l2XXu845kOv92hwJxFgUMINVXrIduJpdICAgcpr
rcw+4BM/Www=
=AoKX
-----END PGP SIGNATURE-----

117
share/security/advisories/FreeBSD-SA-00:39.netscape.asc Normal file
View file

@ -0,0 +1,117 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:39 Security Advisory
FreeBSD, Inc.
Topic: Two vulnerabilities in Netscape
Category: ports
Module: netscape
Announced: 2000-08-28
Credits: Solar Designer <solar@FALSE.COM> (Vulnerability #1)
Dan Brumleve <dan+Bsecurity@brumleve.com> (Vulnerability #2)
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-19
Vendor status: Updated version released
FreeBSD only: NO
I. Background
Netscape is a popular web browser, available in several versions in
the FreeBSD ports collection.
II. Problem Description
There are two security problems in recent versions of netscape:
1) Versions prior to 4.74
A client-side exploit may be possible through a buffer overflow in
JPEG-handling code. Although an exploit is not known, attackers may be
able to execute arbitrary code on the local machine as the user
running netscape, or at the very least cause the netscape binary to
crash.
2) Versions prior to 4.75
The Java Virtual Machine implementation has security vulnerabilities
allowing a remote user to read the contents of local files accessible
to the user running netscape, and to allow these files to be
transmitted to any user on the internet.
The netscape ports are not installed by default, nor are they "part of
FreeBSD" as such: they are part of the FreeBSD ports collection, which
contains over 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5 and 4.1 are
vulnerable to these problems.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can read files on the local system accessible to the user
running netscape, if java is enabled, and may be able to execute
arbitrary code on the local system as that user.
If you have not chosen to install a netscape port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the netscape port/package, if you you have installed it.
Vulnerability 2) can be worked around by disabling Java in the
"Advanced" section of the Preferences control panel. Vulnerability 1)
can be worked around by disabling the "Automatically load images"
option in the same location, although this is not a very practical
workaround.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the relevant
netscape port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from the following directories:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/
Since there are so many variations of the netscape ports in the
FreeBSD ports collection they are not listed separately
here. Localized versions are also available in the respective language
subdirectory.
3) download a new port skeleton for the netscape port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaqy41UuHi5z0oilAQGsgAP/TGyAq7u74FJ/rYkfmTd4qyiyjN2XF0nH
9Pikcu4EAJo8R0yhIU0mmXdK3HXWKRTKzH43+gLH6yZGVTr5SQu4a4RYgS4T8sbD
Iu3p45DwYfZVQCjsJoseF48kaXlScheoxoR3+Et5khzhBDuwRedUXAK4VMWAm3Fp
/4vWrTKykTc=
=A0Wy
-----END PGP SIGNATURE-----

98
share/security/advisories/FreeBSD-SA-00:40.mopd.asc Normal file
View file

@ -0,0 +1,98 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:40 Security Advisory
FreeBSD, Inc.
Topic: mopd port allows remote root compromise
Category: ports
Module: mopd
Announced: 2000-08-28
Credits: Matt Power <mhpower@MIT.EDU>, OpenBSD
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-09
Vendor status: Contacted
FreeBSD only: NO
I. Background
mopd is used for netbooting older DEC machines such as VAXen and
DECstations.
II. Problem Description
The mopd port contains several remotely exploitable
vulnerabilities. An attacker exploiting these can execute arbitrary
code on the local machine as root.
The mopd port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 3700 third-party applications in a ready-to-install format. The
ports collections shipped with FreeBSD 3.5-RELEASE and 4.1-RELEASE
contain this problem, since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can execute arbitrary code on the local machine as root.
If you have not chosen to install the mopd port/package, then your
system is not vulnerable to this problem.
IV. Workaround
One of the following:
1) Deinstall the mopd port/package, if you have installed it.
2) Restrict access to the mopd port using a perimeter firewall, or
ipfw(8)/ipf(8) on the local machine. Note that users who pass these
access restrictions may still exploit the vulnerability.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the mopd port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/mopd-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/mopd-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/mopd-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/mopd-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/mopd-1.2b.tgz
NOTE: Be sure to check the file creation date on the package, because
the version number of the software has not changed.
3) download a new port skeleton for the mopd port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaqy6FUuHi5z0oilAQG14gQAn9RVxulK3pIyHi3aQ5j9p0OnlOoP9Wg2
yKEPARafL+WXHS1oJ+5ZGdhUG2rZjU1QktS0xTy5PXSo0mcX91jLJ7ASwg6K5w2e
rpZMBRHZVFy3HltzFxwygZGGbENIbZNzZ9Qd9Luq/OPPxZzb/9NsHnUovk5/lyIE
yCAt/USxiDs=
=tlfC
-----END PGP SIGNATURE-----

148
share/security/advisories/FreeBSD-SA-00:41.elf.asc Normal file
View file

@ -0,0 +1,148 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:41 Security Advisory
FreeBSD, Inc.
Topic: Malformed ELF images can cause a system hang
Category: core
Module: kernel
Announced: 2000-08-28
Credits: Adam McDougall <bsdx@looksharp.net>
Affects: FreeBSD 3.x, 4.x and 5.x prior to the correction date
Corrected: 2000-07-25 (FreeBSD 5.0-CURRENT)
2000-07-23 (FreeBSD 4.0-STABLE)
FreeBSD only: Yes
I. Background
The ELF binary format is used for binary executable programs on modern
versions of FreeBSD.
II. Problem Description
The ELF image activator did not perform sufficient sanity checks on
the ELF image header, and when confronted with an invalid or truncated
header it suffered a sign overflow bug which caused the CPU to enter
into a very long loop in the kernel.
The result of this is that the system will appear to lock up for an
extended period of time before control returns. This bug can be
exploited by unprivileged local users.
This vulnerability is not present in FreeBSD 4.1-RELEASE, although
3.5-RELEASE and 3.5.1-RELEASE are vulnerable.
III. Impact
Local users can cause the system to lock up for an extended period of
time (15 minutes or more, depending on CPU speed), during which time
the system is completely unresponsive to local and remote users.
IV. Workaround
None available.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1-RELEASE, 4.1-STABLE
or 5.0-CURRENT after the respective correction dates. FreeBSD
3.5-STABLE has not yet been fixed due to logistical difficulties (and
the patch below does not apply cleanly). Consider upgrading to
4.1-RELEASE if this is a concern - this advisory will be reissued once
the patch has been applied to the 3.x branch.
2) Apply the patch below and recompile your kernel.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:41/elf.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:41/elf.patch.asc
# cd /usr/src/sys/kern
# patch -p < /path/to/patch_or_advisory
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
--- imgact_elf.c 2000/04/30 18:51:39 1.75
+++ imgact_elf.c 2000/07/23 22:19:49 1.78
@@ -190,6 +190,21 @@
object = vp->v_object;
error = 0;
+ /*
+ * It's necessary to fail if the filsz + offset taken from the
+ * header is greater than the actual file pager object's size.
+ * If we were to allow this, then the vm_map_find() below would
+ * walk right off the end of the file object and into the ether.
+ *
+ * While I'm here, might as well check for something else that
+ * is invalid: filsz cannot be greater than memsz.
+ */
+ if ((off_t)filsz + offset > object->un_pager.vnp.vnp_size ||
+ filsz > memsz) {
+ uprintf("elf_load_section: truncated ELF file\n");
+ return (ENOEXEC);
+ }
+
map_addr = trunc_page((vm_offset_t)vmaddr);
file_addr = trunc_page(offset);
@@ -341,6 +356,12 @@
}
error = exec_map_first_page(imgp);
+ /*
+ * Also make certain that the interpreter stays the same, so set
+ * its VTEXT flag, too.
+ */
+ if (error == 0)
+ nd.ni_vp->v_flag |= VTEXT;
VOP_UNLOCK(nd.ni_vp, 0, p);
if (error)
goto fail;
@@ -449,6 +470,17 @@
/*
* From this point on, we may have resources that need to be freed.
*/
+
+ /*
+ * Yeah, I'm paranoid. There is every reason in the world to get
+ * VTEXT now since from here on out, there are places we can have
+ * a context switch. Better safe than sorry; I really don't want
+ * the file to change while it's being loaded.
+ */
+ simple_lock(&imgp->vp->v_interlock);
+ imgp->vp->v_flag |= VTEXT;
+ simple_unlock(&imgp->vp->v_interlock);
+
if ((error = exec_extract_strings(imgp)) != 0)
goto fail;
@@ -610,9 +642,6 @@
imgp->auxargs = elf_auxargs;
imgp->interpreted = 0;
- /* don't allow modifying the file while we run it */
- imgp->vp->v_flag |= VTEXT;
-
fail:
return error;
}
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaq1hlUuHi5z0oilAQGpvgQAoaeqjoU1QppgQ+yXF7KOL6EfTQ9mrdEe
zKQ6vU//hc1ejKx9C4zmQybflQIpkHS2TMNAfXuvFG74hvETwa8cpVqolJU29CCf
FKlGTCAGCSzosWrndBuvakKqjeVvvQR4JydVhkO04neVEfbUXkich/2PT+3h3dKW
GuW3coG8nYE=
=2w2A
-----END PGP SIGNATURE-----

194
share/security/advisories/FreeBSD-SA-00:42.linux.asc Normal file
View file

@ -0,0 +1,194 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:42 Security Advisory
FreeBSD, Inc.
Topic: Linux binary compatability mode can cause system compromise
Category: core
Module: kernel
Announced: 2000-08-28
Credits: Boris Nikolaus <boris@cs.tu-berlin.de>
Affects: FreeBSD 3.x, 4.x and 5.x prior to the correction date
Corrected: 2000-07-23 (FreeBSD 5.0-CURRENT)
2000-07-29 (FreeBSD 4.1-STABLE)
2000-08-24 (FreeBSD 3.5-STABLE)
FreeBSD only: Yes
I. Background
FreeBSD is binary-compatible with the Linux operating system through a
loadable kernel module/optional kernel component.
II. Problem Description
The linux binary-compatability module implements a "shadow" filesystem
hierarchy rooted in /compat/linux, which is overlayed against the
regular filesystem hierarchy so that Linux binaries "see" files in the
shadow hierarchy which can mask the native files.
Filenames in this shadow hierarchy are treated incorrectly by the
linux kernel module under certain circumstances, and a kernel stack
overflow leading to a system compromise by an unprivileged user may be
possible when very long filenames are used. This is only possible when
the linux kernel module is loaded, or the equivalent functionality is
statically compiled into the kernel. It is not enabled by default.
This vulnerability was fixed just after the release of FreeBSD
4.1-RELEASE, and 3.5-RELEASE is also vulnerable.
III. Impact
Local users may be able to obtain root privileges on the system when
linux compatability mode is enabled.
IV. Workaround
To determine whether the linux compatability module has been loaded,
execute the following command as root and look for a 'linux.ko' entry:
# kldstat
Id Refs Address Size Name
1 7 0xc0100000 270be0 kernel
2 1 0xc0371000 5540 vesa.ko
3 1 0xc0377000 10094 randomdev.ko
4 1 0xc0e17000 4e000 nfs.ko
5 1 0xc0e83000 11000 linux.ko
If present, unload the "linux" module by executing the following
command as root:
# kldunload linux
For safety, remove the /modules/linux.ko file to prevent it being
reloaded accidentally, and add or change the following line in
/etc/rc.conf:
linux_enable="NO" # Linux binary compatibility loaded at startup (or NO).
If the module is not loaded, to determine whether the functionality
has been statically compiled into the kernel, check the kernel
configuration file for the following line:
options COMPAT_LINUX
If present, remove and recompile the kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 3.5-STABLE, 4.1-STABLE or
5.0-CURRENT after the respective correction dates.
2) Apply the patch below and recompile your kernel.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:42/linux.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:42/linux.patch.asc
# cd /usr/src/sys/i386/linux
# patch -p < /path/to/patch_or_advisory
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
Index: linux_misc.c
===================================================================
RCS file: /home/ncvs/src/sys/i386/linux/linux_misc.c,v
retrieving revision 1.77.2.3
retrieving revision 1.77.2.4
diff -u -r1.77.2.3 -r1.77.2.4
--- linux_misc.c 2000/07/20 05:31:56 1.77.2.3
+++ linux_misc.c 2000/07/30 05:36:11 1.77.2.4
@@ -954,6 +954,8 @@
tv[1].tv_usec = 0;
/* so that utimes can copyin */
tvp = (struct timeval *)stackgap_alloc(&sg, sizeof(tv));
+ if (tvp == NULL)
+ return (ENAMETOOLONG);
if ((error = copyout(tv, tvp, sizeof(tv))))
return error;
bsdutimes.tptr = tvp;
Index: linux_util.c
===================================================================
RCS file: /home/ncvs/src/sys/i386/linux/linux_util.c,v
retrieving revision 1.9.2.1
retrieving revision 1.9.2.2
diff -u -r1.9.2.1 -r1.9.2.2
--- linux_util.c 2000/07/07 01:23:45 1.9.2.1
+++ linux_util.c 2000/07/30 05:36:11 1.9.2.2
@@ -162,7 +162,10 @@
else {
sz = &ptr[len] - buf;
*pbuf = stackgap_alloc(sgp, sz + 1);
- error = copyout(buf, *pbuf, sz);
+ if (*pbuf != NULL)
+ error = copyout(buf, *pbuf, sz);
+ else
+ error = ENAMETOOLONG;
free(buf, M_TEMP);
}
Index: linux_util.h
===================================================================
RCS file: /home/ncvs/src/sys/i386/linux/linux_util.h,v
retrieving revision 1.10
retrieving revision 1.10.2.1
diff -u -r1.10 -r1.10.2.1
--- linux_util.h 1999/12/04 11:10:22 1.10
+++ linux_util.h 2000/07/30 05:36:11 1.10.2.1
@@ -56,29 +56,27 @@
static __inline caddr_t stackgap_init(void);
static __inline void *stackgap_alloc(caddr_t *, size_t);
+#define szsigcode (*(curproc->p_sysent->sv_szsigcode))
+
static __inline caddr_t
stackgap_init()
{
-#define szsigcode (*(curproc->p_sysent->sv_szsigcode))
return (caddr_t)(PS_STRINGS - szsigcode - SPARE_USRSPACE);
}
-
static __inline void *
stackgap_alloc(sgp, sz)
caddr_t *sgp;
size_t sz;
{
- void *p = (void *) *sgp;
- *sgp += ALIGN(sz);
+ void *p = (void *) *sgp;
+
+ sz = ALIGN(sz);
+ if (*sgp + sz > (caddr_t)(PS_STRINGS - szsigcode))
+ return NULL;
+ *sgp += sz;
return p;
}
-
-#ifdef DEBUG_LINUX
-#define DPRINTF(a) printf a;
-#else
-#define DPRINTF(a)
-#endif
extern const char linux_emul_path[];
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaq1wFUuHi5z0oilAQFcVQQAlYhhDM6T/qEDqVTvG9yr9mv++LVGqqRE
SI4MEbmwbV5NvmFqTM2OzGpKsUaAy9gEfA5mjVKR+PRFoY7g68heFGAKWSRHmgs5
ramrzVxBHOeviaHeAXpH7LgJOdFo8EwhqehLtv+M0I5n9JJjPvAEWXG9cdiYXTto
pKJAPVXr9NU=
=r8gN
-----END PGP SIGNATURE-----

98
share/security/advisories/FreeBSD-SA-00:43.brouted.asc Normal file
View file

@ -0,0 +1,98 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:43 Security Advisory
FreeBSD, Inc.
Topic: brouted port allows gid kmem compromise
Category: ports
Module: brouted
Announced: 2000-08-28
Credits: Discovered during internal auditing
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-22
Vendor status: Contacted
FreeBSD only: NO
I. Background
brouted is a dynamic routing daemon.
II. Problem Description
The brouted port is incorrectly installed setgid kmem, and contains
several exploitable buffer overflows in command-line arguments. An
attacker exploiting these to gain kmem privilege can easily upgrade to
full root access by manipulating kernel memory.
The brouted port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5-RELEASE and
4.1-RELEASE contain this problem, since it was discovered after the
releases during internal auditing.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged local users can obtain group kmem privileges, and upgrade
further to full root privileges.
If you have not chosen to install the brouted port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Execute the following command as root to remove the setgid bit on the
/usr/local/sbin/brouted file:
# chmod g-s /usr/local/bin/brouted
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the brouted port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/brouted-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/brouted-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/brouted-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/brouted-1.2b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/brouted-1.2b.tgz
NOTE: It may be several days before updated packages are available. Be
sure to check the file creation date on the package, because the
version number of the software has not changed.
3) download a new port skeleton for the brouted port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaqy+lUuHi5z0oilAQHDzwQApGoedKCQAZcpjqafuNA9jPQ0fQ2PaScu
OZlBlflrUVNAMcEkL3y9lmahdVTcdOBpKAALDzIxYnKYlSxGg1RTtxHoWhJiCD97
c2mc9Ni65YCHab5O90WBHK+VjTiFzfq+dpG+rXLB1W2Pfq68Xf8O2rb2eSjdVW3d
/wazSPNLcSg=
=V2xB
-----END PGP SIGNATURE-----

103
share/security/advisories/FreeBSD-SA-00:44.xlock.asc Normal file
View file

@ -0,0 +1,103 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:44 Security Advisory
FreeBSD, Inc.
Topic: xlockmore port allows reading of password file
Category: ports
Module: xlockmore
Announced: 2000-08-28
Credits: bind <bind@SUBTERRAIN.NET>
Affects: Ports collection prior to the correction date.
Corrected: 2000-08-15
Vendor status: Updated version released
FreeBSD only: NO
I. Background
xlockmore is a utility for locking console access to an X terminal.
II. Problem Description
The xlockmore port, versions 4.17 and below, installs the setuid root
binary xlock, which contains a vulnerability due to incorrect use of
the syslog() function. The xlock program correctly drops root
privileges prior to the point of vulnerability, however it may retain
in memory part of the hashed password database for the user accounts
on the system.
Attackers who can retrieve hashed password information from the memory
space of the process can mount attacks against the user account
passwords and possibly gain access to accounts on the system if
successful.
The xlockmore port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5-RELEASE and
4.1-RELEASE contain this problem, since it was discovered after the
releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged local users may be able to gain unauthorised access to
parts of the /etc/spwd.db file, allowing them to mount guessing
attacks against user passwords.
If you have not chosen to install the xlockmore port/package, then your
system is not vulnerable to this problem.
IV. Workaround
One of the following:
Deinstall the xlockmore port/package, if you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the xlockmore port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/x11/xlockmore-4.17.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/x11/xlockmore-4.17.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/x11/xlockmore-4.17.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/x11/xlockmore-4.17.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/x11/xlockmore-4.17.1.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the xlockmore port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOaqzxFUuHi5z0oilAQEJJgP/cpBPXxsnmcGysBYnZkq0+mhMYxxDyX/D
czvyS90uO3k9slC+QYsmgLeTRrDpULcHNsePwxYKbt+zEydcENLhpiiGRuGkKrvD
b5UH9Sjle3rF3nTecxKRPTPD0009Tk356YeYOPVofqfZzCQpR8MqUHGz9cmhBuXH
t/y3LtBhLDo=
=sJTv
-----END PGP SIGNATURE-----

99
share/security/advisories/FreeBSD-SA-00:45.esound.asc Normal file
View file

@ -0,0 +1,99 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:45 Security Advisory
FreeBSD, Inc.
Topic: esound port allows file permissions to be modified
Category: ports
Module: esound
Announced: 2000-08-31
Credits: Brian Feldman <green@FreeBSD.org> during internal auditing
Affects: Ports collection prior to the correction date
Corrected: 2000-06-30
Vendor status: Contacted
FreeBSD only: NO
I. Background
EsounD is a component of the GNOME desktop environment which is
responsible for multiplexing access to audio devices.
II. Problem Description
The esound port, versions 0.2.19 and earlier, creates a world-writable
directory in /tmp owned by the user running the EsounD session, which
is used for the storage of a unix domain socket. A race condition
exists in the creation of this socket which allows a local attacker to
cause an arbitrary file or directory owned by the user running esound
to become world-writable. This can give the attacker access to the
victim's account, or lead to a system compromise if esound is run by
root.
The esound port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3700 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.0 and 3.5 contain
this problem, but it was corrected prior to the release of FreeBSD
4.1.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users can cause files or directories owned by the target user to
become world-writable when that user runs the esd daemon (e.g. by
starting a GNOME session), allowing a security breach of that user
account (or the entire system if esd is run by root)
If you have not chosen to install the esound port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the esound port/package, if you have installed it (see the
pkg_delete(1) manual page for more information).
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the esound port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/audio/esound-0.2.19.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/audio/esound-0.2.19.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/audio/esound-0.2.19.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/audio/esound-0.2.19.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/audio/esound-0.2.19.tgz
3) download a new port skeleton for the esound port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOa6cE1UuHi5z0oilAQGGPwP/ePOVTscGQ6G4deQqeYVehEk8KTPr0nhm
nWgQln3jZW46maoMgBHq/Zdj5DM+H9xmC9qaVjdJ2mYcNQIL3ldntO8IIeQfZ/zA
kqy+CthlLiF7FSnwC4XwpzBU4OWxuNPT02naD2kK1p6ERcn1QKbqfvzel40Sc2wQ
+XnHbXpx4qE=
=RtJ1
-----END PGP SIGNATURE-----

99
share/security/advisories/FreeBSD-SA-00:46.screen.asc Normal file
View file

@ -0,0 +1,99 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:46 Security Advisory
FreeBSD, Inc.
Topic: screen port contains local root compromise
Category: ports
Module: screen
Announced: 2000-09-13
Affects: Ports collection prior to the correction date.
Corrected: 2000-09-01
Credits: Jouko Pynnönen <jouko@SOLUTIONS.FI>
Vendor status: Updated version released
FreeBSD only: NO
I. Background
screen is a popular application that multiplexes a physical terminal
between several processes.
II. Problem Description
The screen port, versions 3.9.5 and before, contains a vulnerability
which allows local users to gain root privileges. This is
accomplished by inserting string-formatting operators into
configuration parameters, which may allow arbitrary code to be
executed.
The screen port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users can obtain root privileges.
If you have not chosen to install the screen port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Remove the setuid bit on the program: execute the following command as
root:
chmod 555 /usr/local/bin/screen-3.9.5
Note that this should be considered a temporary measure and may affect
the behaviour of the screen program.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the screen port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/misc/screen-3.9.8.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/misc/screen-3.9.8.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/misc/screen-3.9.8.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/misc/screen-3.9.8.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/misc/screen-3.9.8.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the screen port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kA1UuHi5z0oilAQEXLwQAkMV9qAgfMfciDsW/Oseik/kGc//iuPwA
nlQltRMXbVjdEhbe9QgyhVxd7gr3MZcRCfRTdqZodbXZpwA2WwB4BV6syjtuZE7+
ShHCk3cyhgFBAlO7rBdDCu6+GCtfsmjJV3d4McHhsy40UzLxmVDuoEkVYp+TkS1U
6shlUZTkIvI=
=GTCE
-----END PGP SIGNATURE-----

107
share/security/advisories/FreeBSD-SA-00:47.pine.asc Normal file
View file

@ -0,0 +1,107 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:47 Security Advisory
FreeBSD, Inc.
Topic: pine4 port allows denial of service
Category: ports
Module: pine4
Announced: 2000-09-13
Affects: Ports collection.
Corrected: 2000-07-17
Credits: Juhapekka Tolvanen <juhtolv@ST.JYU.FI>
Vendor status: Contacted
FreeBSD only: NO
I. Background
Pine is a popular mail user agent.
II. Problem Description
The pine4 port, versions 4.21 and before, contained a bug which would
cause the program to crash when processing a folder which contains an
email message with a malformed X-Keywords header. The message itself
could be deleted within pine if identified, but other operations such
as closing the folder with the message still present would cause the
program to crash with no apparent cause, discarding changes to the
mailbox.
The FreeBSD port of pine4 was changed on 2000-07-17 to use an updated
version of the c-client library which is used to handle the mailbox
processing. This library does not contain the bug and versions of
pine4 built with it (i.e. ports or packages dated after the correction
date) do not suffer from this vulnerability.
The pine4 port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.1 and 3.5.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users can cause pine4 to crash when closing a mail folder by
sending a malformed email.
If you have not chosen to install the pine4 port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the pine4 port/package, if you have installed it.
It may be possible to use a mail filtering utility such as procmail
(available in FreeBSD ports as /usr/ports/mail/procmail) to filter out
the malformed X-Keywords header from incoming mail, but this solution
is not discussed here.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the pine4 port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/pine-4.21.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/pine-4.21.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/pine-4.21.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/pine-4.21.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/pine-4.21.tgz
NOTE: Be sure to check the file creation date on the package, because
the version number of the software has not changed.
3) download a new port skeleton for the listmanager port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kgFUuHi5z0oilAQEwgAQAnYgLOfvgfM88DLjUXgoZBkVRoroeU8rz
2DXUw4LEQ6ARzruWPepALW2Yls+g5SraDCLHmuTo6tb3vR6kwQ97gQmzNCNDxK9T
/5m4EFYo2ErTOB4nO/MqepJ+/0t4oBPByhaRjQBSqQncaN4FIkWgboqfpbYdL6HC
cnQSlc+0FPs=
=R2n+
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:48.xchat.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:48 Security Advisory
FreeBSD, Inc.
Topic: xchat port inappropriately handles URLs
Category: ports
Module: xchat, xchat-devel
Announced: 2000-09-13
Affects: Ports collection.
Corrected: 2000-08-27
Vendor status: Updated version released
FreeBSD only: NO
I. Background
Xchat is a popular graphical IRC client.
II. Problem Description
The xchat IRC client provides the ability to launch URLs displayed in
an IRC window in a web browser by right clicking on the URL. However
this was handled incorrectly in versions prior to 1.4.3, and prior to
1.5.7 in the 1.5 development series, and allowed a malicious IRC user
to embed command strings in a URL which could cause an arbitrary
command to be executed as the local user if the URL were to be
"launched" in a browser as described above.
The xchat port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.0 and 3.5.1
contain this problem since it was discovered after the release.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote IRC users can cause an arbitrary command to be executed by the
local user, if they attempt to launch a malformed URL by right
clicking on it.
If you have not chosen to install the xchat or xchat-devel
ports/packages, then your system is not vulnerable to this problem.
IV. Workaround
Do not attempt to launch URLs which contain the ` (backtick) character.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the xchat or
xchat-devel port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/irc/xchat-1.4.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/irc/xchat-1.4.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/irc/xchat-1.4.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/irc/xchat-1.4.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/irc/xchat-1.4.3.tgz
3) download a new port skeleton for the xchat port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kBlUuHi5z0oilAQEoEgP+Lso/K6rgAVDeWfsfean7fmKVX1ViID0j
LUGlnLGohzSRC14W+21NIfChc0yl9gMmJRgkNHRLPkuyQBmdp8iHBsQlejjeq2PH
ZqSF6++V3YBqm4H7EgfaNKTk3wn0l/8w+dw3l9iMxmcS8P1oxo4lq04Ufao/N8TS
iCWpAmNQI44=
=0uMP
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:49.eject.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:49 Security Advisory
FreeBSD, Inc.
Topic: eject port allows local root exploit
Category: ports
Module: eject
Announced: 2000-09-13
Affects: Ports collection.
Corrected: 2000-08-21
Credits: Discovered during internal auditing
Vendor status: Contacted
FreeBSD only: NO
I. Background
Eject is a utility for ejecting the media from a CD or optical disk
drive.
II. Problem Description
The eject program is installed setuid root, and contains several
exploitable buffers which can be overflowed by local users, yielding
root privileges.
The eject port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.1 and 3.5.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged users can obtain root privileges on the local system.
If you have not chosen to install the eject port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the eject port/package, if you have installed it, or limit
the file permissions on the /usr/local/sbin/eject file (e.g. remove
setuid permission, or limit it to a trusted group)
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the eject port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/sysutils/eject-1.4.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/sysutils/eject-1.4.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/sysutils/eject-1.4.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/sysutils/eject-1.4.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/sysutils/eject-1.4.tgz
NOTE: Be sure to check the file creation date on the package, because
the version number of the software has not changed.
3) download a new port skeleton for the eject port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kCVUuHi5z0oilAQHfygP/d5QizD/ClKWD6MiKke2lspaI4sLTAKAh
QpnrJv2nF7tgK5DV+7X8J9f4dtSLippccwCscsvF8GT8d6RleP3dN0KfDRou/W/d
BVUgj2SfRNvsacbc8SyiaekT8ylne70WcYT93RrJ7vWbxTRXGEnOkbJD1rgDSksP
RLywyeVfI+U=
=G4Dr
-----END PGP SIGNATURE-----

96
share/security/advisories/FreeBSD-SA-00:50.listmanager.asc Normal file
View file

@ -0,0 +1,96 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:50 Security Advisory
FreeBSD, Inc.
Topic: listmanager port allows local root compromise
Category: ports
Module: listmanager
Announced: 2000-09-13
Affects: Ports collection.
Corrected: 2000-09-08
Credits: Discovered during internal auditing
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
Listmanager is a mailing list manager.
II. Problem Description
The listmanager port, versions prior to 2.105.1, contained several
locally exploitable buffer overflow vulnerabilities which could be
used to gain root privileges.
Since the source code to listmanager is not available, it is difficult
to determine whether there are remaining security vulnerabilities, or
whether the software was previously exploitable remotely, but we
believe the author has made a good faith effort to improve the
security of the code.
The listmanager port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.1 and 3.5.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged users can obtain root privileges on the local system.
If you have not chosen to install the listmanager port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the listmanager port/package, if you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the listmanager port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/listmanager-2.105.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/listmanager-2.105.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/listmanager-2.105.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/listmanager-2.105.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/listmanager-2.105.1.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the listmanager port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kC1UuHi5z0oilAQGUUwQArIH9EegIaatzGdjc9t1g8y7hKEajUTzC
Y5qeFxkOKosCMEEVfiZns6mo+nMuQsTwfxgthCnsCqX9PDXXAWrBjDOixmhp5nB3
3ro8UvTiivXIplzncCEbBWZocXCLZWLPV2uoemsr3Py9OZHmCeXKuqsX0OonIHDy
r+cAObdg7XA=
=YlxZ
-----END PGP SIGNATURE-----

90
share/security/advisories/FreeBSD-SA-00:51.mailman.asc Normal file
View file

@ -0,0 +1,90 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:51 Security Advisory
FreeBSD, Inc.
Topic: mailman port allows local root compromise
Category: ports
Module: mailman
Announced: 2000-09-13
Affects: Ports collection.
Corrected: 2000-08-05
Credits:
Vendor status: Updated version released.
FreeBSD only: NO
I. Background
Mailman is a mailing list manager.
II. Problem Description
The mailman port, versions prior to 2.0b5, contained several
locally exploitable vulnerabilities which could be used to gain root
privileges.
The mailman port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 3800 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.1 and 3.5.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged users can obtain root privileges on the local system.
If you have not chosen to install the mailman port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the mailman port/package, if you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the mailman port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/mailman-2.0b5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/mailman-2.0b5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/mailman-2.0b5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/mailman-2.0b5.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/mailman-2.0b5.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the listmanager port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOb/kDlUuHi5z0oilAQGvbAQAihAdHJMSq1ZyN71EzJ0FpBmzdgDYEIJ2
keMI1mMfgTgH3gxGnQ9POji6vdw+FxuB2QQuNJvvc8xAsbTLxq18kfeLjlRglc9+
rc23bwT83N5PVdQwJEMyvWugghxvT/3MYhnO3djNnpdep8jPmkAinjJWvVFcb50y
kRwD3IJtjUc=
=U45z
-----END PGP SIGNATURE-----

258
share/security/advisories/FreeBSD-SA-00:52.tcp-iss.asc Normal file
View file

@ -0,0 +1,258 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:52 Security Advisory
FreeBSD, Inc.
Topic: TCP uses weak initial sequence numbers
Category: core
Module: kernel
Announced: 2000-10-06
Credits: Hacker Emergency Response Team <hert@hert.org>
Affects: FreeBSD 3.x, 4.x and 5.x prior to the correction date
Corrected: 2000-09-28 (5.0-CURRENT, 4.1.1-STABLE, 3.5.1-STABLE)
FreeBSD only: NO
I. Background
TCP network connections use an initial sequence number as part of the
connection handshaking. According to the TCP protocol, an
acknowledgement packet from a remote host with the correct sequence
number is trusted to come from the remote system with which an
incoming connection is being established, and the connection is
established.
II. Problem Description
It has long been known that an attacker who can guess the initial
sequence number which a system will use for the next incoming TCP
connection can spoof a TCP connection handshake coming from a machine
to which he does not have access, and then send arbitrary data into
the resulting TCP connection which will be accepted by the server as
coming from the spoofed machine.
Systems derived from 4.4BSD-Lite2 including FreeBSD include code which
attempts to introduce an element of unpredictability into the initial
sequence numbers to prevent sequence number guessing by a remote
attacker. However the pseudo-random number generator used is a simple
linear congruent generator, and based on observations of a few initial
sequence values from legitimate connections with a server, an attacker
can guess with high probability the value which will be used for the
next connection.
In order for this to be successfully exploited, the attacker must also
satisfy the following conditions:
a) be able to initiate several consecutive TCP connections to an open
port on the server in a short space of time (immediately followed by
the attack itself). Quiescent servers (those which are not receiving
connections from other systems at the time of attack) are therefore
most vulnerable to the attack.
b) be able to prevent the spoofed client machine from responding to
the packets sent to it from the server, by making use of an address
which is offline or by executing a denial of service attack against
it to prevent it from responding.
c) make use of an application-level protocol on the server which
authenticates or grants trust solely based on the IP address of the
client, not any higher-level authentication mechanisms such as a
password or cryptographic key.
d) be able to guess or infer the return TCP data from the server to
the spoofed client (if any), to which he will not have access,
All versions of FreeBSD prior to the correction date including 4.1.1
and 3.5.1 are vulnerable to this problem.
The FreeBSD Security Officer would like to thank the Hacker Emergency
Response Team for working with us to bring this matter to our
attention, and to coordinate the release of this advisory.
III. Impact
Systems running insecure protocols which blindly trust a TCP
connection which appears to come from a given IP address without
requiring other authentication of the originator are vulnerable to
spoofing by a remote attacker, potentially yielding privileges or
access on the local system.
Examples of such protcols and services are: the rlogin/rsh/rexec
family when used to grant passwordless access (e.g. via .rhosts or
hosts.equiv files); web server address-based access controls on
scripts which do not require user authentication and which control
privileged resources; tcp-wrappers host access controls around
services which do not authenticate the connection further; lpr
address-based access controls, and others.
Note that the rlogin family of protocols when configured to use
Kerberos or UNIX passwords are not vulnerable to this attack since
they authenticate connections (using Kerberos tickets in the former
case, and account passwords in the latter). Source address based
authentication in the rlogin family of protocols is not used by
default, and must be specifically enabled through use of a per-user
.rhosts file, or a global /etc/hosts.equiv file.
Attackers can also forge TCP connections to arbitrary TCP protocols
(including protocols not vulnerable to the spoofing attack described
above) and simulate the effects of failed remote access attempts from
a target machine (e.g. repeated attempts to guess a password),
potentially misleading the administrators of the server into thinking
they are under attack from the spoofed client.
IV. Workaround
Note that in order to exploit the vulnerability an attacker must make
several real connection attempts in close succession to a port on the
target machine (e.g. a web server). Since in order for the attack to
be successful the machine must be quiescent (i.e. not accepting any
other connections), this rapid connection activity followed by a
connection to an insecure service may provide a signature which can be
used to detect and trace the attacker.
Possible workarounds for the vulnerability include one or both of the
following:
1) Disable all insecure protocols and services including rlogin, rsh
and rexec (if configured to use address-based authentication), or
reconfigure them to not authenticate connections based solely on
originating address. In general, the rlogin family should not be used
anyway - the ssh family of commands (ssh, scp, slogin) provide a
secure alternative which is included in FreeBSD 4.0 and above.
To disable the rlogin family of protocols, make sure the
/etc/inetd.conf file does not contain any of the following entries
uncommented (i.e. if present in the inetd.conf file they should be
commented out as shown below:)
#shell stream tcp nowait root /usr/libexec/rshd rshd
#login stream tcp nowait root /usr/libexec/rlogind rlogind
#exec stream tcp nowait root /usr/libexec/rexecd rexecd
Be sure to restart inetd by sending it a HUP signal after making any
changes:
# kill -HUP `cat /var/run/inetd.pid`
Audit the use of other services including those noted in section III
above and either disable the service, or if possible require it to use
a stronger form of authentication. See workaround 3) below.
2) Impose IP-level packet filters on network perimeters or on local
affected machines to prevent access from any outside party to a
vulnerable internal service using a "privileged" source address. For
example, if machines on the internal 10.0.0.0/24 network are allowed
to obtain passwordless rlogin access to a server, then external users
should be prevented from sending packets with 10.0.0.0/24 source
addresses from the outside network into the internal network. This is
standard good security policy. Note however that if an external
address must be granted access to local resources then this type of
filtering cannot be applied. It also does not defend against spoofing
attacks from within the network perimeter. Consider disabling this
service until the affected machines can be patched.
3) Enable the use of IPSEC to authenticate (and/or encrypt) vulnerable
TCP connections at the IP layer. A system which requires authenticaion
of all incoming connections to a port using IPSEC cannot be spoofed
using the attack described in this advisory, nor can TCP sessions be
hijacked by an attacker with access to the packet stream. FreeBSD 4.0
and later include IPSEC functionality in the kernel, and 4.1 and later
include an IKE daemon, racoon, in the ports collection. Configuration
of IPSEC is beyond the scope of this document, however see the
following web resources:
http://www.freebsd.org/handbook/ipsec.html
http://www.netbsd.org/Documentation/network/ipsec/
http://www.kame.net/
V. Solution
Note that address-based authentication is generally weak, and should
be avoided even in environments running with the sequence numbering
improvements. Instead, cryptographically-protected protocols and
services should be used wherever possible.
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or
3.5.1-STABLE after the respective correction dates.
2a) FreeBSD 3.x systems
Download the patch and detached PGP signature from the following
locations, and verify the signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.patch.asc
# cd /usr/src/sys/
# patch -p < /path/to/patch
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
2b) FreeBSD 4.x systems
Apply the patch below and recompile your kernel.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch.asc
# cd /usr/src/sys/netinet
# patch -p < /path/to/patch_or_advisory
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
Patch for vulnerable 4.x systems:
Index: tcp_seq.h
===================================================================
RCS file: /usr2/ncvs/src/sys/netinet/tcp_seq.h,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- tcp_seq.h 1999/12/29 04:41:02 1.11
+++ tcp_seq.h 2000/09/29 01:37:19 1.12
@@ -91,7 +91,7 @@
* number in the range [0-0x3ffff] that is hard to predict.
*/
#ifndef tcp_random18
-#define tcp_random18() ((random() >> 14) & 0x3ffff)
+#define tcp_random18() (arc4random() & 0x3ffff)
#endif
#define TCP_ISSINCR (122*1024 + tcp_random18())
Index: tcp_subr.c
===================================================================
RCS file: /usr2/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- tcp_subr.c 2000/09/25 23:40:22 1.80
+++ tcp_subr.c 2000/09/29 01:37:19 1.81
@@ -178,7 +178,7 @@
{
int hashsize;
- tcp_iss = random(); /* wrong, but better than a constant */
+ tcp_iss = arc4random(); /* wrong, but better than a constant */
tcp_ccgen = 1;
tcp_cleartaocache();
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOd5Gv1UuHi5z0oilAQEzJwQAkJbKJBJcaIYFbMuRnINbNQQS/mLUuRoh
fIzPEC17B2fwx+NjuHppBXroOsmsw0enM4tk7afP2yc3z2Ecyapr+oQH9KzBQ+nQ
56IGoi5/MLgEY2KQn3kQBV++pH9zo/F/Gz3XV/x2gDUgLy0F9p2eYjDGkrA1U1H2
NTx5kXB6ZE4=
=zdbr
-----END PGP SIGNATURE-----

297
share/security/advisories/FreeBSD-SA-00:53.catopen.asc Normal file
View file

@ -0,0 +1,297 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:53 Security Advisory
FreeBSD, Inc.
Topic: catopen() may pose security risk for third party code
Category: core
Module: libc
Announced: 2000-09-27
Affects: FreeBSD 5.0-CURRENT, 4.x and 3.x prior to the correction date.
Corrected: Problem 1: 2000-08-06 (FreeBSD 5.0-CURRENT)
2000-08-22 (FreeBSD 4.1-STABLE)
2000-09-07 (FreeBSD 3.5-STABLE)
Problem 2: 2000-09-08 (FreeBSD 5.0-CURRENT, 4.1-STABLE and
3.5-STABLE)
Credits: Problem 1: Discovered during internal auditing
Problem 2: Ivan Arce <iarce@core-sdi.com>
FreeBSD only: NO
I. Background
catopen() and setlocale() are functions which are used to display text
in a localized format, e.g. for international users.
II. Problem Description
There are two problems addressed in this advisory:
1) The catopen() function did not correctly bounds-check an internal
buffer which could be indirectly overflowed by the setting of an
environment variable. A privileged application which uses catopen()
could be made to execute arbitrary code by an unprivileged local user.
2) The catopen() and setlocale() functions could be made to use an
arbitrary file as the source for localized data and message catalogs,
instead of one of the system files. An attacker could create a file
which is a valid locale file or message catalog but which contains
special formatting characters which may allow certain badly written
privileged applications to be exploited and execute arbitrary code as
the privileged user.
This second vulnerability is slightly different from the problem
originally discovered by Ivan Arce of Core-SDI which affects multiple
UNIX operating systems, which involved a different environment
variable and which FreeBSD is not susceptible to. However
Vulnerability 2 was discovered in FreeBSD after the publication the
Core-SDI advisory, and has the same effect on vulnerable applications.
NOTE that the FreeBSD base system is not believed to be vulnerable to
either of these problems, nor are any vulnerable third party programs
(including FreeBSD ports) currently known. Therefore the impact on the
majority of FreeBSD systems is expected to be nonexistent.
III. Impact
Certain setuid/setgid third-party software (including FreeBSD
ports/packages) may be vulnerable to a local exploit yielding
privileged access. No such software is however currently known.
It is believed that no program in the FreeBSD base system is
vulnerable to these bugs.
The problems were corrected prior to the release of FreeBSD 4.1.1.
IV. Workaround
Vulnerability 1 described above is the more serious of the two, since
it does not require the application to contain a coding flaw in order
to exploit it. A scanning utility is provided to detect privileged
binaries which use the catopen() function (both statically and
dynamically linked binaries), which should be either rebuilt, or have
their privileges limited to minimize potential risk.
It is not feasible to detect binaries which are vulnerable to the
second vulnerability, however the provided utility will also report
statically linked binaries which use the setlocale() functions and
which *may* potentially be vulnerable. Most of the binaries reported
will not in fact be vulnerable, but should be recompiled anyway for
maximum assurance of security. Note that some FreeBSD system binaries
may be reported as possibly vulnerable by this script, however this
is not the case.
Statically linked binaries which are identified as vulnerable or
potentially vulnerable should be recompiled from source code after
patching and recompiling libc, if possible, in order to correct the
vulnerability. Dynamically linked binaries will be corrected by simply
patching and recompiling libc as described below.
As an interim measure, consider removing any identified setuid or
setgid binary, removing set[ug]id privileges from the file, or
limiting the file access permissions, as appropriate.
Of course, it is possible that some of the identified files may be
required for the correct operation of your local system, in which case
there is no clear workaround except for limiting the set of users who
may run the binaries, by an appropriate use of user groups and
removing the "o+x" file permission bit.
1) Download the 'scan_locale.sh' and 'test_locale.sh' scripts from
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:53/scan_locale.sh
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:53/test_locale.sh
e.g. with the fetch(1) command:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:53/scan_locale.sh
Receiving scan_locale.sh (337 bytes): 100%
337 bytes transferred in 0.0 seconds (1.05 MBps)
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:53/test_locale.sh
Receiving test_locale.sh (889 bytes): 100%
889 bytes transferred in 0.0 seconds (1.34 MBps)
2) Verify the md5 checksums and compare to the value below:
# /sbin/md5 scan_locale.sh
MD5 (scan_locale.sh) = efea80f74b05e7ddbc0261ef5211e453
# /sbin/md5 test_locale.sh
MD5 (test_locale.sh) = 2a485bf8171cc984dbc58b4d545668b4
3) Run the scan_locale.sh script against your system:
# sh scan_locale.sh ./test_locale.sh /
This will scan your entire system for setuid or setgid binaries which
make use of the exploitable function catopen(), or the potentially
exploitable function setlocale(). Each returned binary should be
examined (e.g. with 'ls -l' and/or other tools) to determine what
security risk it poses to your local environment, e.g. whether it can
be run by arbitrary local users who may be able to exploit it to gain
privileges.
Note that this script reports setlocale() usage (i.e. vulnerability 2)
only in statically linked binaries, not dynamically linked binaries,
because of the high rate of false positives. It is likely that the
majority of such setlocale() binaries identified are not insecure and
their identification by this script should not be taken as evidence
that they are vulnerable, but they should be recompiled anyway for
maximum assurance of security.
4) Remove the binaries, or reduce their file permissions, as appropriate.
V. Solution
Upgrade your vulnerable FreeBSD system to 4.1-STABLE or 3.5-STABLE
after the correction date, or patch your present system source code
and rebuild. Then run the scan_locale.sh script as instructed in
section IV and identify any statically-linked binaries as reported by
the script. These should either be removed, recompiled, or have
privileges restricted to secure them against this vulnerability (since
statically-linked binaries will not be affected by simply recompiling
the shared libc library).
To patch your present system: save the patch below into a file, and
execute the following commands as root:
cd /usr/src/lib/libc
patch < /path/to/patch/file
make all
make install
Patches for FreeBSD systems before the correction date:
Index: msgcat.c
===================================================================
RCS file: /usr2/ncvs//src/lib/libc/nls/msgcat.c,v
retrieving revision 1.21
retrieving revision 1.27
diff -u -r1.21 -r1.27
--- nls/msgcat.c 2000/01/27 23:06:33 1.21
+++ nls/msgcat.c 2000/09/01 11:56:31 1.27
@@ -91,8 +91,9 @@
__const char *catpath = NULL;
char *nlspath;
char *lang;
- long len;
char *base, *cptr, *pathP;
+ int spcleft;
+ long len;
struct stat sbuf;
if (!name || !*name) {
@@ -106,10 +107,10 @@
} else {
if (type == NL_CAT_LOCALE)
lang = setlocale(LC_MESSAGES, NULL);
- else {
- if ((lang = (char *) getenv("LANG")) == NULL)
- lang = "C";
- }
+ else
+ lang = getenv("LANG");
+ if (lang == NULL || strchr(lang, '/') != NULL)
+ lang = "C";
if ((nlspath = (char *) getenv("NLSPATH")) == NULL
#ifndef __NETBSD_SYSCALLS
|| issetugid()
@@ -129,13 +130,22 @@
*cptr = '\0';
for (pathP = path; *nlspath; ++nlspath) {
if (*nlspath == '%') {
+ spcleft = sizeof(path) - (pathP - path);
if (*(nlspath + 1) == 'L') {
++nlspath;
- strcpy(pathP, lang);
+ if (strlcpy(pathP, lang, spcleft) >= spcleft) {
+ free(base);
+ errno = ENAMETOOLONG;
+ return(NLERR);
+ }
pathP += strlen(lang);
} else if (*(nlspath + 1) == 'N') {
++nlspath;
- strcpy(pathP, name);
+ if (strlcpy(pathP, name, spcleft) >= spcleft) {
+ free(base);
+ errno = ENAMETOOLONG;
+ return(NLERR);
+ }
pathP += strlen(name);
} else *(pathP++) = *nlspath;
} else *(pathP++) = *nlspath;
@@ -186,7 +196,7 @@
MCSetT *set;
long lo, hi, cur, dir;
- if (!cat || setId <= 0) return(NULL);
+ if (cat == NULL || setId <= 0) return(NULL);
lo = 0;
if (setId - 1 < cat->numSets) {
@@ -212,8 +222,8 @@
if (hi - lo == 1) cur += dir;
else cur += ((hi - lo) / 2) * dir;
}
- if (set->invalid)
- (void) loadSet(cat, set);
+ if (set->invalid && loadSet(cat, set) <= 0)
+ return(NULL);
return(set);
}
@@ -225,7 +235,7 @@
MCMsgT *msg;
long lo, hi, cur, dir;
- if (!set || set->invalid || msgId <= 0) return(NULL);
+ if (set == NULL || set->invalid || msgId <= 0) return(NULL);
lo = 0;
if (msgId - 1 < set->numMsgs) {
@@ -318,7 +328,7 @@
off_t nextSet;
cat = (MCCatT *) malloc(sizeof(MCCatT));
- if (!cat) return(NLERR);
+ if (cat == NULL) return(NLERR);
cat->loadType = MCLoadBySet;
if ((cat->fd = _open(catpath, O_RDONLY)) < 0) {
@@ -351,7 +361,7 @@
cat->numSets = header.numSets;
cat->sets = (MCSetT *) malloc(sizeof(MCSetT) * header.numSets);
- if (!cat->sets) NOSPACE();
+ if (cat->sets == NULL) NOSPACE();
nextSet = header.firstSet;
for (i = 0; i < cat->numSets; ++i) {
Index: setlocale.c
===================================================================
RCS file: /home/ncvs/src/lib/libc/locale/setlocale.c,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- locale/setlocale.c 2000/09/04 03:43:24 1.27
+++ locale/setlocale.c 2000/09/08 07:29:48 1.28
@@ -129,7 +129,7 @@
if (!env || !*env)
env = getenv("LANG");
- if (!env || !*env)
+ if (!env || !*env || strchr(env, '/'))
env = "C";
(void) strncpy(new_categories[category], env, ENCODING_LEN);
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOdKTo1UuHi5z0oilAQH9QwQAhEdiXOU7A/hZpMBKU5bWz6alLqr7o4wp
YcypPTnSoMQ2OkFlmuX9sdcgRfwl3gZ1z3QfjhE/eXG7rYSerEyxqcBqgQOBbCUH
vURxPEIRqV90DMMZAp62viA1X1Vyx/Ie2WXG/r5Wck1/Zu6BSxsUo3yiWD4gFoVb
L1f0kBgl2/A=
=YtCH
-----END PGP SIGNATURE-----

142
share/security/advisories/FreeBSD-SA-00:54.fingerd.asc Normal file
View file

@ -0,0 +1,142 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:54 Security Advisory
FreeBSD, Inc.
Topic: fingerd allows remote reading of filesystem
Category: core
Module: fingerd
Announced: 2000-10-13
Credits: NIIMI Satoshi <sa2c@and.or.jp>
Affects: FreeBSD 4.1.1-RELEASE
Corrected: 2000-10-05 (4.1.1-STABLE)
FreeBSD only: Yes
I. Background
The finger service is used to provide information about users on the
system to remote clients.
II. Problem Description
Shortly before the release of FreeBSD 4.1.1, code was added to
finger(1) intended to allow the utility to send the contents of
administrator-specified files in response to a finger request. However
the code incorrectly allowed users to specify a filename directly, the
contents of which would be returned to the user.
The finger daemon usually runs as user 'nobody' and invokes the
finger(1) command in response to a remote request, meaning it does not
have access to privileged files on the system (such as the hashed
password file /etc/master.passwd), however the vulnerability may be
used to read arbitrary files to which the 'nobody' user has read
permission. This may disclose internal information including
information which may be used to mount further attacks against the
system.
Note that servers running web and other services often incorrectly run
these as the 'nobody' user, meaning this vulnerability may be used to
read internal web server data such as web server password files, the
source code to cgi-bin scripts, etc.
FreeBSD 4.1-RELEASE, 4.0-RELEASE, 3.5.1-RELEASE and FreeBSD 4.1-STABLE
systems dated before 2000-09-01 or after 2000-10-05 are unaffected by
this vulnerability.
III. Impact
Remote users can obtain read access (as the 'nobody' user) to large
parts of the local filesystem on systems running a vulnerable
fingerd. This may disclose confidential information and may facilitate
further attacks on the system.
IV. Workaround
Disable the finger protocol in /etc/inetd.conf: make sure the
/etc/inetd.conf file does not contain the following entry
uncommented (i.e. if present in the inetd.conf file it should be
commented out as shown below:)
#finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
On IPv6-connected systems, be sure to disable the IPv6 instance of the
finger daemon as well:
#finger stream tcp6 nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE dated after
the correction date.
2) Apply the patch below and rebuild your fingerd binary.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:54/fingerd.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:54/fingerd.patch.asc
# cd /usr/src/usr.bin/finger
# patch -p < /path/to/patch_or_advisory
# make all install
# cd /usr/src/libexec/fingerd
# make all install
Patch for vulnerable 4.1.x systems:
Index: finger.c
===================================================================
RCS file: /home/ncvs/src/usr.bin/finger/finger.c,v
retrieving revision 1.15.2.3
retrieving revision 1.21
diff -u -r1.15.2.3 -r1.21
--- finger.c 2000/09/15 21:51:00 1.15.2.3
+++ finger.c 2000/10/05 15:56:13 1.21
@@ -293,6 +293,16 @@
goto net;
/*
+ * Mark any arguments beginning with '/' as invalid so that we
+ * don't accidently confuse them with expansions from finger.conf
+ */
+ for (p = argv, ip = used; *p; ++p, ++ip)
+ if (**p == '/') {
+ *ip = 1;
+ warnx("%s: no such user", *p);
+ }
+
+ /*
* Traverse the finger alias configuration file of the form
* alias:(user|alias), ignoring comment lines beginning '#'.
*/
@@ -323,11 +333,11 @@
* gathering the traditional finger information.
*/
if (mflag)
- for (p = argv; *p; ++p) {
- if (**p != '/' || !show_text("", *p, "")) {
+ for (p = argv, ip = used; *p; ++p, ++ip) {
+ if (**p != '/' || *ip == 1 || !show_text("", *p, "")) {
if (((pw = getpwnam(*p)) != NULL) && !hide(pw))
enter_person(pw);
- else
+ else if (!*ip)
warnx("%s: no such user", *p);
}
}
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOebB4FUuHi5z0oilAQEE1AP+I7zDBn5TagYJEELea7ltGkNZ5h3nZi5E
FwxqYekriycAzOqctwzu7lO2AO7KoPTzAfu4OCd+s+ijK+zpXkt+eOAttbhPwENJ
RMAJPwcGr139mIT2ofuEUhtE9NZ66gg7WNh+8ixjtovKbZl1W/slX+wOqlaCcbLm
U4t3bj6bx5M=
=fg83
-----END PGP SIGNATURE-----

96
share/security/advisories/FreeBSD-SA-00:55.xpdf.asc Normal file
View file

@ -0,0 +1,96 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:55 Security Advisory
FreeBSD, Inc.
Topic: xpdf contains multiple vulnerabilities
Category: ports
Module: xpdf
Announced: 2000-10-13
Credits: Unknown
Affects: Ports collection prior to the correction date.
Corrected: 2000-09-04 (4.1.1-RELEASE)
Vendor status: Updated version released
FreeBSD only: NO
I. Background
xpdf is a PDF viewer for X Windows.
II. Problem Description
The xpdf port, versions prior to 0.91, contains a race condition due
to improper handing of temporary files that may allow a local user to
overwrite arbitrary files owned by the user running xpdf.
Additionally, when handling URLs in documents no checking was done for
shell metacharacters before starting the browser. This makes it possible
to construct a document which cause xpdf to run arbitrary commands when
the user views an URL.
The xpdf port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
nearly 4000 third-party applications in a ready-to-install format.
The ports collections shipped with FreeBSD 3.5.1 and 4.1 contain this
problem since it was discovered after the releases, but it was
corrected prior to the release of FreeBSD 4.1.1.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users, using a symlink attack, can cause arbitrary files owned
by the user running xpdf to be overwritten. Also, malicious PDFs can
cause arbitrary code to be executed.
If you have not chosen to install the xpdf port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the xpdf port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the xpdf port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/graphics/xpdf-0.91.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/graphics/xpdf-0.91.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/graphics/xpdf-0.91.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/graphics/xpdf-0.91.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/graphics/xpdf-0.91.tgz
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOebCfVUuHi5z0oilAQEcuAP8DYr3RrCnnysWYS3eVyNJ1sokvXOXZdhZ
hI8ialbbpKY+kEtnL0DrUmeJ9c5xsVb70XJQ3D80n8O2N8I9ZAbfiHadY+omZPZX
Hpk47MuA3R4G6jXldnyq545/QdK3+uKMLkNiGG63P5VcyUsQ3bpB1uIRIX/a9U6Z
rdQfL0s3N0k=
=qh/t
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:56.lprng.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:56 Security Advisory
FreeBSD, Inc.
Topic: LPRng contains potential root compromise
Category: ports
Module: LPRng
Announced: 2000-10-13
Credits: Chris Evans <chris@SCARY.BEASTS.ORG>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-13
Vendor status: Updated version released
FreeBSD only: NO
I. Background
LPRng is a popular printer daemon.
II. Problem Description
The LPRng port, versions prior to 3.6.24, contains a potential
vulnerability which may allow root compromise from both local and
remote systems. The vulnerability is due to incorrect usage of the
syslog(3) function. Local and remote users can send string-formatting
operators to the printer daemon to corrupt the daemon's execution,
potentially gaining root access.
The LPRng port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains nearly 4000 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1, 4.1 and
4.1.1 contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local and remote users may potentially gain root privileges on systems
using LPRng.
If you have not chosen to install the LPRng port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the LPRng port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the LPRng port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/sysutils/LPRng-3.6.25.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/sysutils/LPRng-3.6.25.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/sysutils/LPRng-3.6.25.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/sysutils/LPRng-3.6.25.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/sysutils/LPRng-3.6.25.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOebCc1UuHi5z0oilAQGIrwP+I0aP9pZOMT4FbOar8NpMExmeQXNr74+e
euwWeJZszDNe4p0a2yGB9Xn4CrkQZNhwZKUoDzk1K9RrDxNwjwT7gouKMGgn38Lr
OIQLi2FZqgT0cbnGusdK4sxbQZl2AnPkEunQOskeXhCbZX97wMQOjDid72ZXxNAR
l+KW/XexpuQ=
=Ew7y
-----END PGP SIGNATURE-----

97
share/security/advisories/FreeBSD-SA-00:57.muh.asc Normal file
View file

@ -0,0 +1,97 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:57 Security Advisory
FreeBSD, Inc.
Topic: muh IRC bouncer remote vulnerability
Category: ports
Module: muh
Announced: 2000-10-13
Credits: Maxime Henrion <mux@QUALYS.COM>
Affects: Ports collection prior to the correction date.
Corrected: 2000-09-10 (4.1.1-RELEASE)
Vendor status: Updated version released
FreeBSD only: NO
I. Background
muh is an IRC bouncer, a program that allows a host to act as a relay
between an IRC client on a local/remote machine and the IRC server.
II. Problem Description
The muh port, versions 2.05c and before, contains a vulnerability
which allows remote users to gain the privileges of the user running
muh. This is accomplished by sending a carefully crafted exploit
string containing string format operators to a user using muh but who
is not connected. When the user reconnects and executes '/muh read',
muh will allow the remote attacker to execute arbitrary code as the
local user.
The muh port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
nearly 4000 third-party applications in a ready-to-install format.
The ports collections shipped with FreeBSD 3.5.1 and 4.1 contain this
problem since it was discovered after the releases, but it was
corrected prior to the release of FreeBSD 4.1.1.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote IRC users can cause arbitrary code to be executed as the user
running muh.
If you have not chosen to install the muh port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the muh port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the muh port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/irc/muh-2.05c.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/irc/muh-2.05c.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/irc/muh-2.05c.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/irc/muh-2.05c.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/irc/muh-2.05c.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBOebDhVUuHi5z0oilAQE/3wP+K6oPSZ4jsnLAILhZD3fjdp+3bW7IhDmQ
PoXpqSyEypJ6TlP0wLaZwhz1VPThAN9yVaUTzA7W8MVQyKCdIDBWu86WmcZ4CsY9
v7ku77tshEcxza+ggegy9PkSWYDfaQIyGzRyZht280qxn5XUFIeEvXkx+YHKvffo
Rm4dlo/akzA=
=0bP+
-----END PGP SIGNATURE-----

111
share/security/advisories/FreeBSD-SA-00:58.chpass.asc Normal file
View file

@ -0,0 +1,111 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:58 Security Advisory
FreeBSD, Inc.
Topic: chpass family contains local root vulnerability
Category: core
Module: chfn/chpass/chsh/ypchfn/ypchpass/ypchsh/passwd
Announced: 2000-10-30
Credits: Problem fixed during internal auditing.
Vulnerability pointed out by: caddis <caddis@DISSENSION.NET>
Affects: FreeBSD 3.x (all releases), FreeBSD 4.0-RELEASE,
FreeBSD 4.0-STABLE prior to the correction date
Corrected: 2000/07/20 (FreeBSD 4.0-STABLE)
2000/10/04 (FreeBSD 3.5.1-STABLE)
FreeBSD only: NO
I. Background
ch{fn,pass,sh} are utilities for changing user "finger" information,
passwords, and login shell, respectively. The yp* variants perform the
analogous changes on a NIS account.
II. Problem Description
A "format string vulnerability" was discovered in code used by the
vipw utility during an internal FreeBSD code audit in July 2000. The
vipw utility does not run with increased privileges and so it was
believed at the time that it did not represent a security
vulnerability. However it was not realised that this code is also
shared with other utilities -- namely chfn, chpass, chsh, ypchfn,
ypchpass, ypchsh and passwd -- which do in fact run setuid root.
Therefore, the problem may be exploited by unprivileged local users to
gain root access to the local machine.
All versions of FreeBSD prior to the correction date including 4.0 and
3.5.1 are vulnerable to this problem, but it was fixed in the 4.x
branch prior to the release of FreeBSD 4.1.
III. Impact
Local users can obtain root privileges on the local machine.
IV. Workaround
Remove the setuid bit on the following utilities. This has the
side-effect that non-root users cannot change their finger
information, passwords, or login shells.
# chflags noschg /usr/bin/chfn /usr/bin/chpass /usr/bin/chsh
# chmod u-s /usr/bin/chfn /usr/bin/chpass /usr/bin/chsh
# chflags noschg /usr/bin/ypchfn /usr/bin/ypchpass /usr/bin/ypchsh
# chmod u-s /usr/bin/ypchfn /usr/bin/ypchpass /usr/bin/ypchsh
# chflags noschg /usr/bin/passwd
# chmod u-s /usr/bin/passwd
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1-RELEASE,
4.1.1-RELEASE, 4.1.1-STABLE or 3.5.1-STABLE after the respective
correction dates.
2) Apply the patch below and recompile the respective files:
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:58/vipw.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:58/vipw.patch.asc
Execute the following commands as root:
# cd /usr/src/usr.sbin/vipw
# patch -p < /path/to/patch_or_advisory
# make depend && make all install
# cd /usr/src/usr.bin/chpass/
# make depend && make all install
# cd /usr/src/usr.bin/passwd/
# make depend && make all install
Patch for vulnerable systems:
--- pw_util.c 1999/08/28 01:20:31 1.17
+++ pw_util.c 2000/07/12 00:49:40 1.18
@@ -250,7 +250,7 @@
extern int _use_yp;
#endif /* YP */
if (err)
- warn(name);
+ warn("%s", name);
#ifdef YP
if (_use_yp)
warnx("NIS information unchanged");
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOf3/FFUuHi5z0oilAQEAhAQApmUnWU8Se8V6rAsy98jJLBXp11mmCnaB
lVPve0SjOEhTjYVOfLEslDIPECP1WNrO3Ep/FiczhoTVrMBzWjh74XIGaiDbRxEy
UDWh/cQhAaEmy/KPwraoPas6T2lsJ9brBu5LycKQj/F2SMYCNQOQ3UK4rmXqmf+z
jAqmmerfaPo=
=YNNN
-----END PGP SIGNATURE-----

105
share/security/advisories/FreeBSD-SA-00:59.pine.asc Normal file
View file

@ -0,0 +1,105 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:59 Security Advisory
FreeBSD, Inc.
Topic: pine4 port contains remote vulnerability
Category: ports
Module: pine4/pine4-ssl/zh-pine4/iw-pine4
Announced: 2000-10-30
Affects: Ports collection.
Corrected: 2000-10-29
Credits: arkane@SPEAKEASY.ORG
Vendor status: Contacted
FreeBSD only: NO
I. Background
Pine is a popular mail user agent.
II. Problem Description
The pine4 port, versions 4.21 and before, contains a buffer overflow
vulnerability which allows a remote user to execute arbitrary code on
the local client by the sending of a special-crafted email
message. The overflow occurs during the periodic "new mail" checking
of an open folder.
The pine4 port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4000 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 4.1.1 and 3.5.1
contain this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
Administrators should note that the Pine software has been a frequent
source of past security holes, and makes extensive use of string
routines commonly associated with security vulnerabilities. The
FreeBSD Security Officer believes it is likely that further
vulnerabilities exit in this software, and recommends the use of
alternative mail software in environments where electronic mail may be
received from untrusted sources.
III. Impact
Remote users can cause pine4 to crash when closing a mail folder by
sending a malformed email.
If you have not chosen to install the pine4 port/package, then
your system is not vulnerable to this problem.
IV. Workaround
Deinstall the pine4 port/package, if you have installed it.
The risk can be decreased by not leaving pine sitting idle with an
open folder, but it cannot be completely eliminated without patching
and recompiling the software.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the pine4 port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/mail/pine-4.21_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/mail/pine-4.21_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/mail/pine-4.21_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/mail/pine-4.21_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/mail/pine-4.21_1.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the listmanager port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOf3+NVUuHi5z0oilAQHjFQQAmVrnuMQbQwPKf8LVdsNFgc6470e8Lz07
+8OTApKVTzX1WVbBNQUTJ8tC0TSiZt/BTOq41EVHc+yP6W8gJWPWmGJHMH2vtd2q
/5X1o+Q17IP2doXuDBT2MUJH7simUJBPbZ9Fi+AuI+lecCx80Q9W9qndEypdwpwZ
j01EAufwmMk=
=nefD
-----END PGP SIGNATURE-----

101
share/security/advisories/FreeBSD-SA-00:60.boa.asc Normal file
View file

@ -0,0 +1,101 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:60 Security Advisory
FreeBSD, Inc.
Topic: boa web server allows arbitrary file access/execution
Category: ports
Module: boa
Announced: 2000-10-30
Credits: Lluis Mora <llmora@S21SEC.COM>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-07
Vendor status: Updated version released
FreeBSD only: NO
I. Background
Boa is a high-performance web server.
II. Problem Description
The boa port, versions after 0.92 but prior to 0.94.8.3, contains a
vulnerability which allows remote users to view arbitrary files
outside the document root. The vulnerability is that boa does not
correctly restrict URL-encoded requests containing ".." in the path.
In addition, if the administrator has enabled CGI extension support, a
request for any file ending in .cgi will result in the file being
executed with the privileges of the user id running the web server.
Since the .cgi file may reside outside the document root, this may
result in untrusted binaries/scripts being executed. If an attacker
can upload files to the system, e.g. via anonymous FTP, they can cause
arbitrary code to be executed by the user running the web server.
The boa port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 4000 third-party applications in a ready-to-install format.
The ports collections shipped with FreeBSD 3.5.1 and 4.1.1 contain
this problem since it was discovered after the releases.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users may view any file on the system that is accessible by the
webserver account. In addition, the webserver account may be
compromised due to the execution of arbitrary files outside the
document root.
If you have not chosen to install the boa port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the boa port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the boa port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/boa-0.94.8.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/boa-0.94.8.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/boa-0.94.8.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/boa-0.94.8.3.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/boa-0.94.8.3.tgz
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOf3+LlUuHi5z0oilAQHuAAP+PB/Y6PwDyWZrfvX5cKRdnQiwebU2FPiS
BhKSwjwBsE4jZGFw0YC+tU6TksGhun6LvvIw0DVHXRevH0VwPcf18akuqKQrFhPA
r3NQ1atFvrdDoGQN0J4px1vANXKPu6afe1LKaMTeF+sbjokoniScnAFyH9IHBvQH
mVUcDXhq7sU=
=WmZ+
-----END PGP SIGNATURE-----

112
share/security/advisories/FreeBSD-SA-00:61.tcpdump.asc Normal file
View file

@ -0,0 +1,112 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:61 Security Advisory
FreeBSD, Inc.
Topic: tcpdump contains remote vulnerabilities [REISSUED]
Category: core
Module: tcpdump
Announced: 2000-10-31
Reissued: 2000-11-06
Credits: Discovered during internal auditing.
Affects: All releases of FreeBSD 3.x, 4.x prior to 4.2
FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior to the
correction date
Corrected: 2000-10-04 (FreeBSD 4.1.1-STABLE)
2000-10-05 (FreeBSD 3.5.1-STABLE)
Vendor status: Patch released
FreeBSD only: NO
0. Revision History
v1.0 2000-10-31 Initial release
v1.1 2000-11-06 Corrected patch
I. Background
tcpdump is a tool for monitoring network activity.
II. Problem Description
Several overflowable buffers were discovered in the version of tcpdump
included in FreeBSD, during internal source code auditing. Some
simply allow the remote attacker to crash the local tcpdump process,
but there is a more serious vulnerability in the decoding of AFS ACL
packets in the more recent version of tcpdump (tcpdump 3.5) included
in FreeBSD 4.0-RELEASE, 4.1-RELEASE and 4.1.1-RELEASE, which may allow
a remote attacker to execute arbitrary code on the local system
(usually root, since root privileges are required to run tcpdump).
The former issue may be a problem for systems using tcpdump as a form
of intrusion detection system, i.e. to monitor suspicious network
activity: after the attacker crashes any listening tcpdump processes
their subsequent activities will not be observed.
All released versions of FreeBSD prior to the correction date
including 3.5.1-RELEASE, 4.0-RELEASE, 4.1-RELEASE and 4.1.1-RELEASE
are vulnerable to the "remote crash" problems, and FreeBSD
4.0-RELEASE, 4.1-RELEASE and 4.1.1-RELEASE are also vulnerable to the
"remote execution" vulnerability. Both problems were corrected in
4.1.1-STABLE prior to the release of FreeBSD 4.2-RELEASE.
III. Impact
Remote users can cause the local tcpdump process to crash, and (under
FreeBSD 4.0-RELEASE, 4.1-RELEASE, 4.1.1-RELEASE and 4.1.1-STABLE prior
to the correction date) may be able to cause arbitrary code to be
executed as the user running tcpdump, usually root.
IV. Workaround
Do not use vulnerable versions of tcpdump in network environments
which may contain packets from untrusted sources.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or
3.5.1-STABLE after the respective correction dates.
2a) FreeBSD 3.x systems prior to the correction date
Download the patch and the detached PGP signature from the following
locations, and verify the signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:61/tcpdump-3.x.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:61/tcpdump-3.x.patch.asc
# cd /usr/src/contrib/tcpdump
# patch -p < /path/to/patch
# cd /usr/src/usr.sbin/tcpdump
# make depend && make all install
2b) FreeBSD 4.x systems prior to the correction date
NOTE: The patch distributed with the original version of this advisory
was incomplete and did not include all of the security fixes made to
the tcpdump utility. In particular, it did not address the remote code
execution vulnerability.
Download the patch and the detached PGP signature from the following
locations, and verify the signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:61/tcpdump-4.x.patch.v1.1
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:61/tcpdump-4.x.patch.v1.1.asc
# cd /usr/src/contrib/tcpdump
# patch -p < /path/to/patch
# cd /usr/src/usr.sbin/tcpdump
# make depend && make all install
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgcNKFUuHi5z0oilAQGYQAP9F00eE4rd0M46f8WMWTO7uFb1gV2p4Y0l
KV0vT1wMy+PdmFNpo7SVrb/tdpa4Wtxb/Q/tu7RDZQqFI29yBPTFnE1iu8T2BSAm
cO/dE5ypkjJkEjf8QjxqQXVhTbtIVVQa3Tosw3AdUFP0gKHUkZ36ryCQVxbqRMQK
c0ZkdbwESp8=
=uaOo
-----END PGP SIGNATURE-----

154
share/security/advisories/FreeBSD-SA-00:62.top.asc Normal file
View file

@ -0,0 +1,154 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:62 Security Advisory
FreeBSD, Inc.
Topic: top allows reading of kernel memory [REISSUED]
Category: core
Module: top
Announced: 2000-11-01
Reissued: 2000-11-06
Credits: vort@wiretapped.net via OpenBSD
Affects: FreeBSD 3.x (all releases), FreeBSD 4.x (all releases prior
to 4.2), FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior
to the correction date.
Corrected: 2000-11-04 (FreeBSD 4.1.1-STABLE)
2000-11-05 (FreeBSD 3.5.1-STABLE)
FreeBSD only: NO
0. Revision History
v1.0 2000-11-01 Initial release
v1.1 2000-11-06 Updated patch released.
I. Background
top is a utility for displaying current system resource statistics
such as process CPU and memory use. It is externally-maintained,
contributed software which is included in FreeBSD by default.
II. Problem Description
A "format string vulnerability" was discovered in the top(1) utility
which allows unprivileged local users to cause the top process to
execute arbitrary code. The top utility runs with increased
privileges as a member of the kmem group, which allows it to read from
kernel memory (but not write to it). A process with the ability to
read from kernel memory can monitor privileged data such as network
traffic, disk buffers and terminal activity, and may be able to
leverage this to obtain further privileges on the local system or on
other systems, including root privileges.
All released versions of FreeBSD prior to the correction date
including 4.0, 4.1, 4.1.1 and 3.5.1 are vulnerable to this problem,
but it was fixed in the 4.1.1-STABLE branch prior to the release of
FreeBSD 4.2-RELEASE.
III. Impact
Local users can read privileged data from kernel memory which may
provide information allowing them to further increase their local or
remote system access privileges.
IV. Workaround
Remove the setgid bit on the top utilities. This has the side-effect
that users who are not a member of the kmem group or who are not the
superuser cannot use the top utility.
# chmod g-s /usr/bin/top
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or
3.5.1-STABLE after the respective correction dates.
2) Apply the patch below and recompile the relevant files:
NOTE: The original version of this advisory contained an incomplete
patch which does not fully eliminate the security vulnerability. The
additional vulnerability was pointed out by Przemyslaw Frasunek
<venglin@freebsd.lublin.pl>.
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:62/top.patch.v1.1
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:62/top.patch.v1.1.asc
Execute the following commands as root:
# cd /usr/src/contrib/top
# patch -p < /path/to/patch_or_advisory
# cd /usr/src/usr.bin/top
# make depend && make all install
Patch for vulnerable systems:
Index: display.c
===================================================================
RCS file: /mnt/ncvs/src/contrib/top/display.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- display.c 1999/01/09 20:20:33 1.4
+++ display.c 2000/10/04 23:34:16 1.5
@@ -829,7 +831,7 @@
register int i;
/* first, format the message */
- (void) sprintf(next_msg, msgfmt, a1, a2, a3);
+ (void) snprintf(next_msg, sizeof(next_msg), msgfmt, a1, a2, a3);
if (msglen > 0)
{
Index: top.c
===================================================================
RCS file: /mnt/ncvs/src/contrib/top/top.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- top.c 1999/01/09 20:20:34 1.4
+++ top.c 2000/10/04 23:34:16 1.5
@@ -807,7 +809,7 @@
{
if ((errmsg = kill_procs(tempbuf2)) != NULL)
{
- new_message(MT_standout, errmsg);
+ new_message(MT_standout, "%s", errmsg);
putchar('\r');
no_command = Yes;
}
Index: top.c
===================================================================
RCS file: /mnt/ncvs/src/contrib/top/top.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- top.c 2000/10/04 23:34:16 1.5
+++ top.c 2000/11/03 22:00:10 1.6
@@ -826,7 +826,7 @@
{
if ((errmsg = renice_procs(tempbuf2)) != NULL)
{
- new_message(MT_standout, errmsg);
+ new_message(MT_standout, "%s", errmsg);
putchar('\r');
no_command = Yes;
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgcN7lUuHi5z0oilAQFqJgP/bn4SN6FaNvazYMaVzypsEgWzofK/kdlu
iWXcdZVkoFZlF4J7e6M/wRn0xS1lvNPlv5yNF4bYa7lnZHeNzS/58v94+Sze2ooV
bgML9JzhfaM0Ps+/mAXO4FzGi+WryTkdZGl9KVkwT+QwuRer/bz4GoJvnrsGuBpf
dXoovvpgwiA=
=hVPb
-----END PGP SIGNATURE-----

124
share/security/advisories/FreeBSD-SA-00:63.getnameinfo.asc Normal file
View file

@ -0,0 +1,124 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:63 Security Advisory
FreeBSD, Inc.
Topic: getnameinfo function allows remote denial of service
Category: core
Module: libc
Announced: 2000-11-01
Credits: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>
Affects: FreeBSD 4.x (all releases prior to 4.2), 4.1.1-STABLE prior
to the correction date.
Corrected: 2000/09/25 (FreeBSD 4.1.1-STABLE)
FreeBSD only: NO
I. Background
The getnameinfo() function is part of the protocol-independent
resolver library from the KAME project.
II. Problem Description
An off-by-one error exists in the processing of DNS hostnames which
allows a long DNS hostname to crash the getnameinfo() function when an
address resolution of the hostname is performed (e.g. in response to a
connection to a service which makes use of getnameinfo()).
Under the following conditions, this bug can be used as a denial of
service attack against vulnerable services:
* The attacker must control their DNS server.
* The service must be run as a persistent daemon (i.e. running
"standalone", not spawned as-needed from a supervisor process such
as inetd)
* The daemon must perform the getnameinfo() call on the remote
hostname prior to forking a child process to handle the connection
(otherwise it is just the child process which dies, and the parent
remains running).
* The daemon is not automatically restarted by a "watchdog" process.
All released versions of FreeBSD 4.x prior to the correction date
including 4.0, 4.1, and 4.1.1 are vulnerable to this problem, but it
was fixed in the 4.1.1-STABLE branch prior to the release of FreeBSD
4.2-RELEASE. The FreeBSD 3.x branch is unaffected since it does not
include the KAME code.
Note that this vulnerability is not believed to pose a vulnerability
for any servers included in the FreeBSD base system. It is only a
potential problem for certain third party servers fulfilling the above
conditions (none of which are currently known). Therefore the impact
on the vast majority of FreeBSD systems is expected to be nonexistent.
III. Impact
Remote users may be able to cause a very small class of network
servers to terminate abnormally, causing a denial of service
condition.
IV. Workaround
None practical.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD 4.x system to 4.1.1-STABLE after
the correction date.
2) Apply the patch below and recompile the relevant files:
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:63/getnameinfo.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:63/getnameinfo.patch.asc
Execute the following commands as root:
# cd /usr/src/lib/libc
# patch -p < /path/to/patch_or_advisory
# make depend && make all install
Patch for vulnerable systems:
--- net/getnameinfo.c 2000/07/05 05:09:17 1.5
+++ net/getnameinfo.c 2000/09/25 23:04:36 1.6
@@ -154,12 +153,12 @@
(flags & NI_DGRAM) ? "udp" : "tcp");
}
if (sp) {
- if (strlen(sp->s_name) > servlen)
+ if (strlen(sp->s_name) + 1 > servlen)
return ENI_MEMORY;
strcpy(serv, sp->s_name);
} else {
snprintf(numserv, sizeof(numserv), "%d", ntohs(port));
- if (strlen(numserv) > servlen)
+ if (strlen(numserv) + 1 > servlen)
return ENI_MEMORY;
strcpy(serv, numserv);
}
@@ -253,7 +252,7 @@
*p = '\0';
}
#endif
- if (strlen(hp->h_name) > hostlen) {
+ if (strlen(hp->h_name) + 1 > hostlen) {
freehostent(hp);
return ENI_MEMORY;
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgCgVlUuHi5z0oilAQGqfwP/SYLG0yD0uR4wdPHy5S9eXH4HqtNrVpF7
NlN3iMjHrzIDqeFSYoRTbMEhrbTTGMWYIEadadW9zjlnHfGNRniYx2oOhm+0tqsI
C3wlqsGAo2GXsXfr1hOpcVc1GqLhsK3oLgz9RRMoMlRWJ+K0bHHLwKlB9uEoxPJ2
X/WHJ//RQXI=
=YFwv
-----END PGP SIGNATURE-----

106
share/security/advisories/FreeBSD-SA-00:64.global.asc Normal file
View file

@ -0,0 +1,106 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:64 Security Advisory
FreeBSD, Inc.
Topic: global port allows remote compromise through CGI script
Category: ports
Module: global
Announced: 2000-11-06
Credits: Shigio Yamaguchi <shigio@tamacom.com>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-09
Vendor status: Updated version released
FreeBSD only: NO
I. Background
global is a source-code tagging system for indexing and searching
large bodies of source code.
II. Problem Description
The global port, versions 3.5 through to 3.55, contains a
vulnerability in the CGI script generated by the htags utility which
allows a remote attacker to execute code on the local system as the
user running the script, typically user 'nobody' in most
installations.
There is no vulnerability in the default installation of the port, but
if an administrator uses the 'htags -f' command to generate a CGI
script enabling the browsing of source code, then the system is
vulnerable to attack caused by incorrect validation of input.
An older version of global was included in previous releases of
FreeBSD; this is not vulnerable to the problem described here.
The global port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1
contain this problem since it was discovered after the releases, but
it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
If the 'htags -f' command is used to generate a CGI script which is
then installed under a webserver, then remote users may execute
arbitrary commands on the local system as the user which runs the CGI
script.
If you have not chosen to install the global port/package, or you have
not used the 'htags -f' command to produce a CGI script, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the global port/package, if you you have installed it, or
remove the 'global.cgi' file installed on the website.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the global port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/global-4.0.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/global-4.0.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/global-4.0.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/global-4.0.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/global-4.0.1.tgz
3) download a new port skeleton for the cvsweb port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgcQslUuHi5z0oilAQHKXAP/Wz2SmgOAIYFOquE3z+++5nbNxKYmKS/J
Tb1ClUtPSSk6s/dfX3t17O1o0a/Pmj3u+CxAdRXdIka1XAQE9lY2pL4uhEVr0nXT
/+I4Hap17OZVdNTTiF/a6LYd/WYbJkMrRbADnZjvRp5zrOpPwbzc1ZwIn9GRqiHc
XYA/cWGGWXg=
=+ex8
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:65.xfce.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:65 Security Advisory
FreeBSD, Inc.
Topic: xfce allows local X session compromise
Category: ports
Module: xfce
Announced: 2000-11-06
Credits: Nicholas Brawn <nickbrawn@ONETEL.COM>
Affects: Ports collection prior to the correction date.
Corrected: 2000-11-01
Vendor status: Updated version released
FreeBSD only: NO
I. Background
xfce is a window manager/desktop environment for the X Windows system.
II. Problem Description
Versions of xfce prior to 3.52 contain a startup script which
incorrectly allows access to the X display to all other users on the
local system. Such users are able to monitor and control the contents
of the display window as well as monitoring input from keyboard and
mouse devices. For example, this allows them to monitor passphrases
typed into a terminal window, among other possibilities.
The xfce port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 4100 third-party applications in a ready-to-install format. The
ports collections shipped with FreeBSD 3.5.1 and 4.1.1 are vulnerable
to this problem since it was discovered after the releases, but it was
corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Local users can monitor and control the contents of the X display
running xfce, as well as input devices such as mice and keyboards.
IV. Workaround
Deinstall the xfce port/package, if you you have installed it, or
remove the lines containing 'xhost +$HOSTNAME' in the following files:
/usr/X11R6/etc/xfce/xinitrc
/usr/X11R6/etc/xfce/xinitrc.mwm
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the xfce port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from the following directories:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/x11-wm/xfce-3.12.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/x11-wm/xfce-3.12.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/x11-wm/xfce-3.12.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/x11-wm/xfce-3.12.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/x11-wm/xfce-3.12.tgz
3) download a new port skeleton for the xfce port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgdCalUuHi5z0oilAQEwxwP+OoowcV51kn3hHjcFWZRk2GAIw/mu6gxP
GsLscf2IMAX+dyJG+sNtpzktsrMsIFcv5ADjNjhW+WAqqGhNCosV6cQ8/BNi0+m4
o4Mqyc3jsYBkWzzXd/W6y4EWStup+7/iz/68DPdIUHs1IyfFQ7DiCgWXzZBo8GG1
6muI/XYYm6Q=
=Ioj2
-----END PGP SIGNATURE-----

97
share/security/advisories/FreeBSD-SA-00:66.netscape.asc Normal file
View file

@ -0,0 +1,97 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:66 Security Advisory
FreeBSD, Inc.
Topic: Client vulnerability in Netscape
Category: ports
Module: netscape
Announced: 2000-11-06
Credits: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-29
Vendor status: Updated version released
FreeBSD only: NO
I. Background
Netscape is a popular web browser, available in several versions in
the FreeBSD ports collection.
II. Problem Description
Versions of netscape prior to 4.76 allow a client-side exploit through
a buffer overflow in html code. A malicious website operator can cause
arbitrary code to be executed by the user running the netscape client.
The netscape ports are not installed by default, nor are they "part of
FreeBSD" as such: they are part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1 are
vulnerable to this problem since it was discovered after the release,
but it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote attackers can execute arbitrary code on the local system by
convincing users to visit a malicious website.
If you have not chosen to install the netscape port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the netscape port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the relevant
netscape port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from the following directories:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/
Since there are so many variations of the netscape ports in the
FreeBSD ports collection they are not listed separately
here. Localized versions are also available in the respective language
subdirectory.
3) download a new port skeleton for the netscape port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgdCqFUuHi5z0oilAQFMFgQAjrqHzfVCD2oLCya0budGincSy+e6onfi
XCMqyf8sAeEO5Bg4klVhkTMKCCPo9MEeLNWm3EwQHU4bN8wxD9NUHkYrVgNCsD8b
rN34aAogoJR1fsfN960OW9EHWH8trPJDlC6IS1KYOmpOL8AuBfmbahL1vSx5TtZP
vPFky0dFwKg=
=mKdp
-----END PGP SIGNATURE-----

92
share/security/advisories/FreeBSD-SA-00:67.gnupg.asc Normal file
View file

@ -0,0 +1,92 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:67 Security Advisory
FreeBSD, Inc.
Topic: gnupg fails to correctly verify signatures
Category: ports
Module: gnupg
Announced: 2000-11-10
Credits: Jim Small <cavenewt@MY-DEJA.COM>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-18
Vendor status: Updated version released
FreeBSD only: NO
I. Background
GnuPG is an implementation of the PGP digital signature/encryption
protocol.
II. Problem Description
Versions of gnupg prior to 1.04 fail to correctly verify multiple
signatures contained in a single document. Only the first signature
encountered is actually verified, meaning that other data with invalid
signatures (e.g. data which has been tampered with by an attacker)
will not be verified, and the entire document will be treated as
having valid signatures.
The gnupg port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1 are
vulnerable to this problem since it was discovered after the releases,
but it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Documents containing multiple signed regions of data can be corrupted
or tampered with by an attacker without detection, as long as the
first signature in the document remains valid.
IV. Workaround
Deinstall the gnupg port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the gnupg port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from the following directories:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/security/gnupg-1.04.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/security/gnupg-1.04.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/security/gnupg-1.04.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/security/gnupg-1.04.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/security/gnupg-1.04.tgz
3) download a new port skeleton for the gnupg port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOgx6dlUuHi5z0oilAQEGaAP+KXIJlLBgF7tXXtLWcyJkhI6mAxgMyHEJ
y+9RkI22mz7etMN1Nqm22Rj1cYBO99Q35lx4qJpuGftuRV+D9P6f5FbXMp+qhw24
K1t07eQhgiiNO1y9snvvEwwWtsHiosMFyIleFdbJwXoioqNsDFcByOwbG7zoEOOU
BfDBTmKtPvQ=
=1ZMA
-----END PGP SIGNATURE-----

214
share/security/advisories/FreeBSD-SA-00:68.ncurses.asc Normal file
View file

@ -0,0 +1,214 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:68 Security Advisory
FreeBSD, Inc.
Topic: ncurses allows local privilege escalation [REVISED]
Category: core, ports
Module: ncurses
Announced: 2000-11-13
Revised: 2000-11-20
Affects: FreeBSD 5.0-CURRENT, 4.x prior to the correction date.
FreeBSD 3.x not yet fixed.
Corrected: 2000-10-11 (FreeBSD 4.1.1-STABLE)
2000-11-10 (ncurses port)
Credits: Jouko Pynnonen <jouko@SOLUTIONS.FI>
FreeBSD only: NO
0. Revision History
v1.0 2000-11-13 Initial release
v1.1 2000-11-20 Corrected status of 3.x, referenced ncurses port
I. Background
ncurses is a text-mode display library used for formatting the output
of applications on a variety of terminals. It is externally
maintained, contributed code which is included in FreeBSD by default.
II. Problem Description
There exists an overflowable buffer in the libncurses library in the
processing of cursor movement capabilities. An attacker can force a
privileged application to use the attacker's termcap file containing a
specially crafted terminal entry, which will trigger the vulnerability
when the vulnerable ncurses code is called. This allows them to
execute arbitrary code on the local system with the privileges of the
exploited binary.
The systat utility included in the FreeBSD base system is known to use
vulnerable ncurses routines. It runs with increased privileges as a
member of the kmem group, which allows it to read from kernel memory
(but not write to it). A process with the ability to read from kernel
memory can monitor privileged data such as network traffic, disk
buffers and terminal activity, and may be able to leverage this to
obtain further privileges on the local system or on other systems,
including root privileges.
There may be other vulnerable applications included in the FreeBSD
base system, but no others are confirmed to be vulnerable due to the
difficulty in identifying a complete list of vulnerable ncurses
functions. However the following is a complete list of FreeBSD system
binaries which link against ncurses and run with increased
privileges. They may or may not be vulnerable to exploitation.
/usr/sbin/lpc
/usr/bin/top
/usr/bin/systat
FreeBSD 3.x and earlier versions use a very old, customized version of
ncurses which is difficult to update without breaking
backwards-compatibility. The update was made for FreeBSD 4.0, but 3.x
will not be updated to the newer version. At this stage the
vulnerability has not been fixed in FreeBSD 3.x.
The ncurses port (versions prior to 5.2) also contains this
vulnerability. It was corrected prior to the release of FreeBSD 4.2.
III. Impact
Certain setuid/setgid software (including FreeBSD base system
utilities and third party ports/packages) may be vulnerable to a local
exploit yielding privileged access.
The /usr/bin/systat utility is known to be vulnerable to this problem
in ncurses. At this time is unknown whether /usr/bin/top and
/usr/sbin/lpc are also affected.
The problems were corrected prior to the release of FreeBSD 4.2.
IV. Workaround
It is not feasible to reliably detect binaries which are vulnerable to
the ncurses vulnerability, however the provided utility will scan for
privileged binaries which use ncurses and which may potentially be
vulnerable. Some of the binaries reported may not in fact be
vulnerable, but should be recompiled anyway for maximum assurance of
security.
Statically linked binaries which are identified as potentially
vulnerable should be recompiled from source code if possible, after
patching and recompiling libc, in order to correct the vulnerability.
Dynamically linked binaries will be corrected by simply patching and
recompiling libc as described below.
As an interim measure, consider removing any identified setuid or
setgid binary, removing set[ug]id privileges from the file, or
limiting the file access permissions, as appropriate.
Of course, it is possible that some of the identified files may be
required for the correct operation of your local system, in which case
there is no clear workaround except for limiting the set of users who
may run the binaries, by an appropriate use of user groups and
removing the "o+x" file permission bit.
1) Download the 'scan_ncurses.sh' and 'test_ncurses.sh' scripts from
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/scan_ncurses.sh
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/test_ncurses.sh
e.g. with the fetch(1) command:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/scan_ncurses.sh
Receiving scan_ncurses.sh (381 bytes): 100%
381 bytes transferred in 0.1 seconds (7.03 kBps)
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/tools/SA-00:68/test_ncurses.sh
Receiving test_ncurses.sh (604 bytes): 100%
604 bytes transferred in 0.1 seconds (6.55 kBps)
2) Verify the md5 checksums and compare to the value below:
# md5 scan_ncurses.sh
MD5 (scan_ncurses.sh) = 597f63af701253f053581aa1821cbac1
# md5 test_ncurses.sh
MD5 (test_ncurses.sh) = 12491ceb15415df7682e3797de53223e
3) Run the scan_ncurses.sh script against your system:
# chmod a+x ./test_ncurses.sh
# sh scan_ncurses.sh ./test_ncurses.sh /
This will scan your entire system for setuid or setgid binaries which
make use of the ncurses library. Each returned binary should be
examined (e.g. with 'ls -l' and/or other tools) to determine what
security risk it poses to your local environment, e.g. whether it can
be run by arbitrary local users who may be able to exploit it to gain
privileges.
4) Remove the binaries, or reduce their file permissions, as appropriate.
V. Solution
Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE after the
correction date, or patch your present system source code and
rebuild. Then run the scan_ncurses.sh script as instructed in section
IV and identify any statically-linked binaries as reported by the
script. These should either be removed, recompiled, or have privileges
restricted to secure them against this vulnerability (since
statically-linked binaries will not be affected by simply recompiling
the shared libc library).
To patch your present system: download the updated ncurses code from
the below location, and execute the following commands as root:
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:68/ncurses.tar.gz
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:68/ncurses.tar.gz.asc
Verify the detached PGP signature using your PGP utility.
cd /usr/src
tar xvfz /path/to/ncurses.tar.gz
cd /usr/src/lib/libncurses
make all
make install
In contrast to the usual practise, a simple patch fixing the security
vulnerability is not provided because the vendor did not make one
available, and the updated ncurses snapshot which fixed it contains
numerous other changes whose purpose and relation to the fix was
unclear.
[ncurses port]
If you have installed a vulnerable version of the ncurses port, one of
the following steps may be used to upgrade it:
1) Upgrade your entire ports collection and rebuild the ncurses port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/ncurses-5.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/ncurses-5.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/ncurses-5.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/ncurses-5.2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/ncurses-5.2.tgz
3) download a new port skeleton for the ncurses port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmaFlUuHi5z0oilAQG5MwP9FStZoFKPCqfciIbIcFrE0wLYuEOeI24S
j9D4rSwU1ALzHB7DMpeXmju5pDRROmgUTIOGnBN9FcXZly4lDN3Y9yyIeW6Ia5UZ
wWbkhxsn573kD3P00WHAB1F1ccbbK4+SPNLkdJDgyyqAC4SdgeJEg5+z+Wcx7d3E
t/Xsv/X1ylA=
=ZiMW
-----END PGP SIGNATURE-----

231
share/security/advisories/FreeBSD-SA-00:69.telnetd.asc Normal file
View file

@ -0,0 +1,231 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:69 Security Advisory
FreeBSD, Inc.
Topic: telnetd allows remote system resource consumption [REVISED]
Category: core
Module: telnetd
Announced: 2000-11-14
Revised: 2000-11-20
Credits: Jouko Pynnonen <jouko@SOLUTIONS.FI>
Affects: FreeBSD 3.x (all releases), FreeBSD 4.x (all releases prior
to 4.2), FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior
to the correction date.
Corrected: 2000-11-19 (FreeBSD 4.1.1-STABLE)
2000-11-19 (FreeBSD 3.5.1-STABLE)
FreeBSD only: NO
0. Revision History
v1.0 2000-11-14 Initial release
v1.1 2000-11-20 Corrected patch, pointed out by
Christos Zoulas <christos@ZOULAS.COM>
I. Background
telnetd is the server for the telnet remote login protocol.
II. Problem Description
The telnet protocol allows for UNIX environment variables to be passed
from the client to the user login session on the server. However, some
of these environment variables have special meaning to the telnetd
child process itself and may be used to affect its operation.
Of particular relevance is the ability for remote users to cause an
arbitrary file on the system to be searched for termcap data by
passing the TERMCAP environment variable. Although any file on the
local system can be read since the telnetd server runs as root, the
contents of the file will not be reported in any way to the remote
user unless it contains a valid termcap entry, in which case the
corresponding termcap sequences will be used to format the output sent
to the client. It is believed there is no risk of data disclosure
through this vulnerability.
However, an attacker who forces the server to search through a large
file or to read from a device can cause resources to be spent by the
server, including CPU cycles and disk read bandwidth, which can
increase the server load and may prevent it from servicing legitimate
user requests. Since the vulnerability occurs before the login(1)
utility is spawned, it does not require authentication to a valid
account on the server in order to exploit.
All released versions of FreeBSD prior to the correction date
including 4.0, 4.1, 4.1.1 and 3.5.1 are vulnerable to this problem,
but it was fixed in the 4.1.1-STABLE branch prior to the release of
FreeBSD 4.2-RELEASE.
III. Impact
Remote users without a valid login account on the server can cause
resources such as CPU and disk read bandwidth to be consumed, causing
increased server load and possibly denying service to legitimate
users.
IV. Workaround
1) Disable the telnet service, which is usually run out of inetd:
comment out the following lines in /etc/inetd.conf, if present.
telnet stream tcp nowait root /usr/libexec/telnetd telnetd
telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd
2) Impose access restrictions using TCP wrappers (/etc/hosts.allow),
or a network-level packet filter such as ipfw(8) or ipf(8) on the
perimeter firewall or the local machine, to limit access to the telnet
service to trusted machines.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or
3.5.1-STABLE after the respective correction dates. Note that the
original patch was incorrect and caused telnetd to behave incorrectly
in certain situations.
2) Apply the patch below and recompile the relevant files:
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:69/telnetd.patch.v1.1
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:69/telnetd.patch.v1.1.asc
Execute the following commands as root:
# cd /usr/src/libexec/telnetd
# patch -p < /path/to/patch_or_advisory
# make depend && make all install
Updated patch for vulnerable systems:
Index: ext.h
===================================================================
RCS file: /home/ncvs/src/libexec/telnetd/ext.h,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ext.h 1999/08/28 00:10:22 1.7
+++ ext.h 2000/11/19 10:01:27 1.8
@@ -87,7 +87,7 @@
#endif
extern int pty, net;
-extern char *line;
+extern char line[16];
extern int SYNCHing; /* we are in TELNET SYNCH mode */
#ifndef P
Index: sys_term.c
===================================================================
RCS file: /home/ncvs/src/libexec/telnetd/sys_term.c,v
retrieving revision 1.24
retrieving revision 1.26
diff -u -r1.24 -r1.26
--- sys_term.c 1999/08/28 00:10:24 1.24
+++ sys_term.c 2000/11/19 10:01:27 1.26
@@ -480,14 +480,10 @@
*
* Returns the file descriptor of the opened pty.
*/
-#ifndef __GNUC__
-char *line = "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
-#else
-static char Xline[] = "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
-char *line = Xline;
-#endif
#ifdef CRAY
-char *myline = "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";
+char myline[16];
+#else
+char line[16];
#endif /* CRAY */
int
@@ -1799,6 +1795,13 @@
strncmp(*cpp, "_RLD_", 5) &&
strncmp(*cpp, "LIBPATH=", 8) &&
#endif
+ strncmp(*cpp, "LOCALDOMAIN=", 12) &&
+ strncmp(*cpp, "RES_OPTIONS=", 12) &&
+ strncmp(*cpp, "TERMINFO=", 9) &&
+ strncmp(*cpp, "TERMINFO_DIRS=", 14) &&
+ strncmp(*cpp, "TERMPATH=", 9) &&
+ strncmp(*cpp, "TERMCAP=/", 9) &&
+ strncmp(*cpp, "ENV=", 4) &&
strncmp(*cpp, "IFS=", 4))
*cpp2++ = *cpp;
}
Index: telnetd.c
===================================================================
RCS file: /home/ncvs/src/libexec/telnetd/telnetd.c,v
retrieving revision 1.22
retrieving revision 1.24
diff -u -r1.22 -r1.24
--- telnetd.c 2000/01/25 14:52:00 1.22
+++ telnetd.c 2000/11/19 10:01:27 1.24
@@ -805,13 +805,12 @@
#else
for (;;) {
char *lp;
- extern char *line, *getpty();
if ((lp = getpty()) == NULL)
fatal(net, "Out of ptys");
if ((pty = open(lp, 2)) >= 0) {
- strcpy(line,lp);
+ strlcpy(line,lp,sizeof(line));
line[5] = 't';
break;
}
@@ -1115,7 +1114,7 @@
IM = Getstr("im", &cp);
IF = Getstr("if", &cp);
if (HN && *HN)
- (void) strcpy(host_name, HN);
+ (void) strlcpy(host_name, HN, sizeof(host_name));
if (IF && (if_fd = open(IF, O_RDONLY, 000)) != -1)
IM = 0;
if (IM == 0)
Index: utility.c
===================================================================
RCS file: /home/ncvs/src/libexec/telnetd/utility.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- utility.c 1999/08/28 00:10:25 1.13
+++ utility.c 2000/10/31 05:29:54 1.14
@@ -330,7 +330,7 @@
{
char buf[BUFSIZ];
- (void) sprintf(buf, "telnetd: %s.\r\n", msg);
+ (void) snprintf(buf, sizeof(buf), "telnetd: %s.\r\n", msg);
(void) write(f, buf, (int)strlen(buf));
sleep(1); /*XXX*/
exit(1);
@@ -343,7 +343,7 @@
{
char buf[BUFSIZ], *strerror();
- (void) sprintf(buf, "%s: %s", msg, strerror(errno));
+ (void) snprintf(buf, sizeof(buf), "%s: %s", msg, strerror(errno));
fatal(f, buf);
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmZhlUuHi5z0oilAQECjQP/RJyFP/msuoNj1ebyeE4PjXHFV99FoVIY
jeBCjheFN+9kVR2ZqGxzhF8Ds1jsHI2oURhjNwRkf+OGNzCfDKEseTa0/Aa59XG5
68O9DKP2CEZnNra3N5uWCBX7ozGI1iCfJkBstSXBhdpyeumOjhfkEF1cwvJldyWl
YMIWv/MwRWs=
=wuWd
-----END PGP SIGNATURE-----

129
share/security/advisories/FreeBSD-SA-00:70.ppp-nat.asc Normal file
View file

@ -0,0 +1,129 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:70 Security Advisory
FreeBSD, Inc.
Topic: ppp "deny_incoming" does not correctly deny incoming packets
Category: core
Module: ppp
Announced: 2000-11-14
Credits: Robin Melville <robmel@innotts.co.uk>
Affects: FreeBSD 3.5, 3.5.1, 4.1, 4.1.1
FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior to the
correction date.
Corrected: 2000-10-30 (FreeBSD 4.1.1-STABLE)
2000-10-30 (FreeBSD 3.5.1-STABLE)
FreeBSD only: Yes
I. Background
The ppp(8) utility includes network address translation functionality
for translating between public and private IP address ranges. It uses
the libalias library to perform translation services.
II. Problem Description
The "nat deny_incoming" command is documented as "refusing all
incoming connections" and is commonly used as a simple "firewall" to
prevent outside users from connecting to services on the internal
network. However the behaviour of the ppp code was changed in the 4.x
and 3.x branches prior to the release of FreeBSD 4.1 and 3.5 (on
2000-06-05 and 2000-06-03 respectively) to allow passing of packets
which are not understood, such as IPSEC packets and other IP protocol
traffic not explicitly recognised by the code as being an "incoming
connection attempt". While this was arguably incorrect behaviour in
itself, the code also incorrectly allowed through ALL incoming
traffic, effectively turning "deny_incoming" into a no-op.
Thus, users who are using the deny_incoming functionality in the
expectation that it provides a "deny by default" firewall which only
allows through packets known to be part of an existing NAT session,
are in fact allowing other types of unsolicited IP traffic into their
internal network.
The behaviour of ppp was corrected to only allow incoming packets
which are known to be part of a valid NAT session, which gives the
desired packet filtering behaviour in the general case. Outgoing IP
traffic which is not understood by libalias (such as an outgoing IPSEC
packet part of a VPN) will cause a NAT session to be established which
will allow incoming packets with the corresponding source and
destination IP addresses and protocol number to pass, but all others
to be denied.
This behaviour may be sufficient for the security needs of many users,
although users with advanced filtering or security policy requirements
are advised to use a more configurable packet filter such as those
provided by ipfw(8) or ipf(8) which can meet their needs.
The following released versions of FreeBSD are the only releases
vulnerable to this problem: 3.5, 3.5.1, 4.1, 4.1.1. It was fixed in
the 4.1.1-STABLE branch prior to the release of FreeBSD 4.2-RELEASE.
III. Impact
Remote users can cause incoming traffic which is not part of an
existing NAT session to pass the NAT gateway, which may constitute a
breach of security policy.
IV. Workaround
Use a true packet filter such as ipfw(8) or ipf(8) on the PPP gateway
to deny incoming traffic according to the desired security policy.
V. Solution
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or
3.5.1-STABLE after the respective correction dates.
2) Apply the patch below and recompile the relevant files:
Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:70/ppp.patch.asc
Execute the following commands as root:
# cd /usr/src/usr.sbin/ppp
# patch -p < /path/to/patch_or_advisory
# make depend && make all install
Patch for vulnerable systems:
Index: nat_cmd.c
===================================================================
RCS file: /mnt/ncvs/src/usr.sbin/ppp/nat_cmd.c,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
- --- nat_cmd.c 2000/07/11 22:11:31 1.49
+++ nat_cmd.c 2000/10/30 18:02:01 1.50
@@ -421,7 +421,11 @@
break;
case PKT_ALIAS_IGNORED:
- - if (log_IsKept(LogTCPIP)) {
+ if (PacketAliasSetMode(0, 0) & PKT_ALIAS_DENY_INCOMING) {
+ log_Printf(LogTCPIP, "NAT engine denied data:\n");
+ m_freem(bp);
+ bp = NULL;
+ } else if (log_IsKept(LogTCPIP)) {
log_Printf(LogTCPIP, "NAT engine ignored data:\n");
PacketCheck(bundle, MBUF_CTOP(bp), bp->m_len, NULL, NULL, NULL);
}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhG88FUuHi5z0oilAQFcaAP8D9gkr5GbGfj0visocGTMzKmhbXCwtgVX
B5qwVdDKYSx3sAicK32gsnKdxJYno5D7Vd8ic0/N28DfuR+rw7tyGKPkgZZQiptL
CTODBugeHFV/XZ3CyES+orkRN78Wgc6kBZtvyudaXtYHbzRo2K48acOGnQN/X4tR
Tt613Vl57rY=
=SCKm
-----END PGP SIGNATURE-----

100
share/security/advisories/FreeBSD-SA-00:71.mgetty.asc Normal file
View file

@ -0,0 +1,100 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:71 Security Advisory
FreeBSD, Inc.
Topic: mgetty can create or overwrite files
Category: ports
Module: mgetty
Announced: 2000-11-20
Credits: Stan Bubrouski <satan@FASTDIAL.NET>
Affects: Ports collection prior to the correction date.
Corrected: 2000-9-10
Vendor status: Updated version released
FreeBSD only: NO
I. Background
mgetty is a replacement for the getty utility designed for use with
data and fax modems.
II. Problem Description
The mgetty port, versions prior to 1.1.22.8.17, contains a
vulnerability that may allow local users to create or overwrite any
file on the system. This is due to the faxrunqd daemon (which usually
runs as root) following symbolic links when creating a .last_run file
in the world-writable /var/spool/fax/outgoing/ directory.
This presents a denial of service attack since the attacker can cause
critical system files to be overwritten, but it is not believed the
attacker has the ability to control the contents of the overwritten
file. Therefore the possibility of using this attack to elevate
privileges is believed to be minimal.
The mgetty port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1
contain this problem since it was discovered after the releases, but
it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Unprivileged local users may create or overwrite any file on the
system.
If you have not chosen to install the mgetty port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the mgetty port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the mgetty port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/comms/mgetty-1.1.22.8.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/comms/mgetty-1.1.22.8.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/comms/mgetty-1.1.22.8.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/comms/mgetty-1.1.22.8.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/comms/mgetty-1.1.22.8.17.tgz
3) download a new port skeleton for the mgetty port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmWG1UuHi5z0oilAQE5jAP+Lj1qI76n/cHjmfR05NTckZ4EI1Fkt708
zZfEL9B4y8FCgluw9nLNhVKHYjkQFg/b0SEgBetElPu+k6ivcu9EqI2Gk4RIyT82
HJFqOOnvX2yodMgZo1NozEot3aw3DIQg8TFs0Z/w0E4e+02iCytPmZYfrE5vbWif
q1qAcFpgJWE=
=l2yv
-----END PGP SIGNATURE-----

91
share/security/advisories/FreeBSD-SA-00:72.curl.asc Normal file
View file

@ -0,0 +1,91 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:72 Security Advisory
FreeBSD, Inc.
Topic: curl client-side vulnerability
Category: ports
Module: curl
Announced: 2000-11-20
Credits: Wichert Akkerman <wichert@cistron.nl>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-30
Vendor status: Updated version released
FreeBSD only: NO
I. Background
curl is a multi-protocol file retrieval tool.
II. Problem Description
The curl port, versions prior to 7.4.1, allows a client-side exploit
through a buffer overflow in the error handling code. A malicious ftp
server operator can cause arbitrary code to be executed by the user
running the curl client.
The curl port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 4100 third-party applications in a ready-to-install format.
The ports collections shipped with FreeBSD 3.5.1 and 4.1.1 contain
this problem since it was discovered after the releases, but it was
corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Malicious FTP server operators can execute arbitrary code on the local
system when a file is downloaded from this server.
If you have not chosen to install the curl port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the curl port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the curl port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ftp/curl-7.4.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ftp/curl-7.4.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/ftp/curl-7.4.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/ftp/curl-7.4.1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/ftp/curl-7.4.1.tgz
3) download a new port skeleton for the curl port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmXtlUuHi5z0oilAQGoWwP8D4Do6NX9PMIrCaky4BU4rj37l5PO7kHn
h94zc2ISFpX5IBceUDCbVNjJJPkA8hXHhWXHZulpruu6yza/V9Oo3Uz86HrzY4Tw
7Rj3iwQ/5/wJW3Ya/BcnBozk1/NlnAxGzKluTOlHe8UCFPV8JtCrE5RPRHMQ3BP8
IN3EDVdvLzw=
=EQge
-----END PGP SIGNATURE-----

95
share/security/advisories/FreeBSD-SA-00:73.thttpd.asc Normal file
View file

@ -0,0 +1,95 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:73 Security Advisory
FreeBSD, Inc.
Topic: thttpd allows remote reading of local files
Category: ports
Module: thttpd
Announced: 2000-11-20
Credits: ghandi@MINDLESS.COM
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-30
Vendor status: Updated version released
FreeBSD only: NO
I. Background
thttpd is a simple, small, fast HTTP server.
II. Problem Description
The thttpd port, versions prior to 2.20, allows remote viewing of
arbitrary files on the local server. The 'ssi' cgi script does not
correctly restrict URL-encoded requests containing ".." in the path.
In addition, the cgi script does not have the same restrictions as the
web server for preventing requests outside of the web root. These two
flaws allow remote users to access any file on the system accessible
to the web server user (user 'nobody' in the default configuration).
The thttpd port is not installed by default, nor is it "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1
contain this problem since it was discovered after the releases, but
it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Remote users may access any file on the system accessible to the web
server user (user 'nobody' in the default installation).
If you have not chosen to install the thttpd port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the thttpd port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the thttpd port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/thttpd-2.20b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/thttpd-2.20b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/thttpd-2.20b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/thttpd-2.20b.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/thttpd-2.20b.tgz
3) download a new port skeleton for the thttpd port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmWNFUuHi5z0oilAQF1sQP9Fc/jBFjSNhzGIGc+bglEOiepdajSk3Ep
wtoLUQJug56qcbUtxgg6FxbDv7xW/uYZ1YKWYQsjAr0tyYv+zTSVgvxAhREY1En2
TIqrRTjTPir5yAodzsVvueTdjVhgQhWKHlrNMUKK3hfWoeLXiLhtFTDn8jam/2pO
tw8I3tWT16I=
=+HRv
-----END PGP SIGNATURE-----

94
share/security/advisories/FreeBSD-SA-00:74.gaim.asc Normal file
View file

@ -0,0 +1,94 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:74 Security Advisory
FreeBSD, Inc.
Topic: gaim remote vulnerability
Category: ports
Module: gaim
Announced: 2000-11-20
Credits: Stan Bubrouski <stan@CCS.NEU.EDU>
Affects: Ports collection prior to the correction date.
Corrected: 2000-11-16
Vendor status: Updated version released
FreeBSD only: NO
I. Background
gaim is a popular AOL Instant Messenger client.
II. Problem Description
The gaim port, versions prior to 0.10.3_1, allows a client-side
exploit through a buffer overflow in the HTML parsing code. This
vulnerability may allow remote users to execute arbitrary code as the
user running gaim.
The gaim port is not installed by default, nor is it "part of FreeBSD"
as such: it is part of the FreeBSD ports collection, which contains
over 4100 third-party applications in a ready-to-install format. The
ports collections shipped with FreeBSD 3.5.1 and 4.1.1 contain this
problem since it was discovered after the releases, but it was
corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Malicious remote users may execute arbitrary code as the user running
gaim.
If you have not chosen to install the gaim port/package, then your
system is not vulnerable to this problem.
IV. Workaround
Deinstall the gaim port/package, if you you have installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the gaim port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/net/gaim-0.10.3_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/net/gaim-0.10.3_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/net/gaim-0.10.3_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/net/gaim-0.10.3_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/net/gaim-0.10.3_1.tgz
NOTE: It may be several days before updated packages are available.
3) download a new port skeleton for the gaim port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmWVVUuHi5z0oilAQGDvwP+LYld3QmBByW+w9LkQ6wKLtaqFqWO+dEL
1JQm44OEVgWX01btMuyVvso9iqn3bCVHE8CatXPp4mnwEgR29lu2taU7ilKWOxwX
Odh9Q+XrWGaCRP/LkiPYUVpsc1gwoBpqEdrGjbv2LhIg04uyd/W1rwEfSPtOZUNW
3ISE4DYF7RQ=
=Yt3k
-----END PGP SIGNATURE-----

112
share/security/advisories/FreeBSD-SA-00:75.php.asc Normal file
View file

@ -0,0 +1,112 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:75 Security Advisory
FreeBSD, Inc.
Topic: mod_php3/mod_php4 allows remote code execution
Category: ports
Module: mod_php3/mod_php4
Announced: 2000-11-20
Credits: Jouko Pynnönen <jouko@SOLUTIONS.FI>
Affects: Ports collection prior to the correction date.
Corrected: 2000-10-12 (mod_php4), 2000-10-18 (mod_php3)
Vendor status: Updated version released
FreeBSD only: NO
I. Background
php is a commonly used HTML-embedded scripting language.
II. Problem Description
The mod_php ports, versions prior to 3.0.17 (mod_php3) and 4.0.3
(mod_php4), contain a potential vulnerablilty that may allow a
malicious remote user to execute arbitrary code as the user running
the web server, typically user 'nobody'. The vulnerability is due to
a format string vulnerability in the error logging routines.
A web server is vulnerable if error logging is enabled in php.ini.
Additionally, individual php scripts may cause the web server to be
vulnerable if the script uses the syslog() php function regardless of
error logging in php.ini.
The mod_php ports are not installed by default, nor are they "part of
FreeBSD" as such: it is part of the FreeBSD ports collection, which
contains over 4100 third-party applications in a ready-to-install
format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1
contain this problem since it was discovered after the releases, but
it was corrected prior to the release of FreeBSD 4.2.
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
III. Impact
Malicious remote users can execute arbitrary code on the local system
as the user running the webserver (typically user 'nobody'). This
vulnerability requires error logging to be enabled in php.ini or by
using the syslog() php function in a script.
If you have not chosen to install the mod_php3 or mod_php4
port/package, then your system is not vulnerable to this problem.
IV. Workaround
Deinstall the mod_php3/mod_php4 port/package, if you you have
installed it.
V. Solution
One of the following:
1) Upgrade your entire ports collection and rebuild the
mod_php3/mod_php4 port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
[php3]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/mod_php-3.0.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/mod_php-3.0.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/mod_php-3.0.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/mod_php-3.0.17.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/mod_php-3.0.17.tgz
[php4]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/www/mod_php-4.0.3pl1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/www/mod_php-4.0.3pl1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/www/mod_php-4.0.3pl1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/www/mod_php-4.0.3pl1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/www/mod_php-4.0.3pl1.tgz
3) download a new port skeleton for the mod_php3/mod_php4 port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmWdlUuHi5z0oilAQHlCQP/W+MsHrhJbBEg8JRhw5ZoGh8DI/KHD6gT
PYgaIhr72vmHYN7xtkuHDxV1C5O15YC+z7CzZseYvpdfBDVDm3qKwBQdN5EuumQg
09LHPZEwayLYlgdRmoRQiP8OGsrYER29sYFQZlKvf8ZJw4tZkwJKPmpGBO5bxvSk
+N5lbHKNdHw=
=gy7y
-----END PGP SIGNATURE-----

150
share/security/advisories/FreeBSD-SA-00:76.tcsh-csh.asc Normal file
View file

@ -0,0 +1,150 @@
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-00:76 Security Advisory
FreeBSD, Inc.
Topic: tcsh/csh creates insecure temporary file
Category: core, ports
Module: tcsh, 44bsd-csh
Announced: 2000-11-20
Affects: FreeBSD 4.x, 3.x prior to the correction date.
Corrected: 2000-11-04 (FreeBSD 4.1.1-STABLE)
2000-11-05 (FreeBSD 3.5.1-STABLE)
2000-11-09 (44bsd-csh port)
2000-11-19 (tcsh port)
Credits: proton <proton@ENERGYMECH.NET>
FreeBSD only: NO
I. Background
tcsh is an updated version of the traditional BSD C Shell
(csh). Versions of csh and tcsh are included in the FreeBSD ports
collection (tcsh, 44bsd-csh) and the FreeBSD base system (csh, tcsh).
II. Problem Description
The csh and tcsh code creates temporary files when the '<<' operator
is used, however these are created insecurely and use a predictable
filename based on the process ID of the shell. An attacker can
exploit this vulnerability to overwrite an arbitrary file writable by
the user running the shell. The contents of the file are overwritten
with the text being entered using the '<<' operator, so it will
usually not be under the control of the attacker.
Therefore the likely impact of this vulnerability is a denial of
service since the attacker can cause critical files writable by the
user to be overwritten. It is unlikely, although possible depending
on the circumstances in which the '<<' operator is used, that the
attacker could exploit the vulnerability to gain privileges (this
typically requires that they have control over the contents the target
file is overwritten with).
All versions of FreeBSD prior to the correction date are vulnerable to
this problem: the /bin/csh shell included in the base system (which is
the same as /bin/tcsh in recent versions) as well as the tcsh
(versions prior to 6.09.03_1) and 44bsd-csh ports (versions prior to
44bsd-csh-20001106) in the ports collection. The problems with the
base system shells and the 44bsd-csh port were resolved prior to the
release of FreeBSD 4.2. The tcsh port was not fixed prior to the
release, but the port is disabled in FreeBSD 4.2 since the same
software exists in the base system.
III. Impact
Unprivileged local users can cause an arbitrary file writable by a
victim to be overwritten when the victim invokes the '<<' operator in
csh or tcsh (e.g. from within a shell script).
If you have not installed the tcsh or 44bsd-csh ports on your
4.1.1-STABLE system dated after the correction date, your system is
not vulnerable to this problem.
IV. Workaround
None practical.
V. Solution
Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE after the
correction date, or patch your present system source code and
rebuild.
To patch your present system: download the relevant patch from the
below location, and execute the following commands as root:
[FreeBSD 4.x base system]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:76/tcsh.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:76/tcsh.patch.asc
Verify the detached PGP signature using your PGP utility.
cd /usr/src/contrib/tcsh
patch -p < /path/to/patch
cd /usr/src/bin/csh
make depend && make all install
[FreeBSD 3.x base system]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:76/csh.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-00:76/csh.patch.asc
Verify the detached PGP signature using your PGP utility.
cd /usr/src/bin/csh
patch -p < /path/to/patch
make depend && make all install
[Ports collection]
One of the following:
1) Upgrade your entire ports collection and rebuild the tcsh/44bsd-csh
port.
2) Deinstall the old package and install a new package dated after the
correction date, obtained from:
[tcsh]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/shells/tcsh-6.09.03_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/shells/tcsh-6.09.03_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/shells/tcsh-6.09.03_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/shells/tcsh-6.09.03_1.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/shells/tcsh-6.09.03_1.tgz
[44bsd-csh]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/shells/44bsd-csh-20001106.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/shells/44bsd-csh-20001106.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/shells/44bsd-csh-20001106.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/shells/44bsd-csh-20001106.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/shells/44bsd-csh-20001106.tgz
3) download a new port skeleton for the tcsh/44bsd-csh port from:
http://www.freebsd.org/ports/
and use it to rebuild the port.
4) Use the portcheckout utility to automate option (3) above. The
portcheckout port is available in /usr/ports/devel/portcheckout or the
package can be obtained from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOhmfAlUuHi5z0oilAQGTBQP/fKPInKBn9a5NZSc5fWPYKdQda2gL1Mji
bMaOpF6DiYb9NqKSQdBayq+cf3SI0tqnx0MWDads+Vx6E7zZJ1Eai8zXB0vx37sO
vYULKsaK0Gp2wvPfEn0lDUN1l6tn7OQJIXg63i9qF2r/88G2stNbuxG6w++uponc
PsehE1pTGQY=
=ZAeV
-----END PGP SIGNATURE-----

Some files were not shown because too many files have changed in this diff Show more