From plug-discuss-bounces@lists.phxlinux.org Tue Jan 9 07:37:47 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 35A5432A01B9; Tue, 9 Jan 2018 07:37:47 -0700 (MST) X-Original-To: plug-discuss@lists.phxlinux.org Delivered-To: plug-discuss@lists.phxlinux.org Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com [74.125.83.51]) by phxlinux.org (Postfix) with ESMTPS id 58FF232A01B6 for ; Tue, 9 Jan 2018 07:37:46 -0700 (MST) Received: by mail-pg0-f51.google.com with SMTP id z20so5830302pgv.6 for ; Tue, 09 Jan 2018 06:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=WKQmgTnSKag01vOhdWbiPWeYUcbsSjFaDEbgbN3Tpug=; b=C886ao1W7i7//ynxRcFFvyH1XKYMgWYlB1ls7mcl5clmqSDXuoOwNTJ6rrKg2KsyxA OZAs/8c8th07BMF0Ek1ydHKT5nuSzGDCLXM7C7lr86rj1Migb8rpwZ6M0FmDuogV6xtx QCU/7aQyZUX6eqtOOSTUQx1oP+wDjdmw/UgQ8xb4O6EeqiEJEjWP0UJ9DtH3VTVraGGI NkzAObcD3haD1LwJaiB7ZnZNcdkwH6by4EyLtN26pn4F1yRxWvnY/ttb6VXTyRBPlSUb KwLNIo3pd6gyKvSh6Awxh5tU8wX2ddrhxvrpASzwmLFtSDx8kt3kmJupS4YEv96ykg3b PJNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=WKQmgTnSKag01vOhdWbiPWeYUcbsSjFaDEbgbN3Tpug=; b=M4eF9VlO+KRIyc4sbNPncdrCc5X1UcqGi990WHJVXfJc+Zmw3RlQ5nkYvWdgQ8a39/ x9rGBsyTun75cfdcesxNu4SX+bK29StpJLnYGElIIzpiGfWJDm37yzWmE/0pMU41WcwQ 6lQ+zhRk0H0PZha70Zl3IgIJFKYXhmqVeUn50wlN5wZmNcjQWxS+0hzrkCnUoAQBfF/+ eGCgvHgOv2xI25gPyVRR3veYbUX6fUaeehKc7l84/skyVvG8qAH/zzuWBcO0g+XBxhe/ eLOGV6xM43lH/s65wPXdpKcfoZg5sHaCvpwTJuWHKb/Yfg9tU+n4sTEwNk0QACn2bafG ZC/A== X-Gm-Message-State: AKGB3mKrq2LWkZiokvxBCVpNMUNNe2oh40cPqVvmVpzJrpgcuoSR3GYk ISh1tqDgwu6H7YzTGRpaHrOsRakb X-Google-Smtp-Source: ACJfBouI/1/vaoGD669fohtTVL39cNLcPQvu8ZrwJqiHfmcPW2HGUGvaDsbF5PxRNDR2njPXVobnbg== X-Received: by 10.98.15.75 with SMTP id x72mr14020648pfi.1.1515508665400; Tue, 09 Jan 2018 06:37:45 -0800 (PST) Received: from [192.168.0.22] (71-211-124-167.phnx.qwest.net. [71.211.124.167]) by smtp.gmail.com with ESMTPSA id u19sm28127664pfh.89.2018.01.09.06.37.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 06:37:44 -0800 (PST) From: Aaron Jones Mime-Version: 1.0 (1.0) Date: Tue, 9 Jan 2018 07:37:43 -0700 Subject: Re: Meltdown and Spectre - What to do about it Message-Id: References: <3f681513284f3532600715e3425734cd@phpcoderusa.com> <5AD793C1-A84C-4A46-B156-3A349330BC7D@icloud.com> In-Reply-To: <5AD793C1-A84C-4A46-B156-3A349330BC7D@icloud.com> To: Main PLUG discussion list X-Mailer: iPhone Mail (15C153) 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="===============8208041021283200752==" Errors-To: plug-discuss-bounces@lists.phxlinux.org Sender: "PLUG-discuss" --===============8208041021283200752== Content-Type: multipart/alternative; boundary=Apple-Mail-E0E2E73E-A465-4833-8540-64931374620B Content-Transfer-Encoding: 7bit --Apple-Mail-E0E2E73E-A465-4833-8540-64931374620B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I highly doubt they will punish him. Just like when the credit companies got= to investigate their own breaches.=20 Surprise! No one was found at fault. Weird! > On Jan 9, 2018, at 7:29 AM, Eric Oyen wrote: >=20 > well, > it appears that the "conspiracy theory" of someone shorting tech stocks ha= s already happened. the CEO of Intel dumped a huge load of stock last novemb= er. Now, it is likely that it was for another reason, but the timing seems r= ather suspect. btw, said CEO is now under review by the SEC and may be facin= g charges of insider trading. >=20 > -eric > from the central offices of the technomage Guild, News Dept. >=20 >> On Jan 8, 2018, at 9:29 PM, David Schwartz wrote: >>=20 >> I haven=E2=80=99t done any in-depth research on this, but from what I hav= e read, I cannot really see how anything running in a virtualized or interpr= eted environment, or something that doesn=E2=80=99t have direct access to th= e physical machine, would be a potential threat. >>=20 >> The 286 chip had a "protected mode=E2=80=9D built into it. IBM and Micros= oft spent a huge amount of money writing an OS that was designed to run in p= rotected mode. But it turned out that one of the chip designers at Intel dec= ided to save a few bytes of microcode and created a situation where the proc= essing of the interrupt vector that pushed the current IP onto the stack was= not an =E2=80=9Catomic=E2=80=9D operation =E2=80=94 it could be interrupted= . And this affected context switches into protected mode. >>=20 >> I was working at Intel at the time and there was quite a bit of discussio= n about this, mostly a lot of jokes about the probability of lightning strik= ing the same person twice on the same golf course on a cloudless day. That i= s to say, the statistical likelihood of that happening during =E2=80=9Cnorma= l=E2=80=9D operation was absurdly low. >>=20 >> Needless to day, a protected OS was never released for the 286. But while= they were busy fixing this bit of microcode to make the 386 work properly, t= here was enough pressure from customers that they added a new memory model o= ption that disabled the =E2=80=9Csegmented memory model=E2=80=9D that the 28= 6 used and allowed it to run in a =E2=80=9Cvirtual=E2=80=9D mode that flatte= ned the entire address space. >>=20 >> They still had a couple of protected areas that were carried over from th= e 286 (the GOT and GDT, amongh others) that could only be accessed when the c= hip was put into a special mode that only the OS kernal was supposed to do. >>=20 >> But there were rumors that there were other ways of triggering faults on t= he chip to gain access to some of the protected memory areas. These areas we= re protected by virtue of the fact that they required a base segment registe= r to be loaded that pointed to an area of memory that was outside of the nor= mal memory space. To access them, you generally had to put the chip into wha= t amounts to =E2=80=9Cadmin=E2=80=9D mode (I forget what it=E2=80=99s called= ), load the registered and trigger a fault (or sw interrupt). As I recall, t= his required some assistance from the memory chip interfaces because they us= ed an address bit that wasn=E2=80=99t part of the regular 32-bit address sp= ace. >>=20 >> (Motorola advocates argued that their chips didn=E2=80=99t require this s= pecial chip between the CPU and system RAM, but it was simply a dynamic RAM c= ontroller. I suspect it took on additional security roles over time because i= t WAS independent of the CPU.) >>=20 >> During normal operation, it=E2=80=99s virtually impossible to trigger the= se modes. It used to be that you had to put the chip into =E2=80=9Csingle-us= er mode=E2=80=9D briefly, just like in a Unix environment when you need to p= erform certain low-level OS operations. (Windows doesn=E2=80=99t do that, wh= ich is why you have to reboot the damn thing every time you install a new de= vice driver, for instance.) >>=20 >> It would be necessary to overwrite some kernal code that executes when th= e chip is in this =E2=80=9Cadmin=E2=80=9D mode, and that code would have to e= xecute some protected-mode instructions in a very specific order. Most other= things are locked-out while that=E2=80=99s going on, so it=E2=80=99s not a m= ode that=E2=80=99s usually enabled for very long. >>=20 >> They could have changed things since then, but from what I=E2=80=99ve rea= d this particular =E2=80=9Chairline fracture" has been around forever, and i= sn=E2=80=99t even rooted in a specific CPU or CPU family, but possibly due t= o interactions between the CPU and (external) memory controllers. >>=20 >> The moral of the story is =E2=80=A6 if this is something that java or jav= ascript or anything running in a web browser can trigger, then there=E2=80=99= s absolutely no way to protect any aspect of the hardware whatsoever. >>=20 >> Said another way, it would allow the web browser to install a device driv= er in Windows and activate it without having to reboot the machine. I for on= e would welcome a standalone app that would do that! Not so much something t= hat runs in a web browser, tho. >>=20 >> People would be patching the kernel, switching into protected mode, fiddl= ing within things any time they like, reprogramming the hardware =E2=80=A6 I= mean. there would be no limits to what could be done by code running anywhe= re. >>=20 >> In 30 years we haven=E2=80=99t seen any evidence that this is the case, e= ven though this has apparently been around forever. >>=20 >> Have there even been any reports of any code =E2=80=9Cin the wild=E2=80=9D= triggering this exploit from a web browser? >>=20 >> The articles I=E2=80=99ve seen only said it was discovered =E2=80=9Cin a l= ab=E2=80=9D and they were able to trigger it =E2=80=9Cin the lab=E2=80=9D. >>=20 >> I=E2=80=99m not much of a conspiracy theorist, but I=E2=80=99m far more i= nclined to think this is something that the engineers who work at chip and h= ardware vendors have known about for decades, only never talked about, and s= omebody with a lot of money caught wind of it and decided to use it to win h= is own lottery by shorting a bunch of tech stocks before announcing this =E2= =80=9Cshocking hack=E2=80=9D to the world. >>=20 >> -David Schwartz >>=20 >>=20 >>=20 >>> On Jan 8, 2018, at 8:09 PM, techlists@phpcoderusa.com wrote: >>>=20 >>> Hi, >>>=20 >>> I'm looking for more info or ideas on how one might protect them self gi= ven Meltdown and Spectre. >>>=20 >>> Now that it has come to light that computer memory is not completely seg= regated or kept private by the CPU hardware... a failure in design allowing a= hacker access to even the CPU Kernel memory. This is catastrophic. =20 >>>=20 >>> I'm reading the initial solution is for the O/S manufactures to patch th= eir Kernel to secure the memory at its boundaries. In and of itself this se= ems to be a weak approach, however probably the only one at this point. >>>=20 >>> I am reading that the real solution is a new bread of CPU that does not h= ave this vulnerability. It would seem even modifying the existing CPUs and m= anufacturing them would take months if not a year or so. In the meantime we= have to survive with hardware patched with software. =20 >>>=20 >>> I read that desktops are the most vulnerable. Maybe that should be any d= evise that runs a browser. The browser is the point of failure. Introduce s= ome rogue JavaScript and your memory is compromised. =20 >>>=20 >>> This article says one should enable site isolation using Chrome. >>>=20 >>> At this point my preventative steps are: >>>=20 >>> 1) flush all browsers of any usernames, passwords and history. >>>=20 >>> 2) Only run the latest version of Chrome and only Chrome. >>>=20 >>> 3) Configure Chrome to run in isolation mode.=20 >>>=20 >>> Anyone have any other thoughts? >>>=20 >>> Thank you in advance.=20 >>>=20 >>> Keith =20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=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 >>=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 > --------------------------------------------------- > 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 --Apple-Mail-E0E2E73E-A465-4833-8540-64931374620B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I highly doubt they will pu= nish him. Just like when the credit companies got to investigate their own b= reaches. 

