[Info-vax] Intel x86-64 Processor Design Security Vulnerability?

[Jan-Erik Soderholm]

Den 2018-01-04 kl. 21:17, skrev DaveFroble:
> Arne Vajhøj wrote:
>> On 1/4/2018 9:25 AM, DaveFroble wrote:
>>> Camiel Vanderhoeven wrote:
>>>> Op donderdag 4 januari 2018 11:26:28 UTC+1 schreef Johann 'Myrkraverk' 
>>>> Oskarsson:
>>>>> already5chosen at yahoo.com wrote:
>>>>>> There are two new methods of attack - Spectre and Meltdown.
>>>>>> Separate page tables only help against Meltdown.
>>>>> For people coming late to the party and aren't fully in on the
>>>>> difference between the two, this is Meltdown:
>>>>>
>>>>> https://twitter.com/misc0110/status/948706387491786752
>>>>>
>>>>> Spectre is harder to exploit, but also harder if not impossible
>>>>> to completely patch in software.
>>>>
>>>> Correct. Meltdown is easier to exploit, and enables data leaks across 
>>>> the user mode - kernel mode barrier. This can be patched in the OS. 
>>>> Spectre is much harder to exploit, and leaks data across the barrier 
>>>> between different processes' user mode (and possibly even from kernel 
>>>> mode, but that hasn't been proven). Absent a hardware fix, Spectre 
>>>> would require changes to pretty much any and all code - both OS and 
>>>> application - to mitigate. Just patching the codepaths that deal with 
>>>> sensitive information would not be enough; all code in the 
>>>> process-to-be-protected' working set would need to be patched.
>>>
>>> This is all very interesting, and I don't have a clue about how to 
>>> actually perform such exploits, nor do I care to know.  However, I think 
>>> there is still one thing that is essential in performing any such 
>>> exploits.  One would first need access to the machine.
>>
>> Yes.
>>
>> But:
>> 1) Some systems run multiple applications for multiple users.
>> 2) Even for single application/user context it is bad, because
>>    it reduces defense in depth - if the bad guys get in without
>>    privs then they can use this to get further in
>>
>> Arne
>>
>>
> 
> Ayep, which is why we're all keeping our systems as secure as we can, right?
> 
> There are things an architect can do to protect the important things.
> 
> For example, I seem to recall mentioning running web servers on separate 
> systems.  These systems have nothing of value on them.  They have static 
> data that is provided by the VMS system(s), using service(s).  They can 
> take customer orders, but then again pass that data to service(s) on the 
> VMS system(s).  At no time is anyone from outside actually running on the 
> VMS system(s).
>

What has a web server to do with "anyone from outside actually running on
the VMS system"? Just becuse a system has web server doesn't give anyone
a way to run their own code. You also need a bug or similar in the web
server. In that way it is no different than any other software package.



> Make it as tough on the bad guys as you can.
> 
>