From plug-discuss-bounces@lists.phxlinux.org Tue Jan 9 07:29:35 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 5136032A01B9; Tue, 9 Jan 2018 07:29:35 -0700 (MST) X-Original-To: plug-discuss@lists.phxlinux.org Delivered-To: plug-discuss@lists.phxlinux.org Received: from mr26p44im-ztdg08103301.me.com (mr26p44im-ztdg08103301.me.com [17.111.247.49]) by phxlinux.org (Postfix) with ESMTPS id 34D6E32A01B6 for ; Tue, 9 Jan 2018 07:29:34 -0700 (MST) Received: from process-dkim-sign-daemon.mr26p44im-ztdg08103301.me.com by mr26p44im-ztdg08103301.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2A00200KX33L00@mr26p44im-ztdg08103301.me.com> for plug-discuss@lists.phxlinux.org; Tue, 09 Jan 2018 14:29:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1515508171; bh=KNkSYahMNXIVrV145lF4ZRPnZpOYsaJWCxS1iSiBgG8=; h=From:MIME-version:Content-type:Subject:Date:To:Message-id; b=qm6BwqNqTWV/2PSo3/vJ46H4glYFXB+vW/KUCP77upSnZl6exizTbYBdJWjL8OFZd F5QaYa8T3JDQ0IPaeubIesjEgJf92leetWMFEkjsDyvK7y44HbYHvBqHdsjpHwk3Zv xu0rZVl0sPwF1Z52gVKc49OYVHJkVDtcaQQTHUZlohBHmTeepk+42sVzYqruqyHBHy zQ5ukJgU7eii/Ur7syyant8TAg5nVim4l9NYHsFGteRPfJv2N2r+zoSEMSVwBayCA3 sSBzOdFVih0FuncxkNbw9mC7aJko+WPtpLPSxbL49U56m46HnyaOt6ikTxeuvLD7yw /OW7skGNN1L4w== Received: from icloud.com ([127.0.0.1]) by mr26p44im-ztdg08103301.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2A00KEOLL51840@mr26p44im-ztdg08103301.me.com> for plug-discuss@lists.phxlinux.org; Tue, 09 Jan 2018 14:29:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-09_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801090205 From: Eric Oyen MIME-version: 1.0 (Apple Message framework v1283) Subject: Re: Meltdown and Spectre - What to do about it Date: Tue, 09 Jan 2018 07:29:28 -0700 In-reply-to: To: Main PLUG discussion list References: <3f681513284f3532600715e3425734cd@phpcoderusa.com> Message-id: <5AD793C1-A84C-4A46-B156-3A349330BC7D@icloud.com> X-Mailer: Apple Mail (2.1283) 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="===============1590782154752374770==" Errors-To: plug-discuss-bounces@lists.phxlinux.org Sender: "PLUG-discuss" --===============1590782154752374770== Content-type: multipart/alternative; boundary="Apple-Mail=_074BAC21-7318-4B45-81ED-D997CAB3AC0F" --Apple-Mail=_074BAC21-7318-4B45-81ED-D997CAB3AC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 well, it appears that the "conspiracy theory" 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 for another reason, but the = timing seems rather suspect. btw, said CEO is now under 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=92t done any in-depth research on this, but from what I have = read, I cannot really see how anything running in a virtualized or = interpreted environment, or something that doesn=92t have direct access = to the physical machine, would be a potential threat. >=20 > The 286 chip had a "protected mode=94 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 turned out that one of the chip designers at = Intel decided to save a few bytes of microcode and created a situation = where the processing of the interrupt vector that pushed the current IP = onto the stack was not an =93atomic=94 operation =97 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 = discussion about this, mostly a lot of jokes about the probability of = lightning striking the same person twice on the same golf course on a = cloudless day. That is to say, the statistical likelihood of that = happening during =93normal=94 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, there was enough pressure from customers that they added a new = memory model option that disabled the =93segmented memory model=94 that = the 286 used and allowed it to run in a =93virtual=94 mode that = flattened the entire address space. >=20 > They still had a couple of protected areas that were carried over from = the 286 (the GOT and GDT, amongh others) that could only be accessed = when the chip 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 the chip to gain access to some of the protected memory areas. These = areas were protected by virtue of the fact that they required a base = segment register to be loaded that pointed to an area of memory that was = outside of the normal memory space. To access them, you generally had to = put the chip into what amounts to =93admin=94 mode (I forget what it=92s = called), load the registered and trigger a fault (or sw interrupt). As I = recall, this required some assistance from the memory chip interfaces = because they used an address bit that wasn=92t part of the regular = 32-bit address space. >=20 > (Motorola advocates argued that their chips didn=92t require this = special chip between the CPU and system RAM, but it was simply a dynamic = RAM controller. I suspect it took on additional security roles over time = because it WAS independent of the CPU.) >=20 > During normal operation, it=92s virtually impossible to trigger these = modes. It used to be that you had to put the chip into =93single-user = mode=94 briefly, just like in a Unix environment when you need to = perform certain low-level OS operations. (Windows doesn=92t do that, = which is why you have to reboot the damn thing every time you install a = new device driver, for instance.) >=20 > It would be necessary to overwrite some kernal code that executes when = the chip is in this =93admin=94 mode, and that code would have to = execute some protected-mode instructions in a very specific order. Most = other things are locked-out while that=92s going on, so it=92s not a = mode that=92s usually enabled for very long. >=20 > They could have changed things since then, but from what I=92ve read = this particular =93hairline fracture" has been around forever, and isn=92t= even rooted in a specific CPU or CPU family, but possibly due to = interactions between the CPU and (external) memory controllers. >=20 > The moral of the story is =85 if this is something that java or = javascript or anything running in a web browser can trigger, then = there=92s 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 = driver in Windows and 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 web browser, tho. >=20 > People would be patching the kernel, switching into protected mode, = fiddling within things any time they like, reprogramming the hardware =85 = I mean. there would be no limits to what could be done by code running = anywhere. >=20 > In 30 years we haven=92t seen any evidence that this is the case, even = though this has apparently been around forever. >=20 > Have there even been any reports of any code =93in the wild=94 = triggering this exploit from a web browser? >=20 > The articles I=92ve seen only said it was discovered =93in a lab=94 = and they were able to trigger it =93in the lab=94. >=20 > I=92m not much of a conspiracy theorist, but I=92m far more inclined = to think this is something that the engineers who work at chip and = hardware vendors have known about for decades, only never talked about, = and somebody with a lot of money caught wind of it and decided to use it = to win his own lottery by shorting a bunch of tech stocks before = announcing this =93shocking hack=94 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 = given Meltdown and Spectre. >>=20 >> Now that it has come to light that computer memory is not completely = segregated 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 = their Kernel to secure the memory at its boundaries. In and of itself = this seems 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 have this vulnerability. It would seem even modifying the existing = CPUs and manufacturing 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 devise that runs a browser. The browser is the point of failure. = Introduce some 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 --Apple-Mail=_074BAC21-7318-4B45-81ED-D997CAB3AC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

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

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