Surprise! No one was found at fault.= Weird!

On Jan 9, 2018, at 7:29 AM, Eric Oyen <eric.oyen@icloud.com> wrote:

well,
it appears that the "conspiracy th= eory" of someone shorting tech stocks has already happened. the CEO of Intel= dumped a huge load of stock last november. Now, it is likely that it was fo= r another reason, but the timing seems rather suspect. btw, said CEO is now u= nder review by the SEC and may be facing charges of insider trading.

-eric
from the central offices of the technomage= Guild, News Dept.

On Jan 8, 2018, at 9:29 PM, David= Schwartz wrote:

I haven=E2=80=99t done any in-depth res= earch on this, but from what I have read, I cannot really see how anything r= unning in a virtualized or interpreted environment, or something that doesn=E2= =80=99t have direct access to the physical machine, would be a potential thr= eat.

The 286 chip had a "= protected mode=E2=80=9D built into it. IBM and Microsoft spent a huge amount= of money writing an OS that was designed to run in protected mode. But it t= urned out that one of the chip designers at Intel decided to save a few byte= s of microcode and created a situation where the processing of the interrupt= vector that pushed the current IP onto the stack was not an =E2=80=9Catomic= =E2=80=9D operation =E2=80=94 it could be interrupted. And this affected con= text switches into protected mode.

