From plug-discuss-bounces@lists.phxlinux.org Fri Jan 12 00:18:49 2018 Return-Path: X-Original-To: lurker@lists.phxlinux.org Delivered-To: lurker@lists.phxlinux.org Received: from phxlinux.org (localhost [127.0.0.1]) by phxlinux.org (Postfix) with ESMTP id 2F8E732A01B9; Fri, 12 Jan 2018 00:18:49 -0700 (MST) X-Original-To: plug-discuss@lists.phxlinux.org Delivered-To: plug-discuss@lists.phxlinux.org Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by phxlinux.org (Postfix) with ESMTP id 4A68432A01B6 for ; Fri, 12 Jan 2018 00:18:48 -0700 (MST) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo201.cox.net (InterMail vM.8.01.05.28 201-2260-151-171-20160122) with ESMTP id <20180112071848.BCFD4103.eastrmfepo201.cox.net@eastrmimpo210.cox.net> for ; Fri, 12 Jan 2018 02:18:48 -0500 Received: from [192.168.37.146] ([70.176.219.123]) by eastrmimpo210.cox.net with cox id xKJn1w0052gLLrJ01KJnFc; Fri, 12 Jan 2018 02:18:47 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020205.5A586157.00F5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.2 cv=MfEcg93f c=1 sm=1 tr=0 a=7OC1wKmARHY3xWCiy//A9g==:117 a=7OC1wKmARHY3xWCiy//A9g==:17 a=UOdvdokE3EQA:10 a=13zjGPudsaEWiJwPRgMA:9 a=5M8c3ETZAAAA:8 a=C1vIzcyXAAAA:8 a=pGLkceISAAAA:8 a=dUhcI3yGAAAA:8 a=xKcrbFdgAAAA:8 a=qd1UI2nrAAAA:8 a=5j9rVgsMjBB4NMljX-EA:9 a=UaH8echchUIewVvp:21 a=EjG4CXCnke78O-NX:21 a=QEXdDO2ut3YA:10 a=hjuFqcA8h55HhvuZtuAA:9 a=ONNS8QRKHyMA:10 a=yBUi2uKG2SWF4pULfpJ8:22 a=QK3yvlqKtY1Z1UrYjINi:22 a=a67EkBJFOE-qB7H0IGxR:22 a=4CbDXKfiEl2k451DeNJ_:22 a=Rf78iB88kbcEjsXYuAON:22 X-CM-Score: 0.00 Authentication-Results: cox.net; none Subject: =?UTF-8?Q?Re:_Post_:_INTEL=e2=80=99S_SECURITY_FLAW_IS_NO_FLAW?= To: Main PLUG discussion list References: <20180111000358.4592442b@mydesk.domain.cxm> <1b93cf5ba951530d4a1aed28a87abbb5@phpcoderusa.com> <63D55323-B50A-493A-BE6D-DCB9D7FA9AC4@gmail.com> <7820ffa052c1a6a00d6d1ef2330f92ec@phpcoderusa.com> <784a30bb-ab26-5592-0383-6742ed9cc03e@stcaz.net> <56D43456-E4C4-4112-AA37-C6C8C2AA1F8B@gmail.com> From: Joseph Sinclair Message-ID: Date: Fri, 12 Jan 2018 00:18:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <56D43456-E4C4-4112-AA37-C6C8C2AA1F8B@gmail.com> X-BeenThere: plug-discuss@lists.phxlinux.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Main PLUG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Main PLUG discussion list Content-Type: multipart/mixed; boundary="===============9135445944576179296==" Errors-To: plug-discuss-bounces@lists.phxlinux.org Sender: "PLUG-discuss" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============9135445944576179296== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4IXoH3omxq3PUj8NS6S8Aj4i7Abra2a8S" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4IXoH3omxq3PUj8NS6S8Aj4i7Abra2a8S Content-Type: multipart/mixed; boundary="fRVSGHkjfjrEj2aEV7qWwFMUdupn3oIfm"; protected-headers="v1" From: Joseph Sinclair To: Main PLUG discussion list Message-ID: Subject: =?UTF-8?Q?Re:_Post_:_INTEL=e2=80=99S_SECURITY_FLAW_IS_NO_FLAW?= References: <20180111000358.4592442b@mydesk.domain.cxm> <1b93cf5ba951530d4a1aed28a87abbb5@phpcoderusa.com> <63D55323-B50A-493A-BE6D-DCB9D7FA9AC4@gmail.com> <7820ffa052c1a6a00d6d1ef2330f92ec@phpcoderusa.com> <784a30bb-ab26-5592-0383-6742ed9cc03e@stcaz.net> <56D43456-E4C4-4112-AA37-C6C8C2AA1F8B@gmail.com> In-Reply-To: <56D43456-E4C4-4112-AA37-C6C8C2AA1F8B@gmail.com> --fRVSGHkjfjrEj2aEV7qWwFMUdupn3oIfm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Feel free to repost anywhere. I don't have a blog site I use; so no real= place to post a full article... On 2018-01-11 07:24 PM, Aaron Jones wrote: > Thanks Joe.=20 >=20 > You should blog an article about this cuz that was the best explanation= for the issue I have read so far.=20 >=20 >> On Jan 11, 2018, at 6:42 PM, Joseph Sinclair wrote: >> >> There seems to be a lot of confusion surrounding the recently disclose= d CPU hardware issues... >> A few points to consider: >> 1) This is a cache timing attack using speculative execution (a key pe= rformance feature in the hardware) that exposes data (i.e. it's not an ex= ploit to "take over" a system); it can only read memory, and only VERY sl= owly, while thrashing the heck out of the CPU. >> 2) Abusing speculative execution is literally something nobody thought= of doing until a few years ago. >> 3) The researchers spent an immense amount of time figuring out tactic= s that worked, time no hardware design engineer would ever have had avail= able, assuming that engineer even had the knowledge to do the coding requ= ired (hint: they don't). >> 4) Exploiting these flaws is HARD. It requires native code execution,= careful and highly skilled coding, specific targeting of the memory to b= e read, and a lot of time on the target machine without tripping alarms d= ue to CPU use. >> 5) The major concern here is things like VM farms because this allows = untrusted code in a guest to (very slowly) read memory from the host or o= ther guests. It's possible to use in other contexts, but the cost/benefi= t balance is pretty bad; desktops and other targets are far easier to exp= loit with well-known and widely used "social" hacks. >> >> Lacking the full detail, I would venture that this *type* of exploit i= s possible (in some form) for every Intel CPU since the original Pentium = PRO which introduced speculative execution to the Intel architecture. >> We don't need to replace hardware, fortunately, this specific set of t= actics can be mitigated by having the Kernel (along with microcode, aka f= irmware) set flags in the CPU to force a full context switch in the speci= fic situations identified by the researchers. >> Yes, mitigation slows down execution a bit; basically the IPC for Inte= l chips now roughly matches the IPC for AMD chips which always forced the= context switch (due to a different design balance). >> I would venture that this flaw is actually caused by Intel having such= a heavy focus to achieve (and maintain) higher IPC levels than AMD, and = cutting a (seemingly benign) corner to accomplish that. >> >> A bit of inside-baseball here: >> Every digital design engineer looks for what we call "don't cares" se= gments of the boolean map where the logic value has no impact on the "cor= rectness" of the result. >> Those are places where we can cut gate count or speed up execution. >> Avoiding a context switch in a CPU with the Intel design for 3 layer c= aching is one of those areas where "don't cares" can show up. >> My gut feel is that the Intel engineers saw an opportunity to retain "= correct" execution of code while speeding up speculative execution by ski= pping the context switch until it was actually necessary (e.g. the specul= ative branch became "live"). >> It is exactly the kind of thing I can see a really smart engineer doin= g because, without future knowledge, it's actually the right thing to do.= >> You get faster execution without any added cost and without breaking e= xisting code. >> That, in retrospect, was a mistake that allowed a very sophisticated a= ttacker to read a few bits of unauthorized memory in a very sneaky manner= =2E >> That someone, a decade or two after the design arose, discovered a way= to misuse that design isn't a sign of malice or malpractice; it's a sign= that security researchers are getting REALLY good at finding unexpected = ways to use hardware design against security. >> >> >> P.S. >> That reddit article is utter garbage. >> Yes, there is, on some motherboards, a Management Engine which is a *s= eparate* CPU, is mostly present only on "business" and server motherboard= s, and has NOTHING TO DO WITH the recent exploits. The FSF and others ha= ve been warning about that particular bit of hardware for a long time. >> The ME has valuable functionality that makes sense for servers especia= lly, and for business-owned machines in general (mostly remote system man= agement, particularly lights-out management). >> The ME was added to the system at the request of business customers so= they could remotely access machines owned by the business (even if turne= d off) and either manage their servers or ensure the main O/S and applica= tions were kept in compliance with policy on desktops. >> Every motherboard I've seen with an ME (and only some have one) can di= sable the ME; usually with a jumper or switch on the board. >> As I understand things it was actually government buyers who demanded = the ability to disable the ME (originally it couldn't be disabled), becau= se government agencies are targets far more often than they are attackers= =2E >> >>> On 2018-01-11 10:36 AM, techlists@phpcoderusa.com wrote: >>> This is basic stuff. Kernel memory must be segregated and each >>> application's memory must be segregated. These are the basics of CPU= >>> functionality. That is why I find theses issues perplexing. And it >>> leads me to one basic question. If these problems persisted since 19= 95, >>> how could these issue go undetected until recently when multiple >>> separate groups discovered these flows? AND is it possible others ha= ve >>> found and used these flaws for their own gain?=20 >>> >>> No matter what happened, politics, accident... etc We have a HUGE >>> problem. Even if there were CPUs that were not vulnerable, it would >>> take years to replace all computers that are publicly facing. In the= >>> mean time there are some seriously evil people / groups / countries t= hat >>> will be looking into how they can use theses chip bugs / vulnerabilit= ies >>> / features... to further their goals. =20 >>> >>>> From what I can tell the solution is to use software - the kernel to= fix >>> or patch the shortcomings of these CPUs. A software patch to fix >>> hardware. This is very scary. A software patch can be removed and /= or >>> replaced, leaving the host vulnerable. =20 >>> >>>> On 2018-01-11 10:10, Mark Phillips wrote: >>>> >>>> No, I don't work at Intel. I am, however, not a believer in all the = government conspiracy theories floating around the Internet.=20 >>>> >>>> Mark=20 >>>> >>>> On Thu, Jan 11, 2018 at 9:25 AM, Aaron Jones = wrote: >>>> >>>> Signals intelligence is believed to have been birthed in 1904. =20 >>>> >>>> But exploiting hardware isn't new. For military, police, or criminal= intentions.=20 >>>> >>>> You work at Intel Mark? Lol=20 >>>> >>>> On Jan 11, 2018, at 9:11 AM, Mark Phillips wrote: >>>> >>>> There is no conspiracy here. 23 years ago no one thought about attac= k vectors and how to take over machines. It is only recently that we are = all sensitized to this problem. Even though the tech world is sensitized = to the nature of exploits, companies still ship brand new products (e.g. = Nest, cars, etc.) that can be exploited by almost anyone. It was only rec= ently that router and switch companies stopped using admin and admin as l= ogin credentials!=20 >>>> >>>> Your argument that these new CPU exploits are a government conspirac= y can be applied to any potential exploit discovered today in a piece of = code written yesterday.=20 >>>> >>>> Mark=20 >>>> >>>> On Thu, Jan 11, 2018 at 9:02 AM, Carruth, Rusty wrote: >>>> As mentioned earlier, I've done my share of ... um, looking for flaw= s in design of operating systems back when I was in college. (What, 1976= ?) >>>> >>>> We discovered some bad flaws in the design of the . How l= ong had the Univac been around? I don't know, but a while. Unless someo= ne with WAY too much time on their hands is actively seeking ways around = stuff, there's only so much 'bug' you can find. (and, actually, you reall= y need more than one person involved (partially so someone can ask the 'r= ight' stupid question :-)) >>>> >>>> Doesn't take malice or sloppiness, and I will say being a publicly-t= raded company makes it very hard to spend the time required to even start= on the hacking required (Being publically-traded makes your owner effect= ively insane, since your owner is actually many people, all with differen= t and often diametrically opposing goals for the company). >>>> >>>> Anyway, tell you what - go read the Intel hardware docs and see if y= ou can find the info needed to put together to see the bug. And this wit= h prior knowledge of where to look. >>>> >>>> I will say that this doesn't excuse much, but realize that being a p= ublic company drives you insane ;-) >>>> >>>> Rusty >>>> >>>> -----Original Message----- >>>> From: PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] = On Behalf Of techlists@phpcoderusa.com >>>> Sent: Thursday, January 11, 2018 8:42 AM >>>> To: Main PLUG discussion list >>>> Subject: Re: Post : INTEL'S SECURITY FLAW IS NO FLAW >>>> >>>> ... >>>> >>>> I've read these issues may have persisted as far back as 1995. How = does >>>> that happen? How does an army of engineers miss this for 23 years? = How >>>> do you explain that? >>>> >>>> That means lots of people came and went. There should have been lot= s of >>>> QA... for 23 years. >>>> >>>> How does this happen? Only two ways I can see 1) sloppy work, or 2)= >>>> intentionally. >>>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1] >>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1] >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]=20 >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss=20 >>> >>> Links: >>> ------ >>> [1] http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > http://lists.phxlinux.org/mailman/listinfo/plug-discuss >=20 --fRVSGHkjfjrEj2aEV7qWwFMUdupn3oIfm-- --4IXoH3omxq3PUj8NS6S8Aj4i7Abra2a8S Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJaWGFWAAoJEFuj3m+iQYyKAxIH/A7y3KCwPWRzCBnsKIlVi9Wk Wmut27BHXkDJV++Du2Nvaa5A5aOG0K+I+t2LPN6H4XUdRC7OckHZqN+WV4jg6a9k zTiKcUDpI1BLjSUY0a0CslrY95CRoLuTP4tYicBhcgY1mSHkpV2WCT8VXoqE9uLy 0fmz++y3TujIWtJkDdOnHzHo0Ctb+30t3RaHWLOpGFUq76LkrZN/WNf7NhRB9u7z hjR7RGm1l9fbtED3jhUIU81sIKjfTOHPHpciNwqlj/+VVbIz0ZFQ2LF2s4TJ0qJl 0Fqme7QzYbH6fnmKPmb6uGcDFcz6m46xMi1hXV0qBcxXP4WjwhhH7mnuegzSkvk= =QOx6 -----END PGP SIGNATURE----- --4IXoH3omxq3PUj8NS6S8Aj4i7Abra2a8S-- --===============9135445944576179296== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBMVUct ZGlzY3VzcyBtYWlsaW5nIGxpc3QgLSBQTFVHLWRpc2N1c3NAbGlzdHMucGh4bGludXgub3JnClRv IHN1YnNjcmliZSwgdW5zdWJzY3JpYmUsIG9yIHRvIGNoYW5nZSB5b3VyIG1haWwgc2V0dGluZ3M6 Cmh0dHA6Ly9saXN0cy5waHhsaW51eC5vcmcvbWFpbG1hbi9saXN0aW5mby9wbHVnLWRpc2N1c3M= --===============9135445944576179296==--