Am 09. Jan, 2018 schwätzte Stephen Partington so:
Theo has previously broken embargoes ( arguably justified, but mostly just
arguable ), so OpenBSD was likely intentionally left out.
ciao,
der.hans
> 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
>>
>
>
>
>
--
#
https://www.LuftHans.com https://www.PhxLinux.org
# I only eat free-range vegetables that were hunted down and slain by
# a member of my immediate family. -- der.hans---------------------------------------------------
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)