I was working at Intel at the time and there was quite a bi= t of discussion about this, mostly a lot of jokes about the probability of l= ightning striking the same person twice on the same golf course on a cloudle= ss day. That is to say, the statistical likelihood of that happening during =E2= =80=9Cnormal=E2=80=9D operation was absurdly low.

Needless to day, a protected OS was never re= leased for the 286. But while they were busy fixing this bit of microcode to= make the 386 work properly, there was enough pressure from customers that t= hey added a new memory model option that disabled the =E2=80=9Csegmented mem= ory model=E2=80=9D that the 286 used and allowed it to run in a =E2=80=9Cvir= tual=E2=80=9D mode that flattened the entire address space.

They still had a couple of protected= areas that were carried over from the 286 (the GOT and GDT, amongh others) t= hat could only be accessed when the chip was put into a special mode that on= ly the OS kernal was supposed to do.

But there were rumors that there were other ways of trigg= ering faults on the chip to gain access to some of the protected memory area= s. These areas were protected by virtue of the fact that they required a bas= e segment register to be loaded that pointed to an area of memory that was o= utside of the normal memory space. To access them, you generally had to put t= he chip into what amounts to =E2=80=9Cadmin=E2=80=9D mode (I forget what it=E2= =80=99s called), load the registered and trigger a fault (or sw interrupt). A= s I recall, this required some assistance from the memory chip interfaces be= cause they used an address bit that wasn=E2=80=99t part of the regular  = ;32-bit address space.

