From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 19:50:23 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB7765C for ; Mon, 9 Mar 2015 19:50:23 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67F28FCA for ; Mon, 9 Mar 2015 19:50:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t29JnrBX038577 for ; Mon, 9 Mar 2015 22:49:53 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 9 Mar 2015 22:49:53 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-security@FreeBSD.org Subject: DRAM Rowhammer exploits Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Mon, 09 Mar 2015 22:49:53 +0300 (MSK) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:50:23 -0000 Dear colleagues, any thoughts we're vulnerable to this? http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:02:16 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 679EA8AC for ; Mon, 9 Mar 2015 20:02:16 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 294B7234 for ; Mon, 9 Mar 2015 20:02:15 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C4F43BB86; Mon, 9 Mar 2015 19:52:04 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t29Jq4XZ091441; Mon, 9 Mar 2015 19:52:04 GMT (envelope-from phk@phk.freebsd.dk) To: Dmitry Morozovsky Subject: Re: DRAM Rowhammer exploits In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <91439.1425930724.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Mar 2015 19:52:04 +0000 Message-ID: <91440.1425930724@critter.freebsd.dk> Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:02:16 -0000 -------- In message , Dmitry M= orozo vsky writes: >Dear colleagues, > >any thoughts we're vulnerable to this? It's a hardware problem, *everybody* are vulnerable. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:14:54 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88BB4D87 for ; Mon, 9 Mar 2015 20:14:54 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0704C3C4 for ; Mon, 9 Mar 2015 20:14:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t29KEUEo039003; Mon, 9 Mar 2015 23:14:30 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Mon, 9 Mar 2015 23:14:30 +0300 (MSK) From: Dmitry Morozovsky To: Poul-Henning Kamp Subject: Re: DRAM Rowhammer exploits In-Reply-To: <91440.1425930724@critter.freebsd.dk> Message-ID: References: <91440.1425930724@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Mon, 09 Mar 2015 23:14:30 +0300 (MSK) Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:14:54 -0000 On Mon, 9 Mar 2015, Poul-Henning Kamp wrote: > >any thoughts we're vulnerable to this? > > It's a hardware problem, *everybody* are vulnerable. Well, it seems I used somewhat incorrect wordings. Any chance we could provide workaround like for Pentium f00f bug? Actually I doubt it as cache flush commands do not seem to be avoidable -- but I would like to hear from real security experts.... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:24:34 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62352F2 for ; Mon, 9 Mar 2015 20:24:34 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2429B6D8 for ; Mon, 9 Mar 2015 20:24:33 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id t29K4SJQ035778 for ; Mon, 9 Mar 2015 15:04:28 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Mon Mar 9 15:04:28 2015 Message-ID: <54FDFCC2.1090603@denninger.net> Date: Mon, 09 Mar 2015 15:04:18 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits References: <91440.1425930724@critter.freebsd.dk> In-Reply-To: <91440.1425930724@critter.freebsd.dk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060300080804000807010209" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:24:34 -0000 This is a cryptographically signed message in MIME format. --------------ms060300080804000807010209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 3/9/2015 14:52, Poul-Henning Kamp wrote: > -------- > In message , Dmitr= y Morozo > vsky writes: >> Dear colleagues, >> >> any thoughts we're vulnerable to this? > It's a hardware problem, *everybody* are vulnerable. > And.... this is why (among other reasons) you run ECC memory! Note that privilege escalation is not your only problem; corruption of=20 data headed to the disk, specifically with filesystems like ZFS, in many = ways can be worse because that can result in corruption that the system=20 CANNOT detect. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms060300080804000807010209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAzMDkyMDA0MThaMCMGCSqGSIb3DQEJBDEW BBTOO7ow39C6osIl8kTYsaYX65O36jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAtVFwaDlkwoSlewN5+gOV4sgRRW12 9nsenkR2sNXZiGDpLwHhjwtNr/t0uvNLybEGt7nyEVIZ1LTPnWZOMJfljmV9nwgD66rj8TnG 1MZ2jamjfe4C2DWZDqqZHL7HuOxiSl0/FEZcuxjmFbVQJh5pdwPou/Xkw+bKoQ6EHM9RYwKr DW99zkIl2pqcEPeGVbAxrq8FtGeOqS4OkaPWUG5rgB/5WKC93DeansDNpoIpiJSsA7W9cVkz OEob86XGpCnN8IarGvrpz3O9GnXoB/QGjGc0a7tG66/Xjl5sUlKrhJRohaGtuDR87IC7dzPJ jjO/B3aI5vpWnpIO8su/1R113ef5G7CK0V0AzcF6Owq86hrQaMSTRynDUXYi6wjVdX3jAAAo KBl918C0DzpG3D9Me8dYkYjNIJ/nRF6oxU8QE21sTTHaRBDFmkCODe02MbXWjaKEH6FOa3V4 TGqZ1tqJzjvjZvsnqvRdIncJemrdF7Vk5dYt1jRNbuX7luGsjfPBbtrYa10gFvgU/A372iw9 hYRy5u3vr3EzfeTUcOdeqwz7+PXXf1W0cVZJL7afFsBB6BfegjD+LvPk30u+ALNEYY/W0Hyb E0xFTYWMPQMnnBWYOaffYFSJHQv++xuyf6E+gHTzRzOnXqcrJfuMr2H8pnL1ByWbmukhLuTP 8PeQBGsAAAAAAAA= --------------ms060300080804000807010209-- From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:29:16 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8188C3FF for ; Mon, 9 Mar 2015 20:29:16 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 66DE7794 for ; Mon, 9 Mar 2015 20:29:15 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 64DFBB82A; Mon, 9 Mar 2015 13:23:08 -0700 (PDT) To: "Poul-Henning Kamp" Subject: Re: DRAM Rowhammer exploits In-reply-to: Your message of "Mon, 09 Mar 2015 19:52:04 -0000." <91440.1425930724@critter.freebsd.dk> References: <91440.1425930724@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Mon, 09 Mar 2015 19:52:04 -0000." Date: Mon, 09 Mar 2015 13:23:08 -0700 From: Bakul Shah Message-Id: <20150309202308.64DFBB82A@mail.bitblocks.com> Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:29:16 -0000 On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" wrote: > -------- > In message , Dmitry Moro > zo > vsky writes: > >Dear colleagues, > > > >any thoughts we're vulnerable to this? > > It's a hardware problem, *everybody* are vulnerable. I guess manufacturer memory testing hasn't kept up to deal with shrinking geometries.... Hopefully ECC memory protects against such exploits (at least makes them a lot less vulnerable). From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:45:11 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BEFEBA1 for ; Mon, 9 Mar 2015 20:45:11 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2E4A3C for ; Mon, 9 Mar 2015 20:45:11 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id ED6503BB86; Mon, 9 Mar 2015 20:45:09 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t29Kj9ve068421; Mon, 9 Mar 2015 20:45:09 GMT (envelope-from phk@phk.freebsd.dk) To: Dmitry Morozovsky Subject: Re: DRAM Rowhammer exploits In-reply-to: From: "Poul-Henning Kamp" References: <91440.1425930724@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68419.1425933909.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Mar 2015 20:45:09 +0000 Message-ID: <68420.1425933909@critter.freebsd.dk> Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:45:11 -0000 -------- In message , Dmitry M= orozo vsky writes: >On Mon, 9 Mar 2015, Poul-Henning Kamp wrote: > >> >any thoughts we're vulnerable to this? >> = >> It's a hardware problem, *everybody* are vulnerable. > >Well, it seems I used somewhat incorrect wordings. > >Any chance we could provide workaround like for Pentium f00f bug? As far as I know the only workaround is increasing the DRAM refresh rate sufficiently that the hardware behaves as it should. It seems that such BIOS updates are being rolled out, but undoubtedly a lot of old machines will get none and it's not even entirely obvious that increasing the DRAM refresh rate is enough. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 20:46:21 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29887CEF for ; Mon, 9 Mar 2015 20:46:21 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DC71EA7A for ; Mon, 9 Mar 2015 20:46:20 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id EB55D3BB86; Mon, 9 Mar 2015 20:46:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t29KkJN7070816; Mon, 9 Mar 2015 20:46:19 GMT (envelope-from phk@phk.freebsd.dk) To: Bakul Shah Subject: Re: DRAM Rowhammer exploits In-reply-to: <20150309202308.64DFBB82A@mail.bitblocks.com> From: "Poul-Henning Kamp" References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70814.1425933979.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 09 Mar 2015 20:46:19 +0000 Message-ID: <70815.1425933979@critter.freebsd.dk> Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:46:21 -0000 -------- In message <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah write= s: >On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" wrote: >Hopefully ECC memory protects against such exploits (at least >makes them a lot less vulnerable). ECC only makes it harder, it doesn't make it impossible. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 21:37:03 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD02F18E for ; Mon, 9 Mar 2015 21:37:03 +0000 (UTC) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBAB176 for ; Mon, 9 Mar 2015 21:37:03 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id B07A6B827; Mon, 9 Mar 2015 14:37:02 -0700 (PDT) To: "Poul-Henning Kamp" Subject: Re: DRAM Rowhammer exploits In-reply-to: Your message of "Mon, 09 Mar 2015 20:46:19 -0000." <70815.1425933979@critter.freebsd.dk> References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> <70815.1425933979@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Mon, 09 Mar 2015 20:46:19 -0000." Date: Mon, 09 Mar 2015 14:37:02 -0700 From: Bakul Shah Message-Id: <20150309213702.B07A6B827@mail.bitblocks.com> Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:37:03 -0000 On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" wrote: > -------- > In message <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah writes: > >On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" > wrote: > > >Hopefully ECC memory protects against such exploits (at least > >makes them a lot less vulnerable). > > ECC only makes it harder, it doesn't make it impossible. According to the small sample in the paper below, the incidence of 3 bit errors is about 4000 times or more lower than single bit errors. These are the errors that may not even get detected by ECC. So not impossible but much better. http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_isca14.pdf It also proposes a few solutions. It seems to indicate that reducing refresh time by a factor of 7 (over 64ms) removes such errors. Hopefully this can be done via a firmware upgrade? I don't know if the physical page pool for kernel data can be isolated enough from user data to avoid this. [Probably not. Likely there is no standard way to do map a phys addr to a specific chip/row and diff. mfrs may use diff geometries. Though, perhaps this same phenomenon can be used to infer chip geometry!] Also see: http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 21:38:36 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1DE727F for ; Mon, 9 Mar 2015 21:38:36 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 6D83919B for ; Mon, 9 Mar 2015 21:38:35 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 13FF416A407; Mon, 9 Mar 2015 22:38:32 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsILcy1WiAnh; Mon, 9 Mar 2015 22:38:21 +0100 (CET) Received: from [192.168.10.211] (unknown [192.168.10.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4B69A16A402; Mon, 9 Mar 2015 22:38:21 +0100 (CET) Message-ID: <54FE12CE.1000401@digiware.nl> Date: Mon, 09 Mar 2015 22:38:22 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dmitry Morozovsky , freebsd-security@FreeBSD.org Subject: Re: DRAM Rowhammer exploits References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:38:36 -0000 On 09/03/2015 20:49, Dmitry Morozovsky wrote: > Dear colleagues, > > any thoughts we're vulnerable to this? > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > As pointed out is this a hardware originated problem, not really fixable by software. Only EEC should be able to catch this. Which is mostly used on hardware for servers. And luckily that is probably also the most likely platforms on which "unidentified third parties" can run this. As no sensible PAAS/Hardware provider would forgo the use of ECC. :) I would expect this type of test to appear in tools like memtest86. Giving you in indication in advance of the the possible problem. Next to that I see a few points where we could possibly mitigate this. As I read the article, the problem is not present if the refresh frequency is doubled. This sort of indicates that manufacturers are (a bit) to optimistic about the required RAM refresh cycles. 1) If possible reprogram the RAM referesh cycle time as it is setup by the BIOS. It will reduce the available memory by an unmeasurable fraction. 2) It would be possible to build a RAM refresh thread in the kernel reading every RAM memory within a certain time frame. Thus forgoing the refresh recycle time set by the BIOS. This will require some cycles in the kernel, costing some CPU and some memory bandwidth. Big disadvantage could be that it will cause some serious thrashing of the cache content if these writes go thru the cache flowed by a cacheflush. --WjW From owner-freebsd-security@FreeBSD.ORG Mon Mar 9 23:00:57 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 041E9CDE for ; Mon, 9 Mar 2015 23:00:57 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 B22B9FB3 for ; Mon, 9 Mar 2015 23:00:56 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 435C216A404; Tue, 10 Mar 2015 00:00:52 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NUoGszHdpAg; Tue, 10 Mar 2015 00:00:24 +0100 (CET) Received: from [192.168.10.211] (unknown [192.168.10.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 0EE7E16A406; Tue, 10 Mar 2015 00:00:24 +0100 (CET) Message-ID: <54FE2608.2080202@digiware.nl> Date: Tue, 10 Mar 2015 00:00:24 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Bakul Shah , Poul-Henning Kamp Subject: Re: DRAM Rowhammer exploits References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> <70815.1425933979@critter.freebsd.dk> <20150309213702.B07A6B827@mail.bitblocks.com> In-Reply-To: <20150309213702.B07A6B827@mail.bitblocks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-security@FreeBSD.org, Dmitry Morozovsky X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:00:57 -0000 On 09/03/2015 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" wrote: >> -------- >> In message <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah writes: >>> On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" >> wrote: >> >>> Hopefully ECC memory protects against such exploits (at least >>> makes them a lot less vulnerable). >> >> ECC only makes it harder, it doesn't make it impossible. > > According to the small sample in the paper below, the > incidence of 3 bit errors is about 4000 times or more lower > than single bit errors. These are the errors that may not > even get detected by ECC. So not impossible but much better. ECC does not only correct bit errors, it also allows one the detect them. Perhaps a good reason to start watching the reports about them.. And how many bit do I need to change to actually do something usefull? > It also proposes a few solutions. It seems to indicate that > reducing refresh time by a factor of 7 (over 64ms) removes > such errors. Hopefully this can be done via a firmware > upgrade? That was my suggestion 1. Up the refresh frequency. Might require the manufacturer, but could very well be done by the kernel if it knew how,what,where to write this. > I don't know if the physical page pool for kernel data can be > isolated enough from user data to avoid this. [Probably not. > Likely there is no standard way to do map a phys addr to a > specific chip/row and diff. mfrs may use diff geometries. > Though, perhaps this same phenomenon can be used to infer chip > geometry!] Isn't this what the RAM chip info tells us? And RAM does not move around in the physical address space. So creating a mapping where virtual = physical (perhaps even offsetted into an empty block in the vast 2^64 bits address space) would allow the refresh tread to do its work. But creating that mapping while running in kernelmode could be not so easy. --WjW From owner-freebsd-security@FreeBSD.ORG Tue Mar 10 16:23:32 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECCD0A23 for ; Tue, 10 Mar 2015 16:23:32 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63DB283B for ; Tue, 10 Mar 2015 16:23:31 +0000 (UTC) Received: from [192.168.0.143] ([95.91.226.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MIiHs-1YTA1B3epc-002GwB for ; Tue, 10 Mar 2015 17:23:29 +0100 Message-ID: <54FF1A81.4090706@gmx.de> Date: Tue, 10 Mar 2015 17:23:29 +0100 From: "lokadamus@gmx.de" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits References: <91440.1425930724@critter.freebsd.dk> <20150309202308.64DFBB82A@mail.bitblocks.com> <70815.1425933979@critter.freebsd.dk> <20150309213702.B07A6B827@mail.bitblocks.com> In-Reply-To: <20150309213702.B07A6B827@mail.bitblocks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qQ7FEIvpZzz4LJl0Qjl07v/V8iBO788ScjeU2G+10cEJdz9RA35 4OVaiik9AXR+468KBNGLM2SYgdKjLOnLH9YNBet6oLCxLjIHBaOA7yLgGzXwf6LB/nm6zUf W9pgehuzr4b7CWurlVb0LZJEF7eEpLOGcFniCqi+PunD9VSIMgD3ftcma9OvnS+MC1n74jT k5d9jMCQ+Ju/FnZwrvV6w== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:23:33 -0000 On 03/09/15 22:37, Bakul Shah wrote: > On Mon, 09 Mar 2015 20:46:19 -0000 "Poul-Henning Kamp" > wrote: >> -------- In message >> <20150309202308.64DFBB82A@mail.bitblocks.com>, Bakul Shah >> writes: >>> On Mon, 09 Mar 2015 19:52:04 -0000 "Poul-Henning Kamp" >>> >> wrote: >> >>> Hopefully ECC memory protects against such exploits (at least >>> makes them a lot less vulnerable). >> >> ECC only makes it harder, it doesn't make it impossible. > > According to the small sample in the paper below, the incidence of > 3 bit errors is about 4000 times or more lower than single bit > errors. These are the errors that may not even get detected by > ECC. So not impossible but much better. > > http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_isca14.pdf > > It also proposes a few solutions. It seems to indicate that > reducing refresh time by a factor of 7 (over 64ms) removes such > errors. Hopefully this can be done via a firmware upgrade? > > I don't know if the physical page pool for kernel data can be > isolated enough from user data to avoid this. [Probably not. Likely > there is no standard way to do map a phys addr to a specific > chip/row and diff. mfrs may use diff geometries. Though, perhaps > this same phenomenon can be used to infer chip geometry!] > > Also see: > http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security To > unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > A stupid way is to make hash over physical address space. But how much time will it cost to make it, check and write a new value? And when should it control the memory? After each read? Then only small blocks can be controlled. From owner-freebsd-security@FreeBSD.ORG Tue Mar 10 17:16:38 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AEE3A9F for ; Tue, 10 Mar 2015 17:16:38 +0000 (UTC) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (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 D86F3ED8 for ; Tue, 10 Mar 2015 17:16:37 +0000 (UTC) Received: by wesw62 with SMTP id w62so3351045wes.8 for ; Tue, 10 Mar 2015 10:16:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=cVupNXRDlOQNty3ZW4jIhCiVcA3v98NvOvM4v6EmYbc=; b=MnpIRqbHlsdleeUpIHtXDN60VY5LFoarIBtMOVgJyWAs21P/ouRQY20eTIbVeApiWX lplDkdhb2yZEcz16PR9LMInPo2O0qSfCgRgyBxcOjjKe7nD2jdZEgfatxW8IJcwCMQ3y 9p7POSior0PxtvNBZDtkcPYABcFSW0sPYs0+m/tAIt/tbH4LcbC7TqGFOnRihPqmWblD LJwOwrB5ncGixNmYYHdNgCtg1KEcXQ2j0lGxpBlVDyglFDPTSh15Q3jX1oMkPIOVaT7j 4ifxpn1aSoc8beM2GhyXHnFe/Mmk7WgeY2VU6JBX3FWXvCK0QKZC6fQF9C3xkX2N5+Fv cweQ== X-Gm-Message-State: ALoCoQlAK08qy6+zcVV3mvIgjlTyXGB40vFnqlN/AWIC11MKjkzMwZzXBmgUFcU4JcHhGAnoZY2j X-Received: by 10.194.88.131 with SMTP id bg3mr71765042wjb.119.1426007789688; Tue, 10 Mar 2015 10:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.159.133 with HTTP; Tue, 10 Mar 2015 10:15:49 -0700 (PDT) X-Originating-IP: [68.178.93.3] In-Reply-To: <54FE12CE.1000401@digiware.nl> References: <54FE12CE.1000401@digiware.nl> From: Leif Pedersen Date: Tue, 10 Mar 2015 12:15:49 -0500 Message-ID: Subject: Re: DRAM Rowhammer exploits To: "freebsd-security@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:16:38 -0000 I have a suggestion. As a simpler measure, would it be possible to implement a test at boot time to determine whether the system is vulnerable? I guess such a test would have to run in the kernel to get the particular memory mapping required. The result would naturally emit a kernel message, but it would be much easier to monitor for automatically if it also set a read-only sysctl. For sure at my company, I would add an alert for such a test on our most accessible systems. I could easily replace any affected hardware on our DMZ and edge networks if I can identify it easily. For that matter, some hardware may not need replacing if I diddle with the over-clocker's BIOS settings. Ongoing monitoring matters because I'd hate to have someone swap hardware or reset the BIOS in an emergency and not know they opened the vulnerability. If the hardware can be worked around, that's very helpful, but the proposals sound like they'd have fairly severe performance impacts and/or be impossible to guarantee for all hardware. On many of our systems, multi-user security is just not an issue, and for them I would choose performance over fixing this problem or replacing the hardware. Indeed, I would keep the hardware removed from sensitive systems to reuse in more protected environments. In any case, I would think that having a reliable test would be very helpful to most of this audience. Without it, I'm fumbling in the dark. Does anyone empathize with this? - Leif From owner-freebsd-security@FreeBSD.ORG Tue Mar 10 18:41:31 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E804A07 for ; Tue, 10 Mar 2015 18:41:31 +0000 (UTC) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (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 50DDBC4C for ; Tue, 10 Mar 2015 18:41:30 +0000 (UTC) Received: by yks20 with SMTP id 20so1634754yks.4 for ; Tue, 10 Mar 2015 11:41:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dWQ9VwjuqM/W+6pHrghse8Zc/uFUEkEB0Hl6P89qK5M=; b=Y/nUVJm+V4Mj/5gxxZwuF441JWcDbEvYesUDwGXvHIlfJCIfqn7IZyIM5FdtNkRGk4 NcJxwSQ1cQ6d854ha0VloMjI3YTO8KUbZsIqGPN/1gnXanUpeNJ0ulos18s9iRjn+NhY nzSUyn8Y/6ZVsfhxXBA9SqatDrqiHc1wIuN0GrEY2eF1RBX6qTEhxNSPFA3viMOcBTap /5sxLpOJbLRbUNxgHsN2QbQPNN64kbJujrEGpwg3bXPo9C/SZIj4JAS8nB2igmyQQs3K RoubUFXPQ2bANvaaSes2sjIHOU5gzOwkXZJo5jzf8nwNmLTiunNC9S3Rml+weax8AdE+ 3+mQ== X-Gm-Message-State: ALoCoQmnelpF9djTl5V700vqBJe3Sjm0luQDr1yMC32py8TUEehBNwAuSJQ37nwYnJWZeSKcv1xD MIME-Version: 1.0 X-Received: by 10.236.0.193 with SMTP id 41mr33960960yhb.146.1426012884261; Tue, 10 Mar 2015 11:41:24 -0700 (PDT) Received: by 10.170.104.86 with HTTP; Tue, 10 Mar 2015 11:41:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Mar 2015 19:41:24 +0100 Message-ID: Subject: Re: DRAM Rowhammer exploits From: Oliver Pinter To: Dmitry Morozovsky Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:41:31 -0000 On Mon, Mar 9, 2015 at 8:49 PM, Dmitry Morozovsky wrote: > Dear colleagues, > > any thoughts we're vulnerable to this? In memtest86 exists a rowhammer test - http://www.passmark.com/forum/showthread.php?4836-MemTest86-v6-0-Beta-%282015-02-13-Update-Beta-testing-is-now-closed%29 . > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > -- > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 06:58:04 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2380275 for ; Wed, 11 Mar 2015 06:58:04 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95FED9CC for ; Wed, 11 Mar 2015 06:58:04 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2B6w1rw014065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 Mar 2015 23:58:02 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54FFE774.50103@freebsd.org> Date: Tue, 10 Mar 2015 23:57:56 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd security , current@freebsd.com Subject: sendmail broken by libssl in current Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 06:58:04 -0000 [sorry for reposting but the original copy I got back had been truncated] libssl has a new "feature" implemented by: crypto/openssl/ssl/t1_lib.c 672 /* Add padding to workaround bugs in F5 terminators. 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 674 * 675 * NB: because this code works out the length of all existing 676 * extensions it MUST always appear last. 677 */ 678 //if (s->options & SSL_OP_TLSEXT_PADDING) unfortunatly this makes sendmail incompatible with various email servers around the world, including (apparently (ironically (*))) Ironport email gateways. It fails in TLS handshake. These are commonly installed at companies and government departments. consequently if you are mailing an important documant to your bank, or maybe some tax information to your friendly tax department, youe emails sit in your queue for a week until they time out and get dropped. (you may r may not get notified depending on your spam filters) I had to make the following "fix" to libssl to get sendmail to be able to get my tax forms out. Index: crypto/openssl/ssl/t1_lib.c =================================================================== --- crypto/openssl/ssl/t1_lib.c (revision 279747) +++ crypto/openssl/ssl/t1_lib.c (working copy) @@ -675,7 +675,8 @@ * NB: because this code works out the length of all existing * extensions it MUST always appear last. */ - if (s->options & SSL_OP_TLSEXT_PADDING) + //if (s->options & SSL_OP_TLSEXT_PADDING) + if (0) { int hlen = ret - (unsigned char *)s->init_buf->data; /* The code in s23_clnt.c to build ClientHello messages I saw some hints that there is a change in send mail somewhere that gets around this but haven't been able to find the exact configuration change required to make it happen. Julian (*) Ironically because : 1/ Ironport runs on FreeBSD 2/ I used to work there. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 07:14:19 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9FEF833; Wed, 11 Mar 2015 07:14:19 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BBF3FC12; Wed, 11 Mar 2015 07:14:19 +0000 (UTC) Received: from Xins-MBP.home.us.delphij.net (c-71-202-112-39.hsd1.ca.comcast.net [71.202.112.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id EC638FE60; Wed, 11 Mar 2015 00:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1426058059; x=1426072459; bh=WeVUnOHvPgkCklBbTKr4QT+1cswb7UOrBXjPATsOpiI=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=TNvvtx0NcCo9hI7P1pC89pqbP2/1D7w7tV2A5JJd1TmwOXQXgJOonFG5qMdXvLWB7 /QhJ+6sMQEjln/9VSFP+JadZTailxMAKODdQNcWI6rXJufRlNDEXmhy94/rPFkg64o yN4BvMjuG4oLQ/DcKaQRZeUdeaUc6z6yJ+aBKvA0= Message-ID: <54FFEB49.5030706@delphij.net> Date: Wed, 11 Mar 2015 00:14:17 -0700 From: Xin Li User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Julian Elischer , freebsd security , current@freebsd.com Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> In-Reply-To: <54FFE774.50103@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:14:19 -0000 On 3/10/15 23:57, Julian Elischer wrote: > [sorry for reposting but the original copy I got back had been truncated] > > libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 > 674 * > 675 * NB: because this code works out the length of all > existing > 676 * extensions it MUST always appear last. > 677 */ > 678 //if (s->options & SSL_OP_TLSEXT_PADDING) > > unfortunatly this makes sendmail incompatible with various email servers > around the world, > including (apparently (ironically (*))) Ironport email gateways. > It fails in TLS handshake. I hate workarounds of workarounds :( How about this? %%% Index: contrib/sendmail/src/readcf.c =================================================================== --- contrib/sendmail/src/readcf.c (revision 279857) +++ contrib/sendmail/src/readcf.c (working copy) @@ -116,7 +116,7 @@ readcf(cfname, safe, e) #if STARTTLS Srv_SSL_Options = SSL_OP_ALL; - Clt_SSL_Options = SSL_OP_ALL + Clt_SSL_Options = SSL_OP_ALL & ~SSL_OP_TLSEXT_PADDING #ifdef SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 #endif %%% Cheers, From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 07:59:21 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 062DC227 for ; Wed, 11 Mar 2015 07:59:21 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CBF4451 for ; Wed, 11 Mar 2015 07:59:20 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2B7x2p5014296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Mar 2015 00:59:03 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54FFF5C1.10909@freebsd.org> Date: Wed, 11 Mar 2015 00:58:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Xin Li , freebsd security , current@freebsd.com Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <54FFEB49.5030706@delphij.net> In-Reply-To: <54FFEB49.5030706@delphij.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:59:21 -0000 On 3/11/15 12:14 AM, Xin Li wrote: > > On 3/10/15 23:57, Julian Elischer wrote: >> [sorry for reposting but the original copy I got back had been truncated] >> >> libssl has a new "feature" >> implemented by: >> crypto/openssl/ssl/t1_lib.c >> >> 672 /* Add padding to workaround bugs in F5 terminators. >> 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 >> 674 * >> 675 * NB: because this code works out the length of all >> existing >> 676 * extensions it MUST always appear last. >> 677 */ >> 678 //if (s->options & SSL_OP_TLSEXT_PADDING) >> >> unfortunatly this makes sendmail incompatible with various email servers >> around the world, >> including (apparently (ironically (*))) Ironport email gateways. >> It fails in TLS handshake. > I hate workarounds of workarounds :( > > How about this? > > %%% > Index: contrib/sendmail/src/readcf.c > =================================================================== > --- contrib/sendmail/src/readcf.c (revision 279857) > +++ contrib/sendmail/src/readcf.c (working copy) > @@ -116,7 +116,7 @@ readcf(cfname, safe, e) > > #if STARTTLS > Srv_SSL_Options = SSL_OP_ALL; > - Clt_SSL_Options = SSL_OP_ALL > + Clt_SSL_Options = SSL_OP_ALL & ~SSL_OP_TLSEXT_PADDING > #ifdef SSL_OP_NO_SSLv2 > | SSL_OP_NO_SSLv2 > #endif > %%% that's certainly better.. MY change was to just prove where the problem was after reading a bit on the web. The trouble is that that may break mail servers behind F5 appliances. One wonders if one could only turn it off for every second attempt on a retry after a failed attempt. or some other way of not breaking the F5 appliances... I found I could not talk to my child's school (department of education) and my bank, over a period of just a week.. I will look to see if I start picking up new failures now (and see how many F5 appliances there are :-). > Cheers, > From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 08:11:33 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17525640 for ; Wed, 11 Mar 2015 08:11:33 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E56671CD for ; Wed, 11 Mar 2015 08:11:32 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2B8BUfF014357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 11 Mar 2015 01:11:31 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54FFF8AD.90507@freebsd.org> Date: Wed, 11 Mar 2015 01:11:25 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 08:11:33 -0000 On 3/9/15 12:49 PM, Dmitry Morozovsky wrote: > Dear colleagues, > > any thoughts we're vulnerable to this? > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > one important part of this exploit is the following part: ---quote--- How can we pick pairs of addresses that satisfy the “different row, same bank” requirements? One possibility is to use knowledge of how the CPU’s memory controller maps physical addresses to DRAM’s row, column and bank numbers, along with knowledge of either: * The absolute physical addresses of memory we have access to. Linux allows this via /proc//PID//pagemap. * The relative physical addresses of memory we have access to. Linux can allow this via its support for “huge pages”, which cover 2MB of contiguous physical address space per page. Whereas a normal 4k page is smaller than a typical DRAM row, a 2MB page will typically cover multiple rows, some of which will be in the same bank. ---end quote--- I don't know of a similar source of that information in FreeBSD, though near the start of operation one might be able to make a good guess about memory allocation, until ram got too scrambled.. the "superpages" point would be true in freeBSD as well, tough I 'm not sure how you;d know you had a superpage, but you might be able to do something (file size?) that might make it likely. Of course in their first attack it's the location of the data but the location of the page table entry that's important. that might be more easily worked out if you allocated a large enough chunk of memory while memory is still predictable. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 09:25:02 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F924619; Wed, 11 Mar 2015 09:25:02 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 BCF38C1D; Wed, 11 Mar 2015 09:25:01 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 34C4216A402; Wed, 11 Mar 2015 10:24:53 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7jiHZei_MyN; Wed, 11 Mar 2015 10:24:33 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:601a:ec08:aa7a:a691] (unknown [IPv6:2001:4cb8:3:1:601a:ec08:aa7a:a691]) by smtp.digiware.nl (Postfix) with ESMTP id 22B8816A401; Wed, 11 Mar 2015 10:24:33 +0100 (CET) Message-ID: <550009CF.2070403@digiware.nl> Date: Wed, 11 Mar 2015 10:24:31 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Julian Elischer , Xin Li , freebsd security , current@freebsd.com Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <54FFEB49.5030706@delphij.net> <54FFF5C1.10909@freebsd.org> In-Reply-To: <54FFF5C1.10909@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 09:25:02 -0000 On 11-3-2015 08:58, Julian Elischer wrote: > I found I could not talk to my child's school (department of education) > and my bank, over a period of just a week.. > I will look to see if I start picking up new failures now (and see how > many F5 appliances there are :-). If you'd like to have a bit of incite on that, you could use Shodan: https://www.shodan.io/search?query=F5 And just add futher descriptions to single out what defines a F5 appliance Warning: it is a dangerously fascinating search-engine. --WjW From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 06:44:11 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC84AF53 for ; Wed, 11 Mar 2015 06:44:11 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FEE48C0 for ; Wed, 11 Mar 2015 06:44:11 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2B6hwtm013998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 10 Mar 2015 23:43:59 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <54FFE429.8050509@elischer.org> Date: Tue, 10 Mar 2015 23:43:53 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd security , current@freebsd.com Subject: sendmail broken by libssl in current Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Mar 2015 11:28:12 +0000 Cc: Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 06:44:11 -0000 libssl has a new "feature" implemented by: crypto/openssl/ssl/t1_lib.c 672 /* Add padding to workaround bugs in F5 terminators. 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 674 * 675 * NB: because this code works out the length of all existing 676 * extensions it MUST always appear last. 677 */ 678 //if (s->options & SSL_OP_TLSEXT_PADDING) unfortunatly this makes sendmail incompatible with various email servers around the world, including (apparently (ironically (*))) Ironport email gateways. It fails in TLS handshake. These are commonly installed at companies and government departments. consequently if you are mailing an important documant to your bank, or maybe some tax information to your friendly tax department, youe emails sit in your queue for a week until they time out and get dropped. (you may r may not get notified depending on your spam filters) I had to make the following "fix" to libssl to get sendmail to be able to get my tax forms out. Index: crypto/openssl/ssl/t1_lib.c =================================================================== --- crypto/openssl/ssl/t1_lib.c (revision 279747) +++ crypto/openssl/ssl/t1_lib.c (working copy) @@ -675,7 +675,8 @@ * NB: because this code works out the length of all existing * extensions it MUST always appear last. */ - if (s->options & SSL_OP_TLSEXT_PADDING) + //if (s->options & SSL_OP_TLSEXT_PADDING) + if (0) { int hlen = ret - (unsigned char *)s->init_buf->data; /* The code in s23_clnt.c to build ClientHello messages I saw some hints that there is a change in send mail somewhere that gets around this but haven't been able to find the exact configuration change required to make it happen. Julian (*) Ironically because : 1/ Ironport runs on FreeBSD 2/ I used to work there. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 08:06:19 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7D2B4B5; Wed, 11 Mar 2015 08:06:19 +0000 (UTC) Received: from mx2.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) (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 87BA71A1; Wed, 11 Mar 2015 08:06:18 +0000 (UTC) Received: from hq-cas01.corp.proofpoint.com (hq-cas01.corp.proofpoint.com [10.20.7.201]) by admin1009.us.proofpoint.com (8.15.0.59/8.15.0.59) with ESMTPS id t2B83H9r000486 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Mar 2015 01:03:17 -0700 Received: from the-guenther.attlocal.net (76.253.1.113) by hq-cas01.corp.proofpoint.com (10.20.7.200) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Mar 2015 01:03:17 -0700 Date: Wed, 11 Mar 2015 01:03:18 -0700 From: Philip Guenther X-X-Sender: guenther@morgaine.local To: Julian Elischer Subject: Re: sendmail broken by libssl in current In-Reply-To: <54FFE774.50103@freebsd.org> Message-ID: References: <54FFE774.50103@freebsd.org> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [76.253.1.113] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-03-11_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=-1 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1502090000 definitions=main-1503110085 X-Proofpoint-CLX-Result: SUCCESS: status="OK", duration=0.0077, score=-1 X-Mailman-Approved-At: Wed, 11 Mar 2015 11:28:26 +0000 Cc: current@freebsd.com, freebsd security , Claus Assmann , Gregory Shapiro X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 08:06:19 -0000 [Forwarded from Greg, before he had to go offline] On Tue, 10 Mar 2015, Julian Elischer wrote: > libssl has a new "feature" > implemented by: > crypto/openssl/ssl/t1_lib.c > > 672 /* Add padding to workaround bugs in F5 terminators. > 673 * See https://tools.ietf.org/html/draft-agl-tls-padding-03 > 674 * > 675 * NB: because this code works out the length of all existing > 676 * extensions it MUST always appear last. > 677 */ > 678 //if (s->options & SSL_OP_TLSEXT_PADDING) > > unfortunatly this makes sendmail incompatible with various email servers > around the world, including (apparently (ironically (*))) Ironport email > gateways. It fails in TLS handshake. ... > I had to make the following "fix" to libssl to get sendmail to be able > to get my tax forms out. This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that #define exists. I believe Greg is working on importing that to FreeBSD. Pending that, simply copy the relevant code from the 8.15.1's readcf.c:readcf(), which has this: #if STARTTLS Srv_SSL_Options = SSL_OP_ALL; Clt_SSL_Options = SSL_OP_ALL # ifdef SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv2 # endif # ifdef SSL_OP_NO_TICKET | SSL_OP_NO_TICKET # endif ; # ifdef SSL_OP_TLSEXT_PADDING /* SSL_OP_TLSEXT_PADDING breaks compatibility with some sites */ Srv_SSL_Options &= ~SSL_OP_TLSEXT_PADDING; Clt_SSL_Options &= ~SSL_OP_TLSEXT_PADDING; # endif /* SSL_OP_TLSEXT_PADDING */ #endif /* STARTTLS */ You'll just need to add the #ifdef SSL_OP_TLSEXT_PADDING block. If the default is overriden by explicitly setting the ClientSSLOptions option in then config, then you may need to explicitly remove it there as well, such as seen in the implicit default: O ClientSSLOptions=SSL_OP_ALL SSL_OP_NO_SSLv2 SSL_OP_NO_TICKET -SSL_OP_TLSEXT_PADDING This option and default is documented in op.me in the source distribution. Philip Guenther Proofpoint Engineering From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 14:28:04 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DDD4D23 for ; Wed, 11 Mar 2015 14:28:04 +0000 (UTC) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 697A0372 for ; Wed, 11 Mar 2015 14:28:04 +0000 (UTC) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2BERw5S011505 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 07:27:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sendmail broken by libssl in current From: Paul Hoffman In-Reply-To: <54FFE774.50103@freebsd.org> Date: Wed, 11 Mar 2015 07:27:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> References: <54FFE774.50103@freebsd.org> To: freebsd security X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 11 Mar 2015 14:34:54 +0000 Cc: current@freebsd.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:28:04 -0000 On Mar 10, 2015, at 11:57 PM, Julian Elischer = wrote: > unfortunatly this makes sendmail incompatible with various email = servers around the world, > including (apparently (ironically (*))) Ironport email gateways. > It fails in TLS handshake. Can you say which email servers *other* than unpatched Ironport fail? = I've only seen it with unpatched Ironport on my (somewhat active) = FreeBSD-based mail server. FWIW, I only see these bounces in my mail = queue for exactly two sites. Cisco has known about this for many months; see = . I have been told by = an Ironport user that there is already a patch that is available from = Cisco. If that's true (I can't confirm), why would we want to do a patch = to our core crypto? --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 14:55:33 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 176F8B89 for ; Wed, 11 Mar 2015 14:55:33 +0000 (UTC) Received: from fw.ax.cz (fw.ax.cz [IPv6:2a00:1aa8:1:1000::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B6A4986 for ; Wed, 11 Mar 2015 14:55:32 +0000 (UTC) Received: from [172.20.1.29] (host10.hide.ax.cz [172.20.1.29]) by fw.ax.cz (8.14.5/8.14.5) with ESMTP id t2BEtOBv099620; Wed, 11 Mar 2015 15:55:26 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <55005753.3070306@obluda.cz> Date: Wed, 11 Mar 2015 15:55:15 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Paul Hoffman , freebsd security Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> In-Reply-To: <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:55:33 -0000 Paul Hoffman wrote: > Can you say which email servers *other* than unpatched Ironport fail? > Cisco has known about this for many months; see Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo25329. > If that's true (I can't confirm), why would we want to do a patch to our core crypto? Good question. The following should be taken into consideration. According CSCuo25329, the issue has been fixed on Mar 2,2015 in 8.0.2-055 and 8.5.6-063 release of Cisco Email Security Appliance. There are three known affected releases only - 8.0.1-023, 8.5.0-473, 8.5.5-280 Dan From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 16:15:54 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A71B528; Wed, 11 Mar 2015 16:15:54 +0000 (UTC) Received: from zim.gshapiro.net (zim.gshapiro.net [IPv6:2001:4f8:3:36::224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.gshapiro.net", Issuer "Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 121E2606; Wed, 11 Mar 2015 16:15:54 +0000 (UTC) Received: from C02KM089FFRR.corp.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) (authenticated bits=0) by zim.gshapiro.net (8.14.9/8.14.9) with ESMTP id t2BGFlCf001642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Mar 2015 09:15:52 -0700 (PDT) (envelope-from gshapiro@freebsd.org) Date: Wed, 11 Mar 2015 09:15:49 -0700 From: Gregory Shapiro To: Philip Guenther Subject: Re: sendmail broken by libssl in current Message-ID: <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> References: <54FFE774.50103@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Wed, 11 Mar 2015 17:14:33 +0000 Cc: freebsd security , Julian Elischer X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:15:54 -0000 First, thank you Philip for jumping on this. Much appreciated. > This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in > SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes > SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that > #define exists. I believe Greg is working on importing that to FreeBSD. sendmail 8.15.1 is imported into the vendor area but not merged due to an incompatible change that is being moved into a run-time configuration variable in 8.15.2. Rather than expose the FreeBSD populate to the churn from that change, I am skipping 8.15.1 and will import 8.15.2. That being said, I can certainly make the local fix that Philip mention to take care of the padding issue. Is the new libssl in 11-CURRENT going to be/already been MFC'ed to other branches? From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 18:13:58 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0282C18E for ; Wed, 11 Mar 2015 18:13:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E37F6E2 for ; Wed, 11 Mar 2015 18:13:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2BIDk4R082326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Mar 2015 20:13:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2BIDk4R082326 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2BIDkr1082325 for freebsd-security@freebsd.org; Wed, 11 Mar 2015 20:13:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Mar 2015 20:13:46 +0200 From: Konstantin Belousov To: freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits Message-ID: <20150311181346.GH2379@kib.kiev.ua> References: <54FFF8AD.90507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FFF8AD.90507@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:13:58 -0000 On Wed, Mar 11, 2015 at 01:11:25AM -0700, Julian Elischer wrote: > On 3/9/15 12:49 PM, Dmitry Morozovsky wrote: > > Dear colleagues, > > > > any thoughts we're vulnerable to this? > > > > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > > > one important part of this exploit is the following part: > ---quote--- > How can we pick pairs of addresses that satisfy the ?different row, > same bank? requirements? > > One possibility is to use knowledge of how the CPU?s memory controller > maps physical addresses to DRAM?s row, column and bank numbers, along > with knowledge of either: > > * The absolute physical addresses of memory we have access to. Linux > allows this via /proc//PID//pagemap. > * The relative physical addresses of memory we have access to. Linux > can allow this via its support for ?huge pages?, which cover 2MB > of contiguous physical address space per page. Whereas a normal 4k > page is smaller than a typical DRAM row, a 2MB page will typically > cover multiple rows, some of which will be in the same bank. > > ---end quote--- > I don't know of a similar source of that information in FreeBSD, > though near the start of operation one might be able to make a good > guess about memory allocation, until ram got too scrambled.. > > > the "superpages" point would be true in freeBSD as well, tough I 'm > not sure how you;d know you had a superpage, but you might be able to > do something (file size?) that might make it likely. > Of course in their first attack it's the location of the data but the > location of the page table entry that's important. > that might be more easily worked out if you allocated a large enough > chunk of memory while memory is still predictable. I just made somewhat dirty port of the double_sided program, available at https://github.com/kostikbel/rowhammer-test/tree/freebsd >From what I see, the fetched physical addresses of the mappings look reasonable, e.g. they are continous for the promoted pages. Curiously, my test haswell box does not trip the failure. There is some weirdness either in the c++ code, or bug in the port, you might need to use MALLOC_CONF=junk:false setting on head. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 18:30:40 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D1595B4 for ; Wed, 11 Mar 2015 18:30:40 +0000 (UTC) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D9F28924 for ; Wed, 11 Mar 2015 18:30:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.9/8.14.9) with ESMTP id t2BIUcBW041059; Wed, 11 Mar 2015 14:30:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <550089CD.8040903@sentex.net> Date: Wed, 11 Mar 2015 14:30:37 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov , freebsd-security@freebsd.org Subject: Re: DRAM Rowhammer exploits References: <54FFF8AD.90507@freebsd.org> <20150311181346.GH2379@kib.kiev.ua> In-Reply-To: <20150311181346.GH2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.75 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:30:40 -0000 On 3/11/2015 2:13 PM, Konstantin Belousov wrote: > I just made somewhat dirty port of the double_sided program, available at > https://github.com/kostikbel/rowhammer-test/tree/freebsd How many iterations does it usually take to trip up the bug if its there ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 18:38:04 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F617925 for ; Wed, 11 Mar 2015 18:38:04 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 726FA98A for ; Wed, 11 Mar 2015 18:38:03 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2BIbv6d096432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 20:37:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2BIbv6d096432 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2BIbvCx096431; Wed, 11 Mar 2015 20:37:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Mar 2015 20:37:57 +0200 From: Konstantin Belousov To: Mike Tancsa Subject: Re: DRAM Rowhammer exploits Message-ID: <20150311183757.GI2379@kib.kiev.ua> References: <54FFF8AD.90507@freebsd.org> <20150311181346.GH2379@kib.kiev.ua> <550089CD.8040903@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550089CD.8040903@sentex.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:38:04 -0000 On Wed, Mar 11, 2015 at 02:30:37PM -0400, Mike Tancsa wrote: > On 3/11/2015 2:13 PM, Konstantin Belousov wrote: > > > I just made somewhat dirty port of the double_sided program, available at > > https://github.com/kostikbel/rowhammer-test/tree/freebsd > > How many iterations does it usually take to trip up the bug if its there ? Look at the original report, AFAIR it has the numbers. My machine does not exhibit the issue, at least not with the tests I tried. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 19:09:37 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41B97250 for ; Wed, 11 Mar 2015 19:09:37 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12B7FCF1 for ; Wed, 11 Mar 2015 19:09:36 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2BJ9NhE016841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Mar 2015 12:09:29 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <550092DD.9030808@freebsd.org> Date: Wed, 11 Mar 2015 12:09:17 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dan Lukes , Paul Hoffman , freebsd security Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> <55005753.3070306@obluda.cz> In-Reply-To: <55005753.3070306@obluda.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:09:37 -0000 On 3/11/15 7:55 AM, Dan Lukes wrote: > Paul Hoffman wrote: >> Can you say which email servers *other* than unpatched Ironport fail? >> Cisco has known about this for many months; see > Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo25329. > >> If that's true (I can't confirm), why would we want to do a patch to our core crypto? > Good question. The following should be taken into consideration. > > According CSCuo25329, the issue has been fixed on Mar 2,2015 in > 8.0.2-055 and 8.5.6-063 release of Cisco Email Security Appliance. > > There are three known affected releases only - 8.0.1-023, 8.5.0-473, > 8.5.5-280 well my problem is that I don't know what the other ends are running exactly, but they are pretty big institution. Comonwealth Bank of Australia, and Western Australian department of Education (which shares infrastructure with the rest of the government, so, I might as well just say "state of Western Australia". I don't contact a LOT of large institutions, so given that I had two failures over a small sample, and that the documents in each case were very important, I think it's worth some sort of action. Big institutions don't take updates that often, so its hard to know when they will update their mail appliances. (they may also not be ironport appliances, I just know those are susceptible). since hte change is coming in on the next sendmail anyhow I see no reason to not take it.. Julian > > Dan > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 19:18:45 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9564802 for ; Wed, 11 Mar 2015 19:18:45 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA576E07 for ; Wed, 11 Mar 2015 19:18:45 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t2BJIhBw016882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 11 Mar 2015 12:18:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5500950E.9070905@freebsd.org> Date: Wed, 11 Mar 2015 12:18:38 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> In-Reply-To: <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:18:45 -0000 On 3/11/15 9:15 AM, Gregory Shapiro wrote: > First, thank you Philip for jumping on this. Much appreciated. > >> This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in >> SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes >> SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that >> #define exists. I believe Greg is working on importing that to FreeBSD. > sendmail 8.15.1 is imported into the vendor area but not merged due to an incompatible change that is being moved into a run-time configuration variable in 8.15.2. Rather than expose the FreeBSD populate to the churn from that change, I am skipping 8.15.1 and will import 8.15.2. > > That being said, I can certainly make the local fix that Philip mention to take care of the padding issue. Is the new libssl in 11-CURRENT going to be/already been MFC'ed to other branches? > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > the change is in libssl1.0.1g and later so, yes it's already in 10 From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 19:01:30 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF186EC7; Wed, 11 Mar 2015 19:01:30 +0000 (UTC) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 887F4C89; Wed, 11 Mar 2015 19:01:30 +0000 (UTC) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2BJ1RiJ026383 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 12:01:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sendmail broken by libssl in current From: Paul Hoffman In-Reply-To: <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> Date: Wed, 11 Mar 2015 12:01:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FFE774.50103@freebsd.org> <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> To: Gregory Shapiro X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 11 Mar 2015 20:11:56 +0000 Cc: freebsd security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:01:30 -0000 On Mar 11, 2015, at 9:15 AM, Gregory Shapiro = wrote: > First, thank you Philip for jumping on this. Much appreciated. >=20 >> This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in=20 >> SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes=20= >> SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that=20= >> #define exists. I believe Greg is working on importing that to = FreeBSD. >=20 > sendmail 8.15.1 is imported into the vendor area but not merged due to = an incompatible change that is being moved into a run-time configuration = variable in 8.15.2. Rather than expose the FreeBSD populate to the = churn from that change, I am skipping 8.15.1 and will import 8.15.2. >=20 > That being said, I can certainly make the local fix that Philip = mention to take care of the padding issue. Is the new libssl in = 11-CURRENT going to be/already been MFC'ed to other branches? I'm still *really* hesitant for us to be patching OpenSSL for a bug on a = middlebox vendor's system that already has a fix. --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 19:25:17 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC21E9F2 for ; Wed, 11 Mar 2015 19:25:17 +0000 (UTC) Received: from zim.gshapiro.net (zim.gshapiro.net [IPv6:2001:4f8:3:36::224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.gshapiro.net", Issuer "Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2E8BEEA for ; Wed, 11 Mar 2015 19:25:17 +0000 (UTC) Received: from C02KM089FFRR.corp.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) (authenticated bits=0) by zim.gshapiro.net (8.14.9/8.14.9) with ESMTP id t2BJPEPW019255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Mar 2015 12:25:17 -0700 (PDT) (envelope-from gshapiro@freebsd.org) Date: Wed, 11 Mar 2015 12:25:14 -0700 From: Gregory Shapiro To: Paul Hoffman Subject: Re: sendmail broken by libssl in current Message-ID: <20150311192514.GS16749@C02KM089FFRR.corp.proofpoint.com> References: <54FFE774.50103@freebsd.org> <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Wed, 11 Mar 2015 20:12:05 +0000 Cc: freebsd security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:25:18 -0000 > > sendmail 8.15.1 is imported into the vendor area but not merged due to an incompatible change that is being moved into a run-time configuration variable in 8.15.2. Rather than expose the FreeBSD populate to the churn from that change, I am skipping 8.15.1 and will import 8.15.2. > > > > That being said, I can certainly make the local fix that Philip mention to take care of the padding issue. Is the new libssl in 11-CURRENT going to be/already been MFC'ed to other branches? > > I'm still *really* hesitant for us to be patching OpenSSL for a bug on a middlebox vendor's system that already has a fix. My intent is to patch sendmail, not OpenSSL, with a change that is already part of a newer sendmail release. From owner-freebsd-security@FreeBSD.ORG Wed Mar 11 19:49:07 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47AC831F; Wed, 11 Mar 2015 19:49:07 +0000 (UTC) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1FA1E1A9; Wed, 11 Mar 2015 19:49:06 +0000 (UTC) Received: from [10.20.30.101] (50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2BJmK01029216 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2015 12:49:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-2.dsl.dynamic.fusionbroadband.com [50.1.99.2] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sendmail broken by libssl in current From: Paul Hoffman In-Reply-To: <20150311192514.GS16749@C02KM089FFRR.corp.proofpoint.com> Date: Wed, 11 Mar 2015 12:49:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3FEBF8E9-BB5B-403F-9648-A5F7CB60F9AB@vpnc.org> References: <54FFE774.50103@freebsd.org> <20150311161549.GB16749@C02KM089FFRR.corp.proofpoint.com> <20150311192514.GS16749@C02KM089FFRR.corp.proofpoint.com> To: Gregory Shapiro X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Wed, 11 Mar 2015 20:12:16 +0000 Cc: freebsd security X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:49:07 -0000 On Mar 11, 2015, at 12:25 PM, Gregory Shapiro = wrote: >=20 >>> sendmail 8.15.1 is imported into the vendor area but not merged due = to an incompatible change that is being moved into a run-time = configuration variable in 8.15.2. Rather than expose the FreeBSD = populate to the churn from that change, I am skipping 8.15.1 and will = import 8.15.2. >>>=20 >>> That being said, I can certainly make the local fix that Philip = mention to take care of the padding issue. Is the new libssl in = 11-CURRENT going to be/already been MFC'ed to other branches? >>=20 >> I'm still *really* hesitant for us to be patching OpenSSL for a bug = on a middlebox vendor's system that already has a fix. >=20 > My intent is to patch sendmail, not OpenSSL, with a change that is = already part of a newer sendmail release. Ah, that wasn't clear from the thread, sorry. Sure, patching Sendmail = for this seems fine. Thanks! --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Thu Mar 12 00:35:15 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7653E24; Thu, 12 Mar 2015 00:35:15 +0000 (UTC) Received: from fw.ax.cz (fw.ax.cz [IPv6:2a00:1aa8:1:1000::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47FF37B9; Thu, 12 Mar 2015 00:35:14 +0000 (UTC) Received: from [172.20.1.29] (host10.hide.ax.cz [172.20.1.29]) by fw.ax.cz (8.14.5/8.14.5) with ESMTP id t2C0Z7kV038195; Thu, 12 Mar 2015 01:35:09 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <5500DF36.9070904@obluda.cz> Date: Thu, 12 Mar 2015 01:35:02 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Julian Elischer Subject: Re: sendmail broken by libssl in current References: <54FFE774.50103@freebsd.org> <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> <55005753.3070306@obluda.cz> <550092DD.9030808@freebsd.org> In-Reply-To: <550092DD.9030808@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd security , Paul Hoffman X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:35:15 -0000 Julian Elischer wrote: >>> Can you say which email servers *other* than unpatched Ironport fail? > well my problem is that I don't know what the other ends are running > exactly, but they are pretty big institution. Just side note - you need not to wait for a source patch. Just disable TLS for those destinations as a instant workaround. Users of 8.4/9.3 need to disable TLS to those destinations supporting TLSv1.2 only (as TLSv1.2 is not supported by sendmail on 8.4/9.3-R), so you will not be alone with such kind of workaround ;-) Dan From owner-freebsd-security@FreeBSD.ORG Thu Mar 12 07:04:49 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5350DE4; Thu, 12 Mar 2015 07:04:49 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 72C74829; Thu, 12 Mar 2015 07:04:49 +0000 (UTC) Received: by iecsl2 with SMTP id sl2so22270522iec.1; Thu, 12 Mar 2015 00:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=msvomxlhH3RLBUa5xwNCusngPnYXyrlYooSn5Ee3zkc=; b=tdTtNnpI08c2N/IGKsUY80SDn6yu29K+JOVoKA1bfJ9Ysw2XZsqlD2Q1ySBsaed3uj 9Y3x3XdoS6/jhrJOxyMnTA81vkuptb2w3G+3XYK6qUIYTukVdz2V0AExYPkJxIn8r8qN wd24wJn0kx7iiOwqd0HdJVKFvxZI6Vtprd0plLeMRVwtdYgJ8ZUYFTvxEYhrNsCdWfp9 M+STiLp8xSr5DGnksQH5Xtphra5SbXcXBhWESTjFPThA2o5RwTPO0RCX37NKrg34wq1v 8U5ckA+DGvVbstOMikArKe07nz2PLJvG50xe4uL3TtOWrelt1Qt9GODtSVByoMfxHVIG HfUw== MIME-Version: 1.0 X-Received: by 10.42.93.83 with SMTP id w19mr46367855icm.37.1426143888718; Thu, 12 Mar 2015 00:04:48 -0700 (PDT) Received: by 10.36.104.78 with HTTP; Thu, 12 Mar 2015 00:04:48 -0700 (PDT) Date: Thu, 12 Mar 2015 03:04:48 -0400 Message-ID: Subject: FreeBSD forums, etc [was: Protest Blocking Tor via CloudFlare] From: grarpamp To: tor-talk@lists.torproject.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 12 Mar 2015 11:05:10 +0000 Cc: freebsd-git@freebsd.org, freebsd-security@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-core@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:04:49 -0000 Various wrote: > > Which site blocks tor exit entirely? On Wed, Mar 11, 2015 at 11:58 PM, Libertas wrote: > The FreeBSD forums and (IIRC) download servers do the same thing, just > dropping packets from Tor exits. Very annoying. I haven't got around to > emailing them about it yet. Found an exit that works forums and mapped it for weeks now, but that's a real pain for normal Tor users to contemplate doing. Yes, it's quite annoying and one would hope mailing them to achieve at least readonly access would be opened up. Why block disemmination and viewing of simple free knowledge? This may be inadvertant lack of in depth and open thought on things. This should hopefully get further thought going. They also need to make their builds deterministic and crypto traceable back to a crypto secure source repo which SVN is not afaict. But that's a whole other topic, and these days an important one to raise and ensure is addressed. After all, spies, moles, exploit[er]s, and bitrot are everywhere. Relavent link hierarchies... https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details http://en.wikipedia.org/wiki/Comparison_of_revision_control_software http://git-scm.com/about/distributed http://git-scm.com/about/info-assurance http://www.monotone.ca/ From owner-freebsd-security@FreeBSD.ORG Thu Mar 12 14:38:11 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB001524 for ; Thu, 12 Mar 2015 14:38:11 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 7947318D for ; Thu, 12 Mar 2015 14:38:11 +0000 (UTC) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2DC8620672 for ; Thu, 12 Mar 2015 10:38:08 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Thu, 12 Mar 2015 10:38:09 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:subject :date:in-reply-to:references; s=smtpout; bh=cLCG0UJzBA9qtimbHUsA QsLHcws=; b=rLLirCX7Pq/9FKfpWbk8nN9RBGt/kIM4lgLzY8XtYZ/9bi5sdbxs 3fbRBTeUaQP8o7Lj2nXzmKBbpKfyyJ7IaOh6rt6+dXZXYT1vlgpfeOeiGJkhB0vi wjwJz8nUcjX2s+1Ujm4ytdtNZVF+ZKxLYszXZJ3HK6kjM3CvVKbiLPw= Received: by web3.nyi.internal (Postfix, from userid 99) id BA8DE112DA2; Thu, 12 Mar 2015 10:38:09 -0400 (EDT) Message-Id: <1426171089.1809256.239414225.2EB26D2D@webmail.messagingengine.com> X-Sasl-Enc: f8FJU6VzoFHAIgNSKfTXomsP3jKbYOPMhf1uCblOl3km 1426171089 From: Mark Felder To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-15db86eb Subject: Re: sendmail broken by libssl in current Date: Thu, 12 Mar 2015 09:38:09 -0500 In-Reply-To: <5500DF36.9070904@obluda.cz> References: <54FFE774.50103@freebsd.org> <6BD2AE7F-8EC5-4EBC-A183-E03EC54456BC@vpnc.org> <55005753.3070306@obluda.cz> <550092DD.9030808@freebsd.org> <5500DF36.9070904@obluda.cz> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:38:11 -0000 On Wed, Mar 11, 2015, at 19:35, Dan Lukes wrote: > Julian Elischer wrote: > >>> Can you say which email servers *other* than unpatched Ironport fail? > > > well my problem is that I don't know what the other ends are running > > exactly, but they are pretty big institution. > > Just side note - you need not to wait for a source patch. Just disable > TLS for those destinations as a instant workaround. > > Users of 8.4/9.3 need to disable TLS to those destinations supporting > TLSv1.2 only (as TLSv1.2 is not supported by sendmail on 8.4/9.3-R), so > you will not be alone with such kind of workaround ;-) > It seems like this is the sort of thing where we shouldn't just give up and accept as the norm. *sigh* From owner-freebsd-security@FreeBSD.ORG Fri Mar 13 11:03:14 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 103C366E; Fri, 13 Mar 2015 11:03:14 +0000 (UTC) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.181]) by mx1.freebsd.org (Postfix) with ESMTP id ACDB4797; Fri, 13 Mar 2015 11:03:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIHAPOG1lRFpa1E/2dsb2JhbABbghVxsVQBAQEBAQEGg2mUSgoCgQ1EAQEBAQEBfIQNAQU4HiIBEAshDQEIDwkDAgECASceBgEMAQcBAYgpziMBAQEBAQUBAQEBAQEBARqGBIl0BxIBhBcBBI8bhyeIRYprgUUigjKBWCKBNQcXgSABAQE X-IPAS-Result: AoIHAPOG1lRFpa1E/2dsb2JhbABbghVxsVQBAQEBAQEGg2mUSgoCgQ1EAQEBAQEBfIQNAQU4HiIBEAshDQEIDwkDAgECASceBgEMAQcBAYgpziMBAQEBAQUBAQEBAQEBARqGBIl0BxIBhBcBBI8bhyeIRYprgUUigjKBWCKBNQcXgSABAQE X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="113453150" Received: from 69-165-173-68.dsl.teksavvy.com (HELO porter.razorfever.net) ([69.165.173.68]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2015 07:02:03 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by porter.razorfever.net (8.14.4/8.14.4) with ESMTP id t2DB20Kf095644; Fri, 13 Mar 2015 07:02:01 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <5502C3A7.9090505@razorfever.net> Date: Fri, 13 Mar 2015 07:01:59 -0400 From: "Derek (freebsd lists)" <482254ac@razorfever.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John-Mark Gurney , Jilles Tjoelker Subject: Re: [patch] libcrypt & friends - modular crypt format support in /etc/login.conf References: <54D9F8DF.7070904@razorfever.net> <20150214231712.GA1360@stack.nl> <20150214234243.GX1953@funkthat.com> In-Reply-To: <20150214234243.GX1953@funkthat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org, "A.J. Kehoe IV \(Nanoman\)" , delphij@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 11:03:14 -0000 FYI - I've posted a new patch to the bug that covers all of the mentioned concerns. Looking forward to feedback! Derek