https://www.itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html
On Tue, Jan 9, 2018 at 9:45 AM, Mark Phillips <
mark@phillipsmarketing.biz>
wrote:
> I would be leery of conspiracy theories in relation to the stock market
> and tech stocks. Lots of people are taking profits from the huge rise in
> the stock market in anticipation of a correction. The correction will come,
> we just don't know when.
>
> https://www.google.com/imgres?imgurl=https://upload.
> wikimedia.org/wikipedia/commons/7/7e/S_and_P_500_chart_1950_to_2016_with_
> averages.png&imgrefurl=https://en.wikipedia.org/wiki/S%
> 2526P_500_Index&h=798&w=1145&tbnid=w2UuAMqXUpl0aM:&tbnh=63&
> tbnw=92&usg=__z0CAhDP2E--B9mCoEpEZPz1al6g%3D&vet=
> 10ahUKEwiQnbP0qcvYAhVB3mMKHcFQCmkQ_B0IrQEwDQ..i&docid=
> uzs0pfDsy6G10M&itg=1&sa=X&ved=0ahUKEwiQnbP0qcvYAhVB3mMKHcFQCmkQ_B0IrQEwDQ
>
> Mark
>
> On Tue, Jan 9, 2018 at 7:37 AM, Aaron Jones <retro64xyz@gmail.com> wrote:
>
>> 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 <eric.oyen@icloud.com> 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, 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
>> <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 - PLUG-discuss@lists.phxlinux.org
>> 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 - 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
>>
>
>
> ---------------------------------------------------
> 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
>
--
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.
Stephen
---------------------------------------------------
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 
(text/plain)