(Motorola advocates argued that their chips didn=E2=80=99t require this s= pecial chip between the CPU and system RAM, but it was simply a dynamic RAM c= ontroller. I suspect it took on additional security roles over time because i= t WAS independent of the CPU.)

During normal operation, it=E2=80=99s virtually impossible to t= rigger these modes. It used to be that you had to put the chip into =E2=80=9C= single-user mode=E2=80=9D briefly, just like in a Unix environment when you n= eed to perform certain low-level OS operations. (Windows doesn=E2=80=99t do t= hat, which is why you have to reboot the damn thing every time you install a= new device driver, for instance.)

It would be necessary to overwrite some kernal code that ex= ecutes when the chip is in this =E2=80=9Cadmin=E2=80=9D mode, and that code w= ould have to execute some protected-mode instructions in a very specific ord= er. Most other things are locked-out while that=E2=80=99s going on, so it=E2= =80=99s not a mode that=E2=80=99s usually enabled for very long.

They could have changed thing= s since then, but from what I=E2=80=99ve read this particular =E2=80=9Chairl= ine fracture" has been around forever, and isn=E2=80=99t even rooted in a sp= ecific CPU or CPU family, but possibly due to interactions between the CPU a= nd (external) memory controllers.

=
The moral of the story is =E2=80=A6 if this is something tha= t java or javascript or anything running in a web browser can trigger, then t= here=E2=80=99s absolutely no way to protect any aspect of the hardware whats= oever.

