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