I haven=92t done any in-depth research on = this, but from what I have read, I cannot really see how anything = running in a virtualized or interpreted environment, or something that = doesn=92t have direct access to the physical machine, would be a = potential threat.

The = 286 chip had a "protected mode=94 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 turned out that one of the chip designers at = Intel decided to save a few bytes of microcode and created a situation = where the processing of the interrupt vector that pushed the current IP = onto the stack was not an =93atomic=94 operation =97 it could be = interrupted. And this affected context switches into protected = mode.

I was = working at Intel at the time and there was quite a bit of discussion = about this, mostly a lot of jokes about the probability of lightning = striking the same person twice on the same golf course on a cloudless = day. That is to say, the statistical likelihood of that happening during = =93normal=94 operation was absurdly low.

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, there was enough pressure from = customers that they added a new memory model option that disabled the = =93segmented memory model=94 that the 286 used and allowed it to run in = a =93virtual=94 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) that could only be accessed when the chip was put into a = special mode that only the OS kernal was supposed to do.

But there were rumors = that there were other ways of triggering faults on the chip to gain = access to some of the protected memory areas. These areas were protected = by virtue of the fact that they required a base segment register to be = loaded that pointed to an area of memory that was outside of the normal = memory space. To access them, you generally had to put the chip into = what amounts to =93admin=94 mode (I forget what it=92s called), load the = registered and trigger a fault (or sw interrupt). As I recall, this = required some assistance from the memory chip interfaces because they = used an address bit that wasn=92t part of the regular  32-bit = address space.