Said anothe= r way, it would allow the web browser to install a device driver in Windows a= nd activate it without having to reboot the machine. I for one would welcome= a standalone app that would do that! Not so much something that runs in a w= eb browser, tho.

P= eople would be patching the kernel, switching into protected mode, fiddling w= ithin things any time they like, reprogramming the hardware =E2=80=A6 I mean= . there would be no limits to what could be done by code running anywhere.

In 30 years we have= n=E2=80=99t seen any evidence that this is the case, even though this has ap= parently been around forever.

Have there even been any reports of any code =E2=80=9Cin the wil= d=E2=80=9D triggering this exploit from a web browser?
=
The articles I=E2=80=99ve seen only sai= d it was discovered =E2=80=9Cin a lab=E2=80=9D and they were able to trigger= it =E2=80=9Cin the lab=E2=80=9D.

=
I=E2=80=99m not much of a conspiracy theorist, but I=E2=80=99= m far more inclined to think this is something that the engineers who work a= t chip and hardware vendors have known about for decades, only never talked a= bout, and somebody with a lot of money caught wind of it and decided to use i= t to win his own lottery by shorting a bunch of tech stocks before announcin= g this =E2=80=9Cshocking hack=E2=80=9D to the world.

-David Schwartz



On J= an 8, 2018, at 8:09 PM, techlists@phpcoderusa.com wrote:

Hi,

I'= m looking for more info or ideas on how one might protect them self given Me= ltdown and Spectre.

Now that it has come to light that comp= uter memory is not completely segregated or kept private by the CPU hardware= ... a failure in design allowing a hacker access to even the CPU K= ernel memory.  This is catastrophic.  

I'm r= eading the initial solution is for the O/S manufactures to patch their Kerne= l to secure the memory at its boundaries.  In and of itself this seems t= o be a weak approach, however probably the only one at this point.

I am reading that the real solution is a new bread of CPU that does n= ot have this vulnerability. It would seem even modifying the existing CPUs a= nd manufacturing them would take months if not a year or so.  In the me= antime we have to survive with hardware patched with software.  

I read that desktops are the most vulnerable. Maybe that sho= uld be any devise that runs a browser.  The browser is the point of fai= lure.  Introduce some rogue JavaScript and your memory is compromised.&= nbsp; 

This article says<= /a> one should enable site isolation using Chrome.

At this p= oint my preventative steps are:

1) flush all browsers of an= y usernames, passwords and history.

2) Only run the latest v= ersion of Chrome and only Chrome.

3) Configure Chrome to ru= n in isolation mode. 

Anyone have any other thoughts?<= /p>

Thank you in advance. 

Keith &nb= sp;





---------------------------------------------------
PLUG-discu= ss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscri= be, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss<= /div>

3D""
---------------------------------------------------
PLUG-discuss mailing l= ist - PLUG-discuss@lists.= phxlinux.org
To subscribe, unsubscribe, or to change your mail settin= gs:
h= ttp://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------= ------------------------------------------
PLUG-discuss mail= ing list - PLUG-discuss@l= ists.phxlinux.org
To subscribe, unsubscribe, or to chang= e your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plu= g-discuss
= --Apple-Mail-E0E2E73E-A465-4833-8540-64931374620B-- --===============8208041021283200752== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBMVUct ZGlzY3VzcyBtYWlsaW5nIGxpc3QgLSBQTFVHLWRpc2N1c3NAbGlzdHMucGh4bGludXgub3JnClRv IHN1YnNjcmliZSwgdW5zdWJzY3JpYmUsIG9yIHRvIGNoYW5nZSB5b3VyIG1haWwgc2V0dGluZ3M6 Cmh0dHA6Ly9saXN0cy5waHhsaW51eC5vcmcvbWFpbG1hbi9saXN0aW5mby9wbHVnLWRpc2N1c3M= --===============8208041021283200752==--