http://www.dw.com/en/new-security-flaw-detected-in-intel-hardware/a-42122823
New flaw in intel amt. again Also. The new fix for spdctre and meltdown causes uncontrolled reboots in some haswell and broadwell processors. > On Jan 12, 2018, at 2:09 PM, Nathan O'Brennan <[email protected]> wrote: > > > Would SELinux protect in any way against either of these vulnerabilities? > > >> On 2018-01-12 00:18, Joseph Sinclair wrote: >> Feel free to repost anywhere. I don't have a blog site I use; so no >> real place to post a full article... >>> On 2018-01-11 07:24 PM, Aaron Jones wrote: >>> Thanks Joe. >>> You should blog an article about this cuz that was the best explanation for >>> the issue I have read so far. >>>> On Jan 11, 2018, at 6:42 PM, Joseph Sinclair <[email protected]> >>>> wrote: >>>> There seems to be a lot of confusion surrounding the recently disclosed >>>> CPU hardware issues... >>>> A few points to consider: >>>> 1) This is a cache timing attack using speculative execution (a key >>>> performance feature in the hardware) that exposes data (i.e. it's not an >>>> exploit to "take over" a system); it can only read memory, and only VERY >>>> slowly, while thrashing the heck out of the CPU. >>>> 2) Abusing speculative execution is literally something nobody thought of >>>> doing until a few years ago. >>>> 3) The researchers spent an immense amount of time figuring out tactics >>>> that worked, time no hardware design engineer would ever have had >>>> available, assuming that engineer even had the knowledge to do the coding >>>> required (hint: they don't). >>>> 4) Exploiting these flaws is HARD. It requires native code execution, >>>> careful and highly skilled coding, specific targeting of the memory to be >>>> read, and a lot of time on the target machine without tripping alarms due >>>> to CPU use. >>>> 5) The major concern here is things like VM farms because this allows >>>> untrusted code in a guest to (very slowly) read memory from the host or >>>> other guests. It's possible to use in other contexts, but the >>>> cost/benefit balance is pretty bad; desktops and other targets are far >>>> easier to exploit with well-known and widely used "social" hacks. >>>> Lacking the full detail, I would venture that this *type* of exploit is >>>> possible (in some form) for every Intel CPU since the original Pentium PRO >>>> which introduced speculative execution to the Intel architecture. >>>> We don't need to replace hardware, fortunately, this specific set of >>>> tactics can be mitigated by having the Kernel (along with microcode, aka >>>> firmware) set flags in the CPU to force a full context switch in the >>>> specific situations identified by the researchers. >>>> Yes, mitigation slows down execution a bit; basically the IPC for Intel >>>> chips now roughly matches the IPC for AMD chips which always forced the >>>> context switch (due to a different design balance). >>>> I would venture that this flaw is actually caused by Intel having such a >>>> heavy focus to achieve (and maintain) higher IPC levels than AMD, and >>>> cutting a (seemingly benign) corner to accomplish that. >>>> A bit of inside-baseball here: >>>> Every digital design engineer looks for what we call "don't cares" >>>> segments of the boolean map where the logic value has no impact on the >>>> "correctness" of the result. >>>> Those are places where we can cut gate count or speed up execution. >>>> Avoiding a context switch in a CPU with the Intel design for 3 layer >>>> caching is one of those areas where "don't cares" can show up. >>>> My gut feel is that the Intel engineers saw an opportunity to retain >>>> "correct" execution of code while speeding up speculative execution by >>>> skipping the context switch until it was actually necessary (e.g. the >>>> speculative branch became "live"). >>>> It is exactly the kind of thing I can see a really smart engineer doing >>>> because, without future knowledge, it's actually the right thing to do. >>>> You get faster execution without any added cost and without breaking >>>> existing code. >>>> That, in retrospect, was a mistake that allowed a very sophisticated >>>> attacker to read a few bits of unauthorized memory in a very sneaky manner. >>>> That someone, a decade or two after the design arose, discovered a way to >>>> misuse that design isn't a sign of malice or malpractice; it's a sign that >>>> security researchers are getting REALLY good at finding unexpected ways to >>>> use hardware design against security. >>>> P.S. >>>> That reddit article is utter garbage. >>>> Yes, there is, on some motherboards, a Management Engine which is a >>>> *separate* CPU, is mostly present only on "business" and server >>>> motherboards, and has NOTHING TO DO WITH the recent exploits. The FSF and >>>> others have been warning about that particular bit of hardware for a long >>>> time. >>>> The ME has valuable functionality that makes sense for servers especially, >>>> and for business-owned machines in general (mostly remote system >>>> management, particularly lights-out management). >>>> The ME was added to the system at the request of business customers so >>>> they could remotely access machines owned by the business (even if turned >>>> off) and either manage their servers or ensure the main O/S and >>>> applications were kept in compliance with policy on desktops. >>>> Every motherboard I've seen with an ME (and only some have one) can >>>> disable the ME; usually with a jumper or switch on the board. >>>> As I understand things it was actually government buyers who demanded the >>>> ability to disable the ME (originally it couldn't be disabled), because >>>> government agencies are targets far more often than they are attackers. >>>>> On 2018-01-11 10:36 AM, [email protected] wrote: >>>>> This is basic stuff. Kernel memory must be segregated and each >>>>> application's memory must be segregated. These are the basics of CPU >>>>> functionality. That is why I find theses issues perplexing. And it >>>>> leads me to one basic question. If these problems persisted since 1995, >>>>> how could these issue go undetected until recently when multiple >>>>> separate groups discovered these flows? AND is it possible others have >>>>> found and used these flaws for their own gain? >>>>> No matter what happened, politics, accident... etc We have a HUGE >>>>> problem. Even if there were CPUs that were not vulnerable, it would >>>>> take years to replace all computers that are publicly facing. In the >>>>> mean time there are some seriously evil people / groups / countries that >>>>> will be looking into how they can use theses chip bugs / vulnerabilities >>>>> / features... to further their goals. >>>>>> From what I can tell the solution is to use software - the kernel to fix >>>>> or patch the shortcomings of these CPUs. A software patch to fix >>>>> hardware. This is very scary. A software patch can be removed and / or >>>>> replaced, leaving the host vulnerable. >>>>>> On 2018-01-11 10:10, Mark Phillips wrote: >>>>>> No, I don't work at Intel. I am, however, not a believer in all the >>>>>> government conspiracy theories floating around the Internet. >>>>>> Mark >>>>>> On Thu, Jan 11, 2018 at 9:25 AM, Aaron Jones <[email protected]> >>>>>> wrote: >>>>>> Signals intelligence is believed to have been birthed in 1904. >>>>>> But exploiting hardware isn't new. For military, police, or criminal >>>>>> intentions. >>>>>> You work at Intel Mark? Lol >>>>>> On Jan 11, 2018, at 9:11 AM, Mark Phillips <[email protected]> >>>>>> wrote: >>>>>> There is no conspiracy here. 23 years ago no one thought about attack >>>>>> vectors and how to take over machines. It is only recently that we are >>>>>> all sensitized to this problem. Even though the tech world is sensitized >>>>>> to the nature of exploits, companies still ship brand new products (e.g. >>>>>> Nest, cars, etc.) that can be exploited by almost anyone. It was only >>>>>> recently that router and switch companies stopped using admin and admin >>>>>> as login credentials! >>>>>> Your argument that these new CPU exploits are a government conspiracy >>>>>> can be applied to any potential exploit discovered today in a piece of >>>>>> code written yesterday. >>>>>> Mark >>>>>> On Thu, Jan 11, 2018 at 9:02 AM, Carruth, Rusty >>>>>> <[email protected]> wrote: >>>>>> As mentioned earlier, I've done my share of ... um, looking for flaws in >>>>>> design of operating systems back when I was in college. (What, 1976?) >>>>>> We discovered some bad flaws in the design of the <redacted>. How long >>>>>> had the Univac been around? I don't know, but a while. Unless someone >>>>>> with WAY too much time on their hands is actively seeking ways around >>>>>> stuff, there's only so much 'bug' you can find. (and, actually, you >>>>>> really need more than one person involved (partially so someone can ask >>>>>> the 'right' stupid question :-)) >>>>>> Doesn't take malice or sloppiness, and I will say being a >>>>>> publicly-traded company makes it very hard to spend the time required to >>>>>> even start on the hacking required (Being publically-traded makes your >>>>>> owner effectively insane, since your owner is actually many people, all >>>>>> with different and often diametrically opposing goals for the company). >>>>>> Anyway, tell you what - go read the Intel hardware docs and see if you >>>>>> can find the info needed to put together to see the bug. And this with >>>>>> prior knowledge of where to look. >>>>>> I will say that this doesn't excuse much, but realize that being a >>>>>> public company drives you insane ;-) >>>>>> Rusty >>>>>> -----Original Message----- >>>>>> From: PLUG-discuss [mailto:[email protected]] On >>>>>> Behalf Of [email protected] >>>>>> Sent: Thursday, January 11, 2018 8:42 AM >>>>>> To: Main PLUG discussion list >>>>>> Subject: Re: Post : INTEL'S SECURITY FLAW IS NO FLAW >>>>>> ... >>>>>> I've read these issues may have persisted as far back as 1995. How does >>>>>> that happen? How does an army of engineers miss this for 23 years? How >>>>>> do you explain that? >>>>>> That means lots of people came and went. There should have been lots of >>>>>> QA... for 23 years. >>>>>> How does this happen? Only two ways I can see 1) sloppy work, or 2) >>>>>> intentionally. > <0x241A8881.asc> > --------------------------------------------------- > 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
