From owner-freebsd-security@FreeBSD.ORG Sun Jan 11 13:22:55 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3261065701; Sun, 11 Jan 2009 13:22:55 +0000 (UTC) (envelope-from miwi@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 316CD8FC0A; Sun, 11 Jan 2009 13:22:55 +0000 (UTC) (envelope-from miwi@FreeBSD.org) Received: from freefall.freebsd.org (miwi@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0BDMtAP062076; Sun, 11 Jan 2009 13:22:55 GMT (envelope-from miwi@freefall.freebsd.org) Received: (from miwi@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0BDMsxO062072; Sun, 11 Jan 2009 13:22:54 GMT (envelope-from miwi) Date: Sun, 11 Jan 2009 13:22:54 GMT Message-Id: <200901111322.n0BDMsxO062072@freefall.freebsd.org> To: freebsd-security@freebsd.org, novel@freebsd.org, rea-fbsd@codelabs.ru, miwi@FreeBSD.org, miwi@FreeBSD.org From: miwi@FreeBSD.org Cc: Subject: Re: ports/129050: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706 and CVE-2008-5030 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 13:22:55 -0000 Synopsis: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706 and CVE-2008-5030 State-Changed-From-To: open->closed State-Changed-By: miwi State-Changed-When: Sun Jan 11 13:22:54 UTC 2009 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=129050 From owner-freebsd-security@FreeBSD.ORG Tue Jan 13 22:33:21 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5398B106567C; Tue, 13 Jan 2009 22:33:21 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7968FC25; Tue, 13 Jan 2009 22:33:21 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0DMXLN7055229; Tue, 13 Jan 2009 22:33:21 GMT (envelope-from security-advisories@freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0DMXLcN055227; Tue, 13 Jan 2009 22:33:21 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 13 Jan 2009 22:33:21 GMT Message-Id: <200901132233.n0DMXLcN055227@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: simon set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-09:03.ntpd X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 22:33:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:03.ntpd Security Advisory The FreeBSD Project Topic: ntpd cryptographic signature bypass Category: contrib Module: ntpd Announced: 2009-01-13 Credits: Google Security Team Affects: All FreeBSD releases Corrected: 2009-01-13 21:19:27 UTC (RELENG_7, 7.1-STABLE) 2009-01-13 21:19:27 UTC (RELENG_7_1, 7.1-RELEASE-p2) 2009-01-13 21:19:27 UTC (RELENG_7_0, 7.0-RELEASE-p9) 2009-01-13 21:19:27 UTC (RELENG_6, 6.4-STABLE) 2009-01-13 21:19:27 UTC (RELENG_6_4, 6.4-RELEASE-p3) 2009-01-13 21:19:27 UTC (RELENG_6_3, 6.3-RELEASE-p9) CVE Name: CVE-2009-0021 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ntpd daemon is an implementation of the Network Time Protocol (NTP) used to synchronize the time of a computer system to a reference time source. FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description The EVP_VerifyFinal() function from OpenSSL is used to determine if a digital signature is valid. When ntpd(8) is set to cryptographically authenticate NTP data it incorrectly checks the return value from EVP_VerifyFinal(). III. Impact An attacker which can send NTP packets to ntpd, which uses cryptographic authentication of NTP data, may be able to inject malicious time data causing the system clock to be set incorrectly. IV. Workaround Use IP based restrictions in ntpd itself or in IP firewalls to restrict which systems can send NTP packets to ntpd. NOTE WELL: If ntpd is not explicitly set to use cryptographic authentication of NTP data the setup is not vulnerable to the issue as described in this Security Advisory. V. Solution NOTE WELL: Due to an error in building the updates, this fix is not available via freebsd-update at the time of this advisory. We expect that this will be fixed within the next 48 hours. Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_1, RELENG_7_0, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.0, and 7.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 6.4 and 7.1] # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd.patch # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd.patch.asc [FreeBSD 6.3 and 7.0] # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd63.patch # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd63.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/usr.sbin/ntp/ntpd # make obj && make depend && make && make install # /etc/rc.d/ntpd restart 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/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.2 RELENG_6_4 src/UPDATING 1.416.2.40.2.6 src/sys/conf/newvers.sh 1.69.2.18.2.9 src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.1.2.1 RELENG_6_3 src/UPDATING 1.416.2.37.2.14 src/sys/conf/newvers.sh 1.69.2.15.2.13 src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.20.1 RELENG_7 src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.2 RELENG_7_1 src/UPDATING 1.507.2.13.2.5 src/sys/conf/newvers.sh 1.72.2.9.2.6 src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.1.2.1 RELENG_7_0 src/UPDATING 1.507.2.3.2.13 src/sys/conf/newvers.sh 1.72.2.5.2.13 src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.22.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r187194 releng/6.4/ r187194 releng/6.3/ r187194 stable/7/ r187194 releng/7.1/ r187194 releng/7.0/ r187194 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0021 http://security.FreeBSD.org/advisories/FreeBSD-SA-09:02.openssl.asc The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:03.ntpd.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJbRUfFdaIBMps37IRAqdjAJ42YSH0bjaAJBEVyMM7/em/tu0xUQCfVPrs IrH0Qxo4slvboQHsy1PbkN4= =Q4rn -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 13 22:33:57 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AC5E1065891; Tue, 13 Jan 2009 22:33:57 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0BF8FC23; Tue, 13 Jan 2009 22:33:57 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0DMXvwX055307; Tue, 13 Jan 2009 22:33:57 GMT (envelope-from security-advisories@freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0DMXv2A055305; Tue, 13 Jan 2009 22:33:57 GMT (envelope-from security-advisories@freebsd.org) Date: Tue, 13 Jan 2009 22:33:57 GMT Message-Id: <200901132233.n0DMXv2A055305@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: simon set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Cc: Subject: FreeBSD Security Advisory FreeBSD-SA-09:04.bind X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: freebsd-security@freebsd.org List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 22:33:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:04.bind Security Advisory The FreeBSD Project Topic: BIND DNSSEC incorrect checks for malformed signatures Category: contrib Module: bind Announced: 2009-01-13 Credits: Google Security Team Affects: All supported FreeBSD versions Corrected: 2009-01-10 03:00:21 UTC (RELENG_7, 7.1-STABLE) 2009-01-13 21:19:27 UTC (RELENG_7_1, 7.1-RELEASE-p2) 2009-01-13 21:19:27 UTC (RELENG_7_0, 7.0-RELEASE-p9) 2009-01-10 04:30:27 UTC (RELENG_6, 6.4-STABLE) 2009-01-13 21:19:27 UTC (RELENG_6_4, 6.4-RELEASE-p3) 2009-01-13 21:19:27 UTC (RELENG_6_3, 6.3-RELEASE-p9) CVE Name: CVE-2009-0025 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. DNS Security Extensions (DNSSEC) are additional protocol options that add authentication as part of responses to DNS queries. FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description The DSA_do_verify() function from OpenSSL is used to determine if a DSA digital signature is valid. When DNSSEC is used within BIND it uses DSA_do_verify() to verify DSA signatures, but checks the function return value incorrectly. III. Impact It is in theory possible to spoof a DNS reply even though DNSSEC is set up to validate answers. This could be used by an attacker for man-in-the-middle or other spoofing attacks. IV. Workaround Disable the the DSA algorithm in named.conf. This will cause answers from zones signed only with DSA to be treated as insecure. Add the following to the options section of named.conf: disable-algorithms . { DSA; }; NOTE WELL: If named(8) is not explicitly set to use DNSSEC the setup is not vulnerable to the issue as described in this Security Advisory. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_1, RELENG_7_0, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.0, and 7.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/SA-09:04/bind.patch # fetch http://security.FreeBSD.org/patches/SA-09:04/bind.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/lib/bind # make obj && make depend && make && make install # cd /usr/src/usr.sbin/named # make obj && make depend && make && make install # /etc/rc.d/named restart c) Install and use a fixed version of BIND from the FreeBSD Ports Collection. 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/contrib/bind9/CHANGES 1.1.1.3.2.10 src/contrib/bind9/FAQ 1.1.1.2.2.5 src/contrib/bind9/FAQ.xml 1.1.1.1.2.5 src/contrib/bind9/README 1.1.1.2.2.6 src/contrib/bind9/aclocal.m4 1.1.4.1 src/contrib/bind9/bin/dig/dig.1 1.1.1.1.4.4 src/contrib/bind9/bin/dig/dig.c 1.1.1.2.2.4 src/contrib/bind9/bin/dig/dig.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/dig/dig.html 1.1.1.1.4.4 src/contrib/bind9/bin/dig/dighost.c 1.1.1.2.2.5 src/contrib/bind9/bin/dig/host.1 1.1.1.1.4.4 src/contrib/bind9/bin/dig/host.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/dig/host.html 1.1.1.1.4.4 src/contrib/bind9/bin/dnssec/dnssec-keygen.8 1.1.1.1.4.4 src/contrib/bind9/bin/dnssec/dnssec-keygen.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/dnssec/dnssec-keygen.html 1.1.1.1.4.4 src/contrib/bind9/bin/dnssec/dnssec-signzone.8 1.1.1.1.4.4 src/contrib/bind9/bin/dnssec/dnssec-signzone.c 1.1.1.2.2.4 src/contrib/bind9/bin/dnssec/dnssec-signzone.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/dnssec/dnssec-signzone.html 1.1.1.1.4.4 src/contrib/bind9/bin/named/client.c 1.1.1.2.2.7 src/contrib/bind9/bin/named/config.c 1.1.1.2.2.4 src/contrib/bind9/bin/named/controlconf.c 1.1.1.1.4.4 src/contrib/bind9/bin/named/include/named/globals.h 1.1.1.1.4.2 src/contrib/bind9/bin/named/interfacemgr.c 1.1.1.1.4.4 src/contrib/bind9/bin/named/lwresd.8 1.1.1.1.4.4 src/contrib/bind9/bin/named/lwresd.c 1.1.1.1.4.3 src/contrib/bind9/bin/named/lwresd.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/named/lwresd.html 1.1.1.1.4.4 src/contrib/bind9/bin/named/main.c 1.1.1.2.2.3 src/contrib/bind9/bin/named/named.8 1.1.1.1.4.4 src/contrib/bind9/bin/named/named.conf.5 1.1.1.2.2.4 src/contrib/bind9/bin/named/named.conf.docbook 1.1.1.2.2.5 src/contrib/bind9/bin/named/named.conf.html 1.1.1.2.2.4 src/contrib/bind9/bin/named/named.docbook 1.1.1.1.4.4 src/contrib/bind9/bin/named/named.html 1.1.1.1.4.4 src/contrib/bind9/bin/named/query.c 1.1.1.1.4.6 src/contrib/bind9/bin/named/server.c 1.1.1.2.2.6 src/contrib/bind9/bin/named/unix/include/named/os.h 1.1.1.2.2.2 src/contrib/bind9/bin/named/unix/os.c 1.1.1.2.2.4 src/contrib/bind9/bin/named/update.c 1.1.1.2.2.4 src/contrib/bind9/bin/nsupdate/Makefile.in 1.1.1.1.4.2 src/contrib/bind9/bin/nsupdate/nsupdate.1 1.1.4.1 src/contrib/bind9/bin/nsupdate/nsupdate.8 1.1.1.1.4.4 src/contrib/bind9/bin/nsupdate/nsupdate.docbook 1.1.1.1.4.3 src/contrib/bind9/bin/nsupdate/nsupdate.html 1.1.1.1.4.4 src/contrib/bind9/bin/rndc/rndc-confgen.c 1.1.1.2.2.1 src/contrib/bind9/bin/rndc/rndc.c 1.1.1.3.2.3 src/contrib/bind9/config.h.in 1.1.4.1 src/contrib/bind9/configure.in 1.1.1.2.2.6 src/contrib/bind9/lib/bind/aclocal.m4 1.1.1.2.2.2 src/contrib/bind9/lib/bind/api 1.1.1.2.2.4 src/contrib/bind9/lib/bind/bsd/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/bind/bsd/strerror.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/bsd/strtoul.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/config.h.in 1.1.1.2.2.4 src/contrib/bind9/lib/bind/configure.in 1.1.1.2.2.5 src/contrib/bind9/lib/bind/dst/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/bind/dst/dst_api.c 1.1.1.2.2.4 src/contrib/bind9/lib/bind/dst/hmac_link.c 1.1.1.1.4.4 src/contrib/bind9/lib/bind/dst/support.c 1.1.1.1.4.2 src/contrib/bind9/lib/bind/include/arpa/nameser.h 1.1.1.1.4.1 src/contrib/bind9/lib/bind/include/isc/assertions.h 1.1.1.1.4.1 src/contrib/bind9/lib/bind/include/isc/misc.h 1.1.1.1.4.1 src/contrib/bind9/lib/bind/include/resolv.h 1.1.1.1.4.2 src/contrib/bind9/lib/bind/inet/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/bind/inet/inet_net_pton.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/irs/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/irs/dns_ho.c 1.1.1.1.4.4 src/contrib/bind9/lib/bind/irs/irp.c 1.1.1.1.4.2 src/contrib/bind9/lib/bind/isc/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/bind/isc/assertions.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/isc/bitncmp.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/isc/ctl_clnt.c 1.1.1.1.4.2 src/contrib/bind9/lib/bind/isc/ctl_srvr.c 1.1.1.1.4.2 src/contrib/bind9/lib/bind/nameser/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/bind/port_after.h.in 1.1.1.2.2.4 src/contrib/bind9/lib/bind/resolv/Makefile.in 1.1.1.1.4.2 src/contrib/bind9/lib/bind/resolv/res_debug.c 1.1.1.1.4.2 src/contrib/bind9/lib/bind/resolv/res_mkquery.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind/resolv/res_query.c 1.1.1.1.4.1 src/contrib/bind9/lib/bind9/api 1.1.1.2.2.4 src/contrib/bind9/lib/bind9/check.c 1.1.1.2.2.4 src/contrib/bind9/lib/dns/adb.c 1.1.1.2.2.4 src/contrib/bind9/lib/dns/api 1.1.1.2.2.7 src/contrib/bind9/lib/dns/cache.c 1.1.1.1.4.3 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.1.4.6 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.1.4.5 src/contrib/bind9/lib/dns/journal.c 1.1.1.2.2.3 src/contrib/bind9/lib/dns/masterdump.c 1.1.1.1.4.2 src/contrib/bind9/lib/dns/message.c 1.1.1.1.4.5 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.1.4.3 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.1.4.3 src/contrib/bind9/lib/dns/rbt.c 1.1.1.2.2.3 src/contrib/bind9/lib/dns/rdata/generic/nsec_47.c 1.1.1.1.4.1 src/contrib/bind9/lib/dns/rdata/generic/nsec_47.h 1.1.1.1.4.1 src/contrib/bind9/lib/dns/rdata/generic/txt_16.c 1.1.1.1.4.2 src/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c 1.1.1.1.4.1 src/contrib/bind9/lib/dns/request.c 1.1.1.1.4.4 src/contrib/bind9/lib/dns/resolver.c 1.1.1.2.2.10 src/contrib/bind9/lib/dns/validator.c 1.1.1.2.2.5 src/contrib/bind9/lib/dns/view.c 1.1.1.1.4.2 src/contrib/bind9/lib/dns/xfrin.c 1.1.1.2.2.5 src/contrib/bind9/lib/isc/Makefile.in 1.1.1.1.4.1 src/contrib/bind9/lib/isc/api 1.1.1.2.2.5 src/contrib/bind9/lib/isc/assertions.c 1.1.1.1.4.1 src/contrib/bind9/lib/isc/include/isc/assertions.h 1.1.1.1.4.1 src/contrib/bind9/lib/isc/include/isc/mem.h 1.1.1.2.2.2 src/contrib/bind9/lib/isc/include/isc/msgs.h 1.1.1.1.4.1 src/contrib/bind9/lib/isc/include/isc/platform.h.in 1.1.1.1.4.2 src/contrib/bind9/lib/isc/include/isc/portset.h 1.1.4.1 src/contrib/bind9/lib/isc/include/isc/resource.h 1.1.1.1.4.2 src/contrib/bind9/lib/isc/include/isc/socket.h 1.1.1.1.4.3 src/contrib/bind9/lib/isc/include/isc/timer.h 1.1.1.1.4.4 src/contrib/bind9/lib/isc/include/isc/types.h 1.1.1.1.4.1 src/contrib/bind9/lib/isc/mem.c 1.1.1.1.4.3 src/contrib/bind9/lib/isc/portset.c 1.1.4.1 src/contrib/bind9/lib/isc/print.c 1.1.1.1.4.2 src/contrib/bind9/lib/isc/pthreads/mutex.c 1.1.1.1.4.3 src/contrib/bind9/lib/isc/timer.c 1.1.1.1.4.5 src/contrib/bind9/lib/isc/unix/app.c 1.1.1.1.4.3 src/contrib/bind9/lib/isc/unix/include/isc/net.h 1.1.1.1.4.1 src/contrib/bind9/lib/isc/unix/net.c 1.1.1.1.4.3 src/contrib/bind9/lib/isc/unix/resource.c 1.1.1.1.4.3 src/contrib/bind9/lib/isc/unix/socket.c 1.1.1.2.2.5 src/contrib/bind9/lib/isc/unix/socket_p.h 1.1.1.1.4.2 src/contrib/bind9/lib/isc/unix/time.c 1.1.1.1.4.1 src/contrib/bind9/lib/isccfg/api 1.1.1.2.2.4 src/contrib/bind9/lib/isccfg/namedconf.c 1.1.1.2.2.5 src/contrib/bind9/version 1.1.1.3.2.10 RELENG_6_4 src/UPDATING 1.416.2.40.2.6 src/sys/conf/newvers.sh 1.69.2.18.2.9 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.1.4.2.4.1 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.1.4.2.2.1 RELENG_6_3 src/UPDATING 1.416.2.37.2.14 src/sys/conf/newvers.sh 1.69.2.15.2.13 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.1.4.2.2.1 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.1.4.1.2.1 RELENG_7 src/contrib/bind9/CHANGES 1.1.1.10.2.4 src/contrib/bind9/COPYRIGHT 1.1.1.4.2.3 src/contrib/bind9/FAQ 1.1.1.6.2.2 src/contrib/bind9/FAQ.xml 1.1.1.4.2.2 src/contrib/bind9/README 1.1.1.7.2.2 src/contrib/bind9/aclocal.m4 1.1.2.1 src/contrib/bind9/bin/check/check-tool.c 1.1.1.3.2.2 src/contrib/bind9/bin/check/named-checkconf.c 1.1.1.4.2.1 src/contrib/bind9/bin/check/named-checkzone.c 1.1.1.3.2.2 src/contrib/bind9/bin/dig/dig.1 1.1.1.4.2.2 src/contrib/bind9/bin/dig/dig.c 1.1.1.5.2.2 src/contrib/bind9/bin/dig/dig.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/dig/dig.html 1.1.1.4.2.2 src/contrib/bind9/bin/dig/dighost.c 1.1.1.5.2.3 src/contrib/bind9/bin/dig/host.1 1.1.1.4.2.2 src/contrib/bind9/bin/dig/host.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/dig/host.html 1.1.1.4.2.2 src/contrib/bind9/bin/dnssec/dnssec-keygen.8 1.1.1.4.2.2 src/contrib/bind9/bin/dnssec/dnssec-keygen.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/dnssec/dnssec-keygen.html 1.1.1.4.2.2 src/contrib/bind9/bin/dnssec/dnssec-signzone.8 1.1.1.4.2.2 src/contrib/bind9/bin/dnssec/dnssec-signzone.c 1.1.1.5.2.2 src/contrib/bind9/bin/dnssec/dnssec-signzone.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/dnssec/dnssec-signzone.html 1.1.1.4.2.2 src/contrib/bind9/bin/named/client.c 1.1.1.6.2.4 src/contrib/bind9/bin/named/config.c 1.1.1.4.2.3 src/contrib/bind9/bin/named/controlconf.c 1.1.1.3.2.2 src/contrib/bind9/bin/named/include/named/globals.h 1.1.1.3.2.1 src/contrib/bind9/bin/named/interfacemgr.c 1.1.1.3.2.2 src/contrib/bind9/bin/named/lwaddr.c 1.1.1.2.2.1 src/contrib/bind9/bin/named/lwdgnba.c 1.1.1.2.2.1 src/contrib/bind9/bin/named/lwdnoop.c 1.1.1.2.2.1 src/contrib/bind9/bin/named/lwresd.8 1.1.1.4.2.2 src/contrib/bind9/bin/named/lwresd.c 1.1.1.3.2.2 src/contrib/bind9/bin/named/lwresd.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/named/lwresd.html 1.1.1.4.2.2 src/contrib/bind9/bin/named/main.c 1.1.1.5.2.1 src/contrib/bind9/bin/named/named.8 1.1.1.4.2.2 src/contrib/bind9/bin/named/named.conf.5 1.1.1.5.2.2 src/contrib/bind9/bin/named/named.conf.docbook 1.1.1.5.2.3 src/contrib/bind9/bin/named/named.conf.html 1.1.1.5.2.2 src/contrib/bind9/bin/named/named.docbook 1.1.1.4.2.2 src/contrib/bind9/bin/named/named.html 1.1.1.4.2.2 src/contrib/bind9/bin/named/query.c 1.1.1.6.2.2 src/contrib/bind9/bin/named/server.c 1.1.1.6.2.4 src/contrib/bind9/bin/named/unix/include/named/os.h 1.1.1.3.2.1 src/contrib/bind9/bin/named/unix/os.c 1.1.1.5.2.1 src/contrib/bind9/bin/named/update.c 1.1.1.5.2.2 src/contrib/bind9/bin/nsupdate/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/bin/nsupdate/nsupdate.1 1.1.2.1 src/contrib/bind9/bin/nsupdate/nsupdate.8 1.1.1.4.2.2 src/contrib/bind9/bin/nsupdate/nsupdate.c 1.1.1.5.2.2 src/contrib/bind9/bin/nsupdate/nsupdate.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/nsupdate/nsupdate.html 1.1.1.4.2.2 src/contrib/bind9/bin/rndc/rndc-confgen.c 1.1.1.3.2.1 src/contrib/bind9/bin/rndc/rndc.8 1.1.1.4.2.2 src/contrib/bind9/bin/rndc/rndc.c 1.1.1.6.2.2 src/contrib/bind9/bin/rndc/rndc.docbook 1.1.1.3.2.2 src/contrib/bind9/bin/rndc/rndc.html 1.1.1.4.2.2 src/contrib/bind9/config.h.in 1.1.2.1 src/contrib/bind9/configure.in 1.1.1.6.2.3 src/contrib/bind9/lib/bind/aclocal.m4 1.1.1.2.10.2 src/contrib/bind9/lib/bind/api 1.1.1.5.2.2 src/contrib/bind9/lib/bind/bsd/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/bsd/strerror.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/bsd/strtoul.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/config.h.in 1.1.1.4.2.3 src/contrib/bind9/lib/bind/configure.in 1.1.1.5.2.3 src/contrib/bind9/lib/bind/dst/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/dst/dst_api.c 1.1.1.5.2.2 src/contrib/bind9/lib/bind/dst/hmac_link.c 1.1.1.4.2.2 src/contrib/bind9/lib/bind/dst/support.c 1.1.1.3.2.1 src/contrib/bind9/lib/bind/include/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/include/arpa/nameser.h 1.1.1.2.2.1 src/contrib/bind9/lib/bind/include/isc/assertions.h 1.1.1.2.2.1 src/contrib/bind9/lib/bind/include/isc/eventlib.h 1.1.1.3.2.1 src/contrib/bind9/lib/bind/include/isc/misc.h 1.1.1.2.2.1 src/contrib/bind9/lib/bind/include/isc/platform.h.in 1.2.2.1 src/contrib/bind9/lib/bind/include/netdb.h 1.1.1.4.2.1 src/contrib/bind9/lib/bind/include/resolv.h 1.1.1.3.2.1 src/contrib/bind9/lib/bind/inet/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/inet/inet_net_pton.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/inet/inet_network.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/irs/Makefile.in 1.1.1.3.2.1 src/contrib/bind9/lib/bind/irs/dns_ho.c 1.1.1.4.2.1 src/contrib/bind9/lib/bind/irs/getnetgrent.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/irs/getnetgrent_r.c 1.1.1.4.2.1 src/contrib/bind9/lib/bind/irs/irp.c 1.1.1.3.2.1 src/contrib/bind9/lib/bind/isc/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/isc/assertions.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/isc/bitncmp.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/isc/ctl_clnt.c 1.1.1.2.2.2 src/contrib/bind9/lib/bind/isc/ctl_srvr.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/isc/logging.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/nameser/Makefile.in 1.1.1.2.2.1 src/contrib/bind9/lib/bind/port_after.h.in 1.1.1.4.2.1 src/contrib/bind9/lib/bind/port_before.h.in 1.1.1.4.2.2 src/contrib/bind9/lib/bind/resolv/Makefile.in 1.1.1.3.2.1 src/contrib/bind9/lib/bind/resolv/res_debug.c 1.1.1.3.2.1 src/contrib/bind9/lib/bind/resolv/res_mkquery.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/resolv/res_query.c 1.1.1.2.2.1 src/contrib/bind9/lib/bind/resolv/res_send.c 1.1.1.4.2.1 src/contrib/bind9/lib/bind9/api 1.1.1.5.2.2 src/contrib/bind9/lib/bind9/check.c 1.1.1.5.2.4 src/contrib/bind9/lib/dns/acache.c 1.1.1.1.2.1 src/contrib/bind9/lib/dns/adb.c 1.1.1.5.2.2 src/contrib/bind9/lib/dns/api 1.1.1.6.2.4 src/contrib/bind9/lib/dns/cache.c 1.1.1.4.2.1 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.4.2.4 src/contrib/bind9/lib/dns/dst_parse.c 1.1.1.2.2.1 src/contrib/bind9/lib/dns/dst_parse.h 1.1.1.2.2.1 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.3.2.4 src/contrib/bind9/lib/dns/journal.c 1.1.1.4.2.2 src/contrib/bind9/lib/dns/master.c 1.1.1.2.2.2 src/contrib/bind9/lib/dns/masterdump.c 1.1.1.3.2.1 src/contrib/bind9/lib/dns/message.c 1.1.1.4.2.2 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.3.2.2 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.4.2.1 src/contrib/bind9/lib/dns/rbt.c 1.1.1.4.2.1 src/contrib/bind9/lib/dns/rbtdb.c 1.1.1.4.2.2 src/contrib/bind9/lib/dns/rdata/generic/nsec_47.c 1.1.1.2.2.1 src/contrib/bind9/lib/dns/rdata/generic/nsec_47.h 1.1.1.2.2.1 src/contrib/bind9/lib/dns/rdata/generic/txt_16.c 1.1.1.2.2.1 src/contrib/bind9/lib/dns/rdata/in_1/apl_42.c 1.1.1.2.2.1 src/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c 1.1.1.2.2.1 src/contrib/bind9/lib/dns/request.c 1.1.1.3.2.2 src/contrib/bind9/lib/dns/resolver.c 1.1.1.9.2.4 src/contrib/bind9/lib/dns/rootns.c 1.1.1.2.2.2 src/contrib/bind9/lib/dns/sdb.c 1.1.1.2.2.2 src/contrib/bind9/lib/dns/tkey.c 1.1.1.4.2.1 src/contrib/bind9/lib/dns/tsig.c 1.1.1.4.2.2 src/contrib/bind9/lib/dns/validator.c 1.1.1.6.2.2 src/contrib/bind9/lib/dns/view.c 1.1.1.2.2.2 src/contrib/bind9/lib/dns/xfrin.c 1.1.1.5.2.3 src/contrib/bind9/lib/dns/zone.c 1.1.1.5.2.2 src/contrib/bind9/lib/isc/Makefile.in 1.1.1.2.2.2 src/contrib/bind9/lib/isc/api 1.1.1.5.2.3 src/contrib/bind9/lib/isc/assertions.c 1.1.1.2.2.1 src/contrib/bind9/lib/isc/include/isc/assertions.h 1.1.1.2.2.1 src/contrib/bind9/lib/isc/include/isc/lex.h 1.1.1.2.2.1 src/contrib/bind9/lib/isc/include/isc/mem.h 1.1.1.3.2.1 src/contrib/bind9/lib/isc/include/isc/msgs.h 1.1.1.2.2.1 src/contrib/bind9/lib/isc/include/isc/platform.h.in 1.1.1.2.2.2 src/contrib/bind9/lib/isc/include/isc/portset.h 1.1.2.1 src/contrib/bind9/lib/isc/include/isc/resource.h 1.1.1.2.2.2 src/contrib/bind9/lib/isc/include/isc/socket.h 1.1.1.2.2.2 src/contrib/bind9/lib/isc/include/isc/timer.h 1.1.1.3.2.2 src/contrib/bind9/lib/isc/include/isc/types.h 1.1.1.2.2.1 src/contrib/bind9/lib/isc/mem.c 1.1.1.3.2.2 src/contrib/bind9/lib/isc/portset.c 1.1.2.1 src/contrib/bind9/lib/isc/print.c 1.1.1.3.2.1 src/contrib/bind9/lib/isc/pthreads/mutex.c 1.1.1.3.2.1 src/contrib/bind9/lib/isc/timer.c 1.1.1.4.2.3 src/contrib/bind9/lib/isc/unix/app.c 1.1.1.2.2.2 src/contrib/bind9/lib/isc/unix/include/isc/net.h 1.1.1.2.2.1 src/contrib/bind9/lib/isc/unix/net.c 1.1.1.3.2.2 src/contrib/bind9/lib/isc/unix/resource.c 1.1.1.2.2.2 src/contrib/bind9/lib/isc/unix/socket.c 1.1.1.5.2.3 src/contrib/bind9/lib/isc/unix/socket_p.h 1.1.1.2.2.2 src/contrib/bind9/lib/isc/unix/time.c 1.1.1.2.2.1 src/contrib/bind9/lib/isccfg/api 1.1.1.4.2.3 src/contrib/bind9/lib/isccfg/namedconf.c 1.1.1.5.2.2 src/contrib/bind9/lib/lwres/api 1.1.1.5.2.2 src/contrib/bind9/make/rules.in 1.1.1.4.2.2 src/contrib/bind9/version 1.1.1.10.2.4 RELENG_7_1 src/UPDATING 1.507.2.13.2.5 src/sys/conf/newvers.sh 1.72.2.9.2.6 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.4.6.1 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.3.2.1.4.1 RELENG_7_0 src/UPDATING 1.507.2.3.2.13 src/sys/conf/newvers.sh 1.72.2.5.2.13 src/contrib/bind9/lib/dns/opensslrsa_link.c 1.1.1.4.4.1 src/contrib/bind9/lib/dns/openssldsa_link.c 1.1.1.3.2.1.2.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r187002 releng/6.4/ r187194 releng/6.3/ r187194 stable/7/ r186997 releng/7.1/ r187194 releng/7.0/ r187194 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0025 http://security.FreeBSD.org/advisories/FreeBSD-SA-09:02.openssl.asc https://www.isc.org/node/373 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:04.bind.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJbRUmFdaIBMps37IRAonEAJsFQFtZGTz6tXFc5TSRMLhB1hxb6QCeI0Pd ZFPKsX8/XspOTzRWA1h3QPk= =dpqG -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Jan 13 23:16:29 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA8510658C5 for ; Tue, 13 Jan 2009 23:16:29 +0000 (UTC) (envelope-from stenn@ntp.org) Received: from mail1.ntp.org (mail1.ntp.org [204.152.184.126]) by mx1.freebsd.org (Postfix) with ESMTP id C166B8FC22 for ; Tue, 13 Jan 2009 23:16:29 +0000 (UTC) (envelope-from stenn@ntp.org) Received: from localhost (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP id 15B3F39F24; Tue, 13 Jan 2009 22:51:53 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) Received: from mail1.ntp.org ([127.0.0.1]) by localhost (ntp1.isc.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03148-09; Tue, 13 Jan 2009 22:51:40 +0000 (UTC) Received: from ntp1.ntp.org (localhost [127.0.0.1]) by mail1.ntp.org (Postfix) with ESMTP; Tue, 13 Jan 2009 22:51:39 +0000 (UTC) (envelope-from stenn@ntp1.ntp.org) To: freebsd-security@freebsd.org From: Harlan Stenn In-Reply-To: FreeBSD Security Advisories's (security-advisories@freebsd.org) message dated Tue, 13 Jan 2009 22:33:20. <200901132233.n0DMXKVI055218@freefall.freebsd.org> X-Face: "csXK}xnnsH\h_ce`T#|pM]tG, 6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Jan 2009 22:51:38 +0000 Sender: stenn@ntp.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ntp1.isc.org Message-Id: <20090113225153.15B3F39F24@mail1.ntp.org> X-Mailman-Approved-At: Tue, 13 Jan 2009 23:45:05 +0000 Cc: stenn@ntp.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-09:03.ntpd X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 23:16:32 -0000 Good news/bad news. The good news is that I like to think I did a better job describing this problem than I have done in the past. The bad news is that I think I did a pretty sucky job of describing this problem in our report. Y'all did a much better job of this than I did. The NTP Project has had maybe 3 of these sort of issues in the past 15+ years, so I don't have much experience in dealing with writing the announcements. Might I be able to work with y'all on any future similar security advisories so our security announcements are better? H -- Harlan Stenn http://ntpforum.isc.org - be a member! > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ============================================================================= > FreeBSD-SA-09:03.ntpd Security Advisory > The FreeBSD Project > > Topic: ntpd cryptographic signature bypass > > Category: contrib > Module: ntpd > Announced: 2009-01-13 > Credits: Google Security Team > Affects: All FreeBSD releases > Corrected: 2009-01-13 21:19:27 UTC (RELENG_7, 7.1-STABLE) > 2009-01-13 21:19:27 UTC (RELENG_7_1, 7.1-RELEASE-p2) > 2009-01-13 21:19:27 UTC (RELENG_7_0, 7.0-RELEASE-p9) > 2009-01-13 21:19:27 UTC (RELENG_6, 6.4-STABLE) > 2009-01-13 21:19:27 UTC (RELENG_6_4, 6.4-RELEASE-p3) > 2009-01-13 21:19:27 UTC (RELENG_6_3, 6.3-RELEASE-p9) > CVE Name: CVE-2009-0021 > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > The ntpd daemon is an implementation of the Network Time Protocol > (NTP) used to synchronize the time of a computer system to a reference > time source. > > FreeBSD includes software from the OpenSSL Project. The OpenSSL > Project is a collaborative effort to develop a robust, > commercial-grade, full-featured Open Source toolkit implementing the > Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) > protocols as well as a full-strength general purpose cryptography > library. > > II. Problem Description > > The EVP_VerifyFinal() function from OpenSSL is used to determine if a > digital signature is valid. When ntpd(8) is set to cryptographically > authenticate NTP data it incorrectly checks the return value from > EVP_VerifyFinal(). > > III. Impact > > An attacker which can send NTP packets to ntpd, which uses > cryptographic authentication of NTP data, may be able to inject > malicious time data causing the system clock to be set incorrectly. > > IV. Workaround > > Use IP based restrictions in ntpd itself or in IP firewalls to > restrict which systems can send NTP packets to ntpd. > > NOTE WELL: If ntpd is not explicitly set to use cryptographic > authentication of NTP data the setup is not vulnerable to the issue > as described in this Security Advisory. > > V. Solution > > NOTE WELL: Due to an error in building the updates, this fix is not > available via freebsd-update at the time of this advisory. We expect > that this will be fixed within the next 48 hours. > > Perform one of the following: > > 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the > RELENG_7_1, RELENG_7_0, RELENG_6_4, or RELENG_6_3 security branch > dated after the correction date. > > 2) To patch your present system: > > The following patches have been verified to apply to FreeBSD 6.3, 6.4, > 7.0, and 7.1 systems. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 6.4 and 7.1] > # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd.patch > # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd.patch.asc > > [FreeBSD 6.3 and 7.0] > # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd63.patch > # fetch http://security.FreeBSD.org/patches/SA-09:03/ntpd63.patch.asc > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # cd /usr/src/usr.sbin/ntp/ntpd > # make obj && make depend && make && make install > # /etc/rc.d/ntpd restart > > 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/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.2 > RELENG_6_4 > src/UPDATING 1.416.2.40.2.6 > src/sys/conf/newvers.sh 1.69.2.18.2.9 > src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.1.2.1 > RELENG_6_3 > src/UPDATING 1.416.2.37.2.14 > src/sys/conf/newvers.sh 1.69.2.15.2.13 > src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.20.1 > RELENG_7 > src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.2 > RELENG_7_1 > src/UPDATING 1.507.2.13.2.5 > src/sys/conf/newvers.sh 1.72.2.9.2.6 > src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.1.2.1 > RELENG_7_0 > src/UPDATING 1.507.2.3.2.13 > src/sys/conf/newvers.sh 1.72.2.5.2.13 > src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.22.1 > - ------------------------------------------------------------------------- > > Subversion: > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/6/ r187194 > releng/6.4/ r187194 > releng/6.3/ r187194 > stable/7/ r187194 > releng/7.1/ r187194 > releng/7.0/ r187194 > - ------------------------------------------------------------------------- > > VII. References > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0021 > http://security.FreeBSD.org/advisories/FreeBSD-SA-09:02.openssl.asc > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-09:03.ntpd.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (FreeBSD) > > iD8DBQFJbRUfFdaIBMps37IRAqdjAJ42YSH0bjaAJBEVyMM7/em/tu0xUQCfVPrs > IrH0Qxo4slvboQHsy1PbkN4= > =Q4rn > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-announce@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Jan 14 17:49:23 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1CE106566B for ; Wed, 14 Jan 2009 17:49:23 +0000 (UTC) (envelope-from Carl.Friend@mathworks.com) Received: from smtp2.mathworks.com (smtp2.mathworks.com [144.212.95.218]) by mx1.freebsd.org (Postfix) with ESMTP id 195008FC19 for ; Wed, 14 Jan 2009 17:49:22 +0000 (UTC) (envelope-from Carl.Friend@mathworks.com) Received: from mail-vif.mathworks.com (fred-ce0.mathworks.com [144.212.95.18]) by smtp2.mathworks.com (8.13.8/8.12.11) with ESMTP id n0EHalYd026393 for ; Wed, 14 Jan 2009 12:36:47 -0500 (EST) Received: from exhub-00-ah.ad.mathworks.com (exhub-00-ah.mathworks.com [172.31.22.58]) by mail-vif.mathworks.com (8.13.8/8.11.7) with ESMTP id n0EHaX8Q014184 for ; Wed, 14 Jan 2009 12:36:47 -0500 (EST) Received: from EXCHANGE-AH.ad.mathworks.com ([172.31.22.57]) by exhub-00-ah.ad.mathworks.com ([172.31.22.58]) with mapi; Wed, 14 Jan 2009 12:36:33 -0500 From: Carl Friend To: "freebsd-security@freebsd.org" Date: Wed, 14 Jan 2009 12:36:31 -0500 Thread-Topic: FreeBSD Security Advisory FreeBSD-SA-09:04.bind Thread-Index: Acl2bQHGnNFAQMPpQJCmYKHd259K4wAATSxg Message-ID: <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> References: <200901132233.n0DMXv4a055314@freefall.freebsd.org> In-Reply-To: <200901132233.n0DMXv4a055314@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 14 Jan 2009 17:57:56 +0000 Subject: RE: FreeBSD Security Advisory FreeBSD-SA-09:04.bind X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 17:49:24 -0000 Hi Leonid, I got the message, so it looks like at least something is working. From the advisory: > NOTE WELL: If named(8) is not explicitly set to use DNSSEC the setup > is not vulnerable to the issue as described in this Security Advisory. We are not using DNSSEC on either the internal or external BIND instances. We *are* using authentication keys for some of the internal infrastructure (for dynamic updates) but not for the external, and this facility uses shared-secrets anyway rather than PKI. I think we're OK unless we're going to light up DNSSEC in the near future. +-----------------------------------------+----------------------------+ | Carl Richard Friend (UNIX Sysadmin) | Natick, Massachusetts, USA | | Minicomputer Collector / Enthusiast | 01760-2098 | | mailto:carl_friend@mathworks.com +----------------------------+ | http://users.rcn.com/crfriend/museum | ICBM: +42:18:00 -71:21:03 | +-----------------------------------------+----------------------------+ From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 06:35:45 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575BD1065670 for ; Thu, 15 Jan 2009 06:35:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id DA30B8FC16 for ; Thu, 15 Jan 2009 06:35:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 25350 invoked by uid 399); 15 Jan 2009 06:35:44 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Jan 2009 06:35:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <496ED93D.1010200@FreeBSD.org> Date: Wed, 14 Jan 2009 22:35:41 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Carl Friend References: <200901132233.n0DMXv4a055314@freefall.freebsd.org> <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> In-Reply-To: <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" Subject: Re: FreeBSD Security Advisory FreeBSD-SA-09:04.bind X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 06:35:45 -0000 Carl Friend wrote: > Hi Leonid, > > I got the message, so it looks like at least something is working. > > From the advisory: > >> NOTE WELL: If named(8) is not explicitly set to use DNSSEC the setup >> is not vulnerable to the issue as described in this Security Advisory. > > We are not using DNSSEC on either the internal or external BIND > instances. We *are* using authentication keys for some of the internal > infrastructure (for dynamic updates) but not for the external, and > this facility uses shared-secrets anyway rather than PKI. When you say "authentication keys" I assume you mean TSIG. If so, that is not affected by this advisory. > I think we're OK unless we're going to light up DNSSEC in the near > future. You are only vulnerable to a potential man-in-the-middle attack IF you are validating DNSSEC signatures AND IF the signatures on that record involve DSA. Doug -- This .signature sanitized for your protection From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 15:02:49 2009 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38510106567E for ; Thu, 15 Jan 2009 15:02:49 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by mx1.freebsd.org (Postfix) with ESMTP id E91CE8FC19 for ; Thu, 15 Jan 2009 15:02:48 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 4165AC82F4 for ; Thu, 15 Jan 2009 16:45:01 +0200 (EET) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A04CA83F2C8; Thu, 15 Jan 2009 16:45:01 +0200 Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by emh07.mail.saunalahti.fi (Postfix) with SMTP id 2F13B1C638F for ; Thu, 15 Jan 2009 16:45:00 +0200 (EET) Date: Thu, 15 Jan 2009 16:45:00 +0200 From: Jaakko Heinonen To: freebsd-security@FreeBSD.org Message-ID: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Antivirus: VAMS Cc: Subject: [patch] libc Berkeley DB information leak X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 15:02:49 -0000 Hi, FreeBSD libc Berkeley DB can leak sensitive information to database files. The problem is that it writes uninitialized memory obtained from malloc(3) to database files. You can use this simple test program to reproduce the behavior: http://www.saunalahti.fi/~jh3/dbtest.c Run the program and see the resulting test.db file which will contain a sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual page for the explanation for the "J" flag if you need more information.) This has been reported as PR 123529 (http://www.freebsd.org/cgi/query-pr.cgi?pr=123529) which contains a real information leak case. The PR is assigned to secteam and I have also personally reported it to secteam but I haven't heard a word from secteam members. A code to initialize malloc'd memory exists but the feature must be enabled with PURIFY macro. With following patch applied the test program doesn't output 0xa5 bytes to the database file: %%% Index: lib/libc/db/hash/hash_buf.c =================================================================== --- lib/libc/db/hash/hash_buf.c (revision 187214) +++ lib/libc/db/hash/hash_buf.c (working copy) @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #ifdef DEBUG #include Index: lib/libc/db/Makefile.inc =================================================================== --- lib/libc/db/Makefile.inc (revision 187214) +++ lib/libc/db/Makefile.inc (working copy) @@ -3,6 +3,8 @@ # CFLAGS+=-D__DBINTERFACE_PRIVATE +CFLAGS+=-DPURIFY + .include "${.CURDIR}/db/btree/Makefile.inc" .include "${.CURDIR}/db/db/Makefile.inc" .include "${.CURDIR}/db/hash/Makefile.inc" %%% Could someone consider committing this or some other fix for the problem? -- Jaakko From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 16:41:34 2009 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D5961065675 for ; Thu, 15 Jan 2009 16:41:34 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id A5AA28FC18 for ; Thu, 15 Jan 2009 16:41:33 +0000 (UTC) (envelope-from antab@valka.is) Received: from dumb.farm.antab.is (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n0FGLlUI017103; Thu, 15 Jan 2009 17:21:48 +0100 (CET) (envelope-from antab@valka.is) Message-Id: From: Arnar Mar Sig To: Jaakko Heinonen In-Reply-To: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 15 Jan 2009 17:21:42 +0100 References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.930.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-security@FreeBSD.org Subject: Re: [patch] libc Berkeley DB information leak X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 16:41:34 -0000 Would it not be better to remove the PURITY define all together and always have the memset()'s there or changing the malloc()s to calloc() if there is no special reason for the 0xFF in memset. Can anyone say they would rather have the possibility of sensitive information leek from every app using dbopen versus the small speed down from always having the memset? Greets Arnar Mar Sig Valka ehf On Jan 15, 2009, at 3:45 PM, Jaakko Heinonen wrote: > > Hi, > > FreeBSD libc Berkeley DB can leak sensitive information to database > files. The problem is that it writes uninitialized memory obtained > from > malloc(3) to database files. > > You can use this simple test program to reproduce the behavior: > > http://www.saunalahti.fi/~jh3/dbtest.c > > Run the program and see the resulting test.db file which will > contain a > sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual > page for the explanation for the "J" flag if you need more > information.) > > This has been reported as PR 123529 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=123529) which contains a > real information leak case. The PR is assigned to secteam and I have > also personally reported it to secteam but I haven't heard a word from > secteam members. > > A code to initialize malloc'd memory exists but the feature must be > enabled with PURIFY macro. With following patch applied > the test program doesn't output 0xa5 bytes to the database file: > > %%% > Index: lib/libc/db/hash/hash_buf.c > =================================================================== > --- lib/libc/db/hash/hash_buf.c (revision 187214) > +++ lib/libc/db/hash/hash_buf.c (working copy) > @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > > #ifdef DEBUG > #include > Index: lib/libc/db/Makefile.inc > =================================================================== > --- lib/libc/db/Makefile.inc (revision 187214) > +++ lib/libc/db/Makefile.inc (working copy) > @@ -3,6 +3,8 @@ > # > CFLAGS+=-D__DBINTERFACE_PRIVATE > > +CFLAGS+=-DPURIFY > + > .include "${.CURDIR}/db/btree/Makefile.inc" > .include "${.CURDIR}/db/db/Makefile.inc" > .include "${.CURDIR}/db/hash/Makefile.inc" > %%% > > Could someone consider committing this or some other fix for the > problem? > > -- > Jaakko > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 17:40:43 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B52C10656EE for ; Thu, 15 Jan 2009 17:40:43 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 28EB88FC14 for ; Thu, 15 Jan 2009 17:40:43 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so1295329wfg.7 for ; Thu, 15 Jan 2009 09:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=xQe/YLWk7vLKPPpTt4F7na3hxa66oVweIDmnt5uJULQ=; b=Mup3G1Y+yF27qViJIit1cLljVZFknKYRR7DJ4QQhJATUg121ZsTKzBQZ6rfYTNpBfD KyrzTeFSlPtoNmPPEDOojRNwzPuLOy05cq+LhtDyp19BUJXJi6WadpOl/4pLSGkrF+kG I3yFvAT1/5kqfwZCCBpmbMnXtA1rewbxB+wcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Jzl+n+yc6VGE+a15WTnyWQsKNPvoQjGvbkSdmN9sPkm2Ef1Z7mPxOMNv721htJkR9b m59nS7nWo466rQdkEKNN7onM60jgIKXux56PAFeh3IU821j+zPG1Ud0TTSRxQQtTbVB5 2HGLGDNCwDi/Pdb9DSHDsTtQp2RvqQnKBote4= Received: by 10.143.10.15 with SMTP id n15mr602463wfi.319.1232039345250; Thu, 15 Jan 2009 09:09:05 -0800 (PST) Received: by 10.142.157.4 with HTTP; Thu, 15 Jan 2009 09:09:05 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2009 17:09:05 +0000 From: "Chris Rees" To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 17:40:46 -0000 Hey all, I think that there should be a warning (on the jail man page or handbook page perhaps), on setuid in jails. Ex: John <-- user on the (host) server I give John root access to a jail (just for him to play with), and he then sets vi (for example) to setuid root. He then sshs into the host, and uses $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers He now has root! Am I completely thick not to have noticed this, or should there be a warning about people being allowed to have root in a jail where they have unprivileged access to the host? Or have I missed the point of a jail? Regards Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 18:15:21 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F9E106564A for ; Thu, 15 Jan 2009 18:15:21 +0000 (UTC) (envelope-from jared@w00ttech.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 398D18FC19 for ; Thu, 15 Jan 2009 18:15:21 +0000 (UTC) (envelope-from jared@w00ttech.com) Received: by yw-out-2324.google.com with SMTP id 9so491788ywe.13 for ; Thu, 15 Jan 2009 10:15:20 -0800 (PST) Received: by 10.100.45.9 with SMTP id s9mr382868ans.103.1232041739210; Thu, 15 Jan 2009 09:48:59 -0800 (PST) Received: by 10.100.8.18 with HTTP; Thu, 15 Jan 2009 09:48:59 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2009 09:48:59 -0800 From: Snuggles To: utisoft@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-security@freebsd.org Subject: Re: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 18:15:21 -0000 The best practice that I've been following is to not offer any services on the host install and do not allow users to login to the host. The only accounts on the host are root, and my admin user. On Thu, Jan 15, 2009 at 9:09 AM, Chris Rees wrote: > Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root! > > Am I completely thick not to have noticed this, or should there be a > warning about people being allowed to have root in a jail where they > have unprivileged access to the host? Or have I missed the point of a > jail? > > Regards > > Chris > -- > R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 16:44:51 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDAF91065678 for ; Thu, 15 Jan 2009 16:44:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 912768FC0A for ; Thu, 15 Jan 2009 16:44:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n0FGhZgp080599; Thu, 15 Jan 2009 10:43:35 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n0FGhZEV080598; Thu, 15 Jan 2009 10:43:35 -0600 (CST) (envelope-from brooks) Date: Thu, 15 Jan 2009 10:43:35 -0600 From: Brooks Davis To: Arnar Mar Sig Message-ID: <20090115164335.GA80376@lor.one-eyed-alien.net> References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 15 Jan 2009 10:43:36 -0600 (CST) X-Mailman-Approved-At: Thu, 15 Jan 2009 18:35:40 +0000 Cc: freebsd-security@freebsd.org, Jaakko Heinonen Subject: Re: [patch] libc Berkeley DB information leak X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 16:44:52 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 05:21:42PM +0100, Arnar Mar Sig wrote: > Would it not be better to remove the PURITY define all together and alway= s=20 > have the memset()'s there or changing the malloc()s to calloc() if there = is=20 > no special reason for the 0xFF in memset. >=20 > Can anyone say they would rather have the possibility of sensitive=20 > information leek from every app using dbopen versus the small speed down= =20 > from always having the memset? Given that people who care about performance are almost certaintly using on= e of the newer BDB release from ports, this seems logical to me. -- Brooks > Greets > Arnar Mar Sig > Valka ehf >=20 > On Jan 15, 2009, at 3:45 PM, Jaakko Heinonen wrote: >=20 >>=20 >> Hi, >>=20 >> FreeBSD libc Berkeley DB can leak sensitive information to database >> files. The problem is that it writes uninitialized memory obtained from >> malloc(3) to database files. >>=20 >> You can use this simple test program to reproduce the behavior: >>=20 >> http://www.saunalahti.fi/~jh3/dbtest.c >>=20 >> Run the program and see the resulting test.db file which will contain a >> sequence of 0xa5 bytes directly from malloc(3). (See malloc(3) manual >> page for the explanation for the "J" flag if you need more information.) >>=20 >> This has been reported as PR 123529 >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=3D123529) which contains a >> real information leak case. The PR is assigned to secteam and I have >> also personally reported it to secteam but I haven't heard a word from >> secteam members. >>=20 >> A code to initialize malloc'd memory exists but the feature must be >> enabled with PURIFY macro. With following patch applied >> the test program doesn't output 0xa5 bytes to the database file: >>=20 >> %%% >> Index: lib/libc/db/hash/hash_buf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/libc/db/hash/hash_buf.c (revision 187214) >> +++ lib/libc/db/hash/hash_buf.c (working copy) >> @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >>=20 >> #ifdef DEBUG >> #include >> Index: lib/libc/db/Makefile.inc >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/libc/db/Makefile.inc (revision 187214) >> +++ lib/libc/db/Makefile.inc (working copy) >> @@ -3,6 +3,8 @@ >> # >> CFLAGS+=3D-D__DBINTERFACE_PRIVATE >>=20 >> +CFLAGS+=3D-DPURIFY >> + >> .include "${.CURDIR}/db/btree/Makefile.inc" >> .include "${.CURDIR}/db/db/Makefile.inc" >> .include "${.CURDIR}/db/hash/Makefile.inc" >> %%% >>=20 >> Could someone consider committing this or some other fix for the >> problem? >>=20 >> --=20 >> Jaakko >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to=20 >> "freebsd-security-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >=20 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJb2e3XY6L6fI4GtQRAlGXAKCE/Cxtzq6MSd+Uijd7R4OOPwmlgwCgga9R RhnFuVVQhQh6f4lzIb0maww= =hRmG -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-security@FreeBSD.ORG Thu Jan 15 19:00:42 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBAAD1065672 for ; Thu, 15 Jan 2009 19:00:42 +0000 (UTC) (envelope-from jon.passki@hursk.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id A2B798FC2C for ; Thu, 15 Jan 2009 19:00:42 +0000 (UTC) (envelope-from jon.passki@hursk.com) Received: by wf-out-1314.google.com with SMTP id 24so1329822wfg.7 for ; Thu, 15 Jan 2009 11:00:42 -0800 (PST) Received: by 10.142.14.18 with SMTP id 18mr652765wfn.35.1232044310358; Thu, 15 Jan 2009 10:31:50 -0800 (PST) Received: by 10.143.155.19 with HTTP; Thu, 15 Jan 2009 10:31:50 -0800 (PST) Message-ID: Date: Thu, 15 Jan 2009 12:31:50 -0600 From: "Jon Passki" To: utisoft@gmail.com In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-security@freebsd.org Subject: Re: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 19:00:43 -0000 On Thu, Jan 15, 2009 at 11:09 AM, Chris Rees wrote: > Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root! > > Am I completely thick not to have noticed this, or should there be a > warning about people being allowed to have root in a jail where they > have unprivileged access to the host? Or have I missed the point of a > jail? > Nice catch! My SOP is to chmod 700 on the directory hosting the jails. Your example is a file system issue that is shared between multiple levels of trust for one user. FreeBSD jails do not offer protection on the file system space outside of the jail. This should be documented as a gotcha, though. Another thing to think about is user IDs. You could have a user ID in your host of 1001. Your jail could have a completely different user account, but collide on the user ID of 1001. Your host user ID 1001 will have access to those jail user ID 1001 files, unless you restrict a parent directory. That was the use case I came across and avoided. Jon From owner-freebsd-security@FreeBSD.ORG Fri Jan 16 15:40:10 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8241D1065674 for ; Fri, 16 Jan 2009 15:40:10 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id E8EC98FC18 for ; Fri, 16 Jan 2009 15:40:09 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0GFTShR031756; Fri, 16 Jan 2009 17:29:28 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0GFTSTH028157; Fri, 16 Jan 2009 17:29:28 +0200 Received: from kobe.laptop (adsl145-182.kln.forthnet.gr [195.74.244.182]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0GFTLKQ020289; Fri, 16 Jan 2009 17:29:21 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0GFTJGL038977; Fri, 16 Jan 2009 17:29:19 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0GFTJeu038976; Fri, 16 Jan 2009 17:29:19 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: utisoft@gmail.com References: Date: Fri, 16 Jan 2009 17:29:18 +0200 In-Reply-To: (Chris Rees's message of "Thu, 15 Jan 2009 17:09:05 +0000") Message-ID: <87sknjjmlt.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-security@freebsd.org Subject: Re: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 15:40:10 -0000 On Thu, 15 Jan 2009 17:09:05 +0000, "Chris Rees" wrote: > Hey all, > > I think that there should be a warning (on the jail man page or > handbook page perhaps), on setuid in jails. Ex: > > John <-- user on the (host) server > > I give John root access to a jail (just for him to play with), and he > then sets vi (for example) to setuid root. He then sshs into the host, > and uses > > $ /usr/jail/johnsandbox/usr/bin/vi /usr/local/etc/sudoers > > He now has root! If the host system and the jail share the `john' user *and* you are sharing `/usr/local' as read-write between the host and the jail, then ``you are doing it wrong!''. But that's a good warning to add somewhere in the jail documentation :) From owner-freebsd-security@FreeBSD.ORG Sat Jan 17 01:15:28 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F21A01065670 for ; Sat, 17 Jan 2009 01:15:28 +0000 (UTC) (envelope-from jan-mailinglists@demter.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 87BF58FC1C for ; Sat, 17 Jan 2009 01:15:28 +0000 (UTC) (envelope-from jan-mailinglists@demter.de) Received: from [192.168.0.22] (91-67-214-55-dynip.superkabel.de [91.67.214.55]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1LNzaP1vfy-0004n5; Sat, 17 Jan 2009 02:02:53 +0100 Message-Id: <20AB93FA-080E-47D6-8075-B591A7DBCF38@demter.de> From: Jan Demter To: freebsd-security@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 17 Jan 2009 02:02:52 +0100 References: X-Mailer: Apple Mail (2.930.3) X-Provags-ID: V01U2FsdGVkX18tyrmD8DL4t3vLHVfA8vBDO5lJGILJqk0NR2n 5cifr5mdhmJMLcnxJDm9jIJFiQyuTR+GiEfS/LhLV7bH0q2OiM L7am7uATr/4/YO1185dBg== Subject: Re: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 01:15:29 -0000 Am 15.01.2009 um 19:31 schrieb Jon Passki: > Another thing to think about is user IDs. You could have a user ID > in your host of 1001. Your jail could have a completely different > user > account, but collide on the user ID of 1001. Your host user ID 1001 > will > have access to those jail user ID 1001 files, unless you restrict a > parent > directory. That was the use case I came across and avoided. I do not think restricting directories will help you a lot against these attacks. User 1001 on the host has access to all running processes of user 1001 in the jail and should be able to simply inject code to read the files via debugging interfaces. As Snuggles said, best practice is to not allow access to the host to anyone. If you have to, you should avoid collisions of user IDs. Greetings Jan From owner-freebsd-security@FreeBSD.ORG Sat Jan 17 12:01:38 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F911065688 for ; Sat, 17 Jan 2009 12:01:38 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 823018FC2C for ; Sat, 17 Jan 2009 12:01:38 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so2209122wfg.7 for ; Sat, 17 Jan 2009 04:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2R1860WFlw8JjYvI8U25T/89DxNWsLbjJvUzXuGATsE=; b=F/AzLyBrLPsbROFxfQn8B0paMoZhHdv9h0RIU1/8tjBRyHbzEBLYCdVwEAYua2zhd5 HBcjV/pyCSCCbT/JhG1p/8QUSqCQANmGKENBmZp1pFeVdKHV/364ckxiv9lT4T4wRAkg dE1sRLynEljDXQZuDB2vnxzC0xYMmedNfKVmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=PMU/BoHSKWAmOVzHY61Wmsb5nqTVTMhpCWg7o9+Up402ABexfwsRm1Gc8nu/83oz+o ht7MRH9eEKJDqHkC8MeGcXNZohoaHhctDKpYpL6Ye5M4ui9YivEUGm0UFqi1XQVGmMB0 GGpfoZstKAq/y1sZwMexjpjwHZzwNQ3gpclhE= MIME-Version: 1.0 Received: by 10.142.86.7 with SMTP id j7mr1482074wfb.15.1232193698109; Sat, 17 Jan 2009 04:01:38 -0800 (PST) In-Reply-To: References: <20AB93FA-080E-47D6-8075-B591A7DBCF38@demter.de> Date: Sat, 17 Jan 2009 12:01:38 +0000 Message-ID: From: Chris Rees To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on jail privilege (FAQ submission) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 12:01:40 -0000 ---------- Forwarded message ---------- From: Chris Rees Date: 2009/1/17 Subject: Re: Thoughts on jail privilege (FAQ submission) To: Jan Demter 2009/1/17 Jan Demter : > Am 15.01.2009 um 19:31 schrieb Jon Passki: > >> Another thing to think about is user IDs. You could have a user ID >> in your host of 1001. Your jail could have a completely different user >> account, but collide on the user ID of 1001. Your host user ID 1001 will >> have access to those jail user ID 1001 files, unless you restrict a parent >> directory. That was the use case I came across and avoided. > > I do not think restricting directories will help you a lot against these > attacks. > User 1001 on the host has access to all running processes of user 1001 in > the jail and should be able to simply inject code to read the files via > debugging interfaces. > As Snuggles said, best practice is to not allow access to the host to > anyone. If you have to, you should avoid collisions of user IDs. > > Greetings > Jan > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > I find it quite strange that user 1001 can send signals to a jailed process of UID 1001. Is that intentional, or would it be a *lot* of working round to check the UID _and_ JID when signals are sent etc? I appreciate that UID collisions should be avoided, but I also think the documentation should cover these gotchas. The Handbook is beautiful, and taught me FreeBSD from start to finish, so I don't consider it an advanced-users only reference. I appreciate that jails are quite advanced, but I do think the security concerns should be listed. We all forget things :) I might post to the doc list later to suggest this. I'll provide a patch if necessary. Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > (sendmail.cf) From owner-freebsd-security@FreeBSD.ORG Sat Jan 17 22:36:39 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 474C61065670 for ; Sat, 17 Jan 2009 22:36:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5-141.stack.nl [IPv6:2001:610:1108:5011::149]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9528FC0A for ; Sat, 17 Jan 2009 22:36:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id BC1833F79A; Sat, 17 Jan 2009 23:36:37 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id A027B22892; Sat, 17 Jan 2009 23:36:37 +0100 (CET) Date: Sat, 17 Jan 2009 23:36:37 +0100 From: Jilles Tjoelker To: Chris Palmer Message-ID: <20090117223637.GA84044@stack.nl> References: <20090109062026.GI38127@noncombatant.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090109062026.GI38127@noncombatant.org> X-Operating-System: FreeBSD 7.1-PRERELEASE i386 User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-security@freebsd.org Subject: Re: Incorrect (?) documentation for setreuid(2) could lead to security issues for user code X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 22:36:39 -0000 On Thu, Jan 08, 2009 at 10:20:26PM -0800, Chris Palmer wrote: > According to section 6.4.1 of "Setuid Demystified": > http://www.cs.ucdavis.edu/~hchen/paper/usenix02.html > FreeBSD 4.4's setreuid(2) man page is wrong. The man page for FBSD 7 says > the same thing. Is it still wrong, or was the implementation changed to > match the documentation? > This person noticed the same problem for OBSD: > http://www.nabble.com/setreuid()-documentation-is-confusing-and-wrong-td7953251.html Yes, it is still wrong. From reading the source: The conditions without root privs are: the ruid parameter must be -1, the old real uid or the old saved uid; the euid parameter must be -1, the old real uid, the old effective uid or the old saved uid. (The man page has this wrong.) The effect on the saved uid is: if the ruid parameter is not -1 or the new effective uid differs from the new real uid, the saved uid is set to the new effective uid. (Note that this means that specifying the real uid for ruid is subtly different from specifying -1, and also that setreuid(-1,-1) is not a no-op.) (The man page describes this in a confusing manner.) The main application for setreuid() nowadays probably is that setreuid(X,X) is a more portable way to drop all uid privileges. setuid(X) is particularly nasty because on SysV it may succeed without having dropped all privileges (hence, the recommendation in the man page seems inappropriate). setresuid(X,X,X) is nice because the setresuid() function is easy to understand and consistent in general, but unfortunately not as portable. Swapping real and effective UIDs to relinquish privileges temporarily is inferior to seteuid(). -- Jilles Tjoelker