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