(Motorola advocates argued that their chips didn=92t require = this special chip between the CPU and system RAM, but it was simply a = dynamic RAM controller. I suspect it took on additional security roles = over time because it WAS independent of the CPU.)
During normal operation, it=92s = virtually impossible to trigger these modes. It used to be that you had = to put the chip into =93single-user mode=94 briefly, just like in a Unix = environment when you need to perform certain low-level OS operations. = (Windows doesn=92t do that, 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 executes when the = chip is in this =93admin=94 mode, and that code would have to execute = some protected-mode instructions in a very specific order. Most other = things are locked-out while that=92s going on, so it=92s not a mode = that=92s usually enabled for very long.

They could have changed things since = then, but from what I=92ve read this particular =93hairline fracture" = has been around forever, and isn=92t even rooted in a specific CPU or = CPU family, but possibly due to interactions between the CPU and = (external) memory controllers.

The moral of the story is =85 if this = is something that java or javascript or anything running in a web = browser can trigger, then there=92s absolutely no way to protect any = aspect of the hardware whatsoever.

Said another way, it would allow the = web browser to install a device driver in Windows and 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 = web browser, tho.

People would be patching the kernel, switching into protected = mode, fiddling within things any time they like, reprogramming the = hardware =85 I mean. there would be no limits to what could be done by = code running anywhere.

In 30 years we haven=92t seen any evidence that this is the = case, even though this has apparently been around forever.

Have there even been any = reports of any code =93in the wild=94 triggering this exploit from a web = browser?

The = articles I=92ve seen only said it was discovered =93in a lab=94 and they = were able to trigger it =93in the lab=94.

I=92m not much of a conspiracy = theorist, but I=92m far more inclined to think this is something that = the engineers who work at chip and hardware vendors have known about for = decades, only never talked about, and somebody with a lot of money = caught wind of it and decided to use it to win his own lottery by = shorting a bunch of tech stocks before announcing this =93shocking hack=94= to the world.

-David Schwartz



On Jan 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 Meltdown and Spectre.

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

I'm reading the initial = solution is for the O/S manufactures to patch their Kernel to secure the = memory at its boundaries.  In and of itself this seems to 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 not = have this vulnerability. It would seem even modifying the existing CPUs = and manufacturing them would take months if not a year or so.  In = the meantime we have to survive with hardware patched with = software.  

I read that desktops are the most = vulnerable. Maybe that should be any devise that runs a browser.  = The browser is the point of failure.  Introduce some rogue = JavaScript and your memory is compromised.  

This article says one should enable site isolation using = Chrome.

At this point my preventative steps are:

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

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

3) Configure Chrome to run in isolation = mode. 

Anyone have any other thoughts?

Thank you in advance. 

Keith  





---------------------------------------------------
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

3D""
---------------------------------------------------
PLUG-discuss = mailing list - PLUG-discuss@lists.phxlinu= x.org
To subscribe, unsubscribe, or to change your mail = settings:
http://li= sts.phxlinux.org/mailman/listinfo/plug-discuss

<= /div>= --Apple-Mail=_074BAC21-7318-4B45-81ED-D997CAB3AC0F-- --===============1590782154752374770== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClBMVUct ZGlzY3VzcyBtYWlsaW5nIGxpc3QgLSBQTFVHLWRpc2N1c3NAbGlzdHMucGh4bGludXgub3JnClRv IHN1YnNjcmliZSwgdW5zdWJzY3JpYmUsIG9yIHRvIGNoYW5nZSB5b3VyIG1haWwgc2V0dGluZ3M6 Cmh0dHA6Ly9saXN0cy5waHhsaW51eC5vcmcvbWFpbG1hbi9saXN0aW5mby9wbHVnLWRpc2N1c3M= --===============1590782154752374770==--