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