FreeBSD Security Advisory FreeBSD-SA-14:06.openssl [REVISED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = FreeBSD-SA-14:06.opensslSecurity Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-04-08 Affects:All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-0076, CVE-2014-0160 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://security.FreeBSD.org/>. 0. Revision History v1.0 2014-04-08 Initial release. v1.1 2014-04-08 Added patch applying step in Solutions section. 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. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography. OpenSSL uses the Montgomery Ladder Approach to compute scalar multiplication in a fixed amount of time, which does not leak any information through timing or power. II. Problem Description The code used to handle the Heartbeat Extension does not do sufficient boundary checks on record length, which allows reading beyond the actual payload. [CVE-2014-0160]. Affects FreeBSD 10.0 only. A flaw in the implementation of Montgomery Ladder Approach would create a side-channel that leaks sensitive timing information. [CVE-2014-0076] III. Impact An attacker who can send a specifically crafted packet to TLS server or client with an established connection can reveal up to 64k of memory of the remote system. Such memory might contain sensitive information, including key material, protected content, etc. which could be directly useful, or might be leveraged to obtain elevated privileges. [CVE-2014-0160] A local attacker might be able to snoop a signing process and might recover the signing key from it. [CVE-2014-0076] IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols implementation and do not use the ECDSA implementation from OpenSSL are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.x and FreeBSD 9.x] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch.asc # gpg --verify openssl.patch.asc [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc # gpg --verify openssl-10.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch Recompile the operating system using buildworld and installworld as described in http://www.FreeBSD.org/handbook/makeworld.html>. Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install IMPORTANT: the update procedure above does not update OpenSSL from the Ports Collection or from a package, known as security/openssl, which has to be updated separately via ports or package. Users who have installed security/openssl should update to at least version 1.0
FreeBSD Security Advisory FreeBSD-SA-14:06.openssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = FreeBSD-SA-14:06.opensslSecurity Advisory The FreeBSD Project Topic: OpenSSL multiple vulnerabilities Category: contrib Module: openssl Announced: 2014-04-08 Affects:All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-0076, CVE-2014-0160 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://security.FreeBSD.org/>. 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. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography. OpenSSL uses the Montgomery Ladder Approach to compute scalar multiplication in a fixed amount of time, which does not leak any information through timing or power. II. Problem Description The code used to handle the Heartbeat Extension does not do sufficient boundary checks on record length, which allows reading beyond the actual payload. [CVE-2014-0160]. Affects FreeBSD 10.0 only. A flaw in the implementation of Montgomery Ladder Approach would create a side-channel that leaks sensitive timing information. [CVE-2014-0076] III. Impact An attacker who can send a specifically crafted packet to TLS server or client with an established connection can reveal up to 64k of memory of the remote system. Such memory might contain sensitive information, including key material, protected content, etc. which could be directly useful, or might be leveraged to obtain elevated privileges. [CVE-2014-0160] A local attacker might be able to snoop a signing process and might recover the signing key from it. [CVE-2014-0076] IV. Workaround No workaround is available, but systems that do not use OpenSSL to implement the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols implementation and do not use the ECDSA implementation from OpenSSL are not vulnerable. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 8.x and FreeBSD 9.x] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl.patch.asc # gpg --verify openssl.patch.asc [FreeBSD 10.0] # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc # gpg --verify openssl-10.patch.asc Recompile the operating system using buildworld and installworld as described in http://www.FreeBSD.org/handbook/makeworld.html>. Restart all deamons using the library, or reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install IMPORTANT: the update procedure above does not update OpenSSL from the Ports Collection or from a package, known as security/openssl, which has to be updated separately via ports or package. Users who have installed security/openssl should update to at least version 1.0.1_10. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ---
FreeBSD Security Advisory FreeBSD-SA-14:05.nfsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = FreeBSD-SA-14:05.nfsserver Security Advisory The FreeBSD Project Topic: Deadlock in the NFS server Category: core Module: nfsserver Announced: 2014-04-08 Credits:Rick Macklem Affects:All supported versions of FreeBSD. Corrected: 2014-04-08 18:27:39 UTC (stable/10, 10.0-STABLE) 2014-04-08 18:27:46 UTC (releng/10.0, 10.0-RELEASE-p1) 2014-04-08 23:16:19 UTC (stable/9, 9.2-STABLE) 2014-04-08 23:16:05 UTC (releng/9.2, 9.2-RELEASE-p4) 2014-04-08 23:16:05 UTC (releng/9.1, 9.1-RELEASE-p11) 2014-04-08 23:16:19 UTC (stable/8, 8.4-STABLE) 2014-04-08 23:16:05 UTC (releng/8.4, 8.4-RELEASE-p8) 2014-04-08 23:16:05 UTC (releng/8.3, 8.3-RELEASE-p15) CVE Name: CVE-2014-1453 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://security.FreeBSD.org/>. I. Background The Network File System (NFS) allows a host to export some or all of its file systems so that other hosts can access them over the network and mount them as if they were on local disks. FreeBSD includes both server and client implementations of NFS. II. Problem Description The kernel holds a lock over the source directory vnode while trying to convert the target directory file handle to a vnode, which needs to be returned with the lock held, too. This order may be in violation of normal lock order, which in conjunction with other threads that grab locks in the right order, constitutes a deadlock condition because no thread can proceed. III. Impact An attacker on a trusted client could cause the NFS server become deadlocked, resulting in a denial of service. IV. Workaround Systems that do not provide NFS services are not vulnerable. Neither are systems that do but use the old NFS implementation, which is the default in FreeBSD 8.x. To determine which implementation an NFS server is running, run the following command: # kldstat -v | grep -cw nfsd This will print 1 if the system is running the new NFS implementation, and 0 otherwise. To switch to the old NFS implementation: 1) Append the following lines to /etc/rc.conf: nfsv4_server_enable="no" oldnfs_server_enable="yes" 2) If the NFS server is compiled into the kernel (which is the case for the stock GENERIC kernel), replace the NFSD option with the NFSSERVER option, then recompile your kernel as described in http://www.FreeBSD.org/handbook/kernelconfig.html>. If the NFS server is not compiled into the kernel, the correct module will be loaded at boot time. 3) Finally, reboot the system. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. 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-14:05/nfsserver.patch # fetch http://security.FreeBSD.org/patches/SA-14:05/nfsserver.patch.asc # gpg --verify nfsserver.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the system. 3) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - - stable/8/ r264285 releng/8.3/ r264284 releng/8.4/ r264284 stable/9/ r264285 releng/9.1/ r264284 releng/9.2/ r264284 stable/10/r264266 releng/10.0/ r264267 - - To see which files were modified by a particula
Re: Heartbleed / r264266 / openssl version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/08/14 15:58, Chris Nehren wrote: > On Tue, Apr 08, 2014 at 15:47:29 -0700, Xin Li wrote: >> What would be the preferable way of representing the patchlevel? >> We can do it as part of a EN batch at later time. (Note though, >> even without this the user or an application can still use >> freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out >> the patchlevel for userland). > > On an updated system: > > [(18:56:41) apeiron@behemoth ~] freebsd-version 10.0-STABLE > [(18:56:42) apeiron@behemoth ~] freebsd-version -k 10.0-STABLE > [(18:56:43) apeiron@behemoth ~] freebsd-version -u 10.0-STABLE > [(18:56:47) apeiron@behemoth ~] > > I can't say this is very useful. Is this only supposed to work for > -RELEASE? Only for -RELEASE (note that 10.0-STABLE will be fully updated to a newer OpenSSL release soon so I'm not going to change anything there). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRIBQAAoJEJW2GBstM+nsR4AP/0MQ506KSLfzk9yPv/xTCBe3 vO9grcXPvjNieIZj7unhUJeHjgUoJju9CNZJ6Ee6vNACPAOpa3k1S63YbVCLZWhb Xv2N6TccWsY7Ioju4Mj+6IOOGS6R4yPmMFbd5/vFVTedZcgw5wZOFO+uLGXo05yG sTp9duMM40y3LaUGWje9BAa3Rc2CsrFkedsOgEJGoolpctq9xCGfdD4mKh8hhpQu Jdaz72+Tg0dthNSxpAYPXTGqSjYexPJWqVDm7+pQ7m4kU2otJqCkHH34OqcFRnCB UdDFhzX3hYHL569OW+uwNFguLko5iZ38I0fcRRhDs5M7bF84JzKuBCSjTaoQx2t+ xNSLvpuIW7PhhQQd4Ok9mHfocP1LBnisi3y/oL2mjDF6jlFH4hOS9gc14SPsGAHE jZLUy/H3MODC9vXelOlSYJEqkARRly8aAR6ils4NaOVLapOZAC3pjXr2nAMU0acS sgoCpysvWnx7MaNkBO9ZHT0bmSGmQH8jr29yzzBnZ9Tt4XZBtcGbX+Z0p1WgmUod wlB9IMI6qECEuPqgmkLCE4RPiIyJiFYzqwXPFI9m4+YkbVRpQTEFmzq8HL+ILqQ2 DA6BAfK0xNYZ3cGgKHfo8HvD6ffGfnG5rwGB5hS9MKAv1yaO1Y72H8LxhGyGq3ZR 6l81ijSaeHKsqUGDD9vw =D/V9 -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Heartbleed / r264266 / openssl version
On Tue, Apr 08, 2014 at 15:47:29 -0700, Xin Li wrote: > What would be the preferable way of representing the patchlevel? We > can do it as part of a EN batch at later time. (Note though, even > without this the user or an application can still use > freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out the > patchlevel for userland). On an updated system: [(18:56:41) apeiron@behemoth ~] freebsd-version 10.0-STABLE [(18:56:42) apeiron@behemoth ~] freebsd-version -k 10.0-STABLE [(18:56:43) apeiron@behemoth ~] freebsd-version -u 10.0-STABLE [(18:56:47) apeiron@behemoth ~] I can't say this is very useful. Is this only supposed to work for -RELEASE? -- Chris Nehren pgp8HDAvo8ETQ.pgp Description: PGP signature
Re: Heartbleed / r264266 / openssl version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 (Adding Bryan who asked this and Ben who is the maintainer as they might have some saying here; moving to public list as there is no sensitive information in this discussion). On 04/08/14 14:29, Thierry Thomas wrote: > Hello, > > I've just rebuilt a 10-STABLE server, and now: > > $ openssl version OpenSSL 1.0.1e-freebsd 11 Feb 2013 > > Actually, delphij's commit did'nt change the VERSION string in > crypto/openssl/Makefile. > > This is not very important, but it may be confusing for users. Bryan have brought this up on IRC as well. As far as I know, for the last decade we never bump the version number when making updates, unless it's a "wholesale" upgrade of certain components in very special circumstances. I have done a quick check on Linux systems and found they don't carry a patchlevel for "openssl" either however they do provide a way to tell the patchlevel because it's a package. However, they do bump the date as part of the update. What would be the preferable way of representing the patchlevel? We can do it as part of a EN batch at later time. (Note though, even without this the user or an application can still use freebsd-version(1) on FreeBSD 10.0-RELEASE and up to find out the patchlevel for userland). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTRHyBAAoJEJW2GBstM+nspTsP/RucGMxAU6c7Bn9N0zGGWGBp mjlfTa5wlTYC+04VHX0q/LwFng+bUfPRqY3WC89VOuQkpgDgz/V/PwaZSG+92ib1 h6yQVzojOkV4vvVv2OBcfaaVUuAyIq8HGGT0gMh5wlnpoEt2k8d3GsilPU+R6jUz LQMhc07GAtUfDN7AErZ4TAsouaSQh7Z28tl7F5usel/V502jAzoA8B3qo+otRHnI DLYVSHmOAHrtCJoahC1eLm6zYdJWydyEtzUhDzNhWvGyptnQTw+KP48DoetJiVk7 06l/lODsJB9qh+A9u0ac8MAj/Zx8MTHB1cbP5yXyzr27dTzRe+pLbqqgmrKYA5Xj oQY3wumS8rAclfj7KHgZeE6ZGzp4at8pfrmuxlO/Pf8Si102kXakSoEwtUx9WU/I hgX/t6IPLhxLG7IoU/pJlETE8pAB81STOQs1QrPigK28UYhk3tc9H26TzkcfZvFz 5o86blfV0E6xdkuRUMT3i5sPj2DpHW75MTXzeM/ADdeRgdZBMW5GvDQAhtQCMQGN 1baTZjz46a3ZfJ3lJKbYGRAtGONH5QmeqfX2WlPKOf9ZrX3GMk3OSevcEEJ7QE9f ihccNQzuFMzTkFiE8WBrP5xr9YKXQdM9Uqdx/cDC/PNTnguzAon69bU9m1AJLsPv Xr3LKX5wWT83jO5WW1RX =t1w7 -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Do we need to fetch them from the Internet? Local packages can do the job, nope? But it will lead to kind of bootstrapping… or everything as packages bootstrapped once for all. And yes, it will not be some pie (a french stock phrase meaning it will be hard, translated word for word :) ). On 08/04/2014 21:26, John-Mark Gurney wrote: > Florent Peterschmitt wrote this message on Tue, Apr 08, 2014 at 20:39 +0200: >> On 08/04/2014 19:46, Mark Boolootian wrote: >>> While it may not be quite what you're looking for, ports contains >>> OpenSSL 1.0.1g. >> >> Why not moving critical parts of the basesystem to ports, that will be >> installed at system installation of course? > > Because we have programs in base that depend upon OpenSSL... so, > moving OpenSSL out of base is not really an option, unless you want > to remove fetch, hostapd, pkg, and wpa_supplicant from the base system, > we are stuck w/ OpenSSL in base... > > yes, there is pkg there, how are you going to fetch packages to install > if you don't have that? > > btw, all found w/ ldd /usr/bin/* /usr/sbin/* 2>/dev/null | less and > searching for libssl... > signature.asc Description: OpenPGP digital signature
Re: OpenSSL on 8.3 (pfsense appliance)
08/04/2014 21:44 - Daniel Howard wrote: > Hello, > > Per the heartbleed vulnerability, I'm looking at a vulneranle pfsense > firewall appliance: > > # /usr/bin/openssl version > OpenSSL 0.9.8y 5 Feb 2013 > # /usr/local/bin/openssl version > OpenSSL 1.0.1e 11 Feb 2013 > # ldd /usr/local/sbin/openvpn | grep libssl > libssl.so.8 => /usr/local/lib/libssl.so.8 (0x8007e9000) > > Per Brian Drewery, the port has been fixed, but this appliance does not > have ports installed. > > I see an openssl package here: > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openssl.tbz > > At this moment, the timestamp is January. Can one reasonably expect that > there is a process building updated packages for this branch? Can anyone > advise how long before a new openssl package is published here? Or should > I spin up an 8.3 box to build a package? > > Has anyone else here patched a pfsense appliance yet? Last I saw their fix > ETA is Thursday. > > > Thanks, > -danny > > -- > http://dannyman.toldme.com > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" > For pfsense, you should definitely ask this question in the pfsense forum (http://forum.pfsense.org/). Pfsense is essentially a fork of FreeBSD and they have their own type of package system. They just released version 2.1.1 a few days ago, but I doubt it includes the latest patches of openssl. -- Carlo Strub Ports committer ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
OpenSSL on 8.3 (pfsense appliance)
Hello, Per the heartbleed vulnerability, I'm looking at a vulneranle pfsense firewall appliance: # /usr/bin/openssl version OpenSSL 0.9.8y 5 Feb 2013 # /usr/local/bin/openssl version OpenSSL 1.0.1e 11 Feb 2013 # ldd /usr/local/sbin/openvpn | grep libssl libssl.so.8 => /usr/local/lib/libssl.so.8 (0x8007e9000) Per Brian Drewery, the port has been fixed, but this appliance does not have ports installed. I see an openssl package here: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openssl.tbz At this moment, the timestamp is January. Can one reasonably expect that there is a process building updated packages for this branch? Can anyone advise how long before a new openssl package is published here? Or should I spin up an 8.3 box to build a package? Has anyone else here patched a pfsense appliance yet? Last I saw their fix ETA is Thursday. Thanks, -danny -- http://dannyman.toldme.com ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Florent Peterschmitt wrote this message on Tue, Apr 08, 2014 at 20:39 +0200: > On 08/04/2014 19:46, Mark Boolootian wrote: > > While it may not be quite what you're looking for, ports contains > > OpenSSL 1.0.1g. > > Why not moving critical parts of the basesystem to ports, that will be > installed at system installation of course? Because we have programs in base that depend upon OpenSSL... so, moving OpenSSL out of base is not really an option, unless you want to remove fetch, hostapd, pkg, and wpa_supplicant from the base system, we are stuck w/ OpenSSL in base... yes, there is pkg there, how are you going to fetch packages to install if you don't have that? btw, all found w/ ldd /usr/bin/* /usr/sbin/* 2>/dev/null | less and searching for libssl... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 4/8/2014 2:54 PM, Niklaus Schiess wrote: Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 support in 0.9.x. So thats not an excuse. The FreeBSD security team only maintains advisories for the base distributions. What people install from the ports are not covered by those advisories. Issues affecting the FreeBSD Ports Collection are covered in http://vuxml.freebsd.org/ ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Uh, an excuse for what exactly? You must be talking about installing 1.0.1 from the ports. That was fixed yesterday by updating the version in ports to 1.0.1g: http://svnweb.freebsd.org/ports?view=revision&revision=350548 -nd. On Tue, Apr 8, 2014 at 2:54 PM, Niklaus Schiess wrote: > Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 > support in 0.9.x. So thats not an excuse. > > On 08.04.2014 19:50, Andrei wrote: >> On Tue, 8 Apr 2014 10:46:12 -0700 >> Mark Boolootian wrote: >> >>> While it may not be quite what you're looking for, ports contains >>> OpenSSL 1.0.1g. >> >> And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. >> ___ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" >> > > -- > PGP FP: CB84 8C68 ADDB 6C50 7DF1 4227 F2A6 056A A799 76DA > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Plenty of FreeBSD deployments use 1.0.1x due to the lack of TLS 1.2 support in 0.9.x. So thats not an excuse. On 08.04.2014 19:50, Andrei wrote: > On Tue, 8 Apr 2014 10:46:12 -0700 > Mark Boolootian wrote: > >> While it may not be quite what you're looking for, ports contains >> OpenSSL 1.0.1g. > > And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" > -- PGP FP: CB84 8C68 ADDB 6C50 7DF1 4227 F2A6 056A A799 76DA ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 8 April 2014 14:53, Ed Maste wrote: > I see that the fixes were committed a few minutes ago: Oops, some typos in the revision numbers in my last email (but the links were fine) -- here are the correct revision numbers: FreeBSD current: r264265 http://svnweb.freebsd.org/base?view=revision&revision=264265 FreeBSD stable/10: r264266 http://svnweb.freebsd.org/base?view=revision&revision=264266 FreeBSD 10.0: r264267 http://svnweb.freebsd.org/base?view=revision&revision=264267 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 8 April 2014 14:45, Nathan Dorfman wrote: > Are you sure about that? The only email I saw stated that FreeBSD 8.x > and 9.x weren't vulnerable because they were using an older OpenSSL, > from before the vulnerability was introduced. That is correct. > FreeBSD 10-STABLE, on the other hand, seems to use the vulnerable > OpenSSL 1.0.1e, and I didn't immediately see OPENSSL_NO_HEARTBEATS in > the Makefile there. So I may well be missing something, but it looks > vulnerable at first glance. Also correct. I see that the fixes were committed a few minutes ago: FreeBSD current: r2642675 http://svnweb.freebsd.org/base?view=revision&revision=264265 FreeBSD stable/10: r2642676 http://svnweb.freebsd.org/base?view=revision&revision=264266 FreeBSD 10.0: r264267 http://svnweb.freebsd.org/base?view=revision&revision=264267 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Are you sure about that? The only email I saw stated that FreeBSD 8.x and 9.x weren't vulnerable because they were using an older OpenSSL, from before the vulnerability was introduced. FreeBSD 10-STABLE, on the other hand, seems to use the vulnerable OpenSSL 1.0.1e, and I didn't immediately see OPENSSL_NO_HEARTBEATS in the Makefile there. So I may well be missing something, but it looks vulnerable at first glance. -nd. On Tue, Apr 8, 2014 at 2:17 PM, Merijn Verstraaten wrote: > Unless I misunderstood earlier emails, the heartbeat extension os ALREADY > disabled in base, therefore FreeBSD base isn't vulnerable and the only > problem is people who installed a newer OpenSSL from ports. > > Cheers, > Merijn > > > - Reply message - > From: "Nathan Dorfman" > To: "Mike Tancsa" > Cc: > Subject: FreeBSD's heartbleed response > Date: Tue, Apr 8, 2014 20:05 > > Someone please correct me if I'm wrong, but I think simply adding > -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is > sufficient to remove the vulnerability from the base system. > > -nd. > ___ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 08/04/2014 19:46, Mark Boolootian wrote: > While it may not be quite what you're looking for, ports contains > OpenSSL 1.0.1g. Why not moving critical parts of the basesystem to ports, that will be installed at system installation of course? It was one of the reasons to get BIND out from sysbase, but since their is a fresh new and powerful package manager, I think FreeBSD should rely on them instead on persisting to keep all sort of stuffs into the base. An "openssl-current" and an "openssl-stable", both providing "openssl" (an of course conflicting between each other) can be a good solution, nope? FreeBSD should be split in packages over the time, I think. And splitting it is not a synonym of a "not coherent system" ;) If you tell me FreeBSD should be and will always be delivered as tarballs/svn/freebsd-update, well, at least freebsd-update is a bit slow but still works. signature.asc Description: OpenPGP digital signature
Re: FreeBSD's heartbleed response
On 04/08/14 20:17, Merijn Verstraaten wrote: Unless I misunderstood earlier emails, the heartbeat extension os ALREADY disabled in base, therefore FreeBSD base isn't vulnerable and the only problem is people who installed a newer OpenSSL from ports. It would be nice, if so@ would send out such a statement to the security-announce list ahead of the actual advisory, so that fewer people will be panicing. -- Christian Laursen ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Unless I misunderstood earlier emails, the heartbeat extension os ALREADY disabled in base, therefore FreeBSD base isn't vulnerable and the only problem is people who installed a newer OpenSSL from ports. Cheers, Merijn - Reply message - From: "Nathan Dorfman" To: "Mike Tancsa" Cc: Subject: FreeBSD's heartbleed response Date: Tue, Apr 8, 2014 20:05 Someone please correct me if I'm wrong, but I think simply adding -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is sufficient to remove the vulnerability from the base system. -nd. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 08.04.14 20:05, Nathan Dorfman wrote: > Someone please correct me if I'm wrong, but I think simply adding > -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is > sufficient to remove the vulnerability from the base system. You forgot to mention installing, but yes. erdgeist ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
Someone please correct me if I'm wrong, but I think simply adding -DOPENSSL_NO_HEARTBEATS to crypto/openssl/Makefile (and recompiling!) is sufficient to remove the vulnerability from the base system. -nd. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On Tue, 8 Apr 2014 10:46:12 -0700 Mark Boolootian wrote: > While it may not be quite what you're looking for, ports contains > OpenSSL 1.0.1g. And also FreeBSD 8.x/9.x not affected because have 0.9.x OpenSSL in base. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
On 4/8/2014 1:42 PM, Chris Nehren wrote: later, FreeBSD remains unpatched. There are many worried sysadmins and other users in #freebsd and elsewhere wondering what's going on and when their systems will be patched. So far all we have is an unofficial gist on github and some discussion here (which most users don't see) with no further information. More transparency is needed. * The port was very quickly updated. * Xin posted a working patch to the list for those who really wanted to apply it. * I think it reasonable that code touching such a CRITICAL aspect of the OS be *well* reviewed before getting committed. IIRC there was a quick fix to an openssl bug in the past that then had to be fixed again. * What is stopping people who care about security from joining, or following this mailing list ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: FreeBSD's heartbleed response
While it may not be quite what you're looking for, ports contains OpenSSL 1.0.1g. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
FreeBSD's heartbleed response
First, please let me say that I understand that FreeBSD is a volunteer project. I know that most everyone is using donated time and donated hardware. You'll find some old email addresses of mine in the ports collection, in fact, and it's in the spirit of volunteering that I write today. The Heartbleed vulnerability is probably the highest priority, farthest-reaching vulnerability I've ever seen. Yet nearly a day later, FreeBSD remains unpatched. There are many worried sysadmins and other users in #freebsd and elsewhere wondering what's going on and when their systems will be patched. So far all we have is an unofficial gist on github and some discussion here (which most users don't see) with no further information. More transparency is needed. Given the above, I come with a request to help: how can the userbase at large help with getting these sorts of fixes out more quickly? I and others have hardware and time we'd be glad to donate if it would help resolve these sorts of critical issues more quickly. I'm sorry if I sound impatient. I want to help, but don't know how, so I'm asking here. -- Chris Nehren pgplacYTicAbR.pgp Description: PGP signature
Re: http://heartbleed.com/
On 4/8/2014 10:09 AM, Merijn Verstraaten wrote: On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: Hi, I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? ---Mike Information can be bled from a vulnerable OpenSSL talking to a malicious peer (i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). So no, vulnerable clients can't bleed info from safe servers. More importantly, since the leak only occurs when talking to malicious peers, your clients should be safe if they only communicate with trusted servers (since, presumably, your own servers don't maliciously enable heartbeat and leak info from clients). Of course it's still recommended to update your clients and renew keys, but in practice the risk should be minor for clients that only talk to secure servers. Thanks! Although we are certainly planing to update the vulnerable clients, this is not quite as dire and urgent as first described in the popular press-- at least as it applies to my client base. We also use IP addresses for the target servers in the client configs, so DNS poisoning does not apply to my scenario to trick the clients through that vector. Still, there are other ways, but this reduces the risk somewhat for my scenario at least. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On Apr 8, 2014, at 15:45 , Mike Tancsa wrote: > Hi, > I am trying to understand the implications of this bug in the context > of a vulnerable client, connecting to a server that does not have this > extension. e.g. a client app linked against 1.xx thats vulnerable talking to > a server that is running something from RELENG_8 in the base (0.9.8.x). Is > the server still at risk ? Will the client still bleed information ? > > ---Mike Information can be bled from a vulnerable OpenSSL talking to a malicious peer (i.e. malicious peer forces heartbeat and bleeds info from the vulnerable app). So no, vulnerable clients can't bleed info from safe servers. More importantly, since the leak only occurs when talking to malicious peers, your clients should be safe if they only communicate with trusted servers (since, presumably, your own servers don't maliciously enable heartbeat and leak info from clients). Of course it's still recommended to update your clients and renew keys, but in practice the risk should be minor for clients that only talk to secure servers. Cheers, Merijn signature.asc Description: Message signed with OpenPGP using GPGMail
Re: http://heartbleed.com/
On 08.04.14 15:45, Mike Tancsa wrote: > I am trying to understand the implications of this bug in the > context of a vulnerable client, connecting to a server that does not > have this extension. e.g. a client app linked against 1.xx thats > vulnerable talking to a server that is running something from RELENG_8 > in the base (0.9.8.x). Is the server still at risk ? Will the client > still bleed information ? If the adversary is in control of the network and can MITM the connection, then yes. The client leaks random chunks of up to 64k memory, and that is for each heartbeat request the server sends. erdgeist ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: http://heartbleed.com/
On 4/7/2014 5:02 PM, Xin Li wrote: The implications of this vulnerability are pretty massive, certificates will need to be replaced and so on. I don't want to repeat the page, so go read that. We are already working on this but building, reviewing, etc. would take some time. Attached is the minimal fix (extracted from upstream git repository) we are intending to use in the advisory for those who want to apply a fix now, please DO NOT use any new certificates before applying fixes. Hi, I am trying to understand the implications of this bug in the context of a vulnerable client, connecting to a server that does not have this extension. e.g. a client app linked against 1.xx thats vulnerable talking to a server that is running something from RELENG_8 in the base (0.9.8.x). Is the server still at risk ? Will the client still bleed information ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
