Re: Post : INTEL’S SECURITY FLAW IS NO FLAW

[Nathan O'Brennan]

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 
>>> <plug-discussion at stcaz.net> 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, techlists at phpcoderusa.com 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 <retro64xyz at gmail.com> 
>>>>> 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 
>>>>> <mark at phillipsmarketing.biz> 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 
>>>>> <Rusty.Carruth at smartm.com> 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:plug-discuss-bounces at lists.phxlinux.org] 
>>>>> On Behalf Of techlists at phpcoderusa.com
>>>>> 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.
>>>>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x241A8881.asc
Type: application/pgp-keys
Size: 1723 bytes
Desc: not available
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20180112/7cbf7c3d/attachment.key>