Re: [PLUG] It's the final meltdown!! (Security vulnerabilies)

[Aaron Mulder <ammulder@alumni.princeton.edu>]

On Sun, Jan 7, 2018 at 9:40 AM, Paul Walker <pjwalker76@gmail.com> wrote:
> I have a question: Is this vulnerability the unforeseen outcome of a
> particular design choice, or is it a particularly nasty example of "code and
> fix"?

So one of the issues goes sort of like this:
* CPU can't tell what sequence of operations is coming next, but it
has some free time, so it takes a best guess
* CPU charges ahead with operations based on that guess, at least
doing something potentially useful in its free time
* CPU later discovers its guess was wrong, and discards all the work it did

That seems pretty reasonable -- if the guess was right, then it would
not have discarded the work, and would have been way ahead compared to
if it had just waited doing nothing the whole time.  In the cases
where it was correct, it makes the whole system faster.

The problem is that when the CPU discovers its guess was wrong, it
doesn't *completely* erase all traces of the work it did on the basis
of the guess -- in particular, if data was loaded from main memory
into the high-speed cache memory, it is left there.  This isn't
obviously a problem -- the value in the cache is valid (it accurately
reflects the corresponding value in main memory) -- it just wouldn't
have been there without the guess taking place.

The hack, then, is to manipulate the cache state and instructions fed
to the CPU such that you force it to make a bad guess, and the mere
presence of a certain value in the cache after the guess reveals a bit
of kernel memory.  The instructions amount to, if bit N of kernel
memory is 1, load line A into the cache, otherwise load line B into
the cache.  The CPU makes the bad guess and does the work, and then
discards the work, but leaves either line A or line B in the cache.
Then you try to load the value for line A.  If it loads fast, line A
must have been in the cache, therefore the bit of kernel memory must
have been 1.  If line A loads slow but line B loads fast, then line B
was cached and the bit of kernel memory must have been 0.  Try enough
times, and you can read a significant amount of kernel memory.

There are defenses: you could have established that the bad guess was
leading into kernel memory before allowing it to proceed (AMD,
presumably slower), instead of only checking if the guess turned out
to be correct (Intel, presumably faster).  You could have cleared out
the cache lines loaded by the bad guess once you established that the
guess was wrong.  Browsers defend against the JavaScript version by
just reducing timer resolution, so you can't effectively time the
difference between a cached value and a non-cached value.  I imagine
there are other options too.

But someone would have had to realize there was the possibility of
such an attack in order to consider defending against it.  :)

Thanks,
       Aaron

> On Sat, Jan 6, 2018 at 3:06 PM, Ronald Guilmet <ronpguilmet@gmail.com>
> wrote:
>>
>> I would trust a company like AWS, Azure or Google which has a government
>> sector as well for security before I would trust a not uptodate tech at a
>> local data center any day of the week.
>>
>>
>> On 1/6/2018 2:40 PM, Rich Kulawiec wrote:
>>>
>>> On Thu, Jan 04, 2018 at 11:27:28AM -0500, John Von Essen wrote:
>>>>
>>>> Hence another reason not to use the cloud for critical stuff or
>>>> sensitive data. Cloud is great for little web sites of content, but
>>>> super sensitive data should be on your own hardware.
>>>
>>> This was true long before the current kerfluffle and it will remain
>>> true indefinitely.  "Cloud security" is an oxymoron.
>>>
>>> ---rsk
>>>
>>> ___________________________________________________________________________
>>> Philadelphia Linux Users Group         --
>>> http://www.phillylinux.org
>>> Announcements -
>>> http://lists.phillylinux.org/mailman/listinfo/plug-announce
>>> General Discussion  --
>>> http://lists.phillylinux.org/mailman/listinfo/plug
>>
>>
>>
>> ___________________________________________________________________________
>> Philadelphia Linux Users Group         --
>> http://www.phillylinux.org
>> Announcements -
>> http://lists.phillylinux.org/mailman/listinfo/plug-announce
>> General Discussion  --
>> http://lists.phillylinux.org/mailman/listinfo/plug
>
>
>
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
>
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug