From owner-freebsd-security@freebsd.org Fri Jan 5 10:08:19 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E20FEEC1C0C for ; Fri, 5 Jan 2018 10:08:19 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACB311745 for ; Fri, 5 Jan 2018 10:08:19 +0000 (UTC) (envelope-from repeatable_compression@yahoo.com) X-YMail-OSG: tPYEH6cVM1l5zIptmFMmFqUhIFFALqD8GkaWzpDhwxio1eTwycVVAuvDaQws9vP T4FAG3Z72GpY5tsIACENF9XWn7CyNMsO5o7oCssBN2b1VQddpq5B5wNuc9czB_5uiCBXCXnwJFcB z0o39Y2Y7zeyqB4Zy_Bx7DlA8.Mi2C2ZX5hVux87tRiKciJ.7GMC97yb.U4rr40EcZSEe2bUNmxu cyS4aFQFI_U0TntrAKi5tpmQE6FL5xv71QULySgUkX1A_WqZk4jOSQsDV71pLw_nV.LjNol9Ty7C MR6I5ZFNwCX4utWVPsLme3moztVNWxzPq1jTOTPG.bpLahDnonhYqwzTSyCrx0MhXGwZSVoXDBgJ 6bX8gEn7FjeJvGqrxo5V9yuJ72hU.90AS6kD4sJ0zyy5ZiNdEPair8fqLBRs2iHVb4er3FMzQa.E Mw4tQgasMi.tB3lHeSZRrq8PD44MUp0jsgvOvaw5KBzpb2escrDY56ScyLmwEi_mNPLzJnpEPfPe UqvsqDklmsz1Irp9ICob3dA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Fri, 5 Jan 2018 10:08:18 +0000 Date: Fri, 5 Jan 2018 10:07:01 +0000 (UTC) From: Jules Gilbert To: "Ronald F. Guilmette" , Eric McCorkle , Freebsd Security , Brett Glass , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= , Poul-Henning Kamp , "freebsd-arch@freebsd.org" , FreeBSD Hackers , Shawn Webb , Nathan Whitehorn Message-ID: <809675000.867372.1515146821354@mail.yahoo.com> In-Reply-To: <2594.1515141192@segfault.tristatelogic.com> References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> Subject: Re: Intel hardware bug MIME-Version: 1.0 X-Mailer: WebService/1.1.11150 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:57.0) Gecko/20100101 Firefox/57.0 X-Mailman-Approved-At: Fri, 05 Jan 2018 11:51:40 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 10:08:20 -0000 Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no= one!, has in the past, or will in the future be able to exploit this to ac= tually do something not nice. I'm not saying that the hardware shouldn't be fixed, I am saying that we do= n't need to worry about this. In the early days of DOS their was a hardware bug in nearly all floppy cont= rollers, it wasn't even discovered until (I think,) 1985 or so.=C2=A0 The t= hing is..., no one reported unusual problems. So what is this, really?, it's a market exploit opportunity for AMD. =20 On Friday, January 5, 2018, 3:33:31 AM EST, Ronald F. Guilmette wrote: =20 =20 =20 In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>,=20 Eric McCorkle wrote: >The attack looks like this: > >1) Fetch kernel/other process memory, which eventually faults >2) Do a bit-shift/mask operation to pluck out one bit of the fetched >value.=C2=A0 This gets executed speculatively on the fetched value in (1). >3) Execute fetches of two different addresses depending on some bit in >the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).=C2=A0 Th= is >also gets executed speculatively despite the fact that (1) ends up faultin= g. >4) Recover from fault in (1) >5) Measure performance of accesses to the two addresses to determine >which one is cached. I must say, that's one hell of a round-about way to read just one bit that you wern't supposed to have access to.=C2=A0 But of course, that doesn't re= ally matter if you are an attacker. If the above steps can be repeated, programatically, ad infinitum, to read bits from "protected" memory... and I see no reason why they can't be... then yea, this bug is every bit as bad as the media is making it out to be, and maybe even worse. All your secrets are belong to us! Time to invest in abacuses... or is that abacai? Regards, rfg _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" =20 From owner-freebsd-security@freebsd.org Fri Jan 5 12:01:06 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43A0CEA42EB for ; Fri, 5 Jan 2018 12:01:06 +0000 (UTC) (envelope-from mail@kkoenig.net) Received: from mx1.outerhaven.de (mx1.outerhaven.de [81.14.236.89]) (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 B31226544E for ; Fri, 5 Jan 2018 12:01:05 +0000 (UTC) (envelope-from mail@kkoenig.net) Received: from [10.0.1.35] (port-87-193-161-154.static.qsc.de [87.193.161.154]) by mx1.outerhaven.de (OpenSMTPD) with ESMTPSA id 647e6b59 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 5 Jan 2018 13:01:01 +0100 (CET) Subject: Re: Intel hardware bug To: freebsd-security@freebsd.org References: <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net> <2594.1515141192@segfault.tristatelogic.com> <809675000.867372.1515146821354@mail.yahoo.com> From: =?UTF-8?Q?Karsten_K=c3=b6nig?= Message-ID: <803c9f0c-baa3-f65c-70f8-a27e4ee8a7cf@kkoenig.net> Date: Fri, 5 Jan 2018 13:01:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <809675000.867372.1515146821354@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 12:01:06 -0000 Hello, On 05.01.2018 11:07, Jules Gilbert via freebsd-security wrote: > Sorry guys, you just convinced me that no one, not the NSA, not the FSB, no one!, has in the past, or will in the future be able to exploit this to actually do something not nice. > I'm not saying that the hardware shouldn't be fixed, I am saying that we don't need to worry about this. we should indeed worry about this. This could be just the tip of the iceberg. Think about Rowhammer. This was a bug which affected RAM. In the beginning it was just some basic computer science research which was hard to trigger. After some month people found ways to exploit Rowhammer via JavaScript so that every person using a browser was a possible target. The same could happen with this stuff, people are already working on this. Best, Karsten > In the early days of DOS their was a hardware bug in nearly all floppy controllers, it wasn't even discovered until (I think,) 1985 or so.  The thing is..., no one reported unusual problems. > So what is this, really?, it's a market exploit opportunity for AMD. > > > > On Friday, January 5, 2018, 3:33:31 AM EST, Ronald F. Guilmette wrote: > > > In message <736a2b77-d4a0-b03f-8a6b-6a717f5744d4@metricspace.net>, > Eric McCorkle wrote: > >> The attack looks like this: >> >> 1) Fetch kernel/other process memory, which eventually faults >> 2) Do a bit-shift/mask operation to pluck out one bit of the fetched >> value.  This gets executed speculatively on the fetched value in (1). >> 3) Execute fetches of two different addresses depending on some bit in >> the fetched value in (1) (say, 0x100000 for 0 vs 0x200000 for 1).  This >> also gets executed speculatively despite the fact that (1) ends up faulting. >> 4) Recover from fault in (1) >> 5) Measure performance of accesses to the two addresses to determine >> which one is cached. > > > I must say, that's one hell of a round-about way to read just one bit that > you wern't supposed to have access to.  But of course, that doesn't really > matter if you are an attacker. > > If the above steps can be repeated, programatically, ad infinitum, to read > bits from "protected" memory... and I see no reason why they can't be... > then yea, this bug is every bit as bad as the media is making it out to be, > and maybe even worse. > > All your secrets are belong to us! > > Time to invest in abacuses... or is that abacai? > > > Regards, > rfg > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >