I highly doubt they will punish him. Just like when the credit companies
got to investigate their own breaches.
Surprise! No one was found at fault. Weird!
On Jan 9, 2018, at 7:29 AM, Eric Oyen <[email protected]> wrote:
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’t 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’t have direct access to the physical
machine, would be a potential threat.
The 286 chip had a "protected mode” 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 “atomic” operation — 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 “normal” 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 “segmented memory model” that the 286 used and
allowed it to run in a “virtual” 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 “admin” mode (I forget what it’s 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’t part of the regular 32-bit address space.
(Motorola advocates argued that their chips didn’t 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’s virtually impossible to trigger these
modes. It used to be that you had to put the chip into “single-user mode”
briefly, just like in a Unix environment when you need to perform certain
low-level OS operations. (Windows doesn’t 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 “admin” 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’s going on, so it’s not a mode that’s usually enabled
for very long.
They could have changed things since then, but from what I’ve read this
particular “hairline fracture" has been around forever, and isn’t 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 … if this is something that java or javascript
or anything running in a web browser can trigger, then there’s 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 … I
mean. there would be no limits to what could be done by code running
anywhere.
In 30 years we haven’t 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 “in the wild” triggering
this exploit from a web browser?
The articles I’ve seen only said it was discovered “in a lab” and they
were able to trigger it “in the lab”.
I’m not much of a conspiracy theorist, but I’m 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 “shocking hack”
to the world.
-David Schwartz
On Jan 8, 2018, at 8:09 PM, [email protected] 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
<https://u2206659.ct.sendgrid.net/wf/click?upn=tzJbcg2o-2FNh3kfIF32sRUZ8NnknvQ7-2Bf6wkzOMZJ5l35vJQdR4eO1tqNkrT8g5JyjrDLC3ldM5JJdYP00A0te3bNsb8S-2FwM-2FGJBVS0BNvTQ9Wey3QjFPOff5WpHec9nAKs6Di9WPpNsBr1OIQpLPQBywUm8PtRT-2BnFqDoIIoxBo-3D_6lpMB7VLnN-2Fj9-2FEErg8-2F-2BMBpb5QxlByTgv2M3fbWD9ebvC-2BWrN3h7jImK8EVWYBe90ZrKPsPNFnspMLdRsopRf8gIt0e8Fnu-2B3rLUP-2B5SpBa7TUaFUGLIHIlS5-2BYadzPk8riHnXHIiHSPpBdRUgn-2B52xPZjdNWTyUtwjVOkwz8D9dY-2BUvu4gwXzY2oiV2CWrtDBccVqP3kLi7tgp48qDelv1vJHCGcwghCrbRbepkak-3D>
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 - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
<https://u2206659.ct.sendgrid.net/wf/click?upn=5DvWGaZUY8Sh5aRLWfQTKYiRLVzunonVk948p8WIzMe-2FXlJ9Cta8w8U9xoku9LrUSHNMJbSd3ZEwH-2BqnW2UHlA-3D-3D_6lpMB7VLnN-2Fj9-2FEErg8-2F-2BMBpb5QxlByTgv2M3fbWD9ebvC-2BWrN3h7jImK8EVWYBe90ZrKPsPNFnspMLdRsopRZYGIX2ARMdmeC7OzECbQaerF509GlFyEt16hZE0R-2Bck3ecElkIH5JcVBujltuaZFqBetqXBuMSYeN3giBmt0sBjzzJugaZRaVxStjkCzVU46xvqCZHxBX8mrZwfv8Iu-2Bvs7yflX3Mlgl5HV1qC7yQ4-3D>
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
