Bron: [url=http://www.freebsd.org/support.html#mailing-list]FreeBSD Mailing Lists[/url]
Ik kreeg net 2 mailtjes met security bugs.
Mailtje 1
[quote]FreeBSD-SA-02:25 Security Advisory
The FreeBSD Project
Topic: bzip2 contains multiple security vulnerabilities
Category: core/ports
Module: bzip2
Announced: 2002-05-20
Credits: Volker Schmidt‚ Philippe Troin
Affects: FreeBSD 4.4-RELEASE‚ FreeBSD 4.5-RELEASE‚
FreeBSD 4.5-STABLE prior to the correction date.
bzip2 port prior to bzip2-1.0.2
Corrected: 2002-02-18 09:12:53 UTC (4.5-STABLE‚ RELENG_4)
2002-02-23 18:28:09 UTC (4.5-RELEASE-p1‚ RELENG_4_5)
2002-02-23 18:33:18 UTC (4.4-RELEASE-p8‚ RELENG_4_4)
2002-02-22 13:21:22 UTC (bzip2 port)
FreeBSD only: NO
I. Background
bzip2 is an advanced block-sorting file compression utility.
II. Problem Description
When creating a file during decompression‚ the bzip2 utility failed
to use the O_EXCL flag‚ potentially overwriting files without warning.
In addition‚ the bzip2 utility did not securely create new files
causing a race condition between creating the file and setting the
correct permissions.
When compressing a file pointed to by a symbolic link‚ the bzip2
utility incorrectly stored the permissions of the symbolic link
instead of the file. This may result in potentially lax file
permissions (rwxr-xr-x)‚ causing the decompressed file to be
world-readable.
bzip2 was incorporated into FreeBSD prior to FreeBSD 4.4-RELEASE.
Previous versions of FreeBSD did not contain bzip2 and are unaffected
unless bzip2 was installed from the ports collection or manually by
the system administrator.
III. Impact
1) Files may be inadvertently overwritten without warning.
2) Due to the race condition between creating files and setting proper
permissions‚ a local user may be able to read the contents of files
regardless of their intended permissions.
3) Decompressed files that were originally pointed to by a symbolic
link may end up with in incorrect permissions‚ allowing local users
to view their contents.
IV. Workaround
1) Deinstall the bzip2 port/package if you have it installed.
V. Solution
[FreeBSD 4.4 or 4.5 base system]
1) Upgrade your vulnerable system to 4.5-STABLE or the RELENG_4_4 or
RELENG_4_5 security branch dated after the respective correction dates.
2) To patch your present system‚ download the relevant patch from the
below location‚ and execute the following commands as root:
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:25/bzip2.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-02:25/bzip2.patch.asc
Verify the detached PGP signature using your PGP utility.
This patch has been verified to apply to FreeBSD 4.4-RELEASE and
4.5-RELEASE.
# cd /usr/src
# patch -p < /path/to/patch
# cd lib/libbz2
# make depend && make all install
# cd ../../usr.bin/bzip2
# make depend && make all install
3) FreeBSD 4.4-RELEASE and 4.5-RELEASE systems:
An experimental upgrade package is available for users who wish to
provide testing and feedback on the binary upgrade process. This
package may be installed on FreeBSD 4.4-RELEASE and 4.5-RELEASE
systems only‚ and is intended for use on systems for which source
patching is not practical or convenient.
If you use the upgrade package‚ feedback (positive or negative) to
security-officer@FreeBSD.org is requested so we can improve the
process for future advisories.
During the installation procedure‚ backup copies are made of the files
which are replaced by the package. These backup copies will be
reinstalled if the package is removed‚ reverting the system to a
pre-patched state.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-02.25/security-patch-bzip2-02.25.tgz
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/packages/SA-02.25/security-patch-bzip2-02.25.tgz.asc
Verify the detached PGP signature using your PGP utility.
# pkg_add security-patch-bzip2-02.25.tgz
[ports]
1) Upgrade your entire ports collection and rebuild the bzip2 port.
2) Deinstall the old package and install a new package dated after the
correction date‚ obtained from the following directories:
[i386]
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/archivers/
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/archivers/
[alpha]
Packages are not automatically generated for the alpha architecture at
this time due to lack of build resources.
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 bzip2 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-4-stable/Latest/portcheckout.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/Latest/portcheckout.tgz
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
[Ports collection]
[/quote]
Mailtje 2
[quote]FreeBSD-SA-02:24.k5su Security Advisory
The FreeBSD Project
Topic: k5su utility does not honor `wheel' group
Category: kerberos5
Module: kerberos5/usr.bin/k5su
Announced: 2002-05-20
Credits: jmallet@FreeBSD.org
Affects: FreeBSD 4.4-RELEASE
FreeBSD 4.5-RELEASE
FreeBSD-STABLE prior to the correction date
Corrected: 2002-05-15 12:51:30 UTC (RELENG_4)
2002-05-15 12:56:21 UTC (RELENG_4_5)
2002-05-15 13:04:00 UTC (RELENG_4_4)
FreeBSD only: YES
I. Background
The k5su utility is a SU utility similar to su(1)‚ and is used to
switch privileges after authentication using Kerberos 5 or the local
passwd(5) file. k5su is installed as part of the `krb5' distribution‚
or when building from source with MAKE_KERBEROS5 set. Neither of
these are default settings.
II. Problem Description
Historically‚ the BSD SU utility only allows users who are members
of group `wheel' (group-ID 0) to obtain superuser
privileges. The k5su utility‚ however‚ does not honor this convention
and does not verify group membership if a user has successfully
authenticated.
k5su also lacks other features of su(1)‚ such as checking for
password expiration‚ implementing login classes‚ and checking
for the target user's login shell in /etc/shells.
III. Impact
Contrary to the expectations of many BSD system administrators‚ users
not in group `wheel' may use k5su to attempt to obtain superuser
privileges. Note that this would require knowledge of the root
account password‚ or an explicit entry in the Kerberos 5 `.k5login'
ACL for the root account.
IV. Solution
Remove the set-user-ID bit from the k5su utility:
# chmod u-s /usr/bin/k5su
This will completely disable k5su.
Sites which wish to use Kerberos 5 authentication for SU and are
comfortable with its limitations may choose to leave the set-user-ID
bit enabled. As of the correction date‚ FreeBSD (including the
upcoming 4.6-RELEASE) will install k5su if requested‚ but the
set-user-ID bit will not be enabled by default. See also the
ENABLE_SUID_K5SU option in make.conf(5).
VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
[/quote]