From owner-freebsd-security@freebsd.org Mon Sep 26 06:42:41 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 066CFBEAB8B for ; Mon, 26 Sep 2016 06:42:41 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E5D84167 for ; Mon, 26 Sep 2016 06:42:40 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3C40A3AE87 for ; Sun, 25 Sep 2016 23:42:34 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Two Dumb Questions Date: Sun, 25 Sep 2016 23:42:34 -0700 Message-ID: <32084.1474872154@segfault.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 06:42:41 -0000 Sorry folks. I'm almost entirely ignorant about everything crypto, and these questions would probably be better asked elsewhere, but you all on this list are nicer that folks elsewhere, and probably will have the kindness not to poke too much fun at my ignorance. So, here goes... First question: Regarding the specific kind of MiM deception being discussed in the following old article (which appears to be from way back in 2010), I'm confused by the assertion that it would be necessary to either bribe or bully some CA into handing out a fradulent cert in order to make the scheme work: https://www.wired.com/2010/03/packet-forensics/ Here's my point: If you really have already managed to become the man-in-the-middle anyway, then couldn't you just dummy up any and all responses, including those for DNS, in such a way as to make it all appear to the victim that everything was "normal", you know, such that he can see the cute little padlock symbol to the left of the URL in the browser? Second question: I've been trying to do some very simple- minded early reconnaissance on something that I believe to be a Really Bad Domain. The web site for the domain doesn't appear to use SSL at all, however when I went to this site: https://censys.io/ and punched in teh domain name and then clicked on "certificates" I was surprised to find three different ones shown for the domain in question, all three apparently issued by "Let's Encrypt Authority X3". So anyway, my question is real simple: Is there some way to work backwards from those in order to get some clues... any clues... about the identities of the actual owners/operators of this specific domain and/or its associated web site? Thanks in advance for any and all enlightenment. Regards, rfg From owner-freebsd-security@freebsd.org Mon Sep 26 08:08:08 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBAD8BEAC28 for ; Mon, 26 Sep 2016 08:08:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [199.15.120.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEAE2B8B for ; Mon, 26 Sep 2016 08:08:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 3sjGb40TYDz6V; Mon, 26 Sep 2016 02:59:44 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3sjGb26TmYz2Kx; Mon, 26 Sep 2016 02:59:42 -0500 (CDT) Date: Mon, 26 Sep 2016 02:59:42 -0500 From: "Matthew D. Fuller" To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions Message-ID: <20160926075942.GQ79735@over-yonder.net> References: <32084.1474872154@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.6.1-fullermd.4 (2016-04-27) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 08:08:08 -0000 Ronald F. Guilmette, and lo! it spake thus: > > Here's my point: If you really have already managed to become the > man-in-the-middle anyway, then couldn't you just dummy up any and > all responses, including those for DNS, in such a way as to make it > all appear to the victim that everything was "normal", you know, > such that he can see the cute little padlock symbol to the left of > the URL in the browser? Dummying up DNS responses is probably the way you got the user to your site in the first place; that would often be easier than trying to intercept their TCP 80/443 web connect tries. But they're not gonna get the cute little padlock unless the browser is happy with the cert, which is going to mean either the user accepts it through the increasingly-irritating-and-dire warnings, or it's signed by some CA the browser accepts. So, you'd either need to get one of the umpteen common CA's to give you one, or sneak an extra CA into their browser (and if you could do that latter, you could bypass a lot of the spoofing work anyway). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-security@freebsd.org Mon Sep 26 08:31:16 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E219BBE8427 for ; Mon, 26 Sep 2016 08:31:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FD70D8B for ; Mon, 26 Sep 2016 08:31:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [109.111.229.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 0F21D1D0F for ; Mon, 26 Sep 2016 08:31:10 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/0F21D1D0F; dkim=none; dkim-atps=neutral Subject: Re: Two Dumb Questions To: freebsd-security@freebsd.org References: <32084.1474872154@segfault.tristatelogic.com> From: Matthew Seaman Message-ID: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> Date: Mon, 26 Sep 2016 10:31:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7sO2noG75KfhLoMMKJRA473CIAMgUNK6c" X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, RCVD_IN_BRBL_LASTEXT, RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 08:31:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c Content-Type: multipart/mixed; boundary="W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8"; protected-headers="v1" From: Matthew Seaman To: freebsd-security@freebsd.org Message-ID: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> Subject: Re: Two Dumb Questions References: <32084.1474872154@segfault.tristatelogic.com> In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> --W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 26/09/2016 08:42, Ronald F. Guilmette wrote: >=20 > Sorry folks. I'm almost entirely ignorant about everything crypto, > and these questions would probably be better asked elsewhere, but > you all on this list are nicer that folks elsewhere, and probably > will have the kindness not to poke too much fun at my ignorance. > So, here goes... >=20 > First question: Regarding the specific kind of MiM deception > being discussed in the following old article (which appears to > be from way back in 2010), I'm confused by the assertion that > it would be necessary to either bribe or bully some CA into > handing out a fradulent cert in order to make the scheme work: >=20 > https://www.wired.com/2010/03/packet-forensics/ >=20 > Here's my point: If you really have already managed to become > the man-in-the-middle anyway, then couldn't you just dummy up > any and all responses, including those for DNS, in such a way > as to make it all appear to the victim that everything was > "normal", you know, such that he can see the cute little > padlock symbol to the left of the URL in the browser? The article doesn't make it entirely clear, but they are talking about encrypted web traffic here. In this case the MitM attacker acts as a proxy between you and the real web site you're attempting to contact. In order to gaid any advantage through being the man in the middle, they have to see the plaintext of the traffic you're sending to the intended site (plus they'd need the plaintext if they were intending to alter the traffic as it passed through -- think of them changing the destination or amount of a payment from your on-line banking servers for example). So they need to receive your HTTPS traffic, decrypt it, scan it for interesting stuff or modify it, and then re-encrypt it and send it on to the original destination as if it came directly from you. Similarly in reverse for the responses from the original site. Now, the MitM can easily set up a HTTPS server, but what they should not be able to do is get a TLS certificate in the name of the domain they are trying to spoof. So your browser should warn you about the DN of the certificate not matching the URL you're attempting to reach. This should be the case if the Certification Authority system is working as intended. Mostly it does, but there have been cases where, either through lax procedure or malfeasance a site certificate has been issued to some third party who does not own the site in question. There are also cases of Certification Authorities under the control of repressive regimes who will issue certificates for Google or Facebook or whatever on behalf of their government, thus enabling that government to spy on their citizen's supposedly secure web traffic. Those government controlled CAs were in the global lists of trusted CAs baked into web browsers and available as the ca_root_nss package, so browsers would automatically trust certificates issued by them. At least until this spoofing action was discovered, when they were dropped from the trusted list with extreme alacrity. (Is your copy of ca_root_nss up to date?) > Second question: I've been trying to do some very simple- > minded early reconnaissance on something that I believe to be > a Really Bad Domain. The web site for the domain doesn't > appear to use SSL at all, however when I went to this site: >=20 > https://censys.io/ >=20 > and punched in teh domain name and then clicked on "certificates" > I was surprised to find three different ones shown for the domain > in question, all three apparently issued by "Let's Encrypt Authority > X3". So anyway, my question is real simple: Is there some way to > work backwards from those in order to get some clues... any clues... > about the identities of the actual owners/operators of this specific > domain and/or its associated web site? >=20 > Thanks in advance for any and all enlightenment. Hmmm... their TLS certificate is issued by 'StartCom Class 1 DV Server CA' This is a CA that prominently advertizes free SSL certificates, but otherwise looks like it charges just like any other CA. See: http://www.startssl.com/ No idea if this CA is any good but there's nothing to suggest any wrong doing just from their site. Neither is there anything apparently wrong with censys.io -- in fact the censys.io site looks like a very useful research tool. Well, except it seems to have no clue about IPv6 which is pretty useless in this day and age. Cheers, Matthew --W8i43gvhfDsuSFDe85Kk7TXEDnHGSuNb8-- --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJX6NzOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkAT60EP/3ROIhv0II18byq93oWXmeFw MTmeOHhyRoS8upS6jOeIxNI+zDB+n+x+6tsuGikYn9P7akXVXX/x6aWyGztNKVwa IUlgTcWCH6s+wavn9mtTHOizs6EhT8UfoUWk0+I3L9YccWzFYf/kA6gxhFKKagoS B63YbulZqDA6LoyPvLvzqoIqijCZtPnBDak80K7DQqTI4Uof8M3OyCAMwqPv44m3 3nMRa59WI0l5hm9Bcq76fsPcb0as3G3HY4UBpjiVwQoGVpStf1ErIUcPWSEhxiIu AwxTLSbEAGIJ7DAdR8ciG4ukP2vTFZgiEQGZlhNsr7QW0uxzS06xd5bqDzHvS8aD X7NGbM5PzhhwYagOBvkON2MknPYr+oHU+GNvMLCrj4LRSQ5H59fHyXCYeUvbHnIQ 7CpDk7jANmLHr2DoEY0YPQo2sN3dqiuefQ33fUz4bkdY1+NjDeqFIHMFIB3udjvA 1pxdFXn/MJISBoPwAKFrcJ6qIYVvX9qlle0anjLdlo9As2i1xUbJ/gJplb7nGSnw nrXni0Hw+DFYJwx/ofW1Q2w3a3OZwkqTLJOAWB2W9FYRw9/DsM54hr7MKjVy4cIY 7UEHj+k3kmGzQNKAX8c9tjXFSJCc1SZTBAbm781YJl6eCpUh0jQj9yYN5M8U3QIM Y8RZdeYAjRqd1LyAgdlG =UE3K -----END PGP SIGNATURE----- --7sO2noG75KfhLoMMKJRA473CIAMgUNK6c-- From owner-freebsd-security@freebsd.org Mon Sep 26 08:32:11 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33B28BE8508 for ; Mon, 26 Sep 2016 08:32:11 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 19D5998; Mon, 26 Sep 2016 08:32:11 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id 187AB1996; Mon, 26 Sep 2016 08:32:11 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-16:26.openssl [REVISED] Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20160926083211.187AB1996@freefall.freebsd.org> Date: Mon, 26 Sep 2016 08:32:11 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 08:32:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-16:26.openssl Security Advisory The FreeBSD Project Topic: Multiple OpenSSL vulnerabilities Category: contrib Module: openssl Announced: 2016-09-23; revised on 2016-09-26 Credits: OpenSSL Project Affects: All supported versions of FreeBSD. Corrected: 2016-09-22 14:57:48 UTC (stable/11, 11.0-STABLE) 2016-09-22 15:55:27 UTC (releng/11.0, 11.0-RELEASE) 2016-09-22 15:05:38 UTC (stable/10, 10.3-STABLE) 2016-09-26 08:21:29 UTC (releng/10.3, 10.3-RELEASE-p9) 2016-09-26 08:21:29 UTC (releng/10.2, 10.2-RELEASE-p22) 2016-09-26 08:21:29 UTC (releng/10.1, 10.1-RELEASE-p39) 2016-09-26 08:19:33 UTC (stable/9, 9.3-STABLE) 2016-09-26 08:21:29 UTC (releng/9.3, 9.3-RELEASE-p47) CVE Name: CVE-2016-2177, CVE-2016-2178, CVE-2016-2179, CVE-2016-2180, CVE-2016-2181, CVE-2016-2182, CVE-2016-6302, CVE-2016-6303, CVE-2016-6304, CVE-2016-6306 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision history v1.0 2016-09-23 Initial release. v1.1 2016-09-26 Revised patch to address a regression in CVE-2016-2182 fix. 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 A malicious client can send an excessively large OCSP Status Request extension. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. [CVE-2016-6304] An overflow can occur in MDC2_Update() either if called directly or through the EVP_DigestUpdate() function using MDC2. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. [CVE-2016-6303] If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a DoS attack where a malformed ticket will result in an OOB read which will ultimately crash. [CVE-2016-6302] The function BN_bn2dec() does not check the return value of BN_div_word(). This can cause an OOB write if an application uses this function with an overly large BIGNUM. This could be a problem if an overly large certificate or CRL is printed out from an untrusted source. TLS is not affected because record limits will reject an oversized certificate before it is parsed. [CVE-2016-2182] The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is the total length the OID text representation would use and not the amount of data written. This will result in OOB reads when large OIDs are presented. [CVE-2016-2180] Some calculations of limits in OpenSSL have used undefined pointer arithmetic. This could cause problems with some malloc implementations. [CVE-2016-2177] Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. [CVE-2016-2178] In a DTLS connection where handshake messages are delivered out-of-order those messages that OpenSSL is not yet ready to process will be buffered for later use. Under certain circumstances, a flaw in the logic means that those messages do not get removed from the buffer even though the handshake has been completed. An attacker could force up to approx. 15 messages to remain in the buffer when they are no longer required. These messages will be cleared when the DTLS connection is closed. The default maximum size for a message is 100k. Therefore the attacker could force an additional 1500k to be consumed per connection. [CVE-2016-2179] A flaw in the DTLS replay attack protection mechanism means that records that arrive for future epochs update the replay protection "window" before the MAC for the record has been validated. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means that all subsequent legitimate packets are dropped causing a denial of service for a specific DTLS connection. [CVE-2016-2181] In OpenSSL 1.0.2 and earlier some missing message length checks can result in OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical DoS risk but this has not been observed in practice on common platforms. [CVE-2016-6306] III. Impact A remote attacker can cause OpenSSL server, regardless whether OCSP is supported, to have unbounded memory growth, and eventually lead to a Denial of Service. [CVE-2016-6304] If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. [CVE-2016-6303] An attacker who can send a malformed ticket to the server can cause an OOB read which will ultimately lead to a crash, resulting in a Denial of Service. [CVE-2016-6302] A local attacker can cause an application that parses overly large certificate or CRL to crash. TLS is not affected. [CVE-2016-2182] A local attacker who can create a specially-crafted time stamp file and pass it through the "ts" command of openssl(1) can cause it to crash. This functionality is not used by the SSL/TLS implementation. [CVE-2016-2180] Some OpenSSL code is questionable to integer overflow, which may lead to heap corruption. [CVE-2016-2177] An attacker may recover the private DSA key by conducting timing attack. [CVE-2016-2178] A remote attacker may cause a DTLS server to exhaust memory, resulting in a Denial of Service. [CVE-2016-2179] A remote attacker who can send DTLS records can cause the server to drop all subsequent packets for a specific connection. [CVE-2016-2181] A remote attacker can, in theory, cause OOB reads if the server enabled client authentication. [CVE-2016-6306] IV. Workaround No workaround is available. 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. Restart all daemons that use the library, or reboot the system. 2) 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 Restart all daemons that use the library, or reboot the system. 3) 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 10.3] # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-10.3.patch # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-10.3.patch.asc # gpg --verify openssl-10.3.patch.asc [FreeBSD 10.1 and 10.2] # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-10.2.patch # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-10.2.patch.asc # gpg --verify openssl-10.2.patch.asc [FreeBSD 9.3] # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-9.3.patch # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-9.3.patch.asc # gpg --verify openssl-9.3.patch.asc For all releases, additionally, apply the openssl-fix.patch: # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-fix.patch # fetch https://security.FreeBSD.org/patches/SA-16:26/openssl-fix.patch.asc # gpg --verify openssl-fix.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart all daemons that use the library, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r306335 releng/9.3/ r306336 stable/10/ r306196 releng/10.1/ r306336 releng/10.2/ r306336 releng/10.3/ r306336 stable/11/ r306195 releng/11.0/ r306198 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.13 (FreeBSD) iQIcBAEBCgAGBQJX6NvHAAoJEO1n7NZdz2rncwEP/3E3/QSGoSuhh7nqj3mzpSEl YYVB2B6HrxOa99b6rDT8lnnbdkE+Z409C8PP/gM/86WsMJXRrYbB2Dvnpt2hdMI6 SK94iydp4/QEoahi3DqaiuvO0xfDonUVK/XM+HD2+OGnf5XhRJrXN72aYauK2TEw 3U58NWqdkHKyLMb9Xw6oOeoexOl7rbzvxB1M1Idsb5+mcs4/n9MHfLPPYDMZdGmc XNuHzafINU4RD6ewZXmCjzZ2v4vlN6UJwoCdvm8NmG+2SGTqC+F/eldNFXuDuThz DODYpyfg6LjkxeY+P4eG8BMM1grrf1K0/HAaDx3h+F/H/XrxP2gNQfXPxK9HSddL eFWspWdRfJBydM4zrB8ndu/xmgfuCkgfrOgYU6z9eSLarmElM25Wic4+PiU0DXOq tHoL3k6B8sEio19Jh2ggdrZJBDM+BzlDqXve3Z1t9lY9DVZbcNe1xWJ7SreBQfXl n0r3LKLXxaFq014gb4/MV503XAn1P6Q87nL8wzkm9Z1qIHlJPt6Igrl+A5LcQ589 nW35xpeco8vFG0C6AmUk1cY14nZdZ/OjIEM4zGTd7oXRZRK6VFHJssTl0qJ/KLb1 rssl78ffhonLwFLLUzAGQlzYXYspz0ySwsrECcebOTzKzFUC9V0hcBuRMIwlAn5g aqC0mYXivXqtV/cgdYL/ =3i9P -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Mon Sep 26 12:52:44 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 420ABBE6830 for ; Mon, 26 Sep 2016 12:52:44 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E711FE7B for ; Mon, 26 Sep 2016 12:52:43 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm0-x22a.google.com with SMTP id b130so147638805wmc.0 for ; Mon, 26 Sep 2016 05:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=i+N5fKLQzlB/0Ns6QV57HEiyExeN8kIluYP7rMzNrm4=; b=BV0hXLR0fSTzGlRlavhStACIYccUsuRcrSGNo0iK1130KKGargsXWCbTbNBx0OvitJ SrjOu2uzCVt33M11hF2KcIJRNZ7jRIe+D20Sw8WTipcTU4TwvTFJcLylND35K3UI2DCm 5y6Hu7nVYJvtVtQ4yQszVpP+igyIADp2jTmilHo67zOUKVld2ZeI7trYKwZ6Cz2ld1X6 5tkgkLO69VAb7G5T2NzUa2jlz1pjiaWVJwQhqOPaxhkzpc/O75YPWxOzidJsQG1b2rr+ fZPfTl5sVlGS1ZPwKw8qLOnKhMxyZfhmpyiRXtT1SAeLpsXJdi8ITLYvnFxW2Pbv2qLA K+wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=i+N5fKLQzlB/0Ns6QV57HEiyExeN8kIluYP7rMzNrm4=; b=WKUaQbheJZQc9cWhnap1hmXBtV5mTaSEmDovd+bVtnHccCw23McclIquvNwgKXovdc 2fDJoln/0pasGYr8C/v0MEKQY3FdCWvTAbHFslgnODFkgVH7Is9/FtyLxuIL6i5UCHNc FvoEx6DOGYJZAvoe+GXBY5TrO5ZNNiD+p/rPDzNtdulUyx1j6/QHKjbwYlFP9lBDFyEq QPtHUjQI32wHyovoyah5JYAPK4GE8RzKZSFE5HBdA5l5ty46jytNYcDX1XTP1/TL828N kc2F3/GWYFlm0wFcxPk14uWNEReAS8xfNHsiEOGMbfXC7uVoC/l85ch3T48fND1mGiu7 DYYw== X-Gm-Message-State: AA6/9RnwQ3ddwjsatvyr0yvfziy8nXZYgpjKZWE7EutMVC3wZ7Q7cue2kax1vlk2PL+/KQ== X-Received: by 10.28.105.18 with SMTP id e18mr13461287wmc.14.1474894362105; Mon, 26 Sep 2016 05:52:42 -0700 (PDT) Received: from gumby.homeunix.com ([81.17.24.158]) by smtp.gmail.com with ESMTPSA id f69sm11111896wmg.19.2016.09.26.05.52.40 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Sep 2016 05:52:41 -0700 (PDT) Date: Mon, 26 Sep 2016 13:52:38 +0100 From: RW To: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions Message-ID: <20160926135238.6296ddc2@gumby.homeunix.com> In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> References: <32084.1474872154@segfault.tristatelogic.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 12:52:44 -0000 On Sun, 25 Sep 2016 23:42:34 -0700 Ronald F. Guilmette wrote: > Here's my point: If you really have already managed to become > the man-in-the-middle anyway, then couldn't you just dummy up > any and all responses, including those for DNS, in such a way > as to make it all appear to the victim that everything was > "normal", you know, such that he can see the cute little > padlock symbol to the left of the URL in the browser? There's a simple paint analogy here: https://en.wikipedia.org/wiki/Diffie=E2=80=93Hellman_key_exchange that illustrates how it's possible to exchange a shared secret without an eavesdropper knowing what it is. The shared secret can then be used for symmetric encryption using something like AES. Actual protocols use public key cryptography so it can be established that the exchange is end to end, and not broken into two separate exchanges. From owner-freebsd-security@freebsd.org Mon Sep 26 20:48:16 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52955BEAD2B for ; Mon, 26 Sep 2016 20:48:16 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9A9405 for ; Mon, 26 Sep 2016 20:48:16 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 25D9B5522; Mon, 26 Sep 2016 20:48:15 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 3ADDC4346B; Mon, 26 Sep 2016 22:48:12 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-security Cc: RW Subject: Re: Two Dumb Questions References: <32084.1474872154@segfault.tristatelogic.com> <20160926135238.6296ddc2@gumby.homeunix.com> Date: Mon, 26 Sep 2016 22:48:12 +0200 In-Reply-To: <20160926135238.6296ddc2@gumby.homeunix.com> (RW via freebsd-security's message of "Mon, 26 Sep 2016 13:52:38 +0100") Message-ID: <86r3868k1f.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:48:16 -0000 RW writes: > There's a simple paint analogy here: > > https://en.wikipedia.org/wiki/Diffie=E2=80=93Hellman_key_exchange > > that illustrates how it's possible to exchange a shared secret without > an eavesdropper knowing what it is. The shared secret can then be used > for symmetric encryption using something like AES. SSL / TLS didn't commonly use DH, much less *safe* DH, until fairly recently, and DH alone is not very useful. You need either a shared secret or trusted key pairs to authenticate either or both endpoints. > Actual protocols use public key cryptography so it can be established > that the exchange is end to end, and not broken into two separate > exchanges. Assuming you can trust the public key, which is what CAs are for, but CAs can be hacked, deceived or coerced. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Mon Sep 26 20:53:23 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9A69BEB1F7 for ; Mon, 26 Sep 2016 20:53:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 94FB4CEF for ; Mon, 26 Sep 2016 20:53:23 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id ABCF03AE87 for ; Mon, 26 Sep 2016 13:53:22 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions In-Reply-To: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> Date: Mon, 26 Sep 2016 13:53:22 -0700 Message-ID: <35148.1474923202@segfault.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:53:23 -0000 Thanks to everybody who replied, and sorry for being soooo off topic. In message <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org>, Matthew Seaman wrote: >> https://www.wired.com/2010/03/packet-forensics/ >>... >The article doesn't make it entirely clear, but they are talking about >encrypted web traffic here. In this case the MitM attacker acts as a >proxy between you and the real web site you're attempting to contact. >In order to gaid any advantage through being the man in the middle, they >have to see the plaintext of the traffic you're sending to the intended >site (plus they'd need the plaintext if they were intending to alter the >traffic as it passed through -- think of them changing the destination >or amount of a payment from your on-line banking servers for example). >So they need to receive your HTTPS traffic, decrypt it, scan it for >interesting stuff or modify it, and then re-encrypt it and send it on to >the original destination as if it came directly from you. Similarly in >reverse for the responses from the original site. Right. I had assumed all the above. >Now, the MitM can easily set up a HTTPS server, but what they should not >be able to do is get a TLS certificate in the name of the domain they >are trying to spoof. Well, see, this gets to the heart of my question, and my ignorance. If you are the man in the middle, and if the target/victim asks for the certificate for some spoofed site `X', can't you just give him back something which is valid for the spoofed site, you know, since you are in the middle completely anyway? And also, I read something recently about how some guy was surprised to find that... due to some temporary cock-up by one CA... he could get a certificate for foo.bar.tld but he later found that he could use that also for the superdomain of that, bar.tld. That was a minor but significant screw up by the CA which was later corrected, but it does give one reason to wonder about other possible scenarios. For example, could a MiM perhaps get a cert for wwww.foo.tld (four w's) and then, if that same MiM is able to send the victom spoofed DNS responses, when asked for DNS of www.foo.tld, couldn't he/she just sent back a CNAME which equates www.foo.tld to wwww.foo.tld and then also run a web server that makes wwww.foo.tld look like the real thing? Remember, the story I gave a link to (see above) suggested that somebody has been out there actively selling MiM gear, *and* the story also suggested that -no- CA was either bullied or bribed into creating any dodgy certs. So how that box works is still rather mysterious, to me at least. >So your browser should warn you about the DN of >the certificate not matching the URL you're attempting to reach. This >should be the case if the Certification Authority system is working as >intended. Mostly it does, but there have been cases where, either >through lax procedure or malfeasance a site certificate has been issued >to some third party who does not own the site in question. There are >also cases of Certification Authorities under the control of repressive >regimes who will issue certificates for Google or Facebook or whatever >on behalf of their government, thus enabling that government to spy on >their citizen's supposedly secure web traffic. Those government >controlled CAs were in the global lists of trusted CAs baked into web >browsers and available as the ca_root_nss package, so browsers would >automatically trust certificates issued by them. At least until this >spoofing action was discovered, when they were dropped from the trusted >list with extreme alacrity. (Is your copy of ca_root_nss up to date?) Thanks. This all is very enlightening. I understand the basics of how things are "supposed" to work, but other than that, much of what you said above is news to me. >> Second question: I've been trying to do some very simple- >> minded early reconnaissance on something that I believe to be >> a Really Bad Domain. The web site for the domain doesn't >> appear to use SSL at all, however when I went to this site: >> >> https://censys.io/ >> >> and punched in teh domain name and then clicked on "certificates" >> I was surprised to find three different ones shown for the domain >>... >Hmmm... their TLS certificate is issued by 'StartCom Class 1 DV Server >CA' This is a CA that prominently advertizes free SSL certificates, but >otherwise looks like it charges just like any other CA. >See: http://www.startssl.com/ No idea if this CA is any good but >there's nothing to suggest any wrong doing just from their site. >Neither is there anything apparently wrong with censys.io -- in fact the >censys.io site looks like a very useful research tool. Well, except it >seems to have no clue about IPv6 which is pretty useless in this day and >age. Sorry. I apparently wasn't clear. Yes, absolutely, the censys.io web site appears to me to be a great resarch tool. *It* is *not* the "Really Bad Domain" that I want to do reconnaissance on. It is just a research tool that I was using -as- I was doing recon on an entirely unrelated domain. (I didn't provide the name of that other domain. Let's just call it somereallyevildomain.com. :-) So, returning to my question, I punched in "somereallyevildomain.com" to the censys.io research web site, and it is telling me that the domain name "somereallyevildomain.com" is associated with three certificates, all three issued by "Let's Encrypt Authority X3". I do not know *anything* about the actual *identities* of the people who are running the somereallyevildomain.com domain or its associated web site, but I dearly *do* want to try to find out who these evil parties are. (I do a lot of this kind of thing... finding an outting perpetrators of all manner of Bad Stuff on the Internet.) So again, my question is: Given that I have these three certs, is there any way that I can leverage those into some information... i.e. *any* information... about the party or parties to whom those cets were issued? And also: If I can, how would I do that? Regards, rfg From owner-freebsd-security@freebsd.org Tue Sep 27 00:11:47 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB82DBEBB86 for ; Tue, 27 Sep 2016 00:11:47 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id A763EE24 for ; Tue, 27 Sep 2016 00:11:47 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 2281261DD; Tue, 27 Sep 2016 00:11:46 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 1685343485; Tue, 27 Sep 2016 02:11:40 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions References: <35148.1474923202@segfault.tristatelogic.com> Date: Tue, 27 Sep 2016 02:11:40 +0200 In-Reply-To: <35148.1474923202@segfault.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 26 Sep 2016 13:53:22 -0700") Message-ID: <86inti8amb.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 00:11:47 -0000 "Ronald F. Guilmette" writes: > If you are the man in the middle, and if the target/victim asks for > the certificate for some spoofed site `X', can't you just give him > back something which is valid for the spoofed site, you know, since > you are in the middle completely anyway? The client should not trust the certificate it gets from the server unless it can be traced back to a certificate in the client's trust store. For instance, if the server has a certificate signed by StartCom, it will transmit its own certificate as well as a copy of StartCom's intermediate certificate (which was used to sign the server certificate), which in turn was signed with StartCom's root certificate, which is in the trust store. > And also, I read something recently about how some guy was surprised > to find that... due to some temporary cock-up by one CA... he could > get a certificate for foo.bar.tld but he later found that he could > use that also for the superdomain of that, bar.tld. That was a > minor but significant screw up by the CA which was later corrected, > but it does give one reason to wonder about other possible scenarios. This rings a bell, but all I can think of at the moment is the claim earlier this year that StartSSL (StartCom's CA service) could be tricked into issuing certificates for any domain to anyone, which turned out to be false. Also, StartSSL used to automatically add example.com as an alternate name when you ordered a certificate for foo.example.com (which you could only do after proving that you owned example.com), but they stopped doing that. > For example, could a MiM perhaps get a cert for wwww.foo.tld (four w's) > and then, if that same MiM is able to send the victom spoofed DNS > responses, when asked for DNS of www.foo.tld, couldn't he/she just > sent back a CNAME which equates www.foo.tld to wwww.foo.tld and then > also run a web server that makes wwww.foo.tld look like the real thing? I find your scenario confusing, but if I understand you correctly, no. Browsers don't know or care about CNAMEs. They will try to match the certificate's distinguished name against the server name that was in the URL. In your scenario, the victim's browser will expect a certificate for www.foo.tld and will balk when presented with a certificate for wwww.foo.tld. > So again, my question is: Given that I have these three certs, is there > any way that I can leverage those into some information... i.e. *any* > information... about the party or parties to whom those cets were issued? You could try to contact the certificate authority that issued the certificate and ask, but I doubt they'd answer (if they even know), and in Let's Encrypt's case, there isn't anyone you can ask. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Tue Sep 27 01:01:15 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68918BEA58F for ; Tue, 27 Sep 2016 01:01:15 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49F7A8E9 for ; Tue, 27 Sep 2016 01:01:14 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id u8R0hedG051195 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2016 17:43:40 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id u8R0heaj051194; Mon, 26 Sep 2016 17:43:40 -0700 (PDT) (envelope-from jmg) Date: Mon, 26 Sep 2016 17:43:40 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions Message-ID: <20160927004340.GB1662@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-security@freebsd.org References: <32084.1474872154@segfault.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32084.1474872154@segfault.tristatelogic.com> X-Operating-System: FreeBSD 11.0-ALPHA2 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 26 Sep 2016 17:43:41 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 01:01:15 -0000 Ronald F. Guilmette wrote this message on Sun, Sep 25, 2016 at 23:42 -0700: > Here's my point: If you really have already managed to become > the man-in-the-middle anyway, then couldn't you just dummy up > any and all responses, including those for DNS, in such a way > as to make it all appear to the victim that everything was > "normal", you know, such that he can see the cute little > padlock symbol to the left of the URL in the browser? As for DNS, that is the reason DNSSEC has been deployed. To ensure that the response is correct. Though if the attacker completely controls your inet connection, they don't even need to do this, as they can just pretend to be any IP they want to be. Cryptography allows you to verify the identity of another party and ensuring it is not tampered with using PKI[1]. There are other forums that are better to ask how this is possible. [1] https://en.wikipedia.org/wiki/Public_key_infrastructure -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@freebsd.org Wed Sep 28 06:40:43 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B89A7BEC82F for ; Wed, 28 Sep 2016 06:40:43 +0000 (UTC) (envelope-from nzp@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A26F2E80; Wed, 28 Sep 2016 06:40:43 +0000 (UTC) (envelope-from nzp@riseup.net) Received: from cotinga.riseup.net (unknown [10.0.1.164]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id F2B481A051D; Wed, 28 Sep 2016 06:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1475044836; bh=VNSnIbIlorL2+sV+59psgDxYjp35rQTVkHEXVT9jrM4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EeFgxi0HcOCOqnUMqk3CsbwhLZW0ufrOKwXcX4Rrm69ppyHAFXbPy1q6BwLc9NNoA V4GbiKir9IzDl7kXHIJNAcYRG6TfGZ4gZwQSDRmL/Ik3JklXHw9F3alkx/tvmq5crN My321tj/JFbyvBcQSAmPcw8Axpfvf69NewuYG+JQ= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nzp) with ESMTPSA id 3BE07400A8 Date: Wed, 28 Sep 2016 08:40:27 +0200 From: Nikola =?UTF-8?B?UGF2bG92acSH?= To: Matthew Seaman Cc: freebsd-security@freebsd.org Subject: Re: Two Dumb Questions Message-ID: <20160928084027.20ca33f2@riseup.net> In-Reply-To: <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> References: <32084.1474872154@segfault.tristatelogic.com> <74ed7019-cb87-c55a-fb6d-1c016bf04d59@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 06:40:43 -0000 On Mon, 26 Sep 2016 10:31:02 +0200 Matthew Seaman wrote: [...] > > > > https://censys.io/ > > [...] > > Hmmm... their TLS certificate is issued by 'StartCom Class 1 DV Server > CA' This is a CA that prominently advertizes free SSL certificates, > but otherwise looks like it charges just like any other CA. > See: http://www.startssl.com/ No idea if this CA is any good but > there's nothing to suggest any wrong doing just from their site. Just an FYI regarding StartCom: Mozilla is suspending their CA for one year (and quite likely forever, it's unlikely they'll be able to meet the requirements for reactivation). Lots more info here in Mozilla's investigation report: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview -- PGP: 28CC 9078 8358 CE2D 6824 A5BC 2DB2 CD24 5BE7 8F06 From owner-freebsd-security@freebsd.org Thu Sep 29 12:48:09 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC8D3BEC32F; Thu, 29 Sep 2016 12:48:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81A5F125; Thu, 29 Sep 2016 12:48:09 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bpakq-0022Lt-U4>; Thu, 29 Sep 2016 14:48:00 +0200 Received: from x55b3873c.dyn.telefonica.de ([85.179.135.60] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bpakq-001aC7-KU>; Thu, 29 Sep 2016 14:48:00 +0200 Date: Thu, 29 Sep 2016 14:47:55 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , freebsd-security@freebsd.org Subject: IPFW on CURRENT: NAT forwarding exposes internal IP! Message-ID: <20160929144755.2e4f7800.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Originating-IP: 85.179.135.60 X-Mailman-Approved-At: Thu, 29 Sep 2016 13:45:49 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 12:48:09 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCg0KRGVz cGl0ZSBvdGhlciBwcm9ibGVtcyB3aXRoIElQRlcgYW5kIGl0cyBkb2N1bWVudGF0aW9uIHJlZ2Fy ZGluZyBOQVQsIEkgZmFjZSBhIHNlcmlvdXMNCmFuZCBkaXN0dXJiaW5nIHByb2JsZW0uDQoNCkkg cnVuIGEgTmFub0JTRCBiYXNlZCByb3V0ZXIvZmlyZXdhbGwgcHJvamVjdCBvZiBteSBvd24sIHJ1 bm5pbmcgQ1VSUkVOVCAoRnJlZUJTRA0KMTIuMC1DVVJSRU5UICMxIHIzMDYzMzM6IE1vbiBTZXAg MjYgMDg6MzY6MDIgQ0VTVCAyMDE2KS4gSVBGVyBpcyB0aGUgZmlsdGVyIG9mIG15IGNob2ljZSwN CnNpbmNlIGl0IGlzIEZyZWVCU0QncyBuYXRpdmUuIEkgYWxzbyB1c2UgSW4ta2VybmVsLU5BVCBh cyB3ZWxsIGFzIHBwcG9lZC9wcHAuIFRoZSBtb2RlbQ0KaXMgY29ubmVjdGVkIHRvIGEgZGVkaWNh dGVkIE5JQywgdGhlIHBwcG9lLXRyYWZmaWMgaXMgdHJhbnNwb3J0ZWQgdmlhIHR1bjAgLSBJIHRo aW5rIHRoaXMNCmlzIHRoZSB1c3VhbCBzdHVmZi4NCg0KVGhlIElQRlcgaGFzIHRoaXMgTkFUIHJ1 bGU6DQoNCiR7ZndjbWR9ICAgICAgICBuYXQgMSBjb25maWcgaWYgJHtpZl9pc3AwfSBcDQogICAg ICAgICAgICAgICAgICAgICAgICBsb2cgXA0KICAgICAgICAgICAgICAgICAgICAgICAgcmVzZXQg XA0KICAgICAgICAgICAgICAgICAgICAgICAgc2FtZV9wb3J0cyBcDQogICAgICAgICAgICAgICAg ICAgICAgICByZWRpcmVjdF9wb3J0IHRjcCAke3NlcnZlcl9nYXRlfToyMiAyMiBcDQogICAgICAg ICAgICAgICAgICAgICAgICByZWRpcmVjdF9wb3J0IHRjcCAke3NlcnZlcl93d3d9OjgwIDgwIFwN CiAgICAgICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0X3BvcnQgdGNwICR7c2VydmVyX3d3d306 NDQzIDQ0MyBcDQogICAgICAgICAgICAgICAgICAgICAgICByZWRpcmVjdF9wb3J0IHRjcCAke3Nl cnZlcl9yZWZkYn06OTczNCA5NzM0DQoNCnNlcnZlcl93d3cgaXMgYXNzaWduZWQgdG8gYSBub24t b2ZmaWNpYWwgSVAsIDE5Mi4xNjguMTAuMTAuDQoNCmlmX2lzcD10dW4wLCB0dW4wJ3MgSVAgaXMg Z2l2ZW4gYnkgdGhlIHByb3ZpZGVyLCBJIHVzZSBuZXQvZGRjbGllbnQgYXMgdGhlIHVwZGF0ZXIg Zm9yIGENCmR5bmFtaWMgRE5TIGFjY291bnQuDQoNCkkgdXNlIGFuIGludGVybmFsIEROUyBzZXJ2 ZXIsIHdoaWNoIHJlc29sdmVzIDkyLjE2OC4xMC4xMCB0byBhIGNlcnRhaW4gbmFtZS4gSSBhbHNv IHVzZQ0Kc2VsZiBzaWduZWQgU1NMIGNlcnRpY2F0ZXMsIGp1c3QgZm9yIGNvbXBsZXRlbmVzcyBv ZiB0aGlzIGluZm9ybWF0aW9uLg0KDQpDb25uZWN0aW5nIGZyb20gdGhlIG91dHNpZGUgd29ybGQg dG8gbXkgZHluRE5TIGRvbWFpbiB0cmlnZ2VycyBGaXJlZm94IG9yIGFueSBvdGhlcg0KYnJvd3Nl ciB0byBjb21wYWxpbiBhYm91dCB0aGUgc2VsZiBzaWduZWQgU1NMIGNlcnRpZmljYXRlIC0gYXMg dXN1YWwsIGJ1dCB0aGVuLCBhZGRpbmcNCml0LCBzdWRkZW5seSB0aGUgZG9tYWluIG5hbWUgKHNh eTogd3d3LmJsYWJsYS5vcmcpIGlzIHJlcGxhY2VkIGJ5IHRoZSBpbnRlcm5hbCBJUCBJDQpkZWxl Z2F0ZSBhbnkgYWNjZXNzIG9uIHBvcnRzIDgwIGFuZCA0NDMgdG8uDQoNCldoYXQgaGFwcGVucyBo ZXJlPyBJIGNvbnNpZGVyIHRoaXMgYSBidWcsIEkgbmV2ZXIgc2F3IHRoaXMgb24gb3VyIExpbnV4 IHNlcnZlcnMgcnVubmluZyBhDQpzaW1pbGFyIHNldHVwIChmb3J3YXJkaW5nLCBCSU5EIDkuMTAv QklORCA5LjExKS4NCg0KVGhhbmtzLA0KDQpPbGl2ZXINCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVS RS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mg0KDQppUUVjQkFFQkNBQUdCUUpYN1ExN0FBb0pFT2dC Y0Q3QS81Tjg4eUFIL1JaTFVSUWJDNUxUZ0pEL05VZEU1MUYzDQp5UFZhVVFJYWVHbTkzZHU4N0sy b3BYczNETnRNcjBtMVNJMXdRWmRPQVFEbDN5cU1rejliWDlWVFV3ZXVBbHRwDQpaY0J4aFoyVkFD UUpDdS9Bc1lJV1dXcDZybGluaXlaV01yK1RPeU50VER4ZFBySVhZendlZlgrZllOK1V5LzA0DQo5 UGFsZmNUL1MrOXE1REtkN3NtN0s2THFzVTBISjlHcEtnTm5zeXFXRUFXdk9SZ3hVdktTM0dTOWpF anhVbnJEDQoyMHlUWGp5aXUwbVM4VVlMUzdEYnJyZ0l0ZzNmWEVKVkc4MTg4dHdlRkI1YWFsUVJI Nm95TkdheFdsR2FGOFJjDQpLOXQ0Nzl2Nk9XM1hDczlGaUc2QXRDenBtblVrQ29NdHhsN2xZM2hQ VS9TaDFQNWVwWXUyNmJkb0YyZWNyMWc9DQo9b01HTA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t LS0tDQo= From owner-freebsd-security@freebsd.org Thu Sep 29 13:15:38 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0A6BECC50; Thu, 29 Sep 2016 13:15:38 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AE9076F; Thu, 29 Sep 2016 13:15:36 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.15.2/8.15.2) with ESMTPSA id u8TD0Aq7016952 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Sep 2016 16:00:10 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Subject: Re: IPFW on CURRENT: NAT forwarding exposes internal IP! From: Daniel Kalchev In-Reply-To: <20160929144755.2e4f7800.ohartman@zedat.fu-berlin.de> Date: Thu, 29 Sep 2016 16:00:10 +0300 Cc: FreeBSD CURRENT , freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C0203C4-F332-42B1-AF62-18723E63E112@digsys.bg> References: <20160929144755.2e4f7800.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.3226) X-Mailman-Approved-At: Thu, 29 Sep 2016 15:47:11 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 13:15:38 -0000 It looks like your httpd server is doing a redirect to your internal IP = address, which it thinks is it=E2=80=99s ServerName. Don=E2=80=99t think = NAT has anything to do with it. Daniel > On 29.09.2016 =D0=B3., at 15:47, O. Hartmann = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 >=20 > Despite other problems with IPFW and its documentation regarding NAT, = I face a serious > and disturbing problem. >=20 > I run a NanoBSD based router/firewall project of my own, running = CURRENT (FreeBSD > 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the = filter of my choice, > since it is FreeBSD's native. I also use In-kernel-NAT as well as = pppoed/ppp. The modem > is connected to a dedicated NIC, the pppoe-traffic is transported via = tun0 - I think this > is the usual stuff. >=20 > The IPFW has this NAT rule: >=20 > ${fwcmd} nat 1 config if ${if_isp0} \ > log \ > reset \ > same_ports \ > redirect_port tcp ${server_gate}:22 22 \ > redirect_port tcp ${server_www}:80 80 \ > redirect_port tcp ${server_www}:443 443 \ > redirect_port tcp ${server_refdb}:9734 9734 >=20 > server_www is assigned to a non-official IP, 192.168.10.10. >=20 > if_isp=3Dtun0, tun0's IP is given by the provider, I use net/ddclient = as the updater for a > dynamic DNS account. >=20 > I use an internal DNS server, which resolves 92.168.10.10 to a certain = name. I also use > self signed SSL certicates, just for completeness of this information. >=20 > Connecting from the outside world to my dynDNS domain triggers Firefox = or any other > browser to compalin about the self signed SSL certificate - as usual, = but then, adding > it, suddenly the domain name (say: www.blabla.org) is replaced by the = internal IP I > delegate any access on ports 80 and 443 to. >=20 > What happens here? I consider this a bug, I never saw this on our = Linux servers running a > similar setup (forwarding, BIND 9.10/BIND 9.11). >=20 > Thanks, >=20 > Oliver > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 >=20 > iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3 > yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp > ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04 > 9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD > 20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc > K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=3D > =3DoMGL > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-security@freebsd.org Thu Sep 29 13:24:18 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D04E6C00206; Thu, 29 Sep 2016 13:24:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94E14EF7; Thu, 29 Sep 2016 13:24:18 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bpbJw-002IkD-MC>; Thu, 29 Sep 2016 15:24:16 +0200 Received: from x55b3873c.dyn.telefonica.de ([85.179.135.60] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bpbJw-001dYP-Cb>; Thu, 29 Sep 2016 15:24:16 +0200 Date: Thu, 29 Sep 2016 15:24:11 +0200 From: "O. Hartmann" To: Daniel Kalchev Cc: FreeBSD CURRENT , freebsd-security@freebsd.org Subject: Re: IPFW on CURRENT: NAT forwarding exposes internal IP! Message-ID: <20160929152411.7a9c3f4f.ohartman@zedat.fu-berlin.de> In-Reply-To: <6C0203C4-F332-42B1-AF62-18723E63E112@digsys.bg> References: <20160929144755.2e4f7800.ohartman@zedat.fu-berlin.de> <6C0203C4-F332-42B1-AF62-18723E63E112@digsys.bg> Organization: FU Berlin X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Originating-IP: 85.179.135.60 X-Mailman-Approved-At: Thu, 29 Sep 2016 15:55:03 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 13:24:18 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkFtIFRo dSwgMjkgU2VwIDIwMTYgMTY6MDA6MTAgKzAzMDANCkRhbmllbCBLYWxjaGV2IDxkYW5pZWxAZGln c3lzLmJnPiBzY2hyaWViOg0KDQpZZXMsIHlvdXIgYXJlIHJpZ2h0IDotKQ0KDQpZZXMsIEknbSB3 cm9uZywgaXQgaXMgbm90IE5BVCA6LSgNCg0KVGhhbmtzIGEgbG90LCANCg0KT2xpdmVyDQo+IEl0 IGxvb2tzIGxpa2UgeW91ciBodHRwZCBzZXJ2ZXIgaXMgZG9pbmcgYSByZWRpcmVjdCB0byB5b3Vy IGludGVybmFsIElQIGFkZHJlc3MsIHdoaWNoDQo+IGl0IHRoaW5rcyBpcyBpdOKAmXMgU2VydmVy TmFtZS4gRG9u4oCZdCB0aGluayBOQVQgaGFzIGFueXRoaW5nIHRvIGRvIHdpdGggaXQuDQo+IA0K PiBEYW5pZWwNCj4gDQo+ID4gT24gMjkuMDkuMjAxNiDQsy4sIGF0IDE1OjQ3LCBPLiBIYXJ0bWFu biA8b2hhcnRtYW5AemVkYXQuZnUtYmVybGluLmRlPiB3cm90ZToNCj4gPiANCj4gPiAtLS0tLUJF R0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tDQo+ID4gSGFzaDogU0hBMjU2DQo+ID4gDQo+ID4g DQo+ID4gRGVzcGl0ZSBvdGhlciBwcm9ibGVtcyB3aXRoIElQRlcgYW5kIGl0cyBkb2N1bWVudGF0 aW9uIHJlZ2FyZGluZyBOQVQsIEkgZmFjZSBhIHNlcmlvdXMNCj4gPiBhbmQgZGlzdHVyYmluZyBw cm9ibGVtLg0KPiA+IA0KPiA+IEkgcnVuIGEgTmFub0JTRCBiYXNlZCByb3V0ZXIvZmlyZXdhbGwg cHJvamVjdCBvZiBteSBvd24sIHJ1bm5pbmcgQ1VSUkVOVCAoRnJlZUJTRA0KPiA+IDEyLjAtQ1VS UkVOVCAjMSByMzA2MzMzOiBNb24gU2VwIDI2IDA4OjM2OjAyIENFU1QgMjAxNikuIElQRlcgaXMg dGhlIGZpbHRlciBvZiBteQ0KPiA+IGNob2ljZSwgc2luY2UgaXQgaXMgRnJlZUJTRCdzIG5hdGl2 ZS4gSSBhbHNvIHVzZSBJbi1rZXJuZWwtTkFUIGFzIHdlbGwgYXMgcHBwb2VkL3BwcC4NCj4gPiBU aGUgbW9kZW0gaXMgY29ubmVjdGVkIHRvIGEgZGVkaWNhdGVkIE5JQywgdGhlIHBwcG9lLXRyYWZm aWMgaXMgdHJhbnNwb3J0ZWQgdmlhIHR1bjANCj4gPiAtIEkgdGhpbmsgdGhpcyBpcyB0aGUgdXN1 YWwgc3R1ZmYuDQo+ID4gDQo+ID4gVGhlIElQRlcgaGFzIHRoaXMgTkFUIHJ1bGU6DQo+ID4gDQo+ ID4gJHtmd2NtZH0gICAgICAgIG5hdCAxIGNvbmZpZyBpZiAke2lmX2lzcDB9IFwNCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgIGxvZyBcDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICByZXNl dCBcDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICBzYW1lX3BvcnRzIFwNCj4gPiAgICAgICAg ICAgICAgICAgICAgICAgIHJlZGlyZWN0X3BvcnQgdGNwICR7c2VydmVyX2dhdGV9OjIyIDIyIFwN Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0X3BvcnQgdGNwICR7c2VydmVyX3d3 d306ODAgODAgXA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgcmVkaXJlY3RfcG9ydCB0Y3Ag JHtzZXJ2ZXJfd3d3fTo0NDMgNDQzIFwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgIHJlZGly ZWN0X3BvcnQgdGNwICR7c2VydmVyX3JlZmRifTo5NzM0IDk3MzQNCj4gPiANCj4gPiBzZXJ2ZXJf d3d3IGlzIGFzc2lnbmVkIHRvIGEgbm9uLW9mZmljaWFsIElQLCAxOTIuMTY4LjEwLjEwLg0KPiA+ IA0KPiA+IGlmX2lzcD10dW4wLCB0dW4wJ3MgSVAgaXMgZ2l2ZW4gYnkgdGhlIHByb3ZpZGVyLCBJ IHVzZSBuZXQvZGRjbGllbnQgYXMgdGhlIHVwZGF0ZXINCj4gPiBmb3IgYSBkeW5hbWljIEROUyBh Y2NvdW50Lg0KPiA+IA0KPiA+IEkgdXNlIGFuIGludGVybmFsIEROUyBzZXJ2ZXIsIHdoaWNoIHJl c29sdmVzIDkyLjE2OC4xMC4xMCB0byBhIGNlcnRhaW4gbmFtZS4gSSBhbHNvDQo+ID4gdXNlIHNl bGYgc2lnbmVkIFNTTCBjZXJ0aWNhdGVzLCBqdXN0IGZvciBjb21wbGV0ZW5lc3Mgb2YgdGhpcyBp bmZvcm1hdGlvbi4NCj4gPiANCj4gPiBDb25uZWN0aW5nIGZyb20gdGhlIG91dHNpZGUgd29ybGQg dG8gbXkgZHluRE5TIGRvbWFpbiB0cmlnZ2VycyBGaXJlZm94IG9yIGFueSBvdGhlcg0KPiA+IGJy b3dzZXIgdG8gY29tcGFsaW4gYWJvdXQgdGhlIHNlbGYgc2lnbmVkIFNTTCBjZXJ0aWZpY2F0ZSAt IGFzIHVzdWFsLCBidXQgdGhlbiwgYWRkaW5nDQo+ID4gaXQsIHN1ZGRlbmx5IHRoZSBkb21haW4g bmFtZSAoc2F5OiB3d3cuYmxhYmxhLm9yZykgaXMgcmVwbGFjZWQgYnkgdGhlIGludGVybmFsIElQ IEkNCj4gPiBkZWxlZ2F0ZSBhbnkgYWNjZXNzIG9uIHBvcnRzIDgwIGFuZCA0NDMgdG8uDQo+ID4g DQo+ID4gV2hhdCBoYXBwZW5zIGhlcmU/IEkgY29uc2lkZXIgdGhpcyBhIGJ1ZywgSSBuZXZlciBz YXcgdGhpcyBvbiBvdXIgTGludXggc2VydmVycw0KPiA+IHJ1bm5pbmcgYSBzaW1pbGFyIHNldHVw IChmb3J3YXJkaW5nLCBCSU5EIDkuMTAvQklORCA5LjExKS4NCj4gPiANCj4gPiBUaGFua3MsDQo+ ID4gDQo+ID4gT2xpdmVyDQo+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCj4gPiBW ZXJzaW9uOiBHbnVQRyB2Mg0KPiA+IA0KPiA+IGlRRWNCQUVCQ0FBR0JRSlg3UTE3QUFvSkVPZ0Jj RDdBLzVOODh5QUgvUlpMVVJRYkM1TFRnSkQvTlVkRTUxRjMNCj4gPiB5UFZhVVFJYWVHbTkzZHU4 N0syb3BYczNETnRNcjBtMVNJMXdRWmRPQVFEbDN5cU1rejliWDlWVFV3ZXVBbHRwDQo+ID4gWmNC eGhaMlZBQ1FKQ3UvQXNZSVdXV3A2cmxpbml5WldNcitUT3lOdFREeGRQcklYWXp3ZWZYK2ZZTitV eS8wNA0KPiA+IDlQYWxmY1QvUys5cTVES2Q3c203SzZMcXNVMEhKOUdwS2dObnN5cVdFQVd2T1Jn eFV2S1MzR1M5akVqeFVuckQNCj4gPiAyMHlUWGp5aXUwbVM4VVlMUzdEYnJyZ0l0ZzNmWEVKVkc4 MTg4dHdlRkI1YWFsUVJINm95TkdheFdsR2FGOFJjDQo+ID4gSzl0NDc5djZPVzNYQ3M5RmlHNkF0 Q3pwbW5Va0NvTXR4bDdsWTNoUFUvU2gxUDVlcFl1MjZiZG9GMmVjcjFnPQ0KPiA+ID1vTUdMDQo+ ID4gLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5v cmcgbWFpbGluZyBsaXN0DQo+ID4gaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ZyZWVic2QtY3VycmVudA0KPiA+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWls IHRvICJmcmVlYnNkLWN1cnJlbnQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciICANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGZyZWVic2Qt Y3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cHM6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVudA0KPiBUbyB1bnN1YnNjcmliZSwg c2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJlQGZyZWVic2Qub3Jn Ig0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyDQoNCmlR RWNCQUVCQ0FBR0JRSlg3Ulg3QUFvSkVPZ0JjRDdBLzVOODVyQUgvamJ3UjB5ZDFiRTBhOU9JdWtm SnlmMlkNCjNzK08rR1Fha3haSm1ZRDZ2ditrKzZNMnFEOVRGc3JDSG1IeWxOZnNWNWdCaXJGWmU2 Z0VIUmliWG52bmxReHkNCkptWG5pSzJvL0hYbC9ORHhFS1RzaHFYNnh0Uyt4ZW93N0loT2JDRzQy T2FacnhVZEtnWDNxZmdZMTNWS0VWTTENCjlOZEx2MEVFMHZlSytFbnhteG5CU0RsMmg1d1Y2OXBL MVJhK2lMU1NmWWVPK1ZNTUgyZVVLNmpiaC9TNGNCNWgNCkFKNG9LMDhieTRTTk9zb3ZNd3RLTEYr VTFOSGFEdUhLV0c5MnJYVTFtWU4vTTNycXRWZ1ZwcTA0MHRPVkRGcEMNCk55bGhqNGUxWFJuTS9V M1k3VkJ6dGZUTjRFWEdSSzhEK20xZk9YR2lQbmV0MzB2aGQza1lGUmhURjV2bmYxVT0NCj1MdW1K DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==