From mark at foster.cc Fri Jan 2 05:45:13 2009 From: mark at foster.cc (Mark Foster) Date: Fri Jan 2 05:45:21 2009 Subject: vuxml updates, cont. Message-ID: <495DA524.7060000@foster.cc> Following up on a previous post about who to Cc: for vuxml updates. As it was left, we were supposed to cc: freebsd-vuxml list it seems. Well I signed up for the list weeks ago and after confirming, was told my request was sent to the moderator for approval (nectar@?). I have not heard back. Eygene is the only poster to that list in months. Please open the list to public or get the moderator back in the loop. Also it is completely unclear whether secteam@ still wants to receive vuxml update submissions. My guess is not, but guesswork is silly. -- Realization #2031: That the "meaning of life" is now just another Google search. Mark D. Foster http://mark.foster.cc/ | http://conshell.net/ From remko at elvandar.org Fri Jan 2 10:30:04 2009 From: remko at elvandar.org (Remko Lodder) Date: Fri Jan 2 10:30:10 2009 Subject: vuxml updates, cont. In-Reply-To: <495DA524.7060000@foster.cc> References: <495DA524.7060000@foster.cc> Message-ID: On Jan 2, 2009, at 6:24 AM, Mark Foster wrote: > Following up on a previous post about who to Cc: for vuxml updates. > > As it was left, we were supposed to cc: freebsd-vuxml list it seems. > Well I signed up for the list weeks ago and after confirming, was > told my request was sent to the moderator for approval (nectar@?). > I have not heard back. > Eygene is the only poster to that list in months. > > Please open the list to public or get the moderator back in the loop. > > Also it is completely unclear whether secteam@ still wants to > receive vuxml update submissions. My guess is not, but guesswork is > silly. Why would you guess it's not? We try to document as much as possible, so every contribution to the VuXML document is appreciated. Please do not think that we do not need VuXML updates :) One of the reasons that might tell why the -vuxml list isn't being used that much, is because we get few VuXML contributions from others, and if we do get them they are mostly attached in port-pr's which are then submitted to our team for evalution. There are a number of people doing it like that and that also works out fine. So I believe that we do want to receive VuXML updates on secteam@ If you have questions about the FreeBSD Security Team / VuXML please let me/us know. Thanks, Remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From mark at foster.cc Fri Jan 2 15:43:56 2009 From: mark at foster.cc (Mark Foster) Date: Fri Jan 2 15:44:03 2009 Subject: vuxml updates, cont. In-Reply-To: References: <495DA524.7060000@foster.cc> Message-ID: <495E363B.30708@foster.cc> Remko Lodder wrote: > Why would you guess it's not? > > We try to document as much as possible, so every contribution to the > VuXML document is appreciated. Please do not think that we do not need > VuXML updates :) No, I really think there needs to be much more, that it is always a game of catch-up. > One of the reasons that might tell why the -vuxml list isn't being > used that much, is because we get few VuXML contributions from others, > and if we do get them they are mostly attached in port-pr's which are > then submitted to our team for evalution. There are a number of people > doing it like that and that also works out fine. > > So I believe that we do want to receive VuXML updates on secteam@ > Good enough, so I will Cc: secteam@ on vuxml updates and when/if approved for freebsd-vuxml@ start cc: that too. Thanks! -- Realization #2031: That the "meaning of life" is now just another Google search. Mark D. Foster http://mark.foster.cc/ | http://conshell.net/ From ohartman at mail.zedat.fu-berlin.de Sat Jan 3 22:01:02 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Sun Jan 4 00:16:12 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? Message-ID: <495FDC97.4090301@mail.zedat.fu-berlin.de> MD5 seems to be compromised by potential collision attacks. So I tried to figure out how I can use another hash for security purposes when hashing passwords for local users on a FreeBSD 7/8 box, like root or local box administration. Looking at man login.conf reveals only three possible hash algorithms selectable: md5 (recommended), des and blf. Changing /etc/login.conf's tag default:\ :passwd_format=sha1:\ followed by a obligatory "cap_mkdb" seems to do something - changing root's password results in different hashes when selecting different hash algorithms like des, md5, sha1, blf or even sha256. Well, I never digged deep enough into the source code to reveal the magic and truth, so I will ask here for some help. Is it possible to change the md5-algorithm by default towards sha1 as recommended after the md5-collisions has been published? Thanks in advance, Oliver From mike at sentex.net Sun Jan 4 04:11:43 2009 From: mike at sentex.net (Mike Tancsa) Date: Sun Jan 4 04:11:51 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: <495FDC97.4090301@mail.zedat.fu-berlin.de> References: <495FDC97.4090301@mail.zedat.fu-berlin.de> Message-ID: <200901040346.n043kRCJ000646@lava.sentex.ca> At 04:45 PM 1/3/2009, O. Hartmann wrote: >followed by a obligatory "cap_mkdb" seems to do something - changing >root's password results in different hashes when selecting different >hash algorithms like des, md5, sha1, blf or even sha256. > >Well, I never digged deep enough into the source code to reveal the >magic and truth, so I will ask here for some help. Is it possible to >change the md5-algorithm by default towards sha1 as recommended after >the md5-collisions has been published? Are you sure sha1 is supported ? It looks like if you put in something not understood in the login.conf file, it defaults to what appears to be DES. ---Mike >Thanks in advance, >Oliver >_______________________________________________ >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 stas at FreeBSD.org Sun Jan 4 06:25:33 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Jan 4 06:26:05 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: <495FDC97.4090301@mail.zedat.fu-berlin.de> References: <495FDC97.4090301@mail.zedat.fu-berlin.de> Message-ID: <20090104092744.e0971330.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 03 Jan 2009 22:45:59 +0100 "O. Hartmann" mentioned: > MD5 seems to be compromised by potential collision attacks. So I tried > to figure out how I can use another hash for security purposes when > hashing passwords for local users on a FreeBSD 7/8 box, like root or > local box administration. Looking at man login.conf reveals only three > possible hash algorithms selectable: md5 (recommended), des and blf. > Changing /etc/login.conf's tag > > default:\ > :passwd_format=sha1:\ > > > followed by a obligatory "cap_mkdb" seems to do something - changing > root's password results in different hashes when selecting different > hash algorithms like des, md5, sha1, blf or even sha256. > > Well, I never digged deep enough into the source code to reveal the > magic and truth, so I will ask here for some help. Is it possible to > change the md5-algorithm by default towards sha1 as recommended after > the md5-collisions has been published? > The default hash format can be configured via auth.conf(5) file. AFAIK, md5, des, blowfish and nthash are supported currently. BTW, I don't think that recently discovered collisions in md5 algoritm can compromise system passwords, as crypt(3) md5 scheme doesn't store the plain md5 sums, but result of a number of md5 computations over a salted password string. Of course, being able to find hash collisions can speedup the brute-force attack a bit, but this had to be proven first... - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklgVukACgkQK/VZk+smlYFurQCeOobQDi6tCbJ9ZeK8V5aUAY3O mMoAoIKvPDKvN1oogSWyGhYln3jCFWgX =NZZk -----END PGP SIGNATURE----- !DSPAM:4960565a967008001220501! From jahilliya at gmail.com Sun Jan 4 06:31:29 2009 From: jahilliya at gmail.com (Daniel Marsh) Date: Sun Jan 4 06:31:36 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: <495FDC97.4090301@mail.zedat.fu-berlin.de> References: <495FDC97.4090301@mail.zedat.fu-berlin.de> Message-ID: Hey What's wrong with the blowfish hash? Reading up on it the full 16 round cipher is unbroken, only 4 and 14 round versions can be broke. Regards Daniel On 1/4/09, O. Hartmann wrote: > MD5 seems to be compromised by potential collision attacks. So I tried > to figure out how I can use another hash for security purposes when > hashing passwords for local users on a FreeBSD 7/8 box, like root or > local box administration. Looking at man login.conf reveals only three > possible hash algorithms selectable: md5 (recommended), des and blf. > Changing /etc/login.conf's tag > > default:\ > :passwd_format=sha1:\ > > > followed by a obligatory "cap_mkdb" seems to do something - changing > root's password results in different hashes when selecting different > hash algorithms like des, md5, sha1, blf or even sha256. > > Well, I never digged deep enough into the source code to reveal the > magic and truth, so I will ask here for some help. Is it possible to > change the md5-algorithm by default towards sha1 as recommended after > the md5-collisions has been published? > > Thanks in advance, > Oliver > _______________________________________________ > 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" > -- http://buymeahouse.stiw.org/ From phk at phk.freebsd.dk Sun Jan 4 10:11:07 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun Jan 4 10:11:14 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: Your message of "Sat, 03 Jan 2009 22:45:59 +0100." <495FDC97.4090301@mail.zedat.fu-berlin.de> Message-ID: <38332.1231062065@critter.freebsd.dk> In message <495FDC97.4090301@mail.zedat.fu-berlin.de>, "O. Hartmann" writes: >MD5 seems to be compromised by potential collision attacks. No it is not. Single MD5 invocations with controlled plaintext allow you to construct appendages to the plaintext, which would result in identical MD5 hash values. This does not affect your passwords. 1. If you already know peoples password, why futz with the encryption of them ? 2. MD5 password hash is not single invocation, in fact MD5 i iterated more than a thousand times in various permutations. Nobody has any idea how to break that, short of brute force. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From peterjeremy at optushome.com.au Tue Jan 6 10:27:49 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Jan 6 10:27:57 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: <495FDC97.4090301@mail.zedat.fu-berlin.de> References: <495FDC97.4090301@mail.zedat.fu-berlin.de> Message-ID: <20090106083117.GI87057@server.vk2pj.dyndns.org> On 2009-Jan-03 22:45:59 +0100, "O. Hartmann" wrote: >Well, I never digged deep enough into the source code to reveal the >magic and truth, so I will ask here for some help. The relevant algorithms and their names are embedded in src/lib/libcrypt/crypt.c > Is it possible to >change the md5-algorithm by default towards sha1 as recommended after >the md5-collisions has been published? Note that both MD5 and SHA1 are broken in the cryprographic sense. As various people have noted, the known breaks do not impact on MD5 password hashes. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090106/8902ad97/attachment.pgp From security-advisories at freebsd.org Wed Jan 7 21:36:22 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Wed Jan 7 21:36:36 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:01.lukemftpd Message-ID: <200901072136.n07LaKIW049703@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:01.lukemftpd Security Advisory The FreeBSD Project Topic: Cross-site request forgery in lukemftpd(8) Category: core Module: lukemftpd Announced: 2009-01-07 Credits: Maksymilian Arciemowicz Affects: All supported versions of FreeBSD. Corrected: 2009-01-07 20:17:55 UTC (RELENG_7, 7.1-STABLE) 2009-01-07 20:17:55 UTC (RELENG_7_1, 7.1-RELEASE-p1) 2009-01-07 20:17:55 UTC (RELENG_7_0, 7.0-RELEASE-p8) 2009-01-07 20:17:55 UTC (RELENG_6, 6.4-STABLE) 2009-01-07 20:17:55 UTC (RELENG_6_4, 6.4-RELEASE-p2) 2009-01-07 20:17:55 UTC (RELENG_6_3, 6.3-RELEASE-p8) CVE Name: CVE-2008-4247 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background lukemftpd(8) is a general-purpose implementation of File Transfer Protocol (FTP) server that is shipped with the FreeBSD base system. It is not enabled in default installations but can be enabled as either an inetd(8) server, or a standard-alone server. A cross-site request forgery attack is a type of malicious exploit that is mainly targeted to a web browser, by tricking a user trusted by the site into visiting a specially crafted URL, which in turn executes a command which performs some privileged operations on behalf of the trusted user on the victim site. II. Problem Description The lukemftpd(8) server splits long commands into several requests. This may result in the server executing a command which is hidden inside another very long command. III. Impact This could, with a specifically crafted command, be used in a cross-site request forgery attack. FreeBSD systems running lukemftpd(8) server could act as a point of privilege escalation in an attack against users using web browser to access trusted FTP sites. IV. Workaround No workaround is available, but systems not running FTP servers are not vulnerable. Systems not running the FreeBSD lukemftpd(8) server are not affected, but users of other ftp daemons are advised to take care since several other ftp daemons are known to have related bugs. NOTE WELL: lukemftpd(8) is a different implementation of an FTP server than ftpd(8). 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:01/lukemftpd.patch # fetch http://security.FreeBSD.org/patches/SA-09:01/lukemftpd.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/libexec/lukemftpd # 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_6 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.5.2.2 src/contrib/lukemftpd/src/extern.h 1.1.1.4.2.2 src/contrib/lukemftpd/src/ftpd.c 1.4.2.2 RELENG_6_4 src/UPDATING 1.416.2.40.2.5 src/sys/conf/newvers.sh 1.69.2.18.2.8 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.5.2.1.6.1 src/contrib/lukemftpd/src/extern.h 1.1.1.4.2.1.6.1 src/contrib/lukemftpd/src/ftpd.c 1.4.2.1.6.2 RELENG_6_3 src/UPDATING 1.416.2.37.2.13 src/sys/conf/newvers.sh 1.69.2.15.2.12 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.5.2.1.4.1 src/contrib/lukemftpd/src/extern.h 1.1.1.4.2.1.4.1 src/contrib/lukemftpd/src/ftpd.c 1.4.2.1.4.1 RELENG_7 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.6.2.1 src/contrib/lukemftpd/src/extern.h 1.1.1.5.2.1 src/contrib/lukemftpd/src/ftpd.c 1.5.2.1 RELENG_7_1 src/UPDATING 1.507.2.13.2.4 src/sys/conf/newvers.sh 1.72.2.9.2.5 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.6.6.1 src/contrib/lukemftpd/src/extern.h 1.1.1.5.6.1 src/contrib/lukemftpd/src/ftpd.c 1.5.6.2 RELENG_7_0 src/UPDATING 1.507.2.3.2.12 src/sys/conf/newvers.sh 1.72.2.5.2.12 src/contrib/lukemftpd/src/ftpcmd.y 1.1.1.6.4.1 src/contrib/lukemftpd/src/extern.h 1.1.1.5.4.1 src/contrib/lukemftpd/src/ftpd.c 1.5.4.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r186872 releng/6.4/ r186872 releng/6.3/ r186872 stable/7/ r186872 releng/7.1/ r186872 releng/7.0/ r186872 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4247 http://security.freebsd.org/advisories/FreeBSD-SA-08:12.ftpd.asc The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:01.lukemftpd.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJZR5UFdaIBMps37IRApUJAKCEGZggeEjPC67j5Tmxl2fEDJ9sIQCfTAKn vpOXC5jix3XiB7wxGKrvNJM= =qPEc -----END PGP SIGNATURE----- From security-advisories at freebsd.org Wed Jan 7 21:37:21 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Wed Jan 7 21:37:33 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl Message-ID: <200901072137.n07LbHwD049781@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:02.openssl Security Advisory The FreeBSD Project Topic: OpenSSL incorrectly checks for malformed signatures Category: contrib Module: openssl Announced: 2009-01-07 Credits: Google Security Team Affects: All FreeBSD releases Corrected: 2009-01-07 21:03:41 UTC (RELENG_7, 7.1-STABLE) 2009-01-07 20:17:55 UTC (RELENG_7_1, 7.1-RELEASE-p1) 2009-01-07 20:17:55 UTC (RELENG_7_0, 7.0-RELEASE-p8) 2009-01-07 20:17:55 UTC (RELENG_6, 6.4-STABLE) 2009-01-07 20:17:55 UTC (RELENG_6_4, 6.4-RELEASE-p2) 2009-01-07 20:17:55 UTC (RELENG_6_3, 6.3-RELEASE-p8) CVE Name: CVE-2008-5077 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background 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. The SSL layer in OpenSSL uses EVP_VerifyFinal(), which in several places checks the return value incorrectly and treats verification errors as a good signature. This is only a problem for DSA and ECDSA keys. III. Impact For applications using OpenSSL for SSL connections, an invalid SSL certificate may be interpreted as valid. This could for example be used by an attacker to perform a man-in-the-middle attack. Other applications which use the OpenSSL EVP API may similarly be affected. IV. Workaround For a server an RSA signed certificate may be used instead of DSA or ECDSA based certificate. Note that Mozilla Firefox does not use OpenSSL and thus is not affected. 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. [FreeBSD 7.x] # fetch http://security.FreeBSD.org/patches/SA-09:02/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-09:02/openssl.patch.asc [FreeBSD 6.x] # fetch http://security.FreeBSD.org/patches/SA-09:02/openssl6.patch # fetch http://security.FreeBSD.org/patches/SA-09:02/openssl6.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/secure/lib/libssl # make obj && make depend && make && make install # cd /usr/src/secure/usr.bin/openssl # make obj && make depend && make && make install NOTE: On the amd64 platform, the above procedure will not update the lib32 (i386 compatibility) libraries. On amd64 systems where the i386 compatibility libraries are used, the operating system should instead be recompiled as described in 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/crypto/openssl/apps/speed.c 1.13.2.1 src/crypto/openssl/apps/verify.c 1.1.1.5.12.1 src/crypto/openssl/apps/x509.c 1.1.1.10.2.1 src/crypto/openssl/apps/spkac.c 1.1.1.4.12.1 src/crypto/openssl/ssl/s2_srvr.c 1.12.2.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.12.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.2 src/crypto/openssl/ssl/s2_clnt.c 1.13.2.2 RELENG_6_4 src/UPDATING 1.416.2.40.2.5 src/sys/conf/newvers.sh 1.69.2.18.2.8 src/crypto/openssl/apps/speed.c 1.13.12.1 src/crypto/openssl/apps/verify.c 1.1.1.5.24.1 src/crypto/openssl/apps/x509.c 1.1.1.10.12.1 src/crypto/openssl/apps/spkac.c 1.1.1.4.24.1 src/crypto/openssl/ssl/s2_srvr.c 1.12.12.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.12.12.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.1.6.1 src/crypto/openssl/ssl/s2_clnt.c 1.13.2.1.6.1 RELENG_6_3 src/UPDATING 1.416.2.37.2.13 src/sys/conf/newvers.sh 1.69.2.15.2.12 src/crypto/openssl/apps/speed.c 1.13.10.1 src/crypto/openssl/apps/verify.c 1.1.1.5.22.1 src/crypto/openssl/apps/x509.c 1.1.1.10.10.1 src/crypto/openssl/apps/spkac.c 1.1.1.4.22.1 src/crypto/openssl/ssl/s2_srvr.c 1.12.10.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.12.10.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.14.2.1.4.1 src/crypto/openssl/ssl/s2_clnt.c 1.13.2.1.4.1 RELENG_7 src/crypto/openssl/apps/speed.c 1.15.2.1 src/crypto/openssl/apps/verify.c 1.1.1.6.2.1 src/crypto/openssl/apps/x509.c 1.1.1.11.2.1 src/crypto/openssl/apps/spkac.c 1.1.1.5.2.1 src/crypto/openssl/ssl/s2_srvr.c 1.13.2.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.14.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.17.2.1 src/crypto/openssl/ssl/ssltest.c 1.1.1.10.2.1 src/crypto/openssl/ssl/s2_clnt.c 1.15.2.1 RELENG_7_1 src/UPDATING 1.507.2.13.2.4 src/sys/conf/newvers.sh 1.72.2.9.2.5 src/crypto/openssl/apps/speed.c 1.15.6.1 src/crypto/openssl/apps/verify.c 1.1.1.6.6.1 src/crypto/openssl/apps/x509.c 1.1.1.11.6.1 src/crypto/openssl/apps/spkac.c 1.1.1.5.6.1 src/crypto/openssl/ssl/s2_srvr.c 1.13.6.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.14.6.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.17.6.1 src/crypto/openssl/ssl/ssltest.c 1.1.1.10.6.1 src/crypto/openssl/ssl/s2_clnt.c 1.15.6.1 RELENG_7_0 src/UPDATING 1.507.2.3.2.12 src/sys/conf/newvers.sh 1.72.2.5.2.12 src/crypto/openssl/apps/speed.c 1.15.4.1 src/crypto/openssl/apps/verify.c 1.1.1.6.4.1 src/crypto/openssl/apps/x509.c 1.1.1.11.4.1 src/crypto/openssl/apps/spkac.c 1.1.1.5.4.1 src/crypto/openssl/ssl/s2_srvr.c 1.13.4.1 src/crypto/openssl/ssl/s3_clnt.c 1.1.1.14.4.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.17.4.1 src/crypto/openssl/ssl/ssltest.c 1.1.1.10.4.1 src/crypto/openssl/ssl/s2_clnt.c 1.15.4.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r186873 releng/6.4/ r186872 releng/6.3/ r186872 stable/7/ r186872 releng/7.1/ r186872 releng/7.0/ r186872 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5077 http://www.openssl.org/news/secadv_20090107.txt The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:02.openssl.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJZR5ZFdaIBMps37IRAofJAJ4lm2jGfsMo28c0W4zRkhZrKmttGwCgmdd9 IvNUwk47W24SwhQAGH5+Ggw= =UHSl -----END PGP SIGNATURE----- From m.seaman at infracaninophile.co.uk Wed Jan 7 22:49:20 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Wed Jan 7 22:49:28 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <200901072137.n07LbHwD049781@freefall.freebsd.org> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> Message-ID: <49653163.4070904@infracaninophile.co.uk> FreeBSD Security Advisories wrote: > I. Background > > 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. The SSL layer in OpenSSL uses > EVP_VerifyFinal(), which in several places checks the return value > incorrectly and treats verification errors as a good signature. This > is only a problem for DSA and ECDSA keys. > > III. Impact > > For applications using OpenSSL for SSL connections, an invalid SSL > certificate may be interpreted as valid. This could for example be > used by an attacker to perform a man-in-the-middle attack. > > Other applications which use the OpenSSL EVP API may similarly be > affected. The oCert advisory at http://ocert.org/advisories/ocert-2008-016.html lists BIND and NTP as affected packages. Don't the base system versions of those apps also need patching? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090107/4a532b05/signature.pgp From kitchetech at gmail.com Thu Jan 8 02:01:27 2009 From: kitchetech at gmail.com (matt donovan) Date: Thu Jan 8 02:01:34 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <49653163.4070904@infracaninophile.co.uk> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> <49653163.4070904@infracaninophile.co.uk> Message-ID: <28283d910901071730if218355pdde2752cccc79b44@mail.gmail.com> On Wed, Jan 7, 2009 at 5:49 PM, Matthew Seaman < m.seaman@infracaninophile.co.uk> wrote: > FreeBSD Security Advisories wrote: > > I. Background >> >> 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. The SSL layer in OpenSSL uses >> EVP_VerifyFinal(), which in several places checks the return value >> incorrectly and treats verification errors as a good signature. This >> is only a problem for DSA and ECDSA keys. >> >> III. Impact >> >> For applications using OpenSSL for SSL connections, an invalid SSL >> certificate may be interpreted as valid. This could for example be >> used by an attacker to perform a man-in-the-middle attack. >> >> Other applications which use the OpenSSL EVP API may similarly be >> affected. >> > > The oCert advisory at http://ocert.org/advisories/ocert-2008-016.html > lists BIND and NTP as affected packages. Don't the base system versions > of those apps also need patching? > > Cheers, > > Matthew > > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW I was told they don't but I believe they do since it's the code inside of ntp and bind don't check the return code correctly from what I can tell for the OpenSSL EVP API From dougb at FreeBSD.org Thu Jan 8 07:47:57 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Jan 8 07:48:04 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <28283d910901071730if218355pdde2752cccc79b44@mail.gmail.com> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> <49653163.4070904@infracaninophile.co.uk> <28283d910901071730if218355pdde2752cccc79b44@mail.gmail.com> Message-ID: <4965A96A.4020604@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 matt donovan wrote: > On Wed, Jan 7, 2009 at 5:49 PM, Matthew Seaman < > m.seaman@infracaninophile.co.uk> wrote: >> The oCert advisory at http://ocert.org/advisories/ocert-2008-016.html >> lists BIND and NTP as affected packages. Don't the base system versions >> of those apps also need patching? > I was told they don't but I believe they do since it's the code inside of > ntp and bind don't check the return code correctly from what I can tell for > the OpenSSL EVP API Please see: https://www.isc.org/node/373 Unless you are using DNSSEC to verify signatures you're not vulnerable at all. As usual for non-critical upgrades I will upgrade the ports first so that those that need the new version(s) can easily get to them in a hurry, then upgrade the base(s) over the next day or two. hth, Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkllqWoACgkQyIakK9Wy8PsIgACg1+vOtfCdZcw2Wirybm4lLpWD VUEAnisZEkFBM4I3+8YmLp97Y/z/i8OG =Uelm -----END PGP SIGNATURE----- From Gabor at Zahemszky.HU Thu Jan 8 20:17:27 2009 From: Gabor at Zahemszky.HU (Zahemszky =?ISO-8859-2?Q?G=E1bor?=) Date: Thu Jan 8 20:17:34 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <200901072137.n07LbHwD049781@freefall.freebsd.org> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> Message-ID: <20090108205317.4c097662@Picasso.Zahemszky.HU> Hi! Neither the lukemftpd, nor the openssl advisory speaks about freebsd-update as an upgrade solution. (And I couldn't update with it.) Why? Bye, G?bor Zahemszky < Gabor at Zahemszky dot HU > -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!'; IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break; [[ $i = ??? ]]&&j=$i&&i=${i%?}; typeset -i40 i=8#$i;print -n ${i#???}; [[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;}; IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2; [[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" From Gabor at Zahemszky.HU Thu Jan 8 20:37:27 2009 From: Gabor at Zahemszky.HU (Zahemszky =?ISO-8859-2?Q?G=E1bor?=) Date: Thu Jan 8 20:37:41 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <20090108202250.GB72107@lor.one-eyed-alien.net> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> <20090108205317.4c097662@Picasso.Zahemszky.HU> <20090108202250.GB72107@lor.one-eyed-alien.net> Message-ID: <20090108213725.38f6fc7d@Picasso.Zahemszky.HU> > I'm not sure what it wasn't mentioned, but it worked just fine for a > dozen boxes at work. Opps, my fault. I tried to update one of my machines about 14 hours ago, but there weren't any updates. I tried it now, and it worked. Sorry for the noise. By, G?bor Zahemszky < Gabor at Zahemszky dot HU > -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!'; IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ '; set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break; [[ $i = ??? ]]&&j=$i&&i=${i%?}; typeset -i40 i=8#$i;print -n ${i#???}; [[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;}; IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2; [[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" From stas at FreeBSD.org Thu Jan 8 20:39:20 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Jan 8 20:39:27 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <20090108205317.4c097662@Picasso.Zahemszky.HU> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> <20090108205317.4c097662@Picasso.Zahemszky.HU> Message-ID: <20090108234147.f87169ff.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 8 Jan 2009 20:53:17 +0100 Zahemszky G?bor mentioned: > Hi! > > Neither the lukemftpd, nor the openssl advisory speaks about > freebsd-update as an upgrade solution. (And I couldn't update with > it.) Why? > What is the problem with freebsd-update? - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklmZQsACgkQK/VZk+smlYHNyACfdUBLAVgdti38rQD/RxVPFMP/ ltwAn2UBfdq0oIZpghltCx1WA1RrJD3l =6VDH -----END PGP SIGNATURE----- !DSPAM:49666476967001390911012! From brooks at freebsd.org Thu Jan 8 20:37:32 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jan 8 20:48:00 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:02.openssl In-Reply-To: <20090108205317.4c097662@Picasso.Zahemszky.HU> References: <200901072137.n07LbHwD049781@freefall.freebsd.org> <20090108205317.4c097662@Picasso.Zahemszky.HU> Message-ID: <20090108202250.GB72107@lor.one-eyed-alien.net> On Thu, Jan 08, 2009 at 08:53:17PM +0100, Zahemszky G?bor wrote: > Hi! > > Neither the lukemftpd, nor the openssl advisory speaks about > freebsd-update as an upgrade solution. (And I couldn't update with > it.) Why? I'm not sure what it wasn't mentioned, but it worked just fine for a dozen boxes at work. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090108/25a90c55/attachment.pgp From ohartman at mail.zedat.fu-berlin.de Thu Jan 8 23:02:48 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Thu Jan 8 23:22:35 2009 Subject: MD5 vs. SHA1 hashed passwords in /etc/master.passwd: can we configure SHA1 in /etc/login.conf? In-Reply-To: <200901040346.n043kRCJ000646@lava.sentex.ca> References: <495FDC97.4090301@mail.zedat.fu-berlin.de> <200901040346.n043kRCJ000646@lava.sentex.ca> Message-ID: <49668643.7050507@mail.zedat.fu-berlin.de> Mike Tancsa wrote: > At 04:45 PM 1/3/2009, O. Hartmann wrote: > >> followed by a obligatory "cap_mkdb" seems to do something - changing >> root's password results in different hashes when selecting different >> hash algorithms like des, md5, sha1, blf or even sha256. >> >> Well, I never digged deep enough into the source code to reveal the >> magic and truth, so I will ask here for some help. Is it possible to >> change the md5-algorithm by default towards sha1 as recommended after >> the md5-collisions has been published? > > Are you sure sha1 is supported ? It looks like if you put in something > not understood in the login.conf file, it defaults to what appears to > be DES. > > ---Mike > >> Thanks in advance, >> Oliver Yes, you're absolutely right, I figured this also out after I tried evey possible hashing alogrithmen mentioned in the manpage. I use 'blf' now. Regards, Oliver From chris at noncombatant.org Fri Jan 9 06:37:42 2009 From: chris at noncombatant.org (Chris Palmer) Date: Fri Jan 9 06:37:51 2009 Subject: Incorrect (?) documentation for setreuid(2) could lead to security issues for user code Message-ID: <20090109062026.GI38127@noncombatant.org> 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 From miwi at FreeBSD.org Sun Jan 11 05:22:55 2009 From: miwi at FreeBSD.org (miwi@FreeBSD.org) Date: Sun Jan 11 05:23:03 2009 Subject: ports/129050: [vuxml] [patch] audio/libcdaudio: fix CVE-2005-0706 and CVE-2008-5030 Message-ID: <200901111322.n0BDMsxO062072@freefall.freebsd.org> 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 security-advisories at freebsd.org Tue Jan 13 14:33:24 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Tue Jan 13 14:33:38 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:03.ntpd Message-ID: <200901132233.n0DMXLcN055227@freefall.freebsd.org> -----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 security-advisories at freebsd.org Tue Jan 13 14:33:59 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Tue Jan 13 14:34:16 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:04.bind Message-ID: <200901132233.n0DMXv2A055305@freefall.freebsd.org> -----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 stenn at ntp.org Tue Jan 13 15:16:32 2009 From: stenn at ntp.org (Harlan Stenn) Date: Tue Jan 13 15:45:07 2009 Subject: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-09:03.ntpd 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> Message-ID: <20090113225153.15B3F39F24@mail1.ntp.org> 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 Carl.Friend at mathworks.com Wed Jan 14 09:49:24 2009 From: Carl.Friend at mathworks.com (Carl Friend) Date: Wed Jan 14 09:57:57 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:04.bind In-Reply-To: <200901132233.n0DMXv4a055314@freefall.freebsd.org> References: <200901132233.n0DMXv4a055314@freefall.freebsd.org> Message-ID: <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> 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 dougb at FreeBSD.org Wed Jan 14 22:35:45 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jan 14 22:35:57 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:04.bind In-Reply-To: <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> References: <200901132233.n0DMXv4a055314@freefall.freebsd.org> <0528A1CB48AB5B4FA0D8FD7E0D94D81D5A75B7441B@EXCHANGE-AH.ad.mathworks.com> Message-ID: <496ED93D.1010200@FreeBSD.org> 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 jh at saunalahti.fi Thu Jan 15 07:02:49 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Thu Jan 15 07:02:56 2009 Subject: [patch] libc Berkeley DB information leak Message-ID: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> 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 antab at valka.is Thu Jan 15 08:41:34 2009 From: antab at valka.is (Arnar Mar Sig) Date: Thu Jan 15 08:41:41 2009 Subject: [patch] libc Berkeley DB information leak In-Reply-To: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> Message-ID: 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 utisoft at googlemail.com Thu Jan 15 09:40:46 2009 From: utisoft at googlemail.com (Chris Rees) Date: Thu Jan 15 09:40:53 2009 Subject: Thoughts on jail privilege (FAQ submission) Message-ID: 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 snuggles at w00ttech.com Thu Jan 15 10:15:21 2009 From: snuggles at w00ttech.com (Snuggles) Date: Thu Jan 15 10:15:29 2009 Subject: Thoughts on jail privilege (FAQ submission) In-Reply-To: References: Message-ID: 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 brooks at freebsd.org Thu Jan 15 08:44:52 2009 From: brooks at freebsd.org (Brooks Davis) Date: Thu Jan 15 10:35:42 2009 Subject: [patch] libc Berkeley DB information leak In-Reply-To: References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <20090115164335.GA80376@lor.one-eyed-alien.net> 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 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? Given that people who care about performance are almost certaintly using one of the newer BDB release from ports, this seems logical to me. -- Brooks > 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" > _______________________________________________ > 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" > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090115/f1dc82eb/attachment.pgp From jon.passki at hursk.com Thu Jan 15 11:00:43 2009 From: jon.passki at hursk.com (Jon Passki) Date: Thu Jan 15 11:00:50 2009 Subject: Thoughts on jail privilege (FAQ submission) In-Reply-To: References: Message-ID: 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 keramida at ceid.upatras.gr Fri Jan 16 07:40:10 2009 From: keramida at ceid.upatras.gr (Giorgos Keramidas) Date: Fri Jan 16 07:40:19 2009 Subject: Thoughts on jail privilege (FAQ submission) In-Reply-To: (Chris Rees's message of "Thu, 15 Jan 2009 17:09:05 +0000") References: Message-ID: <87sknjjmlt.fsf@kobe.laptop> 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 jan-mailinglists at demter.de Fri Jan 16 17:15:29 2009 From: jan-mailinglists at demter.de (Jan Demter) Date: Fri Jan 16 17:15:35 2009 Subject: Thoughts on jail privilege (FAQ submission) In-Reply-To: References: Message-ID: <20AB93FA-080E-47D6-8075-B591A7DBCF38@demter.de> 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 utisoft at googlemail.com Sat Jan 17 04:01:40 2009 From: utisoft at googlemail.com (Chris Rees) Date: Sat Jan 17 04:01:47 2009 Subject: Thoughts on jail privilege (FAQ submission) In-Reply-To: References: <20AB93FA-080E-47D6-8075-B591A7DBCF38@demter.de> Message-ID: ---------- 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 jilles at stack.nl Sat Jan 17 14:36:39 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Jan 17 14:36:46 2009 Subject: Incorrect (?) documentation for setreuid(2) could lead to security issues for user code In-Reply-To: <20090109062026.GI38127@noncombatant.org> References: <20090109062026.GI38127@noncombatant.org> Message-ID: <20090117223637.GA84044@stack.nl> 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 From oliver.pntr at gmail.com Fri Jan 23 13:15:08 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Fri Jan 23 13:15:15 2009 Subject: [patch] libc Berkeley DB information leak In-Reply-To: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> References: <20090115144459.GA3154@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <6101e8c40901231246j264c3e43y7989d14fb9b77037@mail.gmail.com> On 1/15/09, 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" > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-mem-info-leak.patch Type: text/x-diff Size: 960 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090123/ee100383/0001-fix-mem-info-leak.bin From victor at bsdes.net Sat Jan 24 00:55:10 2009 From: victor at bsdes.net (Victor Balada Diaz) Date: Sat Jan 24 00:55:19 2009 Subject: freebsd-update-server source code Message-ID: <20090124083721.GG4881@alf.bsdes.net> Hello, I know on CVS the source code of freebsd-update is in projects/freebsd-update-server but i can't find where is it now with svn. I've looked at base/projects/ but it's not there. Can anyone point me where can i find the latest source of freebsd-update-server? Thanks in advance. Regards. -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From brooks at freebsd.org Sat Jan 24 19:46:09 2009 From: brooks at freebsd.org (Brooks Davis) Date: Sun Jan 25 04:19:52 2009 Subject: freebsd-update-server source code In-Reply-To: <20090124083721.GG4881@alf.bsdes.net> References: <20090124083721.GG4881@alf.bsdes.net> Message-ID: <20090125034447.GA4840@lor.one-eyed-alien.net> On Sat, Jan 24, 2009 at 09:37:22AM +0100, Victor Balada Diaz wrote: > Hello, > > I know on CVS the source code of freebsd-update is in > projects/freebsd-update-server but i can't find where is it > now with svn. I've looked at base/projects/ but it's not there. > > Can anyone point me where can i find the latest source of > freebsd-update-server? base/projects is seperate from the projects repository which remains under cvs. The old cvs path remains valid. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090125/311f7147/attachment